Atlas Stream Processing アーキテクチャ

階層

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

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

ストリームプロセッサーの階層は手動で調整できます。または、垂直オートスケーリングを有効にすることで、Atlas Stream Processing が、プロセッサーのリソース使用状況に応じて階層を自動的に変更するようにすることができます。

接続レジストリ

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

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

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

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

• 1 つの接続のみが、特定のストリーム プロセッサのシンクとして機能できます。

• 接続は、ソースまたはシンクのいずれかとして最初に定義されることはありません。 ストリーム プロセッサがその接続を呼び出す方法に応じて、任意の接続がどちらの機能も提供できます。

Atlas Stream Processing は、マルチテナント インフラストラクチャ上に VM レベルの分離を持つ専用のカスタマーコンテナで各ストリーム プロセッサを実行します。MongoDBのセキュリティとコンプライアンスの詳細については、 MongoDB信頼センター を参照してください。

最初の同期

変更ストリーム $source の構成で initialSync が有効な場合、Atlas Stream Processing はソース コレクションをコピーする最初の同期フェーズと通常の変更イベント プロセシング フェーズの両方のチェックポイントを作成します。最初の同期中、Atlas Stream Processing は開始 oplog ポジションをレコードし、ソース コレクションをパーティションに分割します。プロセッサーはパーティションを介して既存のドキュメントをコピーし、コピーが完了すると、最初にレコードされたポジションから変更イベントを再生します。Atlas Stream Processing は最初の同期中にチェックポイントを作成し、中断が発生した場合、プロセッサーは再開できます。

Atlas Stream Processing は、サポートされているすべての _id タイプに対して最初の同期のチェックポイントを設定します。Atlas Stream Processing が予測可能な順序で読み取れない _id の値を持つコレクションはコピーに時間がかかりますが、ObjectId または順序付きの int または long の値を使用するコレクションと同様に復旧可能です。中断されたプロセッサーは、コレクションのコピーを再開するのではなく、最後のチェックポイントから再開します。initialSync がサポートする _id のタイプと、より長い操作に必要な oplog のサイジングについては、Atlas Stream Processing の制限 を参照してください。

Kafkaソースとコンシューマー グループ オフセット

Atlas Stream Processing はチェックポイントをコミットした後、 Kafkaのコンシューマー グループ オフセットを非同期に更新します。Apache Kafka を$source として使用すると、コンシューマー グループはこれらのチェックポイントを、各パーティションのKafkaクラスターでコミットされたオフセットとして追跡します。

これらの更新は定期的かつ非同期的に行われるため、コンシューマーグループのコミットされたオフセットは、最新のチェックポイントより一時的に遅れることがあります。これにより、kafka-consumer-group CLI ツールなど、Kafka からコミットされたオフセットを読み取るツールでは、モニタリングに短期的な遅延が発生し、メトリクスが遅れる可能性があります。これらのツールでは、コンシューマーグループがストリームプロセッサーの真の内部ポジションよりも "遅れている" と表示される可能性があります。

内部チェックポイントとコミットされたKafkaオフセットの間の遅延量は固定されず、ワークロードと構成によって異なる場合があります。一般的なワークロードでは 秒単位ですが、厳格な上限はありません。

フェイルオーバーに関する考慮事項

Stream Processing ワークスペースのフェイルオーバー リージョンを作成できます。ワークスペースを初期に 作成 するとき、または、既存の Stream Processing ワークスペースをフェイルオーバー リージョンを使用するように変更できます。

個別のプロセッサー、所定のワークスペース内のすべてのプロセッサー、または指定されたリージョンでフェイルオーバーが構成されているすべてのプロセッサーのフェイルオーバーを trigger できます。

フェイルオーバープロセッサは、少なくとも 1 回のプロセシングセマンティクスを保証します。

フェイルオーバープロセッサーの要件と制限の詳細については、制限を参照してください。

フェイルオーバー プロセッサーの価格については、請求ドキュメントを参照してください。

フェイルオーバー接続

フェイルオーバーは別個の接続タイプを使用しません。Stream Processing ワークスペース内の各接続には名前が付いています。リージョンをサポートする接続タイプの場合、元の接続と同じ名前とタイプを持ち、固有のリージョンとエンドポイントとなる接続されたデバイスの設定を持つリージョン固有の接続を作成できます。リージョン固有の接続は、お使いの Stream Processing ワークスペースに構成されたフェイルオーバー リージョンのみで作成できます。

フェイルオーバー リージョン間での接続の動作は次のとおりです。

• Atlas クラスター接続はすべてのリージョンで共有されます。リージョン固有のAtlas接続は作成できません。

