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