2020/8/4 - 読み終える時間: 2 分

HCL Accelerate は、バリュー・ストリーム・チェーンとそのボトルネックを可視化して、生産性を高めるソフトウェアです。その解説記事 Bottlenecks in the Value Stream の翻訳版です。

バリューストリームにおけるボトルネック

2020年7月29日

著者: Matthew Steele / Data Scientist

さて、バリュー・ストリーム管理システムがすべてセットアップされたとしましょう。あなたはモニター画面を通して、アイデアの創造から、それが組織から価値を提供する瞬間までを追跡しています。つまり、バリュー・ストリーム・メトリクスを監視しているのです。なんと素晴らしいことでしょう!

では、次は何をしますか？次は、バリューストリームのボトルネックを見つけてください。この記事では、バリュー・ストリームのボトルネックについて考察し、ボトルネックがバリュー・ストリームから効率性を奪う前に、HCL Accelerate を使用して、ボトルネックの出現を検出して緩和する方法を説明します。

なぜボトルネックを追跡するのか

バリューストリーム管理の取り組みから利益を得る最善の方法の1つは、バリューストリームのワークフローのボトルネックを見つけることです。 ボトルネックは、整備されたソフトウェア開発マシンから効率を奪います。バリューストリームのボトルネックを特定して修正することで、プロセスやワークフローの不調や非効率を、多額のコストが発生する前に回避または排除することができます。幸いなことに、HCL Accelerate のようなバリューストリーム管理ツールは、ボトルネックを発見するために必要なデータと、ボトルネックの効率性を損なう結果を回避するためのインテリジェントなモニタリング機能の両方を提供します。

ボトルネックとは

少し形式的な話をしましょう。ボトルネックとは、システムのグローバルなスループットを制限するローカルスループットの制限です。言い換えれば、バリューストリームは、バリューストリームの中で最も制約を受けている部分よりも、与えられた時間内に多くの作業を処理することができません。均一なワークロード（すべてのワークアイテムが同じで、等間隔でシステムに入る）を持つシステムの場合、期待されるスループット（ローカルまたはグローバル）は、期待される処理時間（1 単位のワークを処理するのにかかる時間）に対する処理能力（何個のアイテムを並列に処理できるか）の比にすぎません。このような均一なシステムでは、ボトルネックを見つけるのは簡単です。

キャパシティと予想される処理時間を知ることは、非一様なワークロードでも重要ですが、ボトルネックを見つけるのは実世界のワークロードでは困難です。 ソフトウェア開発のバリューストリーム内のすべての作業が同じように作成されるわけではありません。作業項目によって完了までに必要な作業量が異なり、作業項目には相互に関連した依存関係があり、それらがバリューストリームをどのようにナビゲートするかを決定します。 これらの考慮事項はすべて、キャパシティ／処理時間の分析から明らかになる以上に、一時的なボトルネックを発生させる可能性があります。現実のボトルネックは複雑ですが、幸いなことに、適切なデータがあれば、バリューストリームのボトルネックを発見し、修正し、最終的に防ぐことができます。

ボトルネックを見つけるには

ソフトウェア開発の多くの取り組みと同様に、バリューストリームのボトルネックを発見するための取り組みは、基本的なことを見落とさないように、簡単なことから始めるべきです。バリューストリームのどのプロセスでも、常にリソースが不足していないか？バリューストリームのプロセスの中には、バリューストリームのリードタイムに比べて処理時間が長いものがありませんか？この答えをすでに知っていて、キャパシティと予想される処理時間のボトルネックを積極的に緩和するための手順を持っているかもしれません。もしそうでない場合は、データを入手して、これらのシステム的なボトルネックがバリューストリームを遅らせていないかどうかを確認してください。バリュー・ストリームの各プロセスの段階内時間は？各ステージの平均負荷はどれくらいで、それらの負荷に対応するためにどのようなリソースが使われていますか？幸いなことに、HCL Accelerateは、これらの質問に答えるためのデータだけでなく、容量/処理時間のボトルネックを可視化するためのツールへの自動監視とアラートも提供します。

単純なキャパシティ／処理時間のボトルネックを超えて、プラクティスの方法論によってもたらされるボトルネックに遭遇します。私たちは、グローバルなバリューストリーム効率への影響を考慮せずに、特定のタスクのローカル効率を最大化するために開発手法を選択することがよくあります。例えば、トランザクションのオーバーヘッドとコンテキストの切り替えコストを削減するための一般的なプラクティスの1つは、特定の付加価値の高い作業をバッチで処理することです。バッチ処理は、それが採用されている付加価値作業全体の効率を高めることができますが、下流への継続的な流れを阻害することで、バリューストリームの全体的な効率を低下させる可能性もあります。バッチングプロセスの下流のステージでは、使用率不足と過剰供給が交互に発生し、最適な効率で作業する能力が大幅に低下する可能性があります。なぜなら、ボトルネックは局所的に最適化された付加価値プロセスによって発生する可能性があるため、ボトルネックを発生させているステージのバリュー・ストリーム・メトリクスを見ると、すべてが素晴らしいものに見えるからです。けれども、各ステージのフローパターンと、そのパターンが下流プロセスにどのような影響を与えているかに注目する必要があります。時系列スループットの頻繁なスパイクや谷は、実践方法論によって導入されたボトルネックの主要な指標となります。HCL Accelerate は、すべてのバリューストリームのグローバルおよびローカルのスループットを追跡し、実践方法論がバリューストリームにボトルネックが発生している場合には、ユーザーにアラートを提供します。

