物理アーキテクチャー

このアーキテクチャーは、2026 年 1 月に以下の前提条件で評価されました:

  • 中規模のパーセル管理組織を想定
  • テストの方法セクションに示すターゲット設計負荷によるパーセル管理ワークフローをサポート
  • SQL Server で構成されたエンタープライズ ジオデータベース
  • Microsoft Azure クラウド インフラストラクチャー

このシステムは、指定されたワークフローに合わせて設計とテストが行われ、テスト結果に基づいて、必要に応じてコンピューターの種類やサイズが調整されました。

パーセル管理システムの物理アーキテクチャー: (SQL Server)

このアーキテクチャーの Microsoft Visio ファイルをダウンロードできます。 ArcGIS システムのダイアグラム リソースの詳細をご参照ください。__

注意:

このアーキテクチャーのソフトウェア コンポーネントと主要な連携動作の詳細については、土地情報管理システムのリファレンス アーキテクチャーをご参照ください。

コンピューターの種類とサイズ

以下は、本テスト調査の範囲と目的に合わせて選択および検証されたコンピューターのサイズです。 ただし、実際に構築するときは、自社のビジネス要件と技術要件を考慮し、自社で完全な設計プロセスを行うことを強くおすすめします。

Esri は、ネットワーク、ストレージ、システム環境、サイズ設定など、組織の物理設計に関するさまざまな要素の決定を支援するシステム アーキテクチャー設計サービスを提供しています。 各コンポーネントの最小システム要件は、オンラインで入手可能な該当ソフトウェアのドキュメントに記載されています。

デスクトップ (ArcGIS Pro と Web ブラウザー)

  • テストに使用した 3 台のコンピューター
  • Standard_NC8as_T4_v3
  • 8 vCPU
  • 56 GB の RAM
  • 16 GB の GPU
  • 128 GB のディスク

Portal for ArcGIS

  • 2 台のコンピューター
  • Standard_D4s_v6
  • 4 vCPU
  • 16 GB の RAM
  • 128 GB のディスク
注意:

このテスト システムでは、2 コアで十分でした。 しかし、Esri では、本番システムでは 4 コア以上を強く推奨しています

ArcGIS GIS Server

  • 2 台のコンピューター
  • Standard_D8s_v6
  • 8 vCPU
  • 32 GB の RAM
  • 128 GB のディスク

ArcGIS Server (ホスティング サーバー)

  • 2 台のコンピューター
  • Standard_D8s_v6
  • 8 vCPU
  • 32 GB の RAM
  • 128 GB のディスク

ArcGIS Data Store (リレーショナル)

  • 2 台のコンピューター
  • Standard_D4s_v6
  • 4 vCPU
  • 16 GB の RAM
  • 128 GB のディスク

ArcGIS Web Adaptor

  • 2 台のコンピューター
  • Standard_D2as_v6
  • 2 つの vCPU
  • 8 GB の RAM
  • 128 GB のディスク

ArcGIS Monitor

  • 1 台のコンピューター
  • Standard_D8s_v6
  • 8 vCPU
  • 32 GB の RAM
  • 128 GB のディスク

ファイル ストレージ

  • 1 つのインスタンス
  • NetApp ファイル
  • 100 MiB/秒のスループット
  • 1 TB のディスク

データベース

  • 1 台のコンピューター
  • Standard_D16s_v6
  • 16 vCPU
  • 64 GB の RAM
  • 1 TB のディスク

ディレクトリー サービス

  • Microsoft Entra ドメイン サービス

インフラストラクチャーに関するその他の考慮事項

以下は、ネットワーク情報管理システムを設計する際に考慮すべき他の部分と、このテスト調査のために行われたインフラストラクチャーに関するいくつかの選択の説明です。

Azure のコンポーネントやサービスを使った ArcGIS システムの設計の詳細については、Azure テクノロジーをご参照ください。

ロード バランシングとリバース プロキシー

高可用性の ArcGIS Enterprise デプロイメントでは、ポータル サイトおよびサーバー サイトへのクライアント トラフィック、およびソフトウェア コンポーネント間の内部トラフィックを処理するために、少なくとも 1 つのサードパーティー製ロード バランサーが必要です。 ArcGIS Web Adaptor はロード バランサーと認識されていますが、高可用性構成においてロード バランサーとして機能するには単体では不十分です。 そのため、このテスト調査では Azure Application Gateway を使用しました。

データベースに関する検討事項

このテスト調査の範囲と目的を考慮し、SQL Server を仮想マシンにデプロイすることを選択しました。 ただし、ニーズによっては、Microsoft Azure 環境での Microsoft SQL Managed Instance などのデータベース プラットフォーム サービスの利用も検討対象になります。

共有ストレージ

高可用性の ArcGIS Enterprise デプロイメントを適切に実装するには、構成ストアを高可用性の共有場所に格納する必要があります。 これにより、1 つのサーバーに障害が発生した場合でもデータへのアクセスが維持され、エンドユーザーに中断のないサービスを提供できます。 さらに、共有ストレージは、複数コンピューターのデプロイメントでのデータ管理を簡素化し、データストレージを一元管理して、必要に応じて拡張可能にすることで、スケーラビリティーを向上させます。 このテスト調査では Azure NetApp Files を使用しました。

図に含まれていないシステム コンポーネント

この図には、ウイルス対策ソフトウェアと Azure ネットワーキング コンポーネントは示されていませんが、テスト調査には存在していたことに注意してください。

Top