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