次に検討するボトルネックのタイプは、ソフトウェア開発のバリューストリームの特徴的なボトルネックである、不均一な作業負荷のボトルネックです。ソフトウェアでは、すべての作業が同じように作成されるわけではありません。同じウィジェットを製造しているわけではなく、複雑で創造的な作業に従事しているのです。ソフトウェアの仕事には、仕事の複雑さ、開発リソースの要件、価値の流れへの流入に固有の不均一性があります。つまり、バリューストリームのキャパシティと処理時間が完璧にバランスが取れていて、すべての実践方法論がグローバルにもローカルにも最適化されていたとしても、ボトルネックが発生する可能性があり、また発生する可能性があるということです。システムを通る不均一な流れは、個々のステージで定期的にキューを発生させたり、他のステージの作業アイテムを枯渇させたりして、バリュー・ストリームのスループットを低下させます。幸いなことに、バリューストリームのステージ負荷とスループットのボトルネックを注意深く監視することで、不均一なワークロードによって発生するボトルネックを、バリューストリームに大きなコストが発生する前に検出し、緩和することができます。さらに HCL Accelerate は、何を監視すべきかを既に知っており、不均一なワークロードのボトルネックが発生し始めると、ユーザーを検出して警告することができます。

ボトルネックを修正するには

バリューストリームでボトルネックがどのようにしてどこで発生するかを知ることは、ボトルネック緩和の最も困難な部分です。ボトルネックが発見されず、バリューストリームの効率性を奪ってしまうことがあっては、ボトルネックは問題となりません。バリュー・ストリームとワークフローのメトリクスを手動で検査する日常的かつ体系的な方法、または HCL Accelerate が提供するような自動化されたモニターとアラート・システムのいずれかが、ボトルネックの脅威と戦うための最良の前線の武器となります。Once you’ve found the bottlenecks, you’ll likely find the tools for mitigating them are already in your software development toolkit. (訳不明瞭)。

処理時間が長いために、バリューストリームのステージがボトルネックになっていないか？プロセスを自動化または合理化できる部分があるかどうかを確認してください。

1つのステージでのバッチ処理が下流の流れを阻害していませんか？より小さく、より頻繁なバッチを検討するか、またはバッチングをすべて廃止することを検討します。

不均一な作業負荷がバリューストリームに大混乱をもたらしていませんか？チームのスキルセットに柔軟性を持たせることで、コストが発生する前にリソースを再配分してキューをクリアできるようにしましょう。

HCL Accelerate を持っているとがわかります。どこで、なぜ、いつボトルネックが発生するのかを。それを知ることで、効果的な効率性節約の緩和を実践することができます。HCL Accelerate の検出およびアラートシステムがボトルネックを発見することで、お客様のチームは、効率的で効果的な価値の流れの中でソフトウェアを開発することができるようになります。

2020/8/4 - 読み終える時間: 6 分

HCL AppScan のダイナミックスキャンをより効率的に実施するための機能、「HCL AppScan アクティビティレコーダー」の解説記事 A Closer Look at HCL AppScan Activity Recorder 's Features and Usage の翻訳版です。

HCL AppScan アクティビティレコーダー の機能と使い方の詳細

2020年7月27日

著者: Vinita Sanghi / Engineering Manager at HCL AppScan

こんな経験はないでしょうか。Web アプリケーションの新バージョンをステージングにデプロイ後、ダイナミックスキャンを実行して、セキュリティの脆弱性を把握しようとして Web サイトを開いたものの、「変更点に関するものの操作を記録して、短時間でダイナミックスキャンで検査が完了できればいいのに」と思ったこと。

他の製品を見る必要はないでしょう。HCL AppScan は、それに最適なソリューションを提供します - HCL AppScan Activity Recorder Chrome ブラウザ拡張機能です。この小さなユーティリティを使用すると、ウェブサイトからのトラフィックとアクションを記録し、それらの記録を、選択した AppScan ダイナミック分析ツール（ HCL AppScan Enterprise または HCL AppScan Standard）にアップロードすることができます。記録は、ログイン・シーケンスまたはマルチステップ・データのいずれかにすることができます。また、HCL AppScan On Cloud (ASoC) ユーザーの方にもご用意ができています。ASoC では、AppScan Activity Recorder を介して記録されたログイン・シーケンスをアップロードして、ダイナミック・スキャンを行うことができます。

では、Chrome 拡張機能についての理解が深まったので、簡単なインストール方法と使いやすい機能をご紹介します。

インストール

AppScan Activity Recorder を Chrome ブラウザにインストールするには、以下の手順を実行します。

1. Chrome ウェブストアで「 AppScan 」を検索します。下のスナップショットに示すように、検索結果が表示されます。

または、AppScan ツールには、AppScan Activity Recorder をインストールするための Chrome ウェブストアへのリンクも含まれています。AppScan Enterprise と AppScan on Cloudのスナップショットは以下のように表示されます。

1. Chrome ウェブストアのリンクで、「 Chrome に追加」をクリックします。
2. 以下のようなメッセージが表示されます。パニックにならないでください。お使いのソフトウェアに害が及ぶことはありません。拡張機能の追加」をクリックします。

3. インストールが成功すると、右上のアドレスバーに小さな HCL AppScan アイコンが表示され、以下のようなメッセージが表示されます。

