テストの方法と結果

テストは、設計が期待した性能を発揮し、ワークフロー、ユーザー、および意図した負荷をサポートすることを検証するために実施されました。 システム テストによって、下位環境でのシステム デプロイ中、理想的には本番環境で問題が発生する前に、問題を発見して修正する機会が得られます。 このテスト調査のテスト方法では、システムがワークフローをサポートするかどうかの検証、負荷がシステムやそのコンポーネント、エンドユーザー エクスペリエンスに与える影響を理解することに焦点を当てました。

各コンポーネントについて、それぞれ異なる負荷シナリオに対してワークフローを実行し、監視が行われました。 テストが完了すると、結果が集約され、分析され、システム内のボトルネックとリソース過剰のコンポーネントの両方を特定しました。 この情報を使用して、スケール アップ、スケール ダウン、またはスケール アウトが必要なシステム コンポーネントを特定してから、さらにテストを繰り返しました。

ワークフロー テスターの画面記録を取得して手動のユーザー エクスペリエンス テストを行い、システムのユーザーがワークフローを生産的に完了できることを確認するために実施されました。

詳細については、効果的なテスト戦略の設計の方法をご参照ください。

ワークフローのペーシング

このテスト調査では、テストされたワークフローにペーシング モデルを適用しました。 ペーシング モデルは、パーセル管理組織での作業ペースをテストでシミュレートする方法を示しており、ワークフローはスタッフ リソースのチーム全体で 1 時間あたりの一定数の操作として実行されます。 この手法は Esri のお客様からの情報に基づいており、使用データは中規模のパーセル管理の顧客シナリオに準拠しています。

ワークフローは、1 時間のテスト期間にわたって分散され、同時に開始されないようにずらしつつ、実際の環境でのタスク展開を模してオーバーラップするようにも設定されました。 以下のペーシング モデルでは、各ワークフローのペーシングと 1 時間あたりの操作数をどのように指定したかを確認できます。これがシステムの設計負荷を定義します。

その後で、システムが許容範囲で応答できなくなる、またはワークフローを正しくサポートできなくなるまで、ワークフローの数を徐々に増やすことで、負荷を高めていきました。今回のケースでは、対象となる組織タイプに対してシステムが適切に機能することを検証できる十分な規模に達するまで、負荷を増加させました。 このテスト調査で適用されたワークフロー ペーシング モデルは、組織での一般的な日常使用と一致しない場合があることに注意してください。

パフォーマンス テスト ツール

ArcGIS は多層システムなので、パフォーマンス テストは、クライアント層、サービス層、データ ストレージ層、および基盤となるインフラストラクチャー自体にわたって行われました。 このテスト調査では、JMeter を使用してユーザーのワークフローをシミュレートし、さまざまな負荷のもとでシステム パフォーマンスを測定しました。 ArcGIS Pro の記録されたリクエストを再生することで負荷をシミュレートしました。また、手動のワークフローを実行することで、エンドユーザー エクスペリエンスも評価されました。 各コンポーネントのリソース使用率を監視するため、Windows パフォーマンス モニターと ArcGIS Monitor も使用されました。

詳細については、パフォーマンス テスト ツールをご参照ください。

テストの結果

このアーキテクチャーは、自動負荷テストと手動操作によるテストを通じて、3 つのシナリオで検証されました。各シナリオの結果を以下に示します。 大まかに言うと、テストの結果は、実装時点でシステムには設計負荷からその 8 倍までの負荷をサポートするのに十分なリソースがあったことを示しています。 また、テスト結果からは、アプリケーションとシステムの構成が適切であることがパフォーマンスのため重要だということも明らかになりました。

テスト シナリオ: 設計負荷

Observations:

• システムはこの負荷に対応できました
• ホスティング サーバー (表示ワークフロー) の CPU 使用率は平均で 30% 未満 (オレンジのライン)
• パーセル サーバー (編集ワークフロー) の CPU 使用率は平均で 40% 未満
• SQL Server の CPU 使用率は非常に低く、通常は 15% 未満を維持
• SQL Server インスタンスのディスク使用率の急増は、バックグラウンドの Windows プロセス (金のライン) に起因しています
• 同時リクエスト数を見ると、テスト期間中の任意の時点で、システムはおよそ 3 件の同時ビューアー リクエスト (赤) と 1 件の同時編集者リクエスト (青) をサポートしていることがわかります

テスト シナリオ: 設計負荷の 4 倍

Observations:

• システムはこの負荷をサポートでき、コンポーネント全体の限界のリソース使用率は増加しています
• ホスティング サーバーの CPU 使用率は平均で 40% 未満
• パーセル サーバーの CPU 使用率は平均で 50% 未満
• SQL Server の CPU 使用率は、全体として 40% 未満を維持
• ディスク使用率の周期的な急増は、ワークフローの開始や特定のワークフロー ステップに起因しています。 具体的には、15:10 ～ 15:20 の急増は、複数のダッシュボードが同時に開くパーセルの集計ワークフローに関連しています
• 同時リクエスト数を見ると、テスト期間中に、システムは平均で 10 〜 15 件の同時ビューアー リクエストと編集者リクエストをサポートしており、同時表示リクエストの大きなピークはあるものの、ごく短時間で収束していることがわかります。

