設計は各アーキテクチャーの柱ごとの基準を満たしている必要があります。 各柱に関連する推奨プラクティスの一部を以下に示しますが、これらはアーキテクチャー上のすべての設計上の考慮事項を網羅しているわけではありません。 詳細については、データ編集および管理システム パターンの考慮事項をご参照ください。
また、追加の推奨事項については、物理的設計に関する検討事項もご参照ください。
パフォーマンスとスケーラビリティーの観点から、このアーキテクチャーは、進化するワークロードの要求に対応しながら、ユーザーのシステムに対する全体的なエクスペリエンスを最適化することを目的としています。 ネットワーク情報管理システムは、一貫したパフォーマンス指標で編集エクスペリエンスを提供し、エンドユーザーの効率を向上させるポジティブなエンドユーザー エクスペリエンスを提供する必要があります。 以下に概説するパフォーマンス改善の実践に加えて、リレーショナル データベースのパフォーマンス管理も、ネットワーク情報管理システム全体のパフォーマンスを左右する大きな要因です。
ワークロードの分離は、コンピューティング リソースの最適な分散に重点を置いた設計アプローチです。 たとえば、ネットワーク情報管理システムの編集リクエストの中には、標準のマップ リクエストよりも処理に時間がかかるものがあるため、編集ワークロードでは、個別の専用コンピューティング リソース (ArcGIS GIS Server サイトなど) が役立つ場合があります。 ワークロードの分離というこのアプローチは、実行時間の長いリクエストと短いリクエストを分離するのに役立つため、編集者には専用のリソースが与えられ、閲覧者が時間のかかるトランザクションの影響を受けることもありません。 この分離を実装すると、リソースの競合が減少し、システムのスケーリングが容易になるため、両方のグループのシステム パフォーマンスが向上する可能性があります。リソースはどちらのサーバーサイトにも追加でき、水平方向または垂直方向にスケールできます。 ワークロードの分離には、次のようにいくつかの形式があります。
コンポーネント別 コンポーネントを異なる仮想マシンまたはコンピューティング インフラストラクチャーに分離することで、個々のコンポーネントがシステム リソース競合を避けることができます。 ArcGIS Enterprise は、1 つのシステムに複数のコンポーネントをインストールして構成することをサポートしていますが、適切に設計された運用システムでは一般的に推奨されません。
サービス タイプ別 ArcGIS Server コンポーネント内のこのアーキテクチャーには、別のワークロード分離アプローチ (サービス タイプ別のワークロード分離) が適用されます。 別々の GIS Server サイトで Utility Network ワークロード、およびホストされたサービスまたはマッピングのワークロードをサポートします。
コロケーションは、システム コンポーネントを同じデータ センター、同じサブネットワークにデプロイする設計アプローチであり、ネットワーク全体の通信距離を短縮することでネットワーク遅延を短縮します。 一般に、一般的な GIS 操作では、ネットワーク帯域幅よりもネットワーク遅延の方がエンドユーザー エクスペリエンスに大きな影響を及ぼします。 この領域での別の考慮事項は、ユーザーとクライアント コンピューターの位置です。ユーザーの接続の遅延が長い場合、システム コンポーネントをコロケーションしても、システムの操作エクスペリエンスが向上する可能性が高くなります。 場合によっては、低速または過負荷のネットワーク経由で接続する物理ハードウェアよりも、シン クライアントまたはリモート アクセスの使用が望ましい場合があります。
信頼性は、システムがビジネス、顧客、関係者が求めるサービス レベルを提供することを保証するものです。 ビジネス クリティカルまたはミッション クリティカルなエンタープライズ システムとして、ネットワーク情報管理システムは常にデータのバックアップを必要とし、多くの場合、システム コンポーネントのバックアップが必要です。 より高いレベルのアップタイムを実現するために、高可用性構成が必要になる場合もあります。
可用性の期待、要件、またはコミットメントがあるエンタープライズ システムでは、明確に定義され、実行可能で、十分にテストされたバックアップ手法が不可欠です。 ネットワーク情報管理システムでは、少なくとも ArcGIS Utility Network のデータ レベルのバックアップが不可欠です。 組織の要件によっては、他のシステム コンポーネントのバックアップも必要になる場合があります。 バックアップの戦略と方法の詳細については、バックアップと障害復旧をご参照ください。
高可用性は、特定の期間にわたって、事前に設定された運用パフォーマンスのレベルを満たすようにシステムを構築することを目的とした設計アプローチです。 高可用性システムには、目標とするサービス レベル契約 (SLA) に見合った冗長性、システム モニタリング、自動化が必要です。 冗長性には、ネットワーク接続、電力の安定供給、データセンターの冷却体制、システムの保守スキルを持つスタッフへのアクセスなど、さまざまなコンポーネントが含まれる場合があります。 自動化は、停止を回避するためにモニタリングに基づいてアクションを実行するように設計されている場合があります。 詳細については、可用性の高い ArcGIS Enterprise コンポーネントの構成をご参照ください。
高可用性構成はシステムのインフラストラクチャー コストと運用コストを大幅に増加させるため、成功には専門的なスキルが必要となる点にご留意ください。 高可用性の設計には、人材、プロセス、テクノロジー、ガバナンス全体にわたる運用上のコミットメントが求められます。
可観測性はシステムの状態を可視化し、運用スタッフやその他の技術担当者がこのシステムを正常かつ安定した状態で稼働させ続けることを可能にします。 システムの可用性、パフォーマンス、使用状況のモニタリングはネットワーク情報管理システムにとって極めて重要です。 ArcGIS Enterprise ソフトウェアをモニタリングするだけでなく、Windows または Linux オペレーティング システム、データベース、その他のデータ ストア、コンピューティング、ネットワーク、セキュリティー境界、その他の関連コンポーネントなど、すべてのサポート コンポーネントとインフラストラクチャーをモニタリングすることが重要です。
エンタープライズ システムの構築と運用を成功させるためには、どの組織にもエンタープライズ IT のモニタリングと対応のフレームワークが必要です。 システムのプロアクティブなモニタリングは事後対応型の問題解決と同じくらい重要であり、テレメトリーを効果的にキャプチャーすることで、いつでもシステムの状態を把握し、システムの傾向的な動作を特定できます。
ArcGIS Enterprise on Windows/Linux は、サーバー ログやサーバー統計情報など、さまざまな方法で監視が可能です。 ArcGIS Enterprise ソフトウェアをモニタリングするだけでなく、Windows または Linux オペレーティング システム、データベース、他のデータ ストア、コンピューティング、ネットワーク、セキュリティー、他のインフラストラクチャーなど、すべてのサポート コンポーネントとインフラストラクチャーをモニタリングすることが重要です。
可観測性の重要な側面は、システム上の実際のユーザー アクティビティーを表すテレメトリー、データ、または情報の使用にあります。 デスクトップ クライアント コンピューターを含む、設計のすべてのコンポーネントでテレメトリーをキャプチャーすることは、システムのパフォーマンスと使用率を理解するには不可欠です。これは、システムを最適化するためのボトルネックと機会を特定することを目的としています。
リファレンス アーキテクチャーでは、テレメトリー キャプチャー メカニズムは ArcGIS Monitor で表されます。 この方法でキャプチャーされる重要なシステム特性には、次のようなものがあります。
テレメトリー出力は、必ずしもユーザー エクスペリエンス全体を捉えるものではないことに注意してください。 アプリケーションのエンド ユーザー (デスクトップ、Web、モバイル アプリを使用しているユーザーなど) と連携して、テレメトリー キャプチャーに加えてワークフローの実行エクスペリエンスを観察することを検討してください。
セキュリティーはシステムと情報を保護します。 ネットワーク情報管理システムのセキュリティー設計に関する考慮事項は、ユーザー認証、システム承認、データとアクセス制御、ユーザー アクティビティーとシステム構成変更の監査に関する重要な考慮事項など、システム パターンのセキュリティー要件と密接に関係しています。
統合により、このシステムを他のシステムと接続して、エンタープライズ サービスを提供し、組織の生産性を向上させます。 ネットワーク情報管理システムは通常、エンタープライズ資産管理 (EAM) システム、顧客関係管理 (CRM) システム、高度な流通管理 (ADMS) システムなどの他のシステムとのデータのやり取りや整合性の確保に対応する必要があります。 ネットワーク情報管理システムの統合要件は、データ編集および管理システムのパターンと密接に関係しています。
ネットワーク情報管理システム固有の統合に関する考慮事項には、次の点があります。
| 統合タイプ | 備考 |
|---|---|
| データ | ターゲット システムでは、ネットワーク データを独自の形式/システムでローカルに利用できるようにする必要があります。 |
| サービス | ターゲット システムは、RESTful API 呼び出しを介してネットワーク情報管理システムと統合できます。 |
| アプリケーション | ターゲット システムには、ArcGIS Maps SDK for JavaScript で構築されたカスタム ウィジェットなど、ソース システムのアプリケーションレベルの機能が必要です。 |
自動化は、手動によるデプロイメントと運用タスクに費やす労力を削減することを目的としており、運用効率の向上と、人為的なエラーによるシステム異常の減少につながります。 ネットワーク情報管理システムの自動化要件は、データ編集および管理システムのパターンと密接に関係しており、次のようなプラクティスが含まれます。
ここでの物理設計に関する考慮事項は、主に論理アーキテクチャー設計に焦点を当てており、最終的には物理アーキテクチャー設計に変換する必要があります。 Esri は、ネットワーク、ストレージ、システム環境、サイズ設定など、組織の物理設計に関するさまざまな要素の決定を支援するシステム アーキテクチャー設計サービスを提供しています。
物理設計に関連するその他のリソースには、次のものがあります。
GWD (グラフィック ワークの設計) ツールは、ユーティリティー ネットワークのエンジニアリングにおいて不可欠であり、エンジニアリング設計の作成、施工図面の作成、ユニット ライブラリーを用いた建設コストの見積もりなどの専門的な機能を提供します。 これらのツールは CAD の設計ツールと GIS の空間解析を組み合わせ、設計の策定とネットワーク情報管理システムへの統合に役立ちます。
統合方法は、選択した GWD ツールやネットワーク情報管理システムの実装オプションによって異なり、それぞれに特有の設計や容量の考慮事項があります。
GWD の統合を計画する際には、システムの互換性、統合機能、将来的な機能強化に向けたスケーラビリティーなどの要素を考慮することが極めて重要です。 組織は既存のワークフローとの統合のしやすさや、プロジェクト ライフサイクル全体でのデータ更新をサポートできるかどうかを評価する必要があります。 このような点を踏まえることで、設計プロセスが柔軟性を保ち、進化する運用ニーズに対応できるようになります。
ArcGIS 統合オプションは、GWD 設計プロセスの以下の 3 つのフェーズそれぞれで利用可能です:
以下の表は、これらの異なる統合方法とそれに対応するアクションを比較し、各ネットワーク情報管理システムの実装オプションがシステムに与える潜在的な影響を示しています。 この情報は、組織がプロジェクトの要件や運用目標に基づいて最適なアプローチを評価するうえで、参考になることを目的としています。
3 つの ArcGIS 統合方法は以下のとおりです:
サブネットワークのエクスポート - ユーティリティー ネットワークの一部から JSON ファイルに情報を抽出して、ネットワーク データの共有を可能にするプロセスです。 通常は、これによって初期の計算コストは高くなりますが、その後の ArcGIS サービスの使用量は最小限に抑えられます。 データが抽出されると、ユーザーはデータをポストし直すまで、ローカル データで作業を行うからです。
フィーチャ サービスの同期 - 設計ツールが、同期機能を有効にした ArcGIS Server フィーチャ サービスと連携するプロセスです。 ここでも、通常は初期の計算コストは高くなりますが、その後のフィーチャ サービスの使用量は最小限に抑えられます。 この機能により、クライアントはレプリカを要求し、オフラインでデータを処理し、変更内容をエンタープライズ ジオデータベース内のソース フィーチャクラスに同期させることが可能になります。
ライブ接続 - クライアントが編集可能なフィーチャ サービスと直接連携するパターンです。 この統合手法では、フィーチャ サービスのエンドポイントへの常時接続が必要です。
サブネットワークのエクスポート機能は、サブネットワークの再インポート プロセスが GWD ツールを使って行われることを前提としています。 この統合は GWD ツール固有の機能に依存していますが、ここではそのソリューションについて詳しく説明したり、言及することはありません。
組織のワークフローやニーズに最適な統合方法を判断するには、以下の点を確認する必要があります:
| 設計フェーズ | 統合方法 | アクション | システムへの影響 | オプション 1 | オプション 2 | オプション 3 |
|---|---|---|---|---|---|---|
| 開始 | サブネットワークのエクスポート | GWD ツールはサブネットワークのエクスポート リクエストを送信します。 | サブネットワークのエクスポート リクエストは計算負荷が高い場合があります。 複数の同時リクエストに対応するには、容量の増加が必要になることがあります。 このタスクの作業負荷の分離のために、追加の ArcGIS Server サイトを使用することも可能です。 | |||
| 開始 | フィーチャ サービスとの同期 | GWD ツールは UN にレプリカ定義を提供し、UN は ‘createReplica’ 操作を使ってフィーチャ サービスに必要なデータを抽出します。 | 初期同期リクエストは、サブネットワークのエクスポート プロセスを呼び出します。 複数の同時リクエストに対応するには、容量の増加が必要になることがあります。 | |||
| 開始 | ライブ接続 | UN フィーチャ サービスへのライブ接続を利用して、バージョン内で直接 GIS で編集を行います。 | データとのあらゆるやり取りにより、ArcGIS コンポーネントへのリクエストが作成されます。 これには追加の容量が必要になる場合があります。 | |||
| 設計 | サブネットワークのエクスポート | GWD ツールは、ベースマップや参照データセットに対してのみ、ArcGIS サービスにリクエストを送信します。 | この GWD フェーズでは、ArcGIS サービスの使用は最小限に抑えられます。 | |||
| 設計 | フィーチャ サービスとの同期 | 設計ツールは、ベースマップや参照データセットに対してのみ、ArcGIS サービスにリクエストを送信します。 | この GWD 設計フェーズでは、ArcGIS サービスの使用は最小限に抑えられます。 | |||
| 設計 | ライブ接続 | UN フィーチャ サービスへのライブ接続を利用して、バージョン内で直接 GIS で編集を行います。 | データとのあらゆるやり取りにより、ArcGIS コンポーネントへのリクエストが作成されます。 これには追加の容量が必要になる場合があります。 | |||
| 完了 | サブネットワークのエクスポート | GWD ツールは、ワークフローの最後にすべてのアセットを GIS システムに送信します。 | データをシステムに戻す際に、編集操作を多用します。 そのため、多大なリソースを消費する可能性があります。 このタスクの作業負荷の分離のために、追加の ArcGIS Server サイトを使用することも可能です。 | |||
| 完了 | フィーチャ サービスとの同期 | フィーチャ サービスを通じて、切断された ArcGIS レプリカ ジオデータベースからメインのエンタープライズ データベースへ設計済みアセットを一括同期します。 | フィーチャ数によっては、同期には時間がかかり、大量のリソースが必要になる場合があります。 このタスクの作業負荷の分離のために、追加の ArcGIS Server サイトを使用することも可能です。 | |||
| 完了 | ライブ接続 | すべての編集は GIS で行われ、編集内容をエンタープライズ ジオデータベースにプッシュするには、リコンサイルおよびポスト操作のみが必要です。 | すべての編集は GIS で行われ、リコンサイルとポストのみで済みます。 |
含まれる 利用不可
要約すると、サブネットワークのエクスポート方式を採用する場合、開始フェーズと完了フェーズの両方で容量が必要となります。 フィーチャの同期方式では、3 つのプロジェクト フェーズすべてにおいて、同期イベントごとに容量が必要となり、ライブ接続方式では各フェーズのすべての操作で容量の増加が必要になります。 これらの追加容量要件を適切に計画し、選択した実装オプションが GWD 統合方法をサポートできるようにするために、GWD ツールをネットワーク情報管理システムに統合する方法を評価することが重要です。