ArcGIS Enterprise × クラウドデザイン：ネットワーク遅延の影響とその回避策

[#1]

はじめに

重要なビジネスをサポートするため、ArcGISシステムを利用する際、「動作が遅い」「応答が悪い」と感じたことはありませんか？その原因の多くは「ネットワーク遅延（レイテンシ）」にあります。組織のネットワーク遅延を最小化し、システムのパフォーマンスを向上させ、エンドユーザーの効率性を高めるためには、設計段階からの工夫が必要です。

オンプレミス環境が一般的だった時代には、ArcGIS Enterprise はエンドユーザーと同じ建物内のネットワークで運用されていました。しかし、"Cloud-by-Default" の流れにより、ArcGIS Enterprise サーバーのクラウド環境への移行が進む中で、エンドユーザーと ArcGIS Enterprise の物理的距離が広がり、ネットワークレイテンシの影響が顕著になっています。

Esri は、ArcGIS Enterpriseにおけるネットワーク遅延の影響を定量的に評価するため、実際のユーザー操作を模したテストを実施しました。その結果、レイテンシがユーザー体験や業務効率に与える影響は、予想以上に大きいことが分かりました。

ArcGIS におけるネットワーク遅延の要因

ArcGIS システムでは、以下の要因がネットワーク遅延に影響を与えます。

1. 距離（Distance）：データが移動する物理的な距離。地理的に離れた場所との通信では、遅延が発生しやすくなります。
2. 伝送時間（Transmission）：帯域幅やパケットサイズに依存する送信時間。ネットワークの速度や容量によって、データの送受信にかかる時間が変わります。
3. ネットワーク構成（Network Architecture）：ルーターやスイッチの数、経路の効率性。複雑なネットワーク構成では、経由する機器が多くなり、遅延の原因となります。
4. 処理遅延（Processing Delays）：ネットワーク機器による検査・転送の遅延。ファイアウォールやロードバランサーなどの処理が加わることで、通信時間が延びることがあります。

特に ArcGIS Enterprise においては、Contents Directory、エンタープライズジオデータベース、ArcGIS Data Store などのデータベースとの通信が頻繁に発生します。そのため、データベースレイテンシはシステム全体のパフォーマンスに大きな影響を与えます。

ユーティリティネットワークの編集など、長時間にわたるトランザクションではこの影響が顕著に現れ、ユーザーの操作応答性や処理効率に直接的な影響を及ぼします。

クラウド環境におけるネットワーク遅延の抑制方法

ArcGIS Enterprise のような分散型システムでは、ネットワーク遅延がシステム全体のパフォーマンスに大きく影響します。以下は、クラウド環境でネットワーク遅延を抑えるための代表的な方法です。

1. 通信距離を最小化する

クライアントをシステムやデータの近くに配置することが重要です。ここでの「近く」とは、同一データセンターのネットワーク内、または同一リージョン・アベイラビリティゾーンにあることを意味します。

ArcGIS アプリケーションは、ストレージやデータベースなど複数のコンポーネントに対して並列リクエストを送信するため、レイテンシが高いとパフォーマンスに大きな影響を与えます。

他リージョン・アベイラビリティゾーンにまたがる構成が必要な場合は、以下のようなサービスを活用することで遅延を抑えることができます。

• Amazon S3 の Cross-Region Replication (CRR)
• Amazon RDS の マルチAZ DB クラスター
• VPC Peering や VPC Transit Gateway による専用回線の構築

ArcGIS Server のデータストアやエンタープライズジオデータベースなど、読み書きが頻繁なコンポーネントでは、ネットワークだけでなくストレージの IOPS やスループットも重要です。Amazon EBS の性能見直しや、NAS・SAN・クラウドストレージ（AWS S3、AWS FSx、Azure Filesなど）の用途に応じた選定が求められます。

2. ネットワークホップ数を減らす

データは不要なルーターやスイッチを経由せず、最短経路で通信されるべきです。頻繁に通信するエンドポイントを同一サブネットにグループ化することで、ネットワーク遅延を軽減できます。

ArcGIS Enterprise の各コンポーネント（ArcGIS Server、Portal for ArcGIS、ArcGIS Data Store、エンタープライズジオデータベース、デスクトップクライアントなど）は、可能な限り同一リージョン・同一アベイラビリティゾーン・同一サブネットに配置することが推奨されます。

外部ドメインが存在する場合は、内部通信に使用される URL で ArcGIS Enterprise を構成したり、VPC のルーティングテーブルに不要な経路が含まれていないか確認することも重要です。

3. Web Tier・App Tier・Data Tier を近接させる

ArcGIS Enterprise は Web Tier・App Tier・Data Tier に分かれて設計されています。ArcGIS Server（App Tier）を他のコンポーネントと分離して専用インスタンスに配置する設計は、リソース確保や安定性の面では有効ですが、Portal for ArcGIS（Web Tier）や ArcGIS Data Store（Data Tier）との距離が離れると、ネットワーク遅延の原因になります。

セキュリティ上の理由がない限り、ArcGIS Server を A サブネット、その他のコンポーネントを B サブネットに分ける設計は推奨されません。基本的にすべてのコンポーネントを同一サブネットに配置し、各 Tier 間の通信距離とホップ数を最小限に抑えることで、安定したパフォーマンスを実現できます。

ネットワーク遅延の影響を定量的に評価する

ネットワーク遅延は、ArcGIS システムの複数の階層で発生する可能性があります。今回の Esri によるテストでは、特に ArcGIS Server とエンタープライズジオデータベース間の遅延に焦点を当てて測定が行われました。この階層は、編集パフォーマンス、サービスの応答性、ユーザーエクスペリエンスに直接影響を与える重要なポイントです。

• 設計比較

1. 低レイテンシ設計（推奨）

• 同一リージョン、同一 VPC に配置
• データベースレイテンシ：1〜5ms

2. 高レイテンシ設計

• 異なるリージョン・アベイラビリティゾーン（AZ）に配置
• 2つの VPC を VPC Peering で接続
• Microsoft の psping ユーティリティによる RTT 測定：13ms 以上

• テスト評価ポイント

1. システムリソースの使用率
2. ArcSOC の使用状況
3. ユーザー応答性（ワークフロー完了までの時間）

1. システムリソース使用率

以下のグラフでは、推奨される低レイテンシ設計（左）と高レイテンシ設計（右）の2つのテストシナリオにおける、すべてのシステム階層のリソース使用率を確認できます。オレンジ色の線はCPU使用率を示しており、どちらのテストでも全サーバーで低い値を示しています。両シナリオの大きな違いは、同時編集リクエストを示す青い線にあります。

• データベースレイテンシが低い場合、リクエストは安定して開閉されています。
• データベースレイテンシが高い場合、負荷が下がり始めるまで、開いたままの編集リクエスト（Concurrent Requests）が継続的に増加します。

一般的には、システムリソースの使用率が高くなると、エンドユーザーの応答性が低下します。オレンジ色のグラフを見ると、高レイテンシ設計（右）でもCPU使用率が上昇していないため、システムがユーザーのリクエストを迅速に処理しているように見えるかもしれません。しかし、実際にはそうではありません。

今回のテストシナリオにおいてCPU使用率が低く見える理由は、リクエストがすぐに処理されているからではなく、1つのリクエストが完了せずに長時間システムに滞留しているためです。その結果、新しいリクエストを処理する余裕が減少し、単位時間あたりの処理効率が低下しています。

レストランで例えると…
お客さん（リクエスト）が席を長く占有すると、新しいお客さんは入れないけど、キッチン（CPU）は手が空いてる状態になります。
リソースが空いているように見えても、実際には処理が滞っている状態なのです。

つまり、複数の作業を同時に効率的に処理できなかったため、テストは予定終了時間より実行時間が31分延長され、複数の編集作業が完了せずに残存しました。このように、高レイテンシ設計では、低レイテンシ設計と比較して25分の効率損失が発生しました。

2. ArcSOC 使用状況

ArcSOC は、ユーザーからの Web サービスリクエストを処理する ArcGIS Server のサーバープロセスです。低レイテンシ設計（左）の結果では、ArcSOC の使用率は比較的低く、ホスティングサーバーでは多くのビジーインスタンスが 6 以下、ユーティリティネットワーク（UN）サーバーでは 9 以下であることが示されています。

一方、高レイテンシ設計（右）の結果では、UN サーバーの ArcSOC がテスト期間のほとんどにおいて最大使用率を示しています。前述の通り、CPU 使用率は高くないため、これらのビジーインスタンスは ArcSOC がデータベースからの応答を待機している状態であると考えられます。つまり、処理が完了せずに待機状態が続くことで、インスタンスがビジー状態になっているのです。

3. ユーザー応答性とワークフロー持続時間

低レイテンシ設計（上部のチャート）は、Esri が文書化しているガスネットワーク情報管理システムにおける典型的なワークフロー時間を示しています。一方、高レイテンシ設計（下部のチャート）では、ワークフローの所要時間が大幅に増加し、エンドユーザーの作業効率が著しく低下しています。

両設計の唯一の違いは、データベースが異なるリージョンにホストされている点です。したがって、今回のユーザー効率の低下は、追加された 13ms 以上のデータベースレイテンシ に起因すると考えられます。

ArcSOCインスタンスを拡張してネットワーク遅延の影響を相殺する

先ほどのテスト結果から、ArcSOC は飽和状態である一方、システム全体のリソース使用率は低く抑えられていました。これにより、「システムが追加ArcSOCのサービスインスタンスをサポートできるのであれば、エンドユーザーが感じる遅延を改善できるのではないか？」という疑問が生じました。

この仮説を検証するために、ArcSOC の数を 2 倍に増やし、インスタンスのリソースは変更せずにテストを実施しました。以下のグラフは、次の 3 つの構成におけるワークフローの実行時間を示しています。

1. 低データベースレイテンシ構成
2. 高レイテンシ構成（ArcSOC と vCPU の比率が 1:1）
3. 高レイテンシ構成（ArcSOC と vCPU の比率が 2:1）— ArcSOC の数を 2 倍にし、インスタンスリソースを変更せずに

このグラフは、「低レイテンシ構成」、「1:1 の ArcSOC と vCPU の比率による高レイテンシ構成」、そして 「2:1 の比率による高レイテンシ構成」におけるワークフロー実行時間の変化を示しています。

すでに前回のユーザー応答性テストにおいて、高レイテンシ構成では編集ワークフローの完了に低レイテンシ構成の少なくとも 2 倍の時間がかかることが確認されています。しかし、ArcSOC の数を 2 倍にした高レイテンシ構成では、ワークフロー時間が平均で 約 45% 改善されました。

これは、使用可能な ArcSOC の数が増加したことで、より多くのリクエストが同時に処理されるようになったためです。ただし、各リクエストは依然としてデータベースからの応答を待機しているため、ワークフローの実行時間は低レイテンシ構成と比較して依然として長くなります。

したがって、データベースレイテンシを現実的に削減できない状況では、ArcSOC インスタンスのスケーリングによって、ネットワーク遅延の悪影響をある程度相殺することが可能です。この回避策を適用するには、ArcSOC の増加に対応できる十分なサーバーリソースがあるかどうかを確認するための 適切なシステムモニタリングが不可欠です。

さらに、この方法はサービスインスタンスが飽和状態（すべて使用中）である場合にのみ、ユーザーが体感するパフォーマンスや作業効率の向上につながります。レイテンシの根本的な解決には至りませんが、今回のテストは、システム監視とマップサービスインスタンスのチューニングがパフォーマンス改善において重要であることを示しています。

まとめ

ネットワーク遅延と ArcGIS システムへの影響について理解が深まった今、設計の見直し、システムの観察、サービス構成のチューニングを通じて、ネットワーク遅延を軽減し、組織にとってより良い成果を得るための具体的な対策を講じることができます。

• テスト結果では、高レイテンシ構成ではワークフローの実行時間が低レイテンシ構成と比較して 100%〜550% 増加し、従業員の作業時間や組織の機会損失につながる可能性があります。
• ネットワークパフォーマンスの継続的な監視と、エンドユーザーの体感速度・応答性の把握が重要です。例えば、ArcGIS Monitor などのツールを活用することで、ArcSOC およびシステムリソース使用率やエラー傾向を可視化できます。
• ネットワーク構成の最適化を行い、ファイアウォールやルーターなど遅延を引き起こす可能性のあるコンポーネントを見直しましょう。帯域幅の妨げになっていないかも確認が必要です。
• ArcGIS Enterprise の各コンポーネントは、可能な限り物理的に近接させ、最低でも同一リージョン内に配置することで、ネットワーク遅延を抑えることができます。
• データベースレイテンシの削減が難しい場合は、ArcSOC のスケーリングなどサービス構成のチューニングによって、ユーザー体感のパフォーマンス改善に寄与する可能性があります。
• クラウドサービスの各種機能（AWSの場合、CloudWatch、VPC Flow Logs、Transit Gateway、FSx、EBS など）を活用し、ネットワークやストレージの性能を継続的に評価・改善しましょう。

関連リンク

• Network Latency Costs More Than You Think, and We Have the Data to Prove It
• ArcGIS Enterprise Systems and Network Transport Time
• Physical design considerations | ArcGIS Architecture Center