4.アイコンが表示されない場合は、「拡張機能」アイコンをクリックして、AppScan Activity Recorder をピン留めすると、アドレスバーに拡張機能のアイコンが表示されるようになります。

使用方法に進む前に、覚えておくべきことがいくつかあります。

• 拡張機能の管理」に移動し、「シークレットで許可」オプションを有効にすることで、シークレットモードでの動作を有効にすることができます。
• オプションといえば、AppScan Activity Recorder には、別のデバッガウィンドウでアクティビティを表示するオプションが含まれています。拡張機能を右クリックして「オプション」を選択するだけです。オプションにチェックを入れて保存をクリックします。このブログの残りの部分では、このオプションはチェックを外したままにしておきます。

使い方

AppScan Activity Recorder の使用を開始するには、以下の手順に従ってください。

• スキャンする必要のあるウェブサイトのページに移動します。
• AppScan Activity Recorder のアイコンをクリックします。記録が開始されたことを示すために点滅し始めるはずです。このブログでは、デモサイトのtestfire.netを使用しています。

3. 上のメッセージにドメインURLが表示されていることに注意してください。これは、同じブラウザウィンドウで複数のウェブサイトを開いていて、どのウェブサイトを録画しているのか忘れてしまう可能性がある場合に便利です。

4. 手動クロールを開始し、AppScan Activity Recorder に作業を任せます。

5. ブラウジングが終了したら、以下の方法で録画を停止することができます。

   • 点滅しているアイコンをクリックします。
   • ブラウザウィンドウで「キャンセル」をクリックします。

6. 録画を停止すると、録画を dast.config に保存するように促されます。この形式は、すべての AppScan ツールで認識されるため、選択されています。ファイル名には、参照用にドメインと現在のタイムスタンプが含まれています。必要に応じて自由に変更してください。例えば、ログインシーケンスファイルには、使いやすさのためにログインタグを追加することができます。

7. 好奇心旺盛な方のための追加ステップ。記録を確認したい場合は、保存されたファイルを解凍して、同封されている内容をコピーペーストしてください。私のお勧めは、Online JSON Viewer を使用することです。

AppScan Activity Recorder のデバッグオプション

以前にデバッグオプションについてお話したのを覚えていますか？このオプションは AppScan Activity Recorder に追加され、クッキーやアクション、ヒットしたリクエストを記録することでブラウジング活動を見ることができるようになりました。

デバッグオプションを有効にするとどうなるか見てみましょう。

記録を開始するとすぐに新しいウィンドウがポップアップし、アクションを記録しながら記録を終了するオプションが表示されます。

注意点としては、デバッグオプションを有効にすると、拡張機能のアイコンが点滅しなくなることです。これはバグではありませんが、設計上の制限と考えることができます。しかし、これは録音を完了して保存することを妨げるものではありません。保存時には、デバッグウィンドウを自動的に閉じないようにしています。これは設計上の制限ではなく、自分のペースでデータを見られるようにするための設計上の配慮です。グレーアウトされた情報に気づいた場合、それはフィルタリングされたレスポンスであり、シーケンスファイルには表示されません。

この時点で、AppScan Activity Recorder を使用して、選択した AppScan ツールでトラフィックとアクションを記録する準備が整いました。

HCL AppScan Enterprise での AppScan Activity Recorder の記録の使用

HCL AppScan Enterprise は、大規模、マルチユーザー、マルチアプリの動的アプリケーションセキュリティテスト（DAST）ツールで、脆弱性の特定、理解、修正を行い、規制遵守の実現を支援します。動的テストのニーズに合わせてコンテンツスキャンとADACジョブを設定することができます。

AppScan Activity Recorder を介して記録されたログインシーケンスとアプリケーションの探索データファイルは、コンテンツスキャンとADACジョブの両方に対応しています。さらに、AppScan Enterprise UIや REST API を介したインポートにも対応しています。どのようにしてですか？詳細については、ここに示されている詳細な手順に従ってください。

インポートが成功すると、コンテンツスキャンジョブの場合、以下のように手動で探索されたURLが表示されます。

HCL AppScan on Cloudでの AppScan アクティビティレコーダーの使用

HCL AppScan on Cloud (ASoC) は、動的および静的な手法を用いてWeb、モバイル、デスクトップアプリケーションをスキャンすることができる、あらゆるアプリケーションセキュリティテストのニーズに対応したSaaS型ソリューションです。ASoC は、そのすべての機能を可能にするWeb UIを備えています。このWeb UIを介して動的スキャンを作成している間に、AppScan Activity Recorder を使用してログインシーケンスを記録し、ASoC がスキャン中にアプリにログインする必要があるときにいつでも使用できるようにすることができます（下のスナップショットに示すように）。

ASoC はこの機能を REST API でも公開しています。ASoC は、統合を容易にするために、/api/v2/Scans/DynamicAnalyzer という REST API でこの機能を公開しています。

結論

要約すると、AppScan Activity Recorder は、あなたの記録ニーズに役立つ効果的なツールです。この拡張機能を使用して、Chrome ページのレビューセクションからご希望の機能や強化点をすべてお知らせください。クラウド上の HCL AppScan をテストドライブするには、HCL Software の無料トライアルページをご覧ください。

2020/8/4 - 読み終える時間: ~1 分

HCL Accelerate は旧 UrbanCode Velocity という製品で、多種多様なツールを使用する DevOps の現場において価値を高める製品です。具体的には、可視性の向上、ボトルネックの特定、DevOps の有効性測定により、リスクを軽減して、チームが変革を推進し、より良い意思決定を行えるよう支援します。さらに、組織全体の DevOps フローの改善により DevOps への投資効果を最大化します。