• `Apache Kafka <https://kafka.apache.org/>`__ 接続は、リージョンをサポートする唯一の接続タイプです。リージョン固有の接続が必要かどうかは、接続のネットワーク構成によって異なります。

  • 接続でパブリック ネットワークを使用する場合、リージョン固有の接続を使用する必要はなく、すべてのリージョンで使用できます。

  • 接続で Private Link または VPC ピアリングを使用する場合、各フェイルオーバーリージョンで、そのリージョンのエンドポイントとなる接続されたデバイスを指すリージョン固有の接続を作成する必要があります。リージョンごとにエンドポイントとなる接続されたデバイスとキーストアが異なるため、mTLS を使用する Private Link 接続が含まれます。

既存のStream Processingワークスペースにフェイルオーバーリージョンを追加すると、Atlas Stream Processingは既存のApache Kafka接続にリージョンを割り当てます。

接続を使用するストリーム プロセッサーが実行中である間は、接続を変更できません。

リージョン固有の接続を作成するには、1 つのフェイルオーバー ストリーム接続を作成エンドポイントとなる接続されたデバイス、Atlas CLI、Terraform、または Atlas UI を使用します。mongoshを使用して接続を作成または変更することはできません。

エラーの分類

Atlas Stream Processing はエラーを主要 2 つのカテゴリに分類します。

ユーザー エラー

Atlas Stream Processing の制御外のユーザー構成、データの問題、または外部サービスの問題によって発生するエラー。例としては、次のものが含まれます。

• 無効な接続認証情報

• 外部サービスへのネットワーク接続の問題

• 処理できない不正データ

• 外部リソースへのアクセス権限の問題

内部エラー

Atlas Stream Processing システム自体で発生するエラー。通常、一時的なインフラストラクチャの問題やサービスの中断が原因で、Atlas Stream Processing システム自体で発生するエラー。これらは、解決する Atlas Stream Processing サービスの責任と見なされます。

再試行動作

再試行動作は、エラーの分類によって異なります。

ユーザー エラー再試行ポリシー

• Atlas Stream Processing は、ストリーム プロセッサを 5 分の期間にわたって限定的に再起動しようとします

• この時間枠内ですべての再試行が失敗すると、ストリーム プロセッサは FAILED 状態に移行します

• 一部のユーザー エラーは 再試行不可として分類され 、プロセッサをすぐに失敗させます。例としては、次のものが含まれます。

  • StreamProcessorWorkerOutOfMemory (418): パイプラインが階層メモリ制限を超えています

  • StreamProcessorInvalidOptions (420):パイプラインの構文または構成が無効です

• 失敗したストリーム プロセッサを手動で再起動するには、start() メソッドを呼び出します

内部エラー再試行ポリシー

• Atlas Stream Processing は時間制限なしで内部エラーを継続的に再試行します

• Atlas Stream Processing エンジニアリングチームへの内部エラー トリガー アラート

• システムは、内部問題が解決された後にプロセッサを回復するために自動再試行メカニズムに依存します

• ストリーム プロセッサは再起動時に最後のチェックポイントから自動的に再開します

リカバリプロセス

ストリーム プロセッサでエラーが発生し、再起動が必要な場合、回復プロセスは次の手順に従います。

このリカバリ プロセスにより、一時的な障害によってデータが失われたり、ほとんどの場合に手動による介入が必要になったりすることがなくなります。

イベント時間

イベント時間は、ソースストリームがドキュメントを生成した時点、またはメッセージング システム（例:Apache Kafka）はドキュメントを受け取ります。これは、ドキュメントのタイムスタンプによって保証されます。

ネットワークレイテンシ、上流処理、およびその他の要因により、特定のドキュメントでこれらの時間間の不整合が生じるだけでなく、ドキュメントがイベント時間順からストリーム プロセッサに到達する可能性もあります。いずれの場合も、 Windows はキャプチャする予定のドキュメントを失う可能性があります。 Atlas Stream Processing は、このようなドキュメントが 遅延 しているドキュメントを考慮し、デッド レター キューに送信します（ 設定されている場合）。

イベント時間は、 Tumbling WindowsとホスティングWindowsでサポートされている boundaryフィールドの構成可能なオプションです。

プロセシング時間

処理時間とは、ストリーム プロセッサがドキュメントを使用する時間のことであり、ストリーム プロセッサをホストするシステムのクロックによって確認されます。

プロセシング時間は、boundary フィールドの構成可能なオプションで、タンブリング Windowsとホッピング Windowsでサポートされます。このオプションを利用すると、サーバーのウォール クロック時間に基づいてデータを蓄積するタイプのウィンドウを持つパイプラインを作成できます。イベント時間 ウィンドウとは対照的に、プロセシング時間ウィンドウは、ストリーム プロセッサに到着した際のサーバーのウォール クロック時間に基づいて各イベントにタイムスタンプを割り当てます。

ドキュメントのタイムスタンプとウィンドウ境界のタイムスタンプは UTC です。processingTime ウィンドウを構成する際に、idleTimeout または allowedLateness オプションを指定することはできません。