事前テスト

事前テストは、正式なテストの結果を改善することを目的とした、プロセスにおけるステップです。事前テストは、以下の目的を果たすために行われます。

負荷がかかっている状態のシステムのパフォーマンスとユーザビリティーに支障をきたす可能性のあるシステムのボトルネックを特定する
さまざまな設定や構成を反復的に試す
より正式な負荷テストプロセスを効率化する

初期状態の物理アーキテクチャーは、SAP HANA で構成された、テスト済みの基本的なネットワーク情報管理システムとほぼ同じで、モバイルデバイスが接続できるように AWS Client VPN エンドポイントのみ追加されています。事前テスト中に、以下に示すように作業負荷を追加した場合、システムが想定した負荷に対応できないことが判明しました。その後、「物理アーキテクチャー」で説明するように、アーキテクチャーを適切に調整しました。これらの変更が加えられた後の最終的なテスト結果は、「テスト結果」セクションで確認できます。

注意:

新しいワークフローや作業負荷の増加など、システムに変更を加えるたびにテストと検証を行い、本番環境に変更を取り入れる前にシステムへの潜在的な影響を評価することをおすすめします。

設計負荷の 4 倍での事前テスト

このシステムは、下図の左側に示すように、まずモバイルワークフローを実行しない基本的なネットワーク情報管理ワークフローでテストされました。テストの開始時に ArcGIS Web Adaptor 02 で Windows Defender のアップデートをインストールしたため、リソース使用率は一時的に急上昇しましたが、それ以外はリソース使用率は比較的低くなっています。

これを図の右側と比較します。4 倍の負荷に加えてモバイルワークフローを追加すると、ArcGIS Web Adaptors および Portal for ArcGIS インスタンスで CPU 使用率が大幅に増加することがわかります。 ArcGIS Web Adaptors が飽和状態になり、リクエスト処理が遅くなったりタイムアウトしたりしています。 4 つの GIS サーバーとデータベースはすべて、CPU 使用率 (オレンジ色) とディスク使用率 (金色) が高くなっています。これは、オフラインワークフローのダウンロード手順によるものです。2.66 GB のオフラインエリアが多数のモバイル作業者によってダウンロードされるためです。

設計負荷の 4 倍をモバイルありとなしで比較したテスト結果

以下の図 (左) に示す基本負荷のみの未処理リクエストは、システムが負荷を処理していることを示しています。テストの早い段階で未処理リクエストがわずかに増加しますが、最大 19 人の編集者と 11 人の閲覧者で安定します。しかしモバイル負荷が加わると (右)、ダウンロードが完了する前にデスクトップ (閲覧者と編集者) のリクエストが 42、モバイルの同時リクエストが 127 まで急増し、その後負荷が減少します。このパターンは、ユーザーがオフラインエリアのダウンロード完了を待つ間、テストのダウンロード手順中に速度が低下することを示します。

同時リクエストの比較

インスタンスサイズ

事前テストでは、オフラインエリア (サイズ 2.66 GB) のダウンロード時間が 30 分以上かかることを確認しました (下図を参照)。トラブルシューティングの結果、この問題は、ArcGIS Web Adaptor および Portal for ArcGIS インスタンスの CPU 使用率が非常に高く、それがスループットを制限し、ダウンロードのタイムアウトを引き起こしていることが判明しました。これに対処するために、ArcGIS Web Adaptor インスタンスを 2 vCPU から 8 vCPU、Portal for ArcGIS インスタンスを 4 vCPU から 8 vCPU に増加しました。

最適化前と最適化後のダウンロード時間

特に、非接続環境でのワークフローのダウンロード手順は、ArcGIS Web Adaptor と Portal for ArcGIS のインスタンスサイズの増加によって恩恵を受け、ダウンロード時間が 41% 短縮されました。しかし、大量のダウンロードが行われない場合、これは過剰容量になります。本番環境では、ピーク時にこれらのコンポーネントをスケールアップし、不要なときはインスタンスサイズを縮小することでコストを削減する方法を検討します。したがって、パフォーマンスとコストを適切に均衡化させるには、オフラインマップのサイズのバランスを取りながらリソースを最適化する (必要なエリアをカバーしながらできるだけ小さくする) ことが重要です。

詳しくは、「マップをオフラインにするためのベストプラクティス」をご参照ください。

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

ArcGIS Enterprise では、公開されたサービスのサービスインスタンスは ArcSOC プロセスと呼ばれます。長い待ち時間やユーザーエクスペリエンスの低下を回避するには、さまざまな方法で ArcSOC を構成できます。一般に、ビジー状態の ArcSOC の数がサービスに割り当てられた最大数を超えると、ArcSOC が使用可能になるまでの待機時間が長くなります。しかし、すべてのサービスにわたる ArcSOC の最大数が使用可能な vCPU 数を超える場合も、すべての vCPU がビジー状態になるため待機時間が増加します。したがって、特にシステム変更が導入される場合は、ArcSOC と使用可能な vCPU の比率を監視し、管理することが重要です。

2 つのホスティングサーバーで 16 個の vCPU を使用できるため、モバイルユーティリティーネットワークサービスと読み取り専用のガスユーティリティーネットワークサービスの初期サービスインスタンス設定は、それぞれ次のように設定されました。

最小: 8
最大: 8

読み取り専用のガスユーティリティーネットワークサービスは、事前テストのほとんどの期間で最大の ArcSOC 使用率で稼働していたのに対し、モバイルサービスには余剰の ArcSOC があったため、一部のサービスの再構成が必要であることがわかりました。最適化前と最適化後の ArcSOC 使用率の比較については、以下の図をご参照ください。

最適化前と最適化後の読み取り専用ユーティリティーネットワークサービスインスタンスの観測

最適化前と最適化後のモバイルユーティリティーネットワークサービスインスタンスの観測

モバイルユーティリティーネットワークサービスのサービスインスタンスは、最小と最大 8 から最小と最大 6 に減少しました。ガスユーティリティーネットワークサービスのサービスインスタンスは、最小と最大 8 から最小と最大 10 に増加しました。変更後、両方のサービス間の分布がより均等になり、ユーザーの待ち時間は明確に改善しました。

サービスの調整と構成方法の詳細
サービスインスタンス設定の構成方法の詳細