「バリューストリーム管理」は聞き慣れない言葉かもしれませんが、付加価値を高めていく上で非常に重要な視点です。これについて書かれた英語版ブログ Mitigating Risk with Value Stream Management の翻訳版です。

バリューストリーム管理によるリスクの軽減

2020年7月27日

著者: Bryant Schuck / Product Manager for HCL Software DevOps

今年はパンデミックの影響で、家族で休暇を取ることにしましたが、飛行機ではなく車で行くことにしました。他の大切なことのほとんどと同じように、どこにどのくらいの期間行くのか、そして何をして家族で仲良く過ごすのかについて考えるのに多くの時間を費やし、ノースカロライナ州の島へ行くことを決めました。マップアプリは所要時間が 10.5時間 と、非常に合理的な時間を示したのに対して、。私は12-15時間かかると考えておく必要があることを妻に話しましたが、妻は 11 時間でいいだろうと言い張りました。しかし実際には 15 時間もかかってしまい、フラストレーションと失望で終わったのでした。何が起こったのでしょうか？10.5時間よりも15時間前後になるだろうと予測できたでしょうか。1 歳未満の赤ちゃんがいること、人気のあるバケーションスポットに向かって海岸沿いをドライブしていたこと、出発時間が正確ではなかったこと、事故や交通渋滞で遅れてしまったこと、などなど。Googleマップ上で時間を確認する場合, 旅行時間は、その日のその時間帯における各エリアのトラフィックパターンを考慮に入れる必要があります。

私たちはソフトウェアでも同じような問題に遭遇します。アジャイルや類似の方法論が人気の理由は、リスクの少ない小さな時間単位でリスクを減らそうとしているからです。上の私の休暇の例えを使うと、10 分のドライブは 10 時間のドライブよりもずっとリスクが少ないのです。

ソフトウェアのライフサイクルは開発だけではありません。そこで、アイデアから価値に至るまでのリスクを軽減するために、バリュー・ストリーム・マネジメントの出番です。私たちは皆、なぜ機能 X は失敗したが、コードは完成したのだろうかと疑問に思う会議に参加したことがあります。品質、セキュリティ、コードカバレッジなどに問題があったのかもしれませんが、何らかの理由で、そのアイテムを顧客に展開するにはリスクが大きすぎたのです。当社のバリュー・ストリーム管理プラットフォームである HCL Accelerate は、ソフトウェアの所要時間に関するすべてのメトリクスを可視化し、チームのアウトプットをより予測可能なものにすることで、リスクを管理することを可能にします。

HCL Accelerate を使用することで、ビジネスは新機能を要求することができ、技術チームはリスクについてより良い予測をすることができます。例えば、リードタイムが 25 日であるチームの例を見てみましょう。チームは、コードの品質が平均以上であること、セキュリティスキャンが自動的に実行されていること、そしてすべてのメトリクスが、これが与えられた範囲内で妥当なコミットであることを示していることを確認することができます。さて、もしその機能が平均よりも低いコードカバレッジを持ち、セキュリティスキャンをサードパーティに送る必要があり、ビルドに欠陥があるアプリケーションにあったとしたら、チームはリスクのためにその機能のための期間を長くすることを要求しなければならないかもしれません。

重要なのは、会話をしたり、リスクを管理したりできるように、すべての情報を手元に置いておくことです。もはや「コードが完成した」ということだけではありません。重要なのは、「顧客に価値を提供できたかどうか」ということです。私たちのツールとプロセスは、このような考え方にマッチしていなければなりません。それが、HCL Accelerate が単なるマッピングだけではなく、アイデアから価値への道のりについてのものであり、チームが関連するすべてのデータを克服し、より良い統一性を持つことができるように支援します。

HCL Accelerate を無料でダウンロードして、バリュー・ストリーム・パイプラインの構築を今すぐ始めてみてはいかがでしょうか。

2020/7/29 - 読み終える時間: ~1 分

「何でもどこでもデプロイ」ツールである HCL Launch。高速デプロイについて、英語版ブログ Making upgrades easier in HCL Launch の翻訳版です。

アップグレードを容易にする HCL Launch の機能

2020年7月24日

著者: Max Bellin Warren / Software Developer

HCL Launch は、デプロイをスムーズに実行し、生活を楽にするための多くの機能を備えています。v.7.0.4 で私が気に入っている最近の機能強化の1つは、自動化プラグインのアップグレードの変更です。

過去には、HCL Launch サーバーを最新バージョンにアップグレードするのは非常に時間がかかりました。サーバーのアップグレードは、多くのプラグインを更新し、ひいては多くのプロセスを更新することになります。これには何時間も、時には何日もかかることもありました。

今、私たちは HCL Launch のアップグレードプロセスを超高速になるように再構成しました。一度にすべてを更新するのではなく、プロセスやプラグインは使用するたびにその場で更新されます。これにより、アップグレード後に初めて HCL Launch サーバーを起動したときに、アップデートが終わるまで何時間も待たされることなく、すぐに作業に取り掛かることができるようになりました。

これは、以前はアップグレードを実行するためにサーバーのダウンタイムを設定しなければならなかった管理者にとってはゲームチェンジャーです。今では、サーバー管理者はよりリラックスして、より迅速なアップグレードを体験できるようになりました。この余分な時間で何ができるか想像してみてください。

