イベント駆動マイクロサービスを構築する

第6章. 決定論的ストリーム処理

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

イベント駆動型マイクロサービスは、通常、前章で紹介したものよりも複雑なトポロジーを持つ。イベントは複数のイベントストリームから消費され処理されるが、多くのビジネス上の問題を解決するためにはステートフル処理（次章で説明）が必要となる。マイクロサービスもまた、非マイクロサービスシステムと同じように障害やクラッシュの影響を受ける。ほぼリアルタイムでイベントを処理するマイクロサービスが混在している一方で、新たに開始された他のマイクロサービスが過去のデータを処理して追いついていることも珍しくない。

本章で取り上げる3つの主要な質問は以下の通りである：

• 複数のパーティションからコンシューマする場合、マイクロサービスはどのようにイベントの処理順序を選択するのか？

• マイクロサービスは、順番が遅れたり、到着が遅れたりしたイベントをどのように処理するのか？

• マイクロサービスがストリームをほぼリアルタイムで処理するときと、ストリームの最初から処理するときとで、決定論的な結果を確実に出すにはどうすればいいのか？

タイムスタンプ、イベントスケジューリング、透かし、ストリーム時間を調べ、それらが決定論的処理にどのように寄与するかを調べることで、これらの疑問に答えることができる。バグ、エラー、ビジネスロジックの変更も再処理を必要とするため、決定論的な結果が重要となる。この章では、アウトオブオーダーやレイトアライブ・イベントがどのように発生する可能性があるのか、それらを処理するための戦略、そしてワークフローへの影響を軽減する方法についても説明する。

注

この章は、重要な概念をシンプルかつ簡潔に説明する方法を発見するために最善の努力を尽くしたにもかかわらず、かなり情報量が多い。詳細が本書の範囲を超えることが多いため、自分で調べるためにさらなるリソースを紹介する箇所がいくつもある。

イベント駆動ワークフローによる決定論

イベント駆動型マイクロサービスには、主に2つの処理状態がある。それは、ほぼリアルタイムでイベントを処理している可能性があり、これは長時間稼働するマイクロサービスに典型的である。あるいは、現在に追いつくために過去のイベントを処理している場合もあり、これはスケール不足の新しいサービスによく見られる。

入力イベントストリームのコンシューマグループのオフセットを時間の最初に巻き戻し、マイクロサービスの実行を再び開始したとしたら、最初に実行したときと同じ出力を生成するだろうか？決定論的処理の包括的な目標は、マイクロサービスがリアルタイムで処理しても、現在時刻に追いついても、同じ出力を生成することである。

現在のウォールクロック時刻に基づくワークフローや、外部サービスにクエリ を発行するワークフローなど、明示的に非決定的なワークフローがあることに注意す ること。外部サービスは、クエリを発行するサービスから独立して内部状態が更新される場合は特に、クエリを発行するタイミングによって異なる結果を提供する可能性がある。このような場合、決定論は約束されないので、ワークフロー内の非決定論的な演算に注意すること。

完全に決定論的な処理は、すべてのイベントが時間通りに到着し、遅延がなく、プロデューサやコンシューマに障害がなく、断続的なネットワークの問題がない理想的なケースである。私たちはこのようなシナリオに対処するしかないため、現実には、私たちのサービスは決定性において最善の努力をすることしかできない。ほとんどの場合、ベストエフォート型の決定性で十分である。一貫したタイムスタンプ、よく選択されたイベント・キー、パーティション代入、イベント・スケジューリング、遅れて到着するイベントを処理する戦略などである。 ...