物理アーキテクチャーの比較

以下に示すアーキテクチャーは、どちらも次の前提で設計されました。

• 中小規模のガス事業を想定
• 15 人の ArcGIS Pro 編集者と 200 人の ArcGIS Web ユーザー (一般的なユーザー層) を対象とした設計負荷に対応するワークフローのサポート
• 主要な設計上の選択肢の検討
• AWS クラウド インフラストラクチャー

SAP HANA Private Cloud Edition (PCE) のデプロイメントは、インスタンスのタイプとサイズは同じですが、エンタープライズ ジオデータベースが構成されている AWS PrivateLink を介して ArcGIS Enterprise VPC に接続された、別の VPC が含まれています。 2 つのデプロイメントは EC2 およびデータベースのインスタンス タイプが同じであり、主な違いはジオデータベースのホスティング方法とネットワーク設計です。

インスタンスのタイプと構成

次に示すシステム プロファイルは、このテスト調査の範囲と目的に応じて選択および検証されたインスタンス タイプの詳細な説明です。 どちらのシステムでも、同じ数とタイプの AWS EC2 インスタンスを使用しました。 独自にシステムを設計するときは、組織に固有のビジネスおよび技術の要件を考慮して、完全な設計プロセスを実行することを強くおすすめします。

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

デスクトップ (ArcGIS Pro およびブラウザーベースのワークフロー)

• 3 台のコンピューター
• G4dn.2xlarge インスタンス タイプ
• 4 つの CPU (8 つの vCPU)
• 32 GB の RAM
• 1 TB のディスク
• 16 GB の GPU

Portal for ArcGIS

• 2 台のコンピューター
• M6i.xlarge インスタンス タイプ
• 2 つの CPU (4 つの vCPU)
• 16 GB の RAM
• 128 GB のディスク

ArcGIS GIS Server (ネットワーク管理サービス)

• 2 台のコンピューター
• M6i.2xlarge インスタンス タイプ
• 4 つの CPU (8 つの vCPU)
• 32 GB の RAM
• 128 GB のディスク

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

• 2 台のコンピューター
• M6i.2xlarge インスタンス タイプ
• 4 つの CPU (8 つの vCPU)
• 32 GB の RAM
• 128 GB のディスク

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

• 2 台のコンピューター
• M6i.xlarge インスタンス タイプ
• 2 つの CPU (4 つの vCPU)
• 16 GB の RAM
• 256 GB のディスク

ArcGIS Web Adaptor

• 2 台のコンピューター
• M6i.large インスタンス タイプ
• 1 つの CPU (2 つの vCPU)
• 8 GB の RAM
• 128 GB のディスク

ArcGIS Monitor

• 1 台のコンピューター
• M6i.2xlarge インスタンス タイプ
• 4 つの CPU (8 つの vCPU)
• 32 GB の RAM
• 128 GB のディスク

共有ファイル ストレージ

• 1 つのインスタンス
• C6i.xlarge
• 1 つの CPU (2 つの vCPU)
• 8 GB の RAM
• 2 TB のディスク

データベース ホスト

• 1 台のコンピューター
• R5.8xlarge インスタンス タイプ
• 16 の CPU (32 の vCPU)
• 256 GB の RAM
• (2) 512 GB のディスク

ドメイン サーバー

• 1 台のコンピューター
• C6i.large インスタンス タイプ
• 1 つの CPU (2 つの vCPU)
• 4 GB の RAM
• 128 GB のディスク

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

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

アプリケーション ロード バランサー (ALB)

ロード バランサーは、高可用性の ArcGIS Enterprise デプロイメントで、ポータルおよびサーバーのコンポーネントへのクライアント トラフィック、およびソフトウェア コンポーネント間のサイト内トラフィックのバランスを取り、プロキシーするために必要です。 ArcGIS Web Adaptor はロード バランサーと動作しますが、高可用性構成においてロード バランサーとして機能するには単体では不十分です。 このテスト調査では、AWS Application Load Balancer を使用しました。

共有ストレージ

高可用性の ArcGIS Enterprise デプロイメントを適切に実装するには、いくつかの構成アイテムやフォルダーを、高可用性の共有場所に格納する必要があります。 これにより、1 つのサーバーに障害が発生した場合でもデータへのアクセスが維持され、エンドユーザーへのサービスが中断しなくなります。 さらに、共有ストレージは、複数コンピューターのデプロイメントでのデータ管理を簡素化し、データストレージを一元管理して、必要に応じて拡張可能にすることで、スケーラビリティーを向上させます。 このアーキテクチャーでは、Windows ベースのファイル サーバーを使用してこれらの共有コンポーネントを格納し、AWS EC2 の自動復旧が構成されます。

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

このアーキテクチャーの図には、ウイルス対策ソフトウェアや AWS のネットワーク コンポーネントは示されていませんが、テスト調査には存在中には稼働していました。