ArcGIS GeoEvent Server を配置する場合、リアルタイムの可視化および解析のユース ケースに固有のシステム アーキテクチャを設計し、計画することが重要になります。 これには、ハードウェア コンポーネント、ソフトウェア コンポーネント、およびこれらのコンポーネントの接続が含まれます。 システム上で作業するユーザー、アクセス要件、およびシステムの最適な実行を維持するために、それらのユーザーが従う必要があるベスト プラクティスという、人的要素も含まれます。
最終的に、より適切な情報に基づく決定につながる組織のワークフローを可能にする方法で、リアルタイムのビッグ データのコンテンツを取り込み、解析し、エンド ユーザーに広めるために、GeoEvent Server を配置します。 これらのさまざまなワークフローおよびユース ケースすべてにわたって完全性を保証するように、配置を設計する必要があります。
リアルタイムの可視化および解析のワークフローは、多くの場合、異なる解析要件と共に、複数のデータ フィードをサポートすることを含みます。 各ワークフローは、通常、システム リソースに対して異なる影響を与えます。 この柔軟性のレベルでは、計画段階で特定のワークフローおよびユース ケースを定義し、それらの要件を満たすシステムを構築することが重要になります。
下記のベスト プラクティスは、運用のパフォーマンスおよび信頼性のために、効果的な方針を用いてシステム アーキテクチャを計画し、設計し、配置することに役立ちます。
環境分離
運用環境内の GeoEvent Server をホストするシステムは、開発中のシステムおよびテスト中のシステムから分離した環境内にある必要があります。 この方法は、環境分離と呼ばれます。これによって、エンド ユーザーが依存しているリアルタイム サービスの意図しない更新または削除のリスクを減らします。
開発、ステージング、および運用
環境分離の一般的なモデルには、開発、ステージング、および運用の 3 層が含まれます。 最低限、これら 3 つの層の実装がベスト プラクティスであり、開発およびテストの実践に応じて、追加の層が必要になることがあります。
開発環境では、GeoEvent Server 管理者が、エンド ユーザーに影響を与えることなく、新しいリアルタイム サービスの開発および実装に取り組むことができます。 この専用のサーバー環境は、通常、単体テスト、新しいイベント処理ワークフローの作成、新しいワークフローと機能の作成および配置に使用されます。 変更によって生じるリスクのレベル、コンテンツ作成者の数、およびシステムの停止とダウンタイムが引き起こす影響の可能性に応じて、環境のサイズと複雑さが決まります。
ステージング環境は複数構築でき、運用環境からは分離されていますが、可能な限り運用環境を反映しています。 これによって、システムおよびリアルタイム サービスに伴う問題が、運用環境に配置される前に検出されることを保証します。 たとえば、車両の位置を追跡し、サービス車が施設に入ったときに警告する場合、ステージング環境がそれと同一のワークフローを複製する必要があります。 ベスト プラクティスとして、ソフトウェア、アプリ、構成、およびネットワークを、運用環境に配置する前に、ステージング環境でテストします。
運用環境は、組織のワークフローをサポートするリアルタイムのレイヤー、マップ、およびアプリをエンド ユーザーに提供するシステムです。 許容されるダウンタイム レベルを定義したサービス レベル契約 (SLA) が存在する場合があります。 運用環境の可用性を常に監視し、バックアップ コンピューターやスタンバイ コンピューターなどのダウンタイムを回避する適切な手法を検討する必要があります。
GeoEvent Server 構成の同期
階層化されたシステムで GeoEvent Server の構成を管理するには、必要な変更を各層に対して手動で更新するか、GeoEvent Server 構成ファイルを使用します。 手動による方法は実行可能ですが、GeoEvent Server の構成をエクスポートしてインポートすることが、異なる層を更新するための最も簡単な方法です。
構成ファイルは、XML で書式設定されたテキスト ファイルであり、サーバー名などのキー文字列を更新する必要がある場合は、テキスト エディターで編集できます。 また、GeoEvent Server 構成ファイルをインポートする際には選択的インポートを実行でき、これには 2 つの利点があります。 1 つ目は、更新されたコンポーネントのみをインポートすることを選択できることであり、これによって、ターゲットの構成に対する影響を少なくすることができます。 2 つ目は、新たにインポートされる構成に関連する問題が、それらの変更に分離され、トラブルシューティングを分離できるということです。
新しい構成をインポートする前に、層の構成のバックアップを作成することをお勧めします。 これによって、必要な場合に前の構成に戻すことができるようになります。 GeoEvent Server は、デフォルトで毎晩、自動バックアップを作成しますが、新しい構成をインポートする前に、構成をエクスポートすることをお勧めします。
構成の管理の詳細については、「構成」をご参照ください。
負荷分散
ロード バランサーは、受信イベント フィードと送信イベント フィードの両方のために、クライアントとサーバーの間の中間に位置することができます。 通信内容を識別してから受信し、正しい宛先コンポーネントに渡すことで、利用可能な計算リソース全体にクライアントのワークロードを分散します。 この動作により、ロード バランサーは、サーバーのセキュリティを向上させ、システム使用量を分散し、サービスの運用を簡素化します。
GeoEvent Server は、受信イベント フィードのロード バランサーとして ArcGIS Web Adaptor を使用できません。 GeoEvent Server の配置の負荷を分散する場合、他のサードパーティの技術を利用する必要があります。 イベント フィード自体の性質が、配置する必要のある負荷分散の戦略を決定します。
これらの方針の詳細については、「スケーラビリティ、信頼性、および復元性に関する方針」をご参照ください。
送信イベント フィードの場合、標準的なサードパーティのロード バランサーを使用して、対象のサーバー間でイベントの負荷を分散することができます。 対象のシステムが ArcGIS Enterprise である場合、複数コンピューターの GIS サーバー サイトと結合された ArcGIS Web Adaptor を使用して、スケーラビリティおよび信頼性を改善することができます。
ArcGIS Web Adaptor インスタンスは、ラウンドロビン パターンを使用して、受信リクエストを複数コンピューターの ArcGIS Server サイトに分散します。 簡単な構成の場合は、配置に ArcGIS Web Adaptor インスタンスを含めることをお勧めします。
GeoEvent Server のより高度な構成の場合、サードパーティのロード バランサーを使用するほうが効果的な場合があります。 これらのコンポーネントにより、カスタム ロジック (ラウンドロビン以外のパターンでリクエストを分散) を使用したり、非対称の負荷を管理したり、リバース プロキシなどのセキュリティ対策を追加したりすることが可能になります。 サードパーティのロード バランサーを使用することで、組織は高度なビジネスおよび技術要件に対処できます。
ArcGIS Enterprise 配置では、ArcGIS Web Adaptor かサードパーティ コンポーネントかにかかわらず、1 つ以上のロード バランサーを使用することをお勧めします。 ロード バランサーを使用することで、システムへの入口ポイントの数を制限し、ネットワークの内部トポロジを隠すことができるため、運用を簡素化できます。
ワークロードの分離
組織には、GeoEvent Server 配置で異なるタイプの作業を定義する複数のチームが存在することがあります。 多くの場合、各チームのリソース要件や、成果を管理する期待値または契約内容は異なります。 たとえば、パブリックなリクエストを消費し、イベント量における大きな急上昇を表示するあるイベント フィードは、強力なリソースへの不定期なアクセスを必要とすることがありますが、車両の隊列を追跡する安定したイベント フィードは、あまりリソースを使用しないマップおよびアプリへの一定のアクセスを必要とすることがあります。
GeoEvent Server 配置の計画段階の間に、システムで実装される各イベント フィードの必要性および使用パターンを識別します。 次に、リアルタイム イベント処理の作業負荷を適切なサーバー リソースに割り当て、リソースの使用に基づいて異なるリアルタイム サービスを分離します。
組織のさまざまなリアルタイム サービスの作業負荷を分離した場合、ある一連のサービスが行った作業は、別の一連のサービスの利用可能なリソースに影響を与えなくなります。 このことは、SLA で組織のリアルタイム GIS 運用の一部またはすべてを管理する場合に重要です。 ユーザーに一定レベルの可用性を提供する義務がある場合、コンピューター リソースを分離することで、各チームの作業が他のリソースに影響を与えるリスクを減らします。
作業負荷の分離手法
作業負荷の分離は、通常、複数の GeoEvent Server コンピューターを並べて配置することによって行われます。 その後、各 GeoEvent Server コンピューターは、特定のユース ケースにサービスを提供すること、または類似する要件持つ特定のイベント フィードを操作することに専念します。
複数の GeoEvent Server コンピューターが配置された場合、各 GeoEvent Server コンピューター上でリアルタイム サービスを構成することによって、イベント データを異なるコンピューターに送信できます。また、イベント データまたはワークフローのソースの種類に基づいてイベント データを分散するロード バランサーなどのイベント ルーティング技術を利用することによって、イベント データを異なるコンピューターに送信することもできます。 これによって、異なるコンピューター間でのリソースの競合を効果的に減らします。 たとえば、ある GeoEvent Server コンピューターが、車両位置データを受信して必要なリアルタイム解析を実行し、別のコンピューターが、支援のために、すべての行政相談を受信して管理するとします。 この例では、組織の車両位置追跡ワークフローは、大規模な天気事象の間に送信される可能性のある行政相談の流入による影響を受けません。 ロード バランサーを使用してデータ フィードを管理することによって、イベント データの柔軟な制御を可能にし、さらに、システムの安定性を促進します。 ロード バランサーを使用することの 1 つの欠点は、システム アーキテクチャの複雑さが増し、構成および維持のための追加のツールおよびスキルが必要になることです。
作業負荷の分離のために複数の GeoEvent Server コンピューターを配置することによって、さまざまなリソースを含むコンピューターを異なるイベント フィードに割り当てることができます。 これは、あるフィードに対して実行されるイベント処理が、別のフィードに対して実行されるイベント処理よりも計算負荷の高い場合に役立ちます。