エンドユーザーは、プロセスにわずかな違いを感じることでしょう。この機能強化の前は、プラグインの更新ごとに新しいバージョンのプロセスが生成され、サーバーを停滞させ、作業の速度を低下させていました。今では、すべてのプロセスは、それに関連付けられた自動化プラグインの最新バージョンを自動的に使用します。初めて、古いプロセスのバージョンは、スナップショットであっても、プラグインの最新バージョンを利用することができるようになりました。当社のプラグインはすべて下位互換性があるので、これらのプラグインの自動更新によって業務の流れが中断されることはありません。

私たちは、「何でもどこでもデプロイ」ツールである HCL Launch をより使いやすくする方法を常に探しています。機能や機能強化のための提案があれば、ぜひお聞かせください。

2020/7/27 - 読み終える時間: 3 分

原題は Going Inline with Domino Views という記事です。「Domino ビューにはインラインだよ」というニュアンスだと思います。別のニュアンスも感じ取れますが、自分はネイティブではないので確信はありません。内容的にはビューのインライン更新機能についてです。

Domino ビューのインライン更新機能

2020年7月23日

著者: John Curtis / Domino Core Application Team Lead

私は長年にわたって Notes Indexing Facility (NIF) の奥深くで作業をしてきました。初期の Domino 開発者が最初の日からしっかりとバンドルされた豊富な機能からは、まだまだやるべきことがあり、収穫するべきことがあるからです。非常に多くの多様なデータがコードを通ってガラスの上に流れてくるので、これは挑戦的な領域である可能性があります。注意を怠ると、あるユーザーのストーリーを喜ばせる一方で、別のユーザーのストーリーはそれほどでもないものになってしまいます。

NIF で最も問題となる操作の1つは、更新の処理です。誰かが「じゃあ、何が問題なの？他のデータベース製品はインデックスの更新に問題はありませんが、Dominoはなぜ違うのでしょうか？Dominoはなぜ違うのでしょうか？その答えは、Designer でのビューやフォルダの作成の容易さにあります。ビューは常に数と複雑さを増していくというのはよくある話です。

そこで、私はよくこのように違いの質問に答えます。「あなたがMySQLやOracle、DB2やMongoDBの管理者のところに行って、データベースに 200～1000 個のインデックスを要求したら、彼らは何と言うでしょうか？」もちろん、彼らはあなたを笑い者にするでしょう。しかし、Domino データベースではインデックスの数はごく普通のもので、それが怠惰に更新されたり、スケジュール通りに更新されたり、トリガーや強制的に更新されたりする理由です。更新/更新のルールには様々なものがありますので、ここでは触れません。

NIF で最もコストのかかる問題のいくつかは、更新のための過度のキューイングに起因しています。APIや文書のほとんどは、ユーザーがビューを開いて最新の更新を見たいときに「リフレッシュ」と呼んでいますが、これは完全に理にかなっています。問題は、多数のユーザー（まあ、スレッド）が一度にそれを行うとき、彼らはそれぞれが 「公正な読み書き (fair read/write)」キューでビューを更新する権利を競います。つまり、読みたいだけの人は書き手よりも優先されません（私たちは更新を飢えさせることはありません）。その結果、サービスレベルアグリーメント（SLA）のタイミングに違反し、ビューを開くのに時間がかかりすぎてしまうことがあります。

以下は、SPR JCUS8MXLA2 用にまとめた図です。この中には、スケジュールされた専用のビュー更新を表す「更新タスク」が含まれています。

ご存知ないかもしれませんが、v9.0.1 Feature Pack で、Domino の開発者はこの問題を攻撃するための機能をひっそりと開発していました。これは「インラインビュー更新」あるいはシンプルに「インライン」と呼ばれています。この機能は以下のコマンドで有効/無効にできます。

load updall <データベース名> [-T <ビュー名>] -inline on/off

これが何をするかというと、文書更新時にビューの更新を適用することです。そのため、ビューオープン時のすべてのリフレッシュ要求は、そのまま「nops」として扱うことができます。文書の更新はより重い作業単位になりますが、ビューのオープンと読み込みのパフォーマンスのトレードオフはそれだけの価値があります。

Domino V10では、使用率の高いビューを検出して自動的に専用の更新スレッドを作成するという2つ目の取り組みが開始されました。これは notes.ini の NIF_VIEW_USAGE_ENABLED=1 で有効になっています。

私は最初の取り組みである-inlineの効果を測定したかったので、この夏、HCL Chelmsford で（まあ、COVID-19のために自宅で）、Dominoコアのインターンである Joseph Calles と一緒に仕事をするという特権を得ました。私は Joseph に、-inline のオンとオフを使って実際のタイミングを提供することの探求をお願いしました。彼は、3つのビューを持つ 200K の文書のデータベースに対して、読み込みと更新の負荷を変化させるスクリプトを書き、Domino コンソールで "show trans" を使って統計を収集しました。Joseph 氏は、文書の更新とビュー操作の上限を10/秒に設定しましたが、もちろん、あなたの数値は、ボリューム、データ量、使用するハードウェアに応じて変化します。

誰もこれらの数字が現実のものであると主張していません、データと処理は自動化されています。しかし、彼らは収集されたセットとの相対的な一貫性があります。また、インラインの使用を検討する際に知っておくべき傾向を示しています。テスト負荷の分散は単純なものでした。