テスト シナリオ: 設計負荷の 8 倍

Observations:

• システムはこの負荷をサポートでき、コンポーネント全体で予想どおりのリソース使用率の増加が見られます
• ホスティング サーバーの CPU 使用率は全体として 50% 未満を維持
• パーセル サーバーの CPU 使用率は全体として 50% 未満を維持
• SQL Server のリソース使用率が大幅に増加し、CPU 使用率は常に 60% 前後に達しています。
• 同時リクエスト数を見ると、テスト期間中、システムはピーク時に 35 件の同時ビューアー リクエストと、平均で 2 件の同時編集者リクエストを常にサポートしていることがわかります。
• 20:20 に読み取りリクエストが急増したのは、パーセルの集計ワークフローが開始したからです。

サービス インスタンスの構成

サービスが適切に調整されているかどうかを把握するため、仮想マシンのリソース使用率に加え、各テスト実行の ArcSOC 使用率も監視しました。 設計負荷の 8 倍までのすべての実行で、ビジー状態の ArcSOC は最大 (16 個) を大きく下回りました。つまり、その負荷に対して必要以上に多くのマップ インスタンスを構成していたことになりまます。 これが、設計負荷の 8 倍未満の負荷で稼働する本番環境であれば、ホスティング サーバーと GIS サーバー コンピューターのサイズを縮小してコスト削減を図るという選択肢も考えられます。 これは、需要に応じたスケーリングが必要かどうかを判断するため、サーバーの CPU やメモリーと並行して ArcSOC の使用率を監視することを前提としています。 さらに、各 ArcSOC は一定のメモリーを消費し、ビジー状態の ArcSOC は仮想 CPU を使用するため、これらのコンピューターに過負荷がかからないよう注意する必要があります。

以下の図では、設計負荷の 8 倍の条件下では、ホスティング サーバー サイトでは 16 個すべての ArcSOC が特定の時間帯にビジー状態であることがわかります。 すべての ArcSOC がビジー状態である場合、サービスの待機時間が長くなることが予想されます (実際に観察されたとおり)。 しかし、パーセル サーバー (右) では ArcSOC 使用率は低く、構成された 16 個のうち最大で 9 個の利用に留まっています。

ホスティング サーバー (左) での最初の急増は、テスト開始時にダッシュボードが起動したことが原因でした。 今後のテスト実行に向けてワークフローのペーシングを修正し、実際のシナリオをより正確に反映できるよう、ダッシュボードの起動を数分間にわたって分散させるようにしました。

• 詳しくは、ArcSOC 最適化の手法と技術を詳述したブログ記事をご参照ください。

ユーザー エクスペリエンス - 手動ワークフローの時間

自動化されたワークフローに加え、ワークフロー テスターの画面記録を取得し、その録画からワークフローの所要時間 (ユーザーがワークフローのすべてのステップを実行するのにかかった時間) を抽出することで、ユーザー エクスペリエンスも観察しました。 これは、システムのユーザーがワークフローを生産的に完了できることを確認するために行われます。

以下のグラフに示すように、実施されたワークフローの所要時間はすべてのテスト シナリオを通してほぼ一貫しており、ごくわずかな変動しか見られません。 これは、エンドユーザーが認識するシステムの応答性に悪影響を与えることなく、システムが負荷の増加に対応できることを示しています。

ユーザー エクスペリエンス - 手動ワークフロー ステップの時間

ワークフロー自体に加え、すべてのワークフローにおける主要なステップのワークフロー実行時間も記録しました。 これは、システムに負荷がかけられている状態で、各ワークフローの特定のステップを完了するのにかかった平均時間を表しています。 以下のチャートはパーセルのマージ ワークフローの例ですが、どの負荷シナリオにおいても、各ステップの完了にかかる時間は非常に安定していることがわかります。 このパターンは、わずかな変動はあるものの、すべてのワークフローで一貫して見られます。

結論と重要なポイント

これらのテストは、本番システムではなくテスト環境で実施されました。 ワークフローや構成、設計は、システムによって異なる可能性があります。 たとえば、Azure では、通常は Web Adaptor は使われず (SAML を利用する場合)、AppGateway が直接サーバーに負荷を分散させます。 しかし、これらのテスト手法や結果から、目的に合わせて参考にすることはできます:

• システム全体で可観測性を考慮した設計を取り入れると、インフラストラクチャー コストに見合ったパフォーマンスを適切に調整するための貴重な情報を得られるだけでなく、トラブルシューティングなど他の重要なアクティビティーにも役立ちます。
• テスト中 (ステージング / テスト環境) および本番環境の両方で、システムのサーバー リソース、ArcSOC の使用率、ワークフローの所要時間を監視してください。
• リソースとリソース使用率の間に不整合が見られる箇所を確認します。 例:
  • 設計負荷の 8 倍の条件下で、ホスティング サーバー サイトはこのリクエスト量に対して適切にサイズ設定されているようです。 しかし、GIS サーバー (パーセル サーバー) には依然として多くの未使用リソースがあります。
  • 同じパフォーマンスとユーザー エクスペリエンスを維持しつつ、コスト削減のためにインフラストラクチャーを縮小できる余地がいくつかあります。
  • また、ワークフローをサポートするために、ArcSOC をより適切に分散させるよう再構成できる可能性もあります。