アーキテクチャの基礎
Atlas Stream Processing の主要抽象化はストリーム プロセッサです。ストリーム プロセッサは、指定されたソースからのストリーミングデータで継続的に動作し、出力を Sink に書込むMongoDB 集計パイプラインです。詳細については、ストリーム プロセッサの構造 を参照してください。
ストリーム処理はストリーム処理ワークスペースで行われます。各ストリーム処理ワークスペースは、次のものを関連付ける Atlas名前空間です。
1 つ以上のストリーム プロセッサが、 RAMと CPU の独自の割り当てで実行中。
階層を指定しない場合に各ストリーム プロセッサで使用可能なメモリとコンピュートの量を決定するデフォルトの階層。
最大階層。そのストリーム処理ワークスペース内のポッドに割り当てることができるメモリとコンピュートの最大量を決定します。
クラウドプロバイダーとクラウド リージョン。
ストリーミング データの利用可能なソースとシンクのリストを保存する接続レジストリ。
ユーザー認証を定義するセキュリティ コンテキスト。
ストリーム処理ワークスペース自体への 接続文字列 。
階層
ストリーム プロセッサを定義すると、そのストリーム プロセッサを定義するストリーム処理ワークスペースでのみ使用可能になります。各ストリーム プロセッサは、その階層に応じて割り当てられたリソースで実行されます。 Atlas Stream Processing は、ストリーム プロセッサがを実行中実行中間のみ、ストリーム プロセッサに対して 請求を行います。
階層サイズを宣言せずにストリーム プロセッサを起動すると、ストリーム処理ワークスペースの階層が実行されます。ストリーム処理ワークスペースの最大階層まで、任意の階層のストリーム プロセッサを起動できます
例
myWorkspace という名前のストリーム処理ワークスペースで、デフォルト階層が SP10 で最大階層が SP30 のストリーム プロセッサを定義します。階層を指定せずにプロセッサを起動すると、Atlas Stream Processing はそれを SP10 ポッドに割り当てます。ただし、SP2 から SP30 までの任意の階層を宣言でき、Atlas Stream Processing は適切なサイズのポッドにプロセッサを割り当てます。
ワーカー（レガシー）
重要
各ワーカーは最大 4 つの実行中のストリーム プロセッサをホストできます。レガシーワーカー モデルで実行されるストリーム処理ワークスペースでは、ワーカーの数に応じてユーザーに課金します。 Atlas Stream Processing は、必要に応じプロビジョニングワーカー によってストリーム プロセッサを起動すると、ストリーム処理ワークスペースを自動的にスケールアップします。すべてのストリーム プロセッサを停止することで、ワーカーのプロビジョニングを解除できます。 Atlas Stream Processing では、新しいワーカーをプロビジョニングよりも、既存のワーカーにストリーム プロセッサを割り当てることを常に優先します。
例
proc01 から proc08 という名前の 8 つのストリーム プロセッサを実行中ストリーム処理ワークスペースがある。 proc01 から proc04 は 1 つのワーカーで実行され、proc05から proc08 は 2 番目のワーカーで実行されます。 proc09 という名前の新しいストリーム プロセッサを起動します。 Atlas Stream Processing は、proc09 をホストするための 3 つ目のワーカーをプロビジョニングします。
その後、最初のワーカーでproc03を停止します。 proc09を停止して再起動すると、Atlas Stream Processing はproc09を最初のワーカーに再割り当てし、3 番目のワーカーのプロビジョニングを解除します。
proc09を停止して再起動する前に、 proc10という名前の新しいストリーム プロセッサを起動すると、Atlas Stream Processing は、以前にproc03に割り当てられていたスロットの最初のワーカーにproc10を割り当てます。
スケーリング時に、Atlas Stream Processing では現在実行中のストリーム プロセッサの数のみが考慮されます。を実行中いない定義済みのストリーム プロセッサはカウントされません。ストリーム処理ワークスペースの階層によって、ワーカーのRAMと CPU の割り当てが決まります。
接続レジストリ
接続レジストリには 1 つ以上の接続が保存されます。 各接続は、ストリーム プロセッサが外部サービスと交流できるようにするネットワークとセキュリティの詳細の組み合わせに名前を割り当てます。 接続では、次の動作が見られます。
特定のストリーム処理ワークスペースの接続レジストリで定義された接続のみが、そのストリーム処理ワークスペースでホストされているストリーム プロセッサをサービスできます。
各接続は任意の数のストリーム プロセッサを処理できます
単一の接続のみが、特定のストリーム プロセッサのソースとして機能できます。
1 つの接続のみが、特定のストリーム プロセッサのシンクとして機能できます。
接続は、ソースまたはシンクのいずれかとして最初に定義されることはありません。 ストリーム プロセッサがその接続を呼び出す方法に応じて、任意の接続がどちらの機能も提供できます。
Atlas Stream Processing は、マルチテナント インフラストラクチャ上の専用のカスタマーコンテナでストリーム処理ポッドを実行します。 MongoDBのセキュリティとコンプライアンスの詳細については、 MongoDBトラスト センター を参照してください。
チェックポイント
Atlas Stream Processing は、 チェックポイント を使用してストリーム プロセッサの状態を取得します。各チェックポイントは一意のIDを持ち、ストリーム プロセッサ ロジックのフローに従います。ストリーム プロセッサのすべての演算子がその状態をチェックポイントに追加した後、Atlas Stream Processing はチェックポイントをコミットし、2 種類のレコードを生成します。
チェックポイントIDとそれが属するストリーム プロセッサを検証する単一のコミットレコード
Atlas Stream Processing がチェックポイントをコミットした時点での、関連するストリーム プロセッサの各ステートメント操作の状態を説明するレコードのセット。
中断後にストリーム プロセッサを再起動すると、Atlas Stream Processing は最後にコミットされたチェックポイントをクエリし、記述された状態から操作を再開します。
デッド文字キュー
Atlas Stream Processing は、Atlas データベースのコレクションをデッドレターキュー (DLQ) として使用することをサポートしています。Atlas Stream Processing がデータ ストリームからのドキュメントを加工できない場合、プロセシング失敗の詳細とともにドキュメントの内容を DLQ に書き込みます。ストリーム プロセッサの定義でコレクションを DLQ として割り当てることができます。
詳細については、「ストリーム プロセッサの作成 」を参照してください。
Stream Processing タイミング
ストリーミングデータ処理では、ドキュメントは次の 2 つのタイミング システムの対象となります。
イベント時間
プロセシング時間
Atlas Stream Processing は、ストリーム プロセッサとこれらのタイミング システムとのやり取りを制御するためのさまざまなパラメーターを提供しています。
イベント時間
イベント時間は、ソースストリームがドキュメントを生成した時点、またはメッセージング システム（例:Apache Kafka）はドキュメントを受け取ります。これは、ドキュメントのタイムスタンプによって保証されます。
ネットワークレイテンシ、上流処理、およびその他の要因により、特定のドキュメントでこれらの時間間の不整合が生じるだけでなく、ドキュメントがイベント時間順からストリーム プロセッサに到達する可能性もあります。いずれの場合も、 Windows はキャプチャする予定のドキュメントを失う可能性があります。 Atlas Stream Processing は、このようなドキュメントが 遅延 しているドキュメントを考慮し、デッド レター キューに送信します（ 設定されている場合）。
イベント時間は、 Tumbling WindowsとホスティングWindowsでサポートされている boundaryフィールドの構成可能なオプションです。
プロセシング時間
処理時間とは、ストリーム プロセッサがドキュメントを使用する時間のことであり、ストリーム プロセッサをホストするシステムのクロックによって確認されます。
プロセシング タイムは、Tumbling WindowsとホスティングWindowsでサポートされている boundaryフィールドの構成可能なオプションです。これにより、サーバーのウォール クロック時間に基づいてデータを蓄積するウィンドウの種類のパイプラインを作成できます。イベント時間Windowsとは対照的に、プロセシング時間Windows は、ストリーム プロセッサに到達したときにサーバーのウォール クロック時間に基づいて各イベントにタイムスタンプを割り当てます。
ドキュメント タイムスタンプとウィンドウ境界タイムスタンプは UTC です。ウィンドウを構成するときに、 idleTimeout またはprocessingTime allowレイテンシのオプションを指定することはできません。
例
5 分間のイベント時間ウィンドウを使用してパイプラインを作成します。イベントは 09:33 で、ソース Kafka クラスターに追加されます。Kafka クラスターの遅延により、そのイベントは09:37 のストリーム プロセッサに到達します。
パイプラインのイベント時間ウィンドウが 5 分の場合、このイベントは 09:30-09:35 ウィンドウに割り当てられます。パイプラインの処理時間ウィンドウが 5 分である場合、イベントは代わりに 09:35-09:40 ウィンドウに割り当てられます。
サーバーマーク
ウォームマークは処理時間を上書きし、以前に消費されたドキュメントよりも後のイベント時間が消費されたドキュメントをプロセッサが消費した場合にのみ更新します。Atlas Stream Processing では、すべてのストリーム プロセッサが埋め込みを適用します。
例
5 分のWindowsでストリーム プロセッサを構成します。 プロセッサを 12:00 で起動するため、最初の 2 つのWindowsの期間は 12:00-12:05 と 12:05-12:10 になります。 次の表は、どのWindowsがキャプチャするかどうかを示しています。
イベント時間 | プロセシング時間 | ウィンドウ時間（サーバーマークなし） | ウィンドウ時間（すかし） |
|---|---|---|---|
12:00 | 12:00 | 12:00-12:05 | 12:00-12:05 |
12:01 | 12:03 | 12:00-12:05 | 12:00-12:05 |
12:02 | 12:05 | 12:05-12:10 | 12:00-12:05 |
12:01 | 12:06 | 12:05-12:10 | 12:00-12:05 |
12:06 | 12:07 | 12:05-12:10 | 12:05-12:10 |
ウォームマークがない場合、ストリーム処理ワークスペースのシステム クロックに従って、12:00-12:05ウィンドウは12:05 に閉じ、12:05-12:10ウィンドウがすぐに開きます。したがって、ソースは 12:00-12:05 間隔中に 4 つのドキュメントを生成しましたが、関連するウィンドウは2 つのドキュメントのみをキャプチャします。
ウォームマークを使用すると、12:00-12:05ウィンドウは12:05 で閉じない。その点までに取り込むドキュメントのうち、最新のイベント時間、つまりサーバーの値が 12:03 であるためです。12:00-12:05ウィンドウは、システム クロックの 12:07まで閉じない。ストリーム プロセッサが 12:05 のイベントタイムのドキュメントを取り込むと、その時間までウォームアップを進めて、12:05-12:10ウィンドウを開きます。各ウィンドウは適切なドキュメントをすべてキャプチャします。
Apache Kafkaから読み取る場合、Atlas はすべてのパーティションがウォームマークを渡すまで待機します。パーティションがアイドル状態にあり、レプリカセットの生成に失敗した場合、タイムスタンプは基準値より新しいタイムスタンプを持つイベントを生成したり、ウィンドウは閉じたり結果を出力したりしません。これに対処するために、partitionIdleTimeoutを設定して、アイドル状態のパーティションによってウォームマークの進行が停止しないようにします。詳しくは、$source ステージ（Stream Processing） を参照してください。
許容レイテンシ
イベント時間とプロセシング時間の差が十分に異なる場合、ウォームマークが予想されるウィンドウを閉じるのに十分に進んだ後に、ドキュメントがストリーム プロセッサに到達することがあります。 これを軽減するために、Atlas Stream Processing は 許可レイテンシ をサポートしています。これは、レプリカセットに対して一定の間隔でウィンドウを閉じるのを遅延させる設定です。
サーバーマークはストリーム プロセッサのプロパティですが、許可されたレイテンシはウィンドウのプロパティであり、そのウィンドウが閉じられた場合にのみ影響します。 ストリーム プロセッサのウォームマークが、新しいウィンドウを開くtriggerとなる点まで進む場合、 許可されたレイテンシ はこれを防ぐことなく、以前のWindowsを開いたままにします。
例
5 分のローリングWindowsでストリーム プロセッサを構成します。 プロセッサを 12:00 で起動するため、最初の 2 つのWindowsの期間は 12:00-12:05 と 12:05-12:10 になります。 許可されたレイテンシ を2分に設定します。
以下の表は、ストリーム プロセッサが説明されたドキュメントを取り込む順序を反映しています。
イベント時間 | サーバーマーク | 許可されたレイテンシ時間 | ウィンドウ時間 |
|---|---|---|---|
12:00 | 12:00 | 11:58 | 12:00-12:05 |
12:02 | 12:03 | 12:01 | 12:00-12:05 |
12:01 | 12:04 | 12:02 | 12:00-12:05 |
12:05 | 12:05 | 12:03 | 12:00-12:15, 12:05-12:10 |
12:04 | 12:06 | 12:04 | 12:00-12:05, 12:05-12:10 |
12:07 | 12:07 | 12:05 | 12:05-12:10 |
サーバー マークが12:05まで進むと、 12:05-12:10ウィンドウが開きます。 ただし、許可レイテンシの間隔が2分であるため、 12:00-12:05ウィンドウ内では実質的に12:03のみとなり、開いたままになります。 サーバー マークが12:07に進むとのみ、調整された時間は12:05に達します。 この時点で、 12:00-12:05ウィンドウは閉じます。
アイドルレス タイムアウト
ウィンドウの動作をプロセシング時間から排除すると、ほとんどの場合、ストリーム処理の正確性が向上します。 ただし、ストリーミング データ ソースではアイドル状態が一定期間続く場合があります。 このシナリオでは、ウィンドウがアイドル状態の期間より前のイベントをキャプチャし、ウォームマークが閉じられるまで十分に進むのを待っている間は処理された結果を返すことができなくなる可能性があります。
Atlas Stream Processing を使用すると、ユーザーは Windows のアイドル タイムアウトを構成して、プロセシング時間を使用してこれらのシナリオを軽減できます。アイドル性タイムアウトは、プロセシング時間が渡し、開いているウィンドウの間隔が終了し、ストリーム プロセッサのソースがアイドル状態の場合に開始される間隔です。ソースがアイドル状態タイムアウトと等しい間隔でアイドル状態を維持すると、ウィンドウは閉じ、ウォームマークはドキュメントの取り込みとは無関係に進みます。
例
3分の間隔と1分のアイドルタイムアウトでタームリング ウィンドウを構成します。 次の表は、ウィンドウの間隔中とその後のアイドル性タイムアウトの影響を示しています。
プロセシング時間 | イベント時間またはステータス | サーバーマーク | ウィンドウ時間 |
|---|---|---|---|
12:00 | 12:00 | 12:00 | 12:00-12:03 |
12:01 | ソース アイドル | 12:00 | 12:00-12:03 |
12:02 | ソース アイドル | 12:00 | 12:00-12:03 |
12:03 | ソース アイドル | 12:00 | 12:00-12:03 |
12:04 | 12:02 | 12:02 | 12:00-12:03 |
12:05 | 12:05 | 12:05 | 12:03-12:06 |
12:06 | ソース アイドル | 12:05 | 12:03-12:06 |
12:07 | ソース アイドル | 12:00 | 12:06-12:09 |
12:08 | ソース アイドル | 12:00 | 12:06-12:09 |
12:09 | 12:09 | 12:09 | 12:09-12:12 |
12:00-12:03間隔中、ソースは 3 分間アイドル状態になりますが、ストリーム プロセッサはウィンドウを閉じないで、処理時間がウィンドウの間隔の終了を超えないため、ウィンドウの間隔が終了した後もソースはアイドル状態を維持しません。 ウォームマークが12:05まで進むと、ウィンドウは正常に閉じ、 12:03-12:06ウィンドウが開きます。
ソースが12:06でアイドル状態になると、 12:07を通じてアイドル状態のままになり、アイドルタイムアウトがトリガーされ、 ウォームマークが12:06に進みます。