OPEN_COLLECTION トランザクションは、インラインがオフのときにビューを更新しようとするときの負荷を下げるものです。その利点は最初のグラフを見れば一目瞭然で、インラインがないとビューを開く時間が直線的に増加するよりもはるかに速くなることに注目すべきです。これが、私が言及したログジャムです。

2つ目のグラフでは、ビューを開いている時間とビューを読んでいる時間を組み合わせて、1つの時間を提供しています。これは、ユーザーがビューを開いて最初のウィンドウのエントリがレンダリングされるまでの時間に近いものです。ここでも、-inline を使用しないトランザクションの数が多くなるとスパイクが発生することは明らかです。

今では、800 ミリ秒のレスポンスで SLA に違反することはほとんどありません。繰り返しになりますが、ポイントは曲線です。ビューを開くための最大時間を表示すると、実際にはほとんどのSLAに違反するであろう、不規則で最悪のケースのユーザー体験を示しています（このグラフでは、時間は秒単位で表示されていますのでご注意ください）。

ウソのない宣伝 (Truth in advertising): 文書の更新時間は -inline をオンにすると増加しますが、それを期待するでしょう。そして、指数関数的に増加するのではなく、直線的に増加します。しかし、これをスループットの低下と混同しないでください。

この最後のグラフは、更新、検索、ビューのオープン、ビューエントリの読み込みなど、すべての操作を等しく扱い、それらの合計時間を平均化しています。つまり、インライン処理の全体的な持続時間の影響を表しています。

しかし、元々のユースケースを覚えておくことは重要です。複数のユーザーがビューを開いて読もうとしていますが、最初に「リフレッシュ」（更新）を行います。複数のユーザがビューを開いて読もうとしますが、最初に「リフレッシュ」（つまり更新）を行います。 -inline をオンにすると、読まれているビューは NSFNoteUpdate 操作中に更新されるので、リフレッシュ操作は不要です。そのため、これらのビューのオープン操作ははるかに軽量化されます。

繰り返しになりますが、この動作はトランザクション中心のデータベースシステム、特にデータがきちんとした四角形の中に存在するリレーショナルシステムでは「普通」です（少し進歩しています）。しかし、Domino では、文書の格納と処理を行う NoSQL エンジンである Domino では、非常に多くの異なるインデックスをサポートしており、インデックスデータを非常に多くの異なる方法で構築しているため、多くの場合、遅延更新モデルが適切なものとなります。そして -inline 機能は、それが適切でない場合に対処します。

ですから、もしあなたが競合するビューを持っているのであれば (すべてのビューが熱く競合しているわけではありませんが)、以下のコマンドを使用して、インラインビュー更新を有効にする検討を強くお勧めします。

load updall <DB名> -inline on -T <競合するビュー名>

すると、良い結果を得ることができることでしょう。

文書の更新コストが急増する可能性があるため、データベース内のすべてのビューに対してオンにすることには注意が必要です。みなさんは、ご自身の環境で、最も競合の多いビューを知っているでしょうからうまくやってみてください。

2020/7/24 - 読み終える時間: ~1 分

旧 UrbanCode Deploy である HCL Launch は「あらゆるものを、どこにでもデプロイするエンタープライズソリューション」です。その製品解説記事 Get to know HCL Launch が英語版ブログにポストされました。その翻訳版を掲載します。

HCL Launch を知る

2020年7月23日

著者: Brian Stump / Product Specialist

HCL Launch は、あらゆるものをどこにでもデプロイできるように構築されたエンタープライズグレードの継続的デリバリーソリューションです。HCL Launch は、サーバーエージェントモデルを使用してアプリケーションをマッピングし、デプロイします。これらのコンポーネントは、ビルドサーバーから引き出され、アーティファクトリポジトリから引き出されます。これらのコンポーネントを設定する方法はたくさんありますので、それらのアーティファクトやファイルを引き出してデプロイできます。

HCL Launch 製品の最高レベルでは、アプリケーションがあります。アプリケーションは通常、複数のコンポーネントで構成されており、これらのコンポーネントをデプロイしたい環境にマッピングされています。これらのアプリケーションのそれぞれについて、このアプリケーションがどのようにデプロイされるかのプロセスを定義します。例えば、デプロイのプロセスでは、Web サーバー、データベースコンポーネント、データベーススキーマ、Java ファイルをインストールできます。これらの各ステップの中には、アプリケーションをデプロイする環境に応じて、ターゲットマシン上でエージェントが実行するスクリプトとステップを含むコンポーネントプロセスがあります。

各環境はコンポーネントで構成されています。コンポーネント・プロセスは、ドラッグ&ドロップのビジュアル・デザイナーを使って非常に簡単にカスタマイズできます。HCL Launch 環境のダッシュボードでは、コンポーネントのバージョン、最後にデプロイされた日付、デプロイに成功した場合はデプロイのログにアクセスできます。これにより、監査、ガバナンス、承認を簡単に追跡でき、エンタープライズ環境に最適です。

コンポーネント、アプリケーション、リソース、および環境ごとに、プロセスをテンプレート化できるので、多くの類似したアプリケーションを簡単にオンボードできます。例えば、類似のプロセスに従う多くの java コンポーネントがあり、そのデプロイメント・プロセスを共有したい場合、テンプレートを簡単に作成して、そのプロセスをシンプルで再現性のあるものにできます。

