次の考慮事項は、ArcGIS Well-Architected Framework のアーキテクチャーの柱を中心に構成されています。 これらの各技術領域でベスト プラクティスとアーキテクチャー アプローチを適切に適用することは、Well-Architected システムの設計と実装の成功の鍵となります。
また、追加の推奨事項については、物理的設計に関する検討事項もご参照ください。
ワークロードの分離設計を採用したのは、システム全体にわたるコンピューティング リソースの最適な配分を実現するためです。 このテスト調査では、編集リクエストは全体的に標準のマップ リクエストよりも処理に時間がかかったため、編集ワークロードを別の ArcGIS GIS Server サイトとして専用のコンピューティング リソースで分離する設計が採用されました。
さらに、システム コンポーネント自体を異なるコンピューターに分離することで、システム リソースをめぐる競合を防ぎ、各コンポーネントのシステム要件に合わせてコンピューターの種類とサイズを調整できるようになります。
適切な GPU (グラフィックス処理装置) を選択することは、仮想化環境で ArcGIS Pro のパフォーマンスを確保するうえで不可欠です。 テストの結果、ArcGIS Pro 仮想マシンに専用の GPU を追加すると、エンドユーザーの生産性が大幅に向上し、運用コスト (人件費など) を考慮すると、コスト削減につながることが明らかになりました。
設計上の決定を下す際には、仮想 CPU (vCPU) と物理 CPU の比率を理解して、システム コンポーネントに適切なリソースを割り当てることが重要です。 図のほとんどのインスタンスで、vCPU と CPU の比率は 2:1 ですが、デスクトップのインスタンスは 1:1 です。
仮想化オプションによって、比率が異なる場合があることを考慮してください。 パフォーマンスへの潜在的な影響に加え、Esri のライセンスにも影響を及ぼす可能性があります。 パブリック クラウド比率の例については、以下のリソースをご参照ください。
GIS サービスの適切な構成は、システムのパフォーマンスとユーザー エクスペリエンスの満足度にとって非常に重要です。GIS サービス インスタンスの構成が適切でないと、システムに障害や信頼性の低下を引き起こす可能性があります。 たとえば、マップ サービスやフィーチャ サービスのインスタンス数を少なく設定しすぎると、クライアントの待機時間が長くなり、タイムアウト エラーが発生する可能性があります。 ただし、インスタンス数を高く設定しすぎると、コンピューター リソースが過剰に消費され、固定ハードウェア構成にデプロイできるサービスの数が制限される可能性があります。
最大インスタンス設定が最小設定より大きい場合、システムでは要求に応じて新しいインスタンスを自動的に追加できます。 しかし、新しいインスタンスが起動するまでリクエストが待たされるため、パフォーマンス上の問題になる可能性もあります。 インスタンス数とサーバー リソースを調整して最適なパフォーマンスを実現できるように、どのようなシステムでもサービスの使用状況を理解することが重要です。
このテスト目的のために、各サービスのサービス インスタンスと vCPU (仮想 CPU) の比率を 1:1 に設定し、最小インスタンスと最大インスタンスを同じ値で構成しました。 したがって、GIS とホスティング サーバー サイトにはそれぞれ 8 つの vCPU を持つインスタンスが 2 つずつあり、1 つのサーバー サイトに 16 個のインスタンスが存在していました。 システムが負荷を処理する方法を特定するために、インスタンスの使用状況が監視されました。 GIS サーバー上のすべてのインスタンスが混雑した場合、そのサービスの待ち時間が長くなることが予想されます。
これはテスト システムにおける最適なサービス インスタンス構成でしたが、組織の構成は異なる可能性があります。 監視やテレメトリーの収集は、サービス インスタンス設定を適切に構成するために必要です。 ガイダンスについては「ArcSOC 最適化の手法と技術」をご参照ください。
このテスト調査では、パーセル ファブリックの編集サービスを次のように構成しました:
ホスティング サーバー (表示専用のワークフロー) は以下のように構成されました:
指定されたサービス タイムアウトは次のように構成されました。
テスト プロセス中に発生したタイムアウトに対処するため、タイムアウト構成は反復的に調整されました。 これらの設定は特定の要件によって異なる場合があるため、最適な構成を特定するために独自のテストを実施することをおすすめします。
バックアップは、ほとんどのデータ編集や管理に特化したシステムと同様に、パーセル管理システムにおいても不可欠です。 テストされた設計は運用システムではありませんでしたが、コンピューターのスナップショットとデータベースのバックアップは、テストの実行ごとに、システムに変更を加える前にキャプチャーされました。 仮想マシンのスナップショットは、環境の変更 (コンピューターのサイズ変更、パッチのインストール、Windows の更新など) の前後に取得しました。 その後、次のいずれかを可能にするためにスナップショットがカタログ化されました。
スナップショットだけでは、環境を復旧できない場合もあります。 ArcGIS Enterprise のバックアップ プロセスの概要については「バックアップと障害復旧」をご参照ください。
詳細については、「土地情報管理システムのリファレンス アーキテクチャー」をご参照ください。
このシステムを ArcGIS Enterprise コンポーネントの高可用性構成で設計するという選択は、ビジネスおよび技術的なシステム要件に加え、中断のない運用の実現やダウンタイムの最小化などのその他の組織の目標に基づいて行われました。 この構成は、冗長化されたシステム コンポーネントと、ファイル ストレージ用のクラウドネイティブで高可用性のファイル ストアを備えた設計に示されています。 このテストではテスト目的で高可用性データベースを構成しませんでしたが、クラウドネイティブ サービスなど、リレーショナル データベース ベンダーには高可用性を実現するためのさまざまな方法があります。
高可用性構成は、システムのインフラストラクチャーと運用コストを大幅に増加させる可能性があり、成功のためには専門的なスキルが必要であることに留意してください。 パーセル管理システムの高可用性に関する設計上の選択と考慮事項の詳細についてご参照ください。
システム検証を成功させ、有意義な結果を得るうえで、システム監視とテレメトリー キャプチャーがテスト調査の重要な側面でした。
ArcGIS Monitor に加え、Windows パフォーマンス モニターなどのエンタープライズ IT 監視ツールを使用して、システムのパフォーマンスを監視し、特定の条件下における動作に関するテレメトリーを取得しました。 ログは、以下のシステムコンポーネントから収集されました。
CPU 使用率、RAM 消費量、ディスク アクティビティー、ネットワーク アクティビティーなどのコンピューター レベルの指標は、環境内のすべてのコンピューターで取得されました。 詳細については、テスト結果をご参照ください。
さらに、エンドユーザー エクスペリエンスと生産性を観察および評価するために、実施されたワークフローの画面記録がキャプチャーされました。
テスト調査の範囲は主に負荷テストに重点を置いたものであったため、運用システムに推奨されるほとんどのタイプの自動化 (管理タスクのスクリプト化など) は採用されませんでした。 ただし、環境によっては、管理スクリプトがワークフローと運用に大きな価値をもたらす可能性があります。 運用環境にデプロイする前に、自動化スクリプトを下位の環境でテストする必要があります。
このテストでは、負荷テスト中のリクエストをシミュレートすることを主な目的として自動化を適用しました。 テスト結果に示されているように、さまざまな負荷サイズに適用できる仮想ユーザーによって複数のワークフローが大規模に実行されました。
Python スクリプトを使用して、サービスの待機時間、サービスのインスタンス利用率、応答時間、および失敗したリクエストのパターンを解析、特定することで、必要なシステム変更を通知しました。 Python、PowerShell、SQL の各スクリプトも使用され、負荷テストの完了後にデータベースを元の状態に復元しました。
セキュリティーは、ユーザー認証と承認、フィルター、暗号化、監査、ハードニングなど、あらゆるエンタープライズ IT システムにとって不可欠な要素です。 ArcGIS ソフトウェアは、インターネットから完全に切断されたネットワークを含む、セキュリティーで保護されたネットワーク内で効果的に動作するように構築されています。 運用システムの設計プロセスの早い段階でセキュリティー要件を考慮することが極めて重要です。
セキュリティーはこのテスト調査の主な対象ではありませんでしたが、物理アーキテクチャー図に見られるように、適切なユーザー認証と承認を提供するために ID プロバイダーの使用が含まれています。 サブネット セグメンテーションは、このテスト調査で適用されたもう 1 つの基盤的なセキュリティー手法であり、最小権限とネットワーク隔離の原則に根ざしています。
関連リソース:
統合はこのテスト調査の範囲外でしたが、パーセル管理システムは、多くの場合に CAMA (Computer Aided Mass Appraisal) システムなどの他のエンタープライズ システムとの統合が必要です。 ArcGIS との統合に関する考慮事項の詳細をご参照ください。