MongoDB.local SF, Jan 15: See the speaker lineup & ship your AI vision faster. Use WEB50 to save 50%
Find out more >
Docs Menu
Docs Home
/ /

Atlas Stream Processing アーキテクチャ

Atlas Stream Processing の主要抽象化はストリーム プロセッサです。ストリーム プロセッサは、指定されたソースからのストリーミングデータで継続的に動作し、出力を Sink に書込むMongoDB 集計パイプラインです。詳細については、ストリーム プロセッサの構造 を参照してください。

ストリーム処理は Stream Processing ワークスペース上で実行されます。各 Stream Processing ワークスペースは、以下を関連付ける Atlas 名前空間です。

  • それぞれ独自の RAM と CPU の割り当てで実行されている1つ以上のストリーム プロセッサ。

  • 階層を指定しない場合に各ストリーム プロセッサで使用可能なメモリとコンピュートの量を決定するデフォルトの階層。

  • 最大階層。その Stream Processing ワークスペース内のポッドに割り当てることができるメモリとコンピュートの最大量を決定します。

  • クラウドプロバイダーとクラウド リージョン。

  • ストリーミング データの利用可能なソースとシンクのリストを保存する接続レジストリ

  • ユーザー認証を定義するセキュリティ コンテキスト。

  • Stream Processing ワークスペース自体への 文字列接続。

ストリーム プロセッサを定義すると、そのストリーム プロセッサを定義するストリーム処理ワークスペースでのみ使用可能になります。各ストリーム プロセッサは、その階層に応じて割り当てられたリソースで実行されます。Atlas Stream Processing は、ストリーム プロセッサがを実行中間のみ、ストリーム プロセッサに対して 請求を行います。

階層サイズを宣言せずにストリーム プロセッサを起動すると、Stream Processing ワークスペースの階層で実行されます。Stream Processing ワークスペースの最大階層まで、任意の階層のストリーム プロセッサを起動できます。

myWorkspace という名前の Stream Processing ワークスペースに、デフォルトの階層をSP10、最大階層をSP30 として、ストリーム プロセッサを定義します。階層を指定せずにプロセッサを起動すると、Atlas Stream Processing はそれを SP10 ポッドに割り当てます。ただし、SP2からSP30までの任意の階層を宣言することができ、Atlas Stream Processing はプロセッサを適切なサイズのポッドに割り当てます。

各ワーカーは最大 4 つの実行中のストリームプロセッサをホストできます。レガシーワーカー モデルで実行されるストリーム処理ワークスペースは、ワーカーの数に応じてユーザーに課金します。Atlas Stream Processing は、必要にプロビジョニングワーカー によってストリーム プロセッサを起動すると、ストリーム処理ワークスペースを自動的にスケールアップします。すべてのストリーム プロセッサを停止することで、ワーカーのプロビジョニングを解除できます。Atlas Stream Processing では、新しいワーカーをプロビジョニングよりも、既存のワーカーにストリーム プロセッサを割り当てることを常に優先します。

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 では現在実行中のストリーム プロセッサの数のみが考慮されます。実行されていない定義済みストリーム プロセッサはカウントされません。Stream Processing ワークスペースの階層によって、ワーカーの RAM と CPU の割り当てが決定されます。

重要

SP10SP30 プロセッサは、レガシーワーカー モデルに従ってユーザーを操作し、ユーザーに請求します。これらのプロセッサは、3 年 12 月 日(2025)にプロセッサごとの価格モデルに更新されます。詳細については、Atlas Stream Processing アーキテクチャの概要のワーカー モデルセクションを参照してください。

接続レジストリには 1 つ以上の接続が保存されます。 各接続は、ストリーム プロセッサが外部サービスと交流できるようにするネットワークとセキュリティの詳細の組み合わせに名前を割り当てます。 接続では、次の動作が見られます。

  • 特定の Stream Processing ワークスペースの接続レジストリで定義された接続のみが、その Stream Processing ワークスペース上のストリーミング配信するプロセッサ ホストにサービスを提供できます。

  • 各接続は任意の数のストリーム プロセッサを処理できます

  • 単一の接続のみが、特定のストリーム プロセッサのソースとして機能できます。

  • 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 として割り当てることができます。

詳細については、「ストリーム プロセッサの作成 」を参照してください。

ストリーミングデータ処理では、ドキュメントは次の 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:0512: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

ウォーターマークがない場合、 Stream Processing ワークスペースのシステム クロックに従って、 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:0512: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に進みます。

戻る

はじめる

項目一覧