HCL Launch を使用すると、スナップショットを使用できます。スナップショットを使用すると、一緒にデプロイできることがわかっているバージョンの「黄金の」構成バンドルを作成できます。スナップショットでは、プロパティ、プロセス、テンプレートなどのオブジェクトの特定のバージョンをロックできるので、スナップショットで構成をロックした後にオブジェクトが変更されても、スナップショットをデプロイして、最初にスナップショットを作成した時にデプロイしたのと全く同じ構成を取得できます。言い換えれば、スナップショットにステータスを設定すると、これらのコンポーネントのそれぞれのバージョンがテストされたことがわかり、一緒に進むことができるので、依存関係の問題やバージョンの不一致などの問題に遭遇することはありません。

今実行するデプロイメントをスケジュールすることができ、将来的にはいつでも実行できます。HCL Launch バックエンドAPIは非常にオープンで文書化されているので、スクリプトや継続的インテグレーションサーバーからデプロイメントを開始するのは非常に簡単です。

HCL Launch サーバーの設定と設定では、ユーザーとグループのロールを定義して、誰が承認を行い、誰が履歴を表示し、誰がデプロイを実行できるかを制御できます。ロールは、HCL Launch オブジェクトのサブタイプごとに別々の権限を持つことができます。ユーザーが開発環境、QA 環境、または本番環境と対話しているかどうかに応じて、ロールの権限を簡単に分割できます。設定セクションは、プラグインを設定する場所でもあり、HCL Launch がどのように機能するかの鍵となる機能です。HCL Launch は何百ものプラグインと統合されており、自動化やソースの設定を行うことができます。

上のデモビデオを見て、HCL Launch の動作を確認してください。個別にデモをご希望の場合は、こちらからお申し込みください。

2020/7/24 - 読み終える時間: 3 分

DNS に関するセキュリティーテストの解説記事 Hey, DNS! (with HCL AppScan Domain Name Server) の翻訳記事です。

翻訳者注: 本記事は技術的詳細内容が含まれています。技術者による翻訳文の妥当性確認は行っていません。不明点等がある場合は、恐れ入りますが原文を参照願います。

Hey, DNS! (HCL AppScan Domain Name Server の利用)

2020年7月22日

著者: Shahar Sperling / Chief Architect at HCL AppScan

昔々、「動的解析」は「ブラックボックステスト」と呼ばれていました。昔の名前（Black-Box、White-Box、Glass-Box...）が懐かしいです。新しい名前には素敵な頭字語（DAST、SAST、IASTなど）が使われていますが、その名前は、その作業方法についての説明力としては不足しています。あるタイプのテストや別のタイプのテストを実行するときに直面する課題は、名前がテストオプションが実際にどのように動作するかを説明しているとはほど遠いことです。

Black-Box は、テスト対象を「ブラックボックス」として扱っていることを非常に明確に伝えています。中を見ることはできません。あなたは、ブラックボックスがあなたに公開することを選択したものだけに頼ることができます。私たちがテスト攻撃を実行するとき、アプリケーションが攻撃に対してどのように反応するかを「リフレクション」と呼びます。テストが成功したかどうかを示すのは、リフレクションの欠如であることがあります。

このリフレクションへの依存は、DAST が直面している大きな課題の 1 つです。これは、検出できる問題の種類を制限する要因となっています。いくつかのテストは、即時の応答(またはそれに続く一連の要求に対する応答)を作成し、それらはDASTが発見できる問題です。テストの中には、WebApp の実行フローを混乱させるように設計されているものもあります (意図的に反映の失敗を引き起こす) が、これらも DAST が検出できる問題です。

それ以外はどうでしょうか？

非同期検証メカニズムテストの影響

他のすべてではないかもしれませんが、数年前に導入された非同期検証メカニズムは役に立ちます。これらのテストの背後にある考えは、直接的なリフレクション (あるいはその欠如) に頼るのではなく、アプリケーションの他の外部から観測可能な動作に頼るということです。

これはどこで役に立つのでしょうか？例えば、コマンド実行のテストをするときです。私たちは、以下に説明されているアクションの一つを実行するコマンドを実行しようとします。これらのコマンドは、実行中のアプリケーションのコンテキストの外で実行され、多くの場合、それらに関連したレスポンス（例えば、HTMLへの直接的なリフレクション）がありません。通常の状況では、DAST スキャナはこれらの脆弱性を検出することはできません。

最初のクラスのテストでは、AppScan スキャナ自体に組み込まれた Web サーバーへの HTTP リクエストをトリガーしようとします。AppScanは、テストされたサーバーに特定のURLへのHTTPリクエストを開始させようとしますが、これは攻撃源を理解するのに役立ちます。また、外部ファイル挿入の脆弱性の検出も向上します。

ペイロード部分: http://:/AppScanMsg.html?varId=＜attack_id＞ (山括弧は意図的に全角にしています)

ここで、appscan_ip と port は、スキャナが実行されているマシンの IP と組み込み Web サーバーのポートです。attack_id の値は、送信された実際の攻撃を識別します。

これらのテストは非常に高い精度を持っていますが、失敗しやすいです。多くの場合、ネットワークのセグメンテーションにより、これらの要求がそもそも AppScan に到達しないようになっています。HTTP リクエストは実際にはサーバーによって生成されますが、その後、ネットワーク自体のファイアウォールやセグメンテーションルールによってブロックされることがあります。これはラボやステージング環境では非常に一般的です。ネットワークセグメントへのアクセスは許可されていても、セグメント内のマシンはセグメント外で HTTP トラフィックを生成することはできません。

