ArcGIS Enterprise 配置の最初のステップとして、システム アーキテクチャを設計および計画します。これには、ハードウェアおよびソフトウェア コンポーネント、およびこれらのコンポーネントの相互接続が含まれます。これには、人材の配置も含まれます。具体的には、システムで作業する担当者、担当者に付与するアクセス権限、および担当者が順守する承認済みの作業です。
最終的には、ArcGIS Enterprise を配置することで、ユーザーの期待に応え、ワークフローを実現できる方法で地理空間コンテンツをユーザーに配信します。このため、作成する配置では、整合性が担保された形で地理空間コンテンツが配信されるように設計する必要があります。
多くの場合、Web GIS システムを運用するには、複数の関係者グループとそのさまざまな要件に対応し、ハードウェアとリソースの制限事項に対処して、コンテンツおよび ID セキュリティを脅威から保護する必要があります。このように複雑な作業を伴うため、計画段階ですべての観点を考慮することが重要です。
以下のベスト プラクティスは、ArcGIS Enterprise 配置の効果的な運用パフォーマンス、信頼性、およびセキュリティ戦略の設計に役立ちます。
環境分離
ArcGIS Enterprise システム アーキテクチャを設計する際は、エンド ユーザーが利用できるようにする前に、組織で新しいエレメントを開発およびテストする方法を検討します。
ユーザーがワークフローで利用するコンテンツは、開発およびテストが行われる環境とは別の場所に配置する必要があります。この方法は環境分離と呼ばれ、GIS コンテンツに対して意図しない変更または削除を行うリスクを軽減します。
開発、ステージング、および運用
環境分離の一般的なモデルには、開発、ステージング、および運用の 3 層が含まれます。これらの 3 層を実装することは、最低限のベスト プラクティスになります。開発およびテストの方法に応じて、層を追加したり、品質保証のレベルを向上したりできます。
開発ワークスペースでは、GIS アナリストと開発者は多くのシステム利用者に影響を与えることなく、コンテンツに対する作業を行い、新しいアイテムを探索できます。通常、この専用サーバー環境はユニットのテスト、ビジネス ワークフローの構築、または新しい機能の作成に使用されます。変更によって生じるリスクのレベル、コンテンツ作成者の数、およびシステムの停止とダウンタイムが引き起こす影響の可能性に応じて、環境のサイズと複雑さが決まります。
ステージング環境は複数構築でき、最終的な運用環境からは分離されていますが、可能な限り運用環境を反映しています。このため、エンド ユーザーに発生する可能性のある不具合をテスト時に確実に検出できます。たとえば、顧客アプリのカスタム ベースマップでベクター タイル レイヤーを使用し、そのベクター タイル レイヤーを頻繁に更新する場合、ステージング環境はそのアプリを複製する必要があります。その後、各アプリのベクター タイル レイヤーへの毎回の更新内容を保証することで、顧客の操作が中断されないようにすることができます。コンテンツに対するすべての変更は、運用環境に配置する前にステージング環境でテストする必要があります。
フィールド スタッフ、ビジネス顧客などのエンド ユーザーや自動監視システムが、運用環境にアクセスできる必要があります。運用環境には、許容されるダウンタイム レベルを定義したサービス レベル契約 (SLA) が存在する場合があります。可用性とアクセスを常に監視し、バックアップ コンピューターやスタンバイ コンピューターなどのダウンタイムを回避する適切な手法を利用できるようにしておく必要があります。詳細については、「ArcGIS Enterprise における高可用性の実現」をご参照ください。
1 つ以上のステージング環境でテストしてから、運用システムのソフトウェア、アプリ、構成、またはネットワークを変更してください。
負荷分散
ロード バランサーは、クライアントとサーバーの中間位置に配置します。通信内容を識別してから受信し、正しい宛先コンポーネントに渡すことで、利用可能な計算リソース全体にクライアントのワークロードを分散します。この動作により、サーバーのセキュリティが向上し、システム使用量が分散され、サービスの運用が簡素化します。
ArcGIS Enterprise プラットフォームには、独自のロード バランサー コンポーネントである ArcGIS Web Adaptor が存在し、ArcGIS Server サイトと ArcGIS Enterprise ポータルへのトラフィックを処理できます。ArcGIS Web Adaptor は、サーバー サイトまたはポータルをインストール先の Web サーバーと統合し、追加のロード バランサーがない場合に着信トラフィックを処理して、Web 層認証を実施できます。
Web Adapter インスタンスは、ラウンドロビン パターンを使用して、受信リクエストを複数コンピューターの ArcGIS Server サイトに分散します。簡単な構成の場合は、配置に Web Adapter インスタンスを含めることをお勧めします。
高度な構成の場合、サードパーティのロード バランサーを使用するほうが効果的な場合があります。これらのコンポーネントは、カスタム ロジック (ラウンドロビン以外のパターンでリクエストを分散) を使用したり、非対称の負荷を管理したり、リバース プロキシなどのセキュリティ対策を追加したりでき、ArcGIS Web Adaptor 機能よりも優れています。サードパーティのロード バランサーを使用することで、組織は高度なビジネスおよび技術要件に対処できます。
ArcGIS Enterprise 配置では、ArcGIS Web Adaptor コンポーネントかサードパーティのコンポーネントかにかかわらず、常に 1 つ以上のロード バランサーを使用する必要があります。ロード バランサーを使用することで、システムへの入口ポイントの数を制限し、ネットワークの内部トポロジを隠すことができるため、運用を簡素化できます。
コンテンツの配信
ArcGIS Enterprise はそれ自体で完全な Web GIS プラットフォームとして使用できますが、ArcGIS プラットフォーム全体とシームレスに連携できるように設計されています。GIS 専門家は、ArcGIS Desktop と ArcGIS Pro を使用してコンテンツを作成し、ArcGIS Enterprise に共有します。Collector for ArcGIS や Operations Dashboard などのアプリでは、ArcGIS Enterprise ポータルの地理空間コンテンツを強化または追加するワークフローを提供しています。ArcGIS Online を使用すると、独自のデジタル インフラストラクチャを使用せずに、組織の成果をパブリックに公開できます。
組織で ArcGIS プラットフォームの各エレメントをどのように使用しているか、また今後どのように使用していくかについて検討してください。たとえば、フィールド スタッフがモバイル アプリを使用してマップ内のデータを更新する場合、セキュリティへの影響、稼働時間の要件などを把握する必要があります。
組織が、内部ユーザー (GIS アナリスト、データ サイエンティスト、意思決定者など) と、情報を求める外部またはパブリック ユーザーの両方に運用およびトランザクション環境を提供する場合、複数の ArcGIS Enterprise 配置または ArcGIS Online を使用して、個別に環境をセットアップすることを検討してください。
運用およびトランザクション ユーザーを、情報を求めるパブリック ユーザーから分離することで、外部ユーザーによる内部コンテンツへの不適切なアクセスを防ぎ、インフラストラクチャへのトラフィックの影響を軽減できます。
ワークロードの分離
組織には、ArcGIS Enterprise 配置で異なるタイプの作業を実行する複数のグループが存在することがあります。多くの場合、各機能のリソース要件や、成果を管理する期待値または契約内容は異なります。たとえば、強力なジオプロセシング リソースへのアクセスが一時的に必要になる GIS 分析チームもいれば、処理量の低いマップやアプリに常時アクセスが必要になる意思決定支援チームもいます。
ArcGIS Enterprise 配置の計画段階で、システムを使用する各運用グループのニーズと使用パターンを調査します。次に、ワークロード トラフィックを適切なサーバー リソースに割り当て、リソースの使用状況に基づいてさまざまな地理空間機能を分離できます。
組織のさまざまな地理空間機能のワークロードを分離した場合、あるグループが行った作業が別のグループの利用可能なリソースに影響を与えることはありません。このことは、SLA で組織の GIS 運用の一部またはすべてを管理する場合に重要です。ユーザーに一定レベルの可用性を提供する義務がある場合、コンピューター リソースを分離することで、他のグループの作業がユーザーの利用可能なリソースを妨害するリスクが軽減されます。
ワークロードを分離する手法
ワークロードを分離する最も一般的な方法は、複数の ArcGIS Server サイトを配置することです。サイトは、同等の条件で動作する ArcGIS Server コンピューターのコレクションです。サイトに渡されたリクエストは、任意のコンピューターに割り当てられます。
複数のサイトが配置されている場合、ロード バランサーがリクエストのタイプまたは送信者に基づいて、リクエストをサイトにルーティングできます。これにより、リソースの競合からタスクが保護されます。たとえば、ある ArcGIS Server サイトですべてのジオプロセシング タスク リクエストを受信し、別のサイトですべてのマップ サービス リクエストを受信することができます。大規模なジオプロセシング タスクが実行されている場合でも、組織のマップ サービスは影響を受けません。その逆も同様です。
ロード バランサーを使用してすべてのリクエストを処理することで、システムの制御、柔軟性、および安定性が向上するだけでなく、ユーザーがサーバー コンピューターに直接アクセスすることを防ぐことができ、セキュリティが向上します。
個別のワークロードに複数の ArcGIS Server サイトを実装することで、さまざまな性能を持つコンピューターのグループを異なるサイトに割り当てることができます。これは、あるサイトで実行されているタスクが、別のサイトで実行されているタスクよりも計算負荷が高い場合に役立ちます。計算リソースを最大限に活用して、最高レベルのパフォーマンスを実現できます。