ジオイベント サービスの設計におけるアプローチは、ArcGIS Pro の ModelBuilder でのジオプロセシング モデルの開発を反映する必要があります。 基本的には、処理フローによって接続された一連のワークフローを定義します。 これらの操作は、イベント処理ワークフローのレイアウト方法に応じて、連続または並列して発生します。 下した決定は、1 秒間間にジオイベント サービスを通過する、合理的に期待できるイベント レコードの数に直接影響します。 ジオイベント サービスが合理的に処理できるイベント レコードの数を把握するには、ワークフロー操作の数と複雑さを全体的に考える必要があります。
注意:
「GeoEvent Server の概要チュートリアル」に、ジオイベント サービスを作成する手順が詳しく記載されています。 このチュートリアルには、「GeoEvent Server チュートリアル」からアクセスすることもできます。
ジオイベント サービスに含まれるどの操作にも処理を完了するための時間が必要です。 たとえば、フィルタリング操作では、イベント レコードの属性値と閾値を比較してイベントを破棄するか次の処理ステップに渡すかを決めるのに 1 ミリ秒 (またはそれ以下) しかかかりません。 一方、1 つのフィーチャの情報付加操作では、処理の完了に最大 100 ミリ秒かかります。 フィルターのように時間のかからない操作であろうとフィーチャの情報付加のように時間のかかる操作であろうと、1 秒は 1000 ミリ秒です。
次の例について考えます。ジオイベント サービスにおいて、フィルターおよびプロセッサによって与えられる遅延時間の合計が最大 10 ミリ秒であるとします。 そのサービスはジオイベント サービスを通じて 1 秒間に 100 個だけイベント レコードを送ることができます (毎秒 1,000 ms をイベント レコードあたり 10 ms で割ると、1 秒あたり 100 イベント レコードが得られます)。
つまり、ジオイベント サービスで使用されるフィルターとプロセッサが増えるほど、ジオイベント サービスはさらに複雑になります。 ジオイベント サービスが複雑になるほど、各操作での遅延が増え、1 秒間に処理できるイベント レコードの数が少なくなります。 設計し公開するジオイベント サービスが増えるほど、GeoEvent Server 全体で処理できるイベント レコードの数が少なくなります。
GeoEvent Server のメッセージ バス
すべてのジオイベント サービスは共通の基本メッセージ バスを共有します。 したがって、設計するジオイベント サービスは、入力のトピック キューからイベント レコードを取得し処理ワークフローの実行を開始すると互いに競合します。
例として、次の単純なジオイベント サービス A について考えてみましょう。
単独で実行するジオイベント サービス A は平均で 1 秒あたり数千のイベントを処理できます。 ここで、2 つ目の非常に複雑なジオイベント サービスである次の [ジオイベント サービス B] を構成するとします。 このサービスは、ジオイベント サービス A と同じ入力および出力を使用します。
ジオイベント サービス B が開始されると、ジオイベント サービスごとに毎秒数千個のイベント レコードから毎秒わずか数個のイベント レコードに、全体的なイベント レコードのスループットが減少する可能性があります。 2 つのジオイベント サービスは同じ入力と出力を共有しているため、多くのリソースを使用するジオイベント サービスが開始されると、単一のメッセージ バス上での競合により、両方のジオイベント サービスのイベント スループットが低下します。
ジオイベント サービスの合理化と単純化
複数のプロセッサとフィルターを使用してイベント処理ワークフローをモデル化する方がよいかどうか、またはイベント処理ワークフローを単純化してルートおよび分岐をなくす方がよいかどうかというよくある質問があります。 たとえば、上の図の複雑なジオイベント サービス B には、イベントが出力に到着するまでに通る 12 個のルートがあります。
問題は、このジオイベント サービスを 12 個のサービスに分割することで優れたパフォーマンスを得られるかどうかということです。 現在のバージョンの GeoEvent Server では、答えは「いいえ」である可能性が高いです (例外として、以下の「並列と入力のフィルタリング」のセクションをご参照ください)。 パフォーマンス上の理由で、イベント処理ワークフローが単一の複雑なジオイベント サービスを使用するかどうか、または別々のジオイベント サービスに分割されるかどうかは多くの場合重要ではありません。
ただし、1 つの複雑なサービスではなく複数の単純なジオイベント サービスを使用する説得力のある理由があります。それは保守性とデバッグです。 複雑なジオイベント サービスは難解になり、ロジックを理解しにくくなることがあります。 ジオイベント サービスの処理の複雑さが増すにつれて、特に多くのユーザーがその作業に対して責任を負っている場合に、ジオイベント サービスを維持するのがますます困難になることがあります。 さらに、複雑なジオイベント サービスを整合チェックしデバッグするのは大変です。 処理ワークフローを複数の単純なジオイベント サービスに分割して単純化すると、目的の結果を容易に保守および整合チェックできるようになります。
並列と入力のフィルタリング
複数のフィルターをジオイベント サービスで使用して一連の決定を行う場合、フィルタリング操作が並列して実行されるようなジオイベント サービスを設計できます。 ただし、イベント レコードを一連のプロセッサまたはフィルターに並列して送る設計は、できれば避ける必要があります。
以下の図に示す 2 つのジオイベント サービスの設計について考えてみましょう。
上の図のジオイベント サービスの入力は、外部の Web サイトをポーリングしてデータを取得していたとし、そのレコードは 3 つのタイプ (自家用車、軽トラック、商用トラック) のいずれかであるとします。 各車両タイプは別々に処理される必要があるため、ジオイベント サービス C では、3 つのフィルターを使用してタイプ別に車両をグループに分けます。 特定の不連続フィルタリング操作を実行するには、ジオイベント サービスはそれぞれのイベント レコードのコピーを各フィルターに送る必要があります。 基本的に、イベント レコードの完全なセットが 3 つの別々のフィルターに送られます。 つまり、基本メッセージ バス上でフィルタリングされるレコードが 3 倍になります。
各フィルターは、受信したイベント レコードの一部を選択し、条件を満たさないイベント レコードを破棄し、その後、対象のイベント レコードを出力にルーティングするように構成されます。 各フィルターは独自のデータのコピーを処理して、どのイベント レコードを保持し、どのイベント レコードを破棄するかを判断する必要があります。
次の例について考えます。入力 123 が毎秒 1,000 個のイベントを取り込み、ジオイベント サービス C が、毎秒 3,000 個のイベントを処理する必要があると仮定します。 量の増加により、すべての構成されたジオイベント サービスの受信イベント データで GeoEvent Server が 1 秒間に実行できる全体的な操作の数が制限されます。これは、単一のメッセージ バスが入力、出力、およびジオイベント サービスのすべてに使用されるためです。
[ジオイベント サービス D] は、同じ全体的な操作を実行しますが、フィルターは構成されていません。 その代わり、イベント データを別々のグループに分割する負担は、イベント レコードの各タイプに割り当てられた 3 つの別々の入力によって処理されます。 可能な場合、このジオイベント サービスの設計方針をお勧めします。 ほとんどの Web サービスでは、クエリ パラメーターを使用してデータを異なるグループに分割できます。 3 つの入力を構成することにより、特定のタイプの車両をポーリングするクエリ パラメーターをそれぞれ使用することで、ジオイベント サービスを単純化してイベント処理ワークフロー内のルートをなくすことができます。
操作の遅延とコスト
フィルターとプロセッサが構成された操作をどのように遂行するのかを理解することは、ジオイベント サービスに関連付けられた遅延 (および処理コスト) を理解する上で重要です。 以下の図に示す 3 つのジオイベント サービスについて考えてみましょう。
プロセッサが最も多いジオイベント サービスの運用コストが最も多くなるのは容易に想定できます。 ただし、さらに調査する必要があります。
ジオイベント サービス 3 は、フィールド エンリッチャー、フィールド演算、およびインターセクター プロセッサという最も多くのプロセッサを含んでおり、これらは、イベント レコードのジオメトリとジオフェンスの間の空間的交差を計算するために使用されます。 実行される操作を考えると、フィールド エンリッチャーはフィーチャ サービスを検索して、フィーチャ レコードをキャッシュすることがわかります。 特定のトラック識別子を持つイベント レコードを初めて受け取ったとき、関連するフィーチャを取得するコストは比較的高くなりますが、その最初の呼び出しの後は、メモリに保持されたフィーチャ レコードのキャッシュからの情報付加のコストは非常に小さくなります。 通常フィールド演算により実行される文字列操作または算術演算も一般的に低コストです。 ジオフェンス ジオメトリも、空間処理をできるだけ高速にするためにメモリに保持されます。 そのため、[ジオイベント サービス #3] の 3 つのプロセッサの遅延またはコストはそれほどでもありません。
ジオイベント サービス #2 には、2 つのタイプのジオメトリ プロセッサがあります。 1 つ目はプロジェクター プロセッサであり、イベント レコードのジオメトリを取得して、それを異なる空間参照および座標系に投影します。 イベント レコードのジオメトリが多数の頂点を含む複雑なポリゴンの場合、ジオメトリの投影は比較的コストの高い操作になります。 2 つ目のプロセッサであるシンプリファイアー プロセッサは、ジオメトリの単純化を実行して、ジオメトリの基本的な形状を保持しながら、余分な湾曲や頂点を削除し、場合によっては並べ替えます。 繰り返しになりますが、より大きく複雑なジオメトリの場合、キャッシュされたデータを使用して操作を実行できなくなるため、この操作は、比較的コストが高くなります。 小さい、あまり複雑でないライン ジオメトリまたはポリゴン ジオメトリの場合、このジオイベント サービスは十分適切に動作できます。 しかし、より大きく複雑なラインまたはポリゴン ジオメトリの場合、遅延が大きくなります。
[ジオイベント サービス #1] は、プロセッサが 1 つだけの最も単純なジオイベント サービスですが、最もコストが高くなる可能性があります。 到達圏計算プロセッサは、GeoEvent Server のすぐに使用できるプロセッサではありませんが、GeoEvent Server SDK を使用して作成できるサンプル プロセッサとして利用できます。 このプロセッサは、Network Analyst サービスを使用して、中心点からポリゴンの外周上の任意の点までの運転時間を表す境界を持つポリゴンを計算します。 カスタム プロセッサによって呼び出されるジオプロセシング サービスが道路ネットワークを解析して、運転時間ポリゴンを計算するまで、かなりの時間がかかります (ミリ秒ではなく秒)。 計算時間に加えて、Network Analyst サービスへのリクエストを実行し、応答を受け取るネットワーク遅延があります。 これは、1 分間に多数のイベントを受信する場合に実行するような操作ではありません。
要約すると、[ジオイベント サービス #1] は単純なジオイベント サービスのように思えますが、その 1 つのプロセッサで実行される処理を理解すると、3 つの例の中で遅延コストが最も高くなる理由が簡単にわかります。