サイロ ストラテジー
サイロ ストラテジーは、分割を使用して、複数の ArcGIS GeoEvent Server コンピューターでの作業負荷の分離を実現します。 イベント ストリームの読み込み、イベント履歴の依存関係、およびイベント配信方法を使用する分割方針に基づいて、各サイロの構成において、制約されたタスクのセットが定義されます。 サイロ内で、GeoEvent Server コンピューターは、他のコンピューターを検出せず、各コンピューターは、別々に受信するイベントを処理します。 通常、サイロ ストラテジーは、信頼性またはスケーラビリティが重視される状況において使用されます。 加えて、サイロ ストラテジーは、それ自体が負荷分散の方針を意味するものではありません。 詳細については、以下の「イベント ルーティング ストラテジー」をご参照ください。
サイロの複製: アクティブ/パッシブ
アクティブ/パッシブ サイロ アーキテクチャでは、2 台以上の同一のコンピューターが構成されます。 1 台のコンピューターが「アクティブ」として識別され、一方、他の「パッシブ」コンピューターが、電源がオフにされるか、何らかの方法で分離されます。 アクティブ コンピューターが故障した場合、パッシブ コンピューターが選択され、新しいアクティブなシステムとしてアクティブ化されます。 フェイルオーバーを管理するためのメカニズムは、このドキュメントの対象外ですが、手動で実現することができます。または、ほとんどの仮想環境において一般的であるように、自動化された方法で実現できます。
サイロの複製: アクティブ/アクティブ
アクティブ/アクティブ サイロ アーキテクチャでは、一連のコンピューターが、完全に同じように構成され、並列に動作することができます。 どのコンピューターも、アクティブまたはパッシブとして識別されず、一連のコンピューター全体が同時に動作します。 すべてのコンピューターが並列に動作するため、フェイルオーバーの方針は不要ですが、コンピューターのプールが期待通りに動作していることを確認するために、コンピューターの故障の監視が依然として必要です。
アクティブ/アクティブ環境に固有の問題は、データの重複です。 N 台のコンピューターのセットが完全に同じように構成されている場合、各イベントが、N 回、並列に処理されると期待されます。 この追加の負荷は、データベースやネットワークなどの関連するシステムに負担をかける可能性があります。 レコードを一意に識別するための方法は、データが送信先に到着した後のデータの重複排除において重要になることがありますが、システムに対する全体的負荷を減らしません。
イベント ルーティング ストラテジー
イベント ルーティング ストラテジーは、バランサー コンポーネント (通常はロード バランサーまたはルーティング可能なメッセージ キュー) をシステムに追加することによって、サイロ ストラテジーの上に構築されます。 アーキテクチャにおいて、完全に同じように構成された一連の GeoEvent Server コンピューターの前にロード バランサーを組み込むことによって、イベントを、同じサービスを含むコンピューターに個別にルーティングすることができます。 この方法では、コンピューターがグループとして動作し、ロード バランサーが、イベントを各コンピューターに送信する役割を担います。 通常、イベント ルーティング ストラテジーは、回復力またはスケーラビリティが主な目的である状況において使用されます。 この方針では、イベント データがサイトに (プルではなく) プッシュされる必要があります。
注意:
イベントをプルする GeoEvent Server のデプロイメントは、外部のロード バランサーまたはメッセージ キューに依存する最初の 2 つのイベント ルーティングの方針を使用できません。 GeoEvent Server のデプロイメントがデータをプル (ポーリング) している場合は、下の「イベント分割を使用したサイロの複製」をご参照ください。
ロード バランサー
ロード バランサーを使用して、完全に同じように構成され、アクティブに監視されている複数の GeoEvent Server コンピューター全体にわたって、プッシュされるイベントのセットのバランスを調整することができます。 イベントの到着時に、ロード バランサーは、各イベントをクラスター内の異なるコンピューターに割り当てます。 基本的に、このサイト構成は、前方にあるロード バランサーと、その後方にあるアクティブ/アクティブ構成でサイロ化された一連の GeoEvent Server コンピューター (それぞれ、完全に同じように構成されている) とで構成されます。
メッセージ キュー クラスター
Kafka クラスターをアーキテクチャに追加して、アクティブに監視されている複数の GeoEvent Server コンピューター全体にわたって、プッシュされるイベントのセットのバランスを調整することができ、それらの各コンピューターは、異なる構成を有することができます。 イベントの到着時に、Kafka クラスターは、イベントの一意の識別子に基づいて、各イベントを異なるメッセージ トピックに割り当てます。 各 GeoEvent Server コンピューターは、1 つ以上のメッセージ トピックを監視し、イベントを処理します。
基本的に、このサイト構成は、前方にある Kafka クラスターと、その後方にあるアクティブ/アクティブ構成でサイロ化された一連の GeoEvent Server コンピューターとで構成されます。 この構成は、各イベントを特定の GeoEvent Server 構成またはコンピューターにルーティングできるという点が、上のロード バランサーの解決策と異なっています。 この構成は、履歴の依存関係を使用してイベントを処理する場合に有利です。
イベント分割を使用したサイロの複製
サイロの複製を使用するイベント分割は、サイロ アーキテクチャのパフォーマンスをスケール アウトする場合に使用できる特殊な方法です。 イベントがプッシュされるのではなく、GeoEvent Server によってプルされている場合に特に役立ちます。
サイロ化された各コンピューターは、処理ワークフローに関して完全に同じように構成されていますが、処理対象のイベントの特定のサブセットが、各コンピューターに割り当てられています。 通常、この構成は、通常はイベント データのトラック ID または何らかのその他のグローバル一意識別子に基づいて、イベント データの構成されたサブセットを要求するか、承認するように、個別のコンピューターの構成を変更することによって実現されます。 このシナリオでは、たとえばクエリ リクエストで WHERE 句を使用して、イベント ストリームを分割する必要があります。