HTTP トラフィックはエスケープできないかもしれませんが、DNS の性質上、DNS リクエストはそれがよく起こりえることです。そのため、第二のクラスのテストを含めることにしました。最初のテストと同様に、これらのテストはリクエストをトリガーしようとします。しかし、新しいテストでは、組み込みサーバーへの DNS ルックアップをトリガーしようとします。

DNS は連鎖したプロセスです。ある DNS サーバーがホスト名を IP に解決できない場合、接続されている他の DNS サーバーでそのホスト名を探そうとします。DNS リクエストは、ファイアウォールやゲートウェイ、その他のネットワークメカニズムによってブロックされることはほとんどありません。

その結果は高い精度で非常に良いのですが、キャッチがあります。多くのマシンでは、組織のポリシーにより、特定の DNS リゾルバへのルックアップを実行できません。これは、スキャナ内蔵の DNS サーバーをマシン上で設定しなければならないことを意味します。これは問題です。

解決策は、自動的に認識される DNS サーバーを作成することです。

AppScanドメインネームサーバー（ADNS）の導入

ADNS - AppScan Domain Name Server のご紹介です。オープンなインターネット上に鎮座するクラウドベースのサーバーで、インターネットベースのDNS サーバーを利用できるマシンであれば誰でもアクセス可能で、利用できるようになっています。これは、世界中のコンピュータの大多数を構成しています（物理的にインターネットに接続されていないコンピュータを除く）。HTTP トラフィックが遮断されている環境や、ファイアウォールによって遮断されている環境でも、通常は DNS トラフィックを通過させることができます。

その結果、テストの仕組みは次のようになります。

• ステップ 1: クラフトされたホストへのペイロードを持つ攻撃を作成する。

• ステップ2: テストされたサーバーはこのホスト名を調べる。

• ステップ 3: ADNSはこのルックアップの記録を受信して保持する。

• ステップ 4: AppScanは、ルックアップが行われたかどうかをADNSに問い合わせる。

シンプルさを維持し、ステップ 4 が成功することを確実にするために、DNS ルックアップを使用してクエリも行われます。そのため、インターネットへの直接アクセス（HTTPアクセス）がないAppScanインスタンスでも、DNS ルックアップが成功する確率が非常に高いため、このメカニズムを使用することができます。

前述したように、DNS の検索は細工されたホスト名に対して行われます。ホスト名は次のように構成されています。

vX-ping-＜variant_id＞-＜scan_GUID＞.securityip.appscan.com (山括弧は意図的に全角しています)

• securityip.appscan.com / securityip.appsechcl.com - これらは ADNS 自体を参照しています。この記事は「appsechcl」から「appscan」への移行期に書かれています。どちらかの名前が出てきます。この記事の目的のために、私は "appscan.com "を使用しています。
• variant_id - 特定の攻撃を識別するID
• scan_GUID - 特定のスキャンを識別するID。バリアントIDは1回のスキャンでは一意ですが、グローバルに識別可能なIDのためには、ランダムなスキャンIDも必要です。
• X - これは AppScan プロトコル(スキャナと ADNS 間の交換)の内部識別子です。

ペイロードは次のようになります。

v3-ping-11345?b697b0fb-06f5-4aab-a8d5-1867c7daa8c5.securityip.appscan.com

• 3 - 現在のプロトコルのバージョン
• 11345 - バリアント ID は送信された元のテストを識別します。
• b697b0fb-06f5-4aab-a8d5-1867c7daa8c5 - グローバルに一意なインスタンス ID。

ADNS はこれらのルックアップを待っており、それらの記録を保持しています。ADNS は解決されたホスト名 (例えば、ソースIP/ポート) 以外のものを保持しませんし、 リクエストの発信元を特定する方法もありません。ADNS はその後、次のように見える別のルックアップを待ちます。

v3-query-11345-b697b0fb-06f5-4aab-a8d5-1867c7daa8c5.securityip.appscan.com

これは、AppScan スキャナが生成するルックアップです。この名前を解決すると、ADNS IP アドレスまたは NXDOMAIN (Non-Existent Domain) が返されます。これは攻撃の検証段階です。サーバーが有効な IP アドレスを返す場合、攻撃は成功しています。そうでない場合、AppScanはテストされたアプリケーションが脆弱性がなかったことを登録します。

AppScan は様々なテストで ADNS を使用します。明らかなのはコマンド実行シナリオでの直接検索です。しかし、他のタイプのテストでも恩恵を受けることができます。例えば、リモートファイルインクルージョンです。古典的な DAST の検証は、アプリケーションを騙して、レスポンスの中に検出できる外部コンテンツを埋め込むように試みます。ADNS を使用して、外部 URL に ADNS ドメインを含めることができます。コンテンツは埋め込まれませんが、アプリケーションは少なくともホスト名を解決する必要があり、これが脆弱性の証明となります。

ADNS は、非リフレクションテストの精度の飛躍的な向上を表し、AppScan が検出するために使用できる脆弱性の種類の全体的な数を増やします。

私たちはこれを常に喜んでいます。

詳細

ADNS の詳細については、HCL Software に連絡してデモを予約してください。

2020/7/23 - 読み終える時間: ~1 分

2020年7月17日: HCLテクノロジーズの 2021年度 (インド表記。日本の2020年度) 第1四半期の連結決算が発表されました。おかげさまで、ソフトウェア部門は堅調に推移しております。感謝申し上げます。詳細は以下をご覧ください。

• 2020年7月17日: HCLテクノロジーズ、2021年度第1四半期の連結決算を発表 - ソフトウェア部門は堅調 -