ArcGIS GeoEvent Server システムのシステム アーキテクチャを計画し、設計する際に考慮するべき主要な概念の 1 つは、作業負荷の分離 (GeoEvent Server の用語では、イベント分割と呼ばれる) です。 イベント分割では、各イベント ストリームが、下の表内の正しいボックスに配置される必要があり、理想的な運用システムのアーキテクチャでは、分離した GeoEvent Server システムを使用して各セルのアドレスを指定するように計画する必要があります。 この方針を用いて、異なるイベント ストリームの特定の課題に対処するために、最適化されたシステムを配置できます。 最適なシステム アーキテクチャは、システム管理、ライセンス、およびハードウェアのコストの複雑さに対応する必要があります。
運用環境では、専用の分離した GeoEvent Server コンピューター上で、各ボックスに共通するイベント ストリームを分割するよう努力する必要があります。 合計 4 つの考慮するべき可能性のあるシナリオがありますが、下で説明されている追加の分割方針によって、シナリオの数が増えることがあります。 基礎となるシナリオの各々を構成する概念の概要を、以下で詳しく説明します。
- シナリオ 1 - イベントのプッシュ + 履歴に依存する
- シナリオ 2 - イベントのプル + 履歴に依存する
- シナリオ 3 - イベントのプッシュ + 履歴に依存しない
- シナリオ 4 - イベントのプル + 履歴に依存しない
イベントの配信
GeoEvent Server は、プッシュまたはプルのいずれかを使用してイベント ストリームを受信しています。
イベントのプッシュ
一例として、[TCP ソケットからテキストを受信] 入力コネクタまたは [REST エンドポイントで JSON を受信] 入力コネクタを使用しているとき、データは GeoEvent Server にプッシュされています。 入力が作成されると、その入力はデータが到着するのを待ちます。 データ ソースがデータを生成し、各イベント (またはイベントのセット) を GeoEvent Server にプッシュします。 この区別によって、システム設計者は選択した方針に従って受信メッセージを傍受しルーティングするシステムを設計できるため、重要です。
イベントのプル
一例として、[外部 Web サイトをポーリング (XML)] 入力コネクタまたは [ArcGIS Server をポーリング (フィーチャ サービス)] 入力コネクタを使用しているとき、GeoEvent Server はイベント データをプル (またはポーリング) しています。 リクエストが定期的にデータ ソースに送信され、応答には、処理されるべき 1 つ以上のイベントが含まれます。 データをポーリングしている場合、メッセージが GeoEvent Server に到着する前にそれらを傍受する機会はありません。 その場合、データを分割し、イベントの複製を処理するためのアーキテクチャの方針を検討することが重要になります。
イベントの履歴の依存性
可用性の高いアーキテクチャの選択は、イベント データの履歴の依存性の性質による影響を受けることがあります。
履歴に依存しないイベント
GeoEvent Server で実行されるほとんどのリアルタイムの処理および解析は、履歴に依存しません。 各イベントは、以前のイベントの知識なしで個別に処理されます。 各イベントは、独立したエンティティとして扱われ、同一の構成を持つ任意の GeoEvent Server インスタンス上で処理できます。 複数のコンピューターにわたるイベントの作業負荷のバランス調整の従来の方針は、このような状況において適切に機能することができます。
履歴に依存するイベント
空間処理の開始および終了などの、GeoEvent Server で実行される一部のリアルタイムの処理および解析は、以前のイベントの知識を必要とします。 どちらも、現在のイベントに対して正確な結果が決定される前に、以前のイベントの位置の知識が必要です。 GeoEvent Server は、コンピューター間でこのイベントの履歴のコンテキストを共有するための手段を提供しないため、イベントを、そのイベントの以前の知識を持っているコンピューターに ([トラック ID] に基づいて) ルーティングすることが不可欠です。 システム アーキテクチャに関して、トラック ID に基づいてイベントをルーティングできるようにするために、可用性の高いシステムを設計する必要があります。
追加の作業負荷の分離に関する考慮事項
異なるシステムにわたってイベントを分割するための上記の方針に加えて、データ自体の性質を確認することも重要です。 異なるチーム、プロジェクト、またはイベント データの地理的位置が、データの分割方法に関する追加の洞察を提供できるということがわかる場合が、よくあります。 たとえば、異なるチームまたはプロジェクトは、データ処理に関して異なる要件を持っていることがあります。または、データが大きいエリアにわたって地理的に配置されている場合、そのデータを複数の領域に分割できます。
イベントの負荷
イベント ストリームを分割する場合、考慮する必要のある最初の概念は、イベントの負荷です。 イベント ストリームの負荷は、データが入力コネクタに到着する方法および速度によってだけでなく、特定の期間にわたって到着するイベントの数によっても定義されます。 特定のイベントの負荷の種類 (均一な負荷と不均一な負荷) に基づいて、分離した GeoEvent Server システム上でイベント ストリームを分割することをお勧めします。 イベントの処理中に、不均一な負荷は、より多くのシステム リソースを必要とし、イベント ストリームの負荷に関するリソースの競合を引き起こすことがあります。 このため、均一な負荷のイベント ストリームと不均一な負荷のイベント ストリームを、異なる 2 つのシステム上で分離することをお勧めします。
均一なイベントの負荷
均一なイベントの負荷は、一貫性のある均一なペースで、イベントを GeoEvent Server の入力に供給します。 均一なイベントの負荷は、通常、一定の速度でデータを生成するシステムから送信されます。 例:
- 各車両が 30 秒ごとにその位置を報告する自動車両位置 (AVL) イベント ストリーム。
- 各ゲージが 60 分ごとに河川の高さのデータを報告する流量計ネットワーク。
均一なイベントの負荷を処理する場合、GeoEvent Server が一定のレベルで動作するということが予想されます。 この場合、CPU またはメモリにおける急上昇は予想されないため、システムは、均一な負荷に対して設計されるべきです。
不均一なイベントの負荷
不均一なイベントの負荷では、イベントは、不均一な速度で GeoEvent Server の入力に到着します。 これらの急激に変化するタイプのイベントの負荷は、大量のイベントが入力のメッセージ キューに配置され、処理されるのを待つことを引き起こす可能性があります。 例:
- ある地域全体の落雷を報告する雷追跡システム。
- 各スクーターが運用中であるときに、スクーターの状態をプッシュするレンタル スクーター システム。
不均一なイベントの負荷を処理する場合、急激に変化する各イベントのセットの到着時に、システム リソースが大量に使用されることが予想されます。 このとき、CPU が 100% に急上昇することがあり、メモリが一時的に増加することがあり、Kafka Topic (メッセージ キュー) が非常に多くのディスク容量 (デフォルトの 3 倍または 4 倍) を必要とします。 この処理時間の間に、GeoEvent Server が大量のイベントを処理しているため、システム上の他のイベント ストリームのリソースが不足することがあります。 このデータを処理する目的に応じて、次の急上昇が到着する前に、過不足のない時間内でイベントの急上昇を処理するように、システムを設計できます (最小システム要件、ジャストインタイム処理)。 または、望ましい最大速度でイベントの処理を可能にするために、追加リソースをシステムに割り当てることができます (最大システム要件、重大イベント処理)。