Kafkaを用いたイベント駆動型アーキテクチャ

今日のペースの速いデジタルエコシステムでは、リアルタイムのデータ処理とスケーラブルで疎結合なシステムの必要性がこれまで以上に顕著になっています。マイクロサービスが多くの最新アプリケーションの事実上のアーキテクチャパターンとなるにつれて、エンジニアはサービス間の通信、データ同期、システム回復力に関連する課題に頻繁に直面しています。これらの問題に対処する最も効果的な方法の1つは、Apache Kafkaを搭載したイベント駆動型アーキテクチャ（EDA）を採用することです。

イベント駆動型アーキテクチャは、疎結合されたアプリケーションがイベントブローカーを介してイベントを非同期的に公開および購読できるソフトウェア設計パターンです。このパラダイムでは、「イベント」とは、顧客が注文する、センサーが温度の急上昇を読み取る、ユーザーがサービスにログインするなど、状態の重要な変化を指します。これらのイベントが発生すると、システムはそれらを記録し、関心のあるサービスにブロードキャストします。この際、プロデューサーはコンシューマーが誰であるかを知る必要はありません。

Audio Briefing• Voice: Google Cloud Journey-F

0:00 / 0:00

EDAにおけるApache Kafkaの役割

Apache Kafkaは、その比類のないスループット、耐久性、耐障害性により、主要なイベントストリーミングプラットフォームとして台頭してきました。RabbitMQやActiveMQのような従来のメッセージキューとは異なり、Kafkaは分散コミットログとして設計されています。

不変のコミットログ

Kafkaは、その核となる部分で、トピックにデータを保存します。トピックはパーティション分割され、複数のブローカーに複製されます。プロデューサーがメッセージをトピックに公開すると、そのメッセージは特定のパーティションのコミットログの末尾に追加されます。この追記専用の設計により、書き込みはシーケンシャルであるため、信じられないほど高速になります。一度書き込まれたメッセージは不変であり、設定可能な保持期間の間トピックに残ります。消費され次第削除されるわけではありません。この永続性モデルにより、コンシューマーはイベントを巻き戻して再生できます。これは、デバッグ、監査、または履歴コンテキストを必要とする新しいサービスを立ち上げる際に非常に貴重です。

トピック、パーティション、コンシューマーグループ

高いスケーラビリティを実現するために、Kafkaトピックはパーティションに分割されます。パーティションは、順序付けられた不変のレコードシーケンスです。トピックを複数のパーティションに分割することで、Kafkaは複数のコンシューマーが単一のトピックから並行して読み取れるようにします。これにより、コンシューマーグループの概念が生まれます。

コンシューマーグループは、1つ以上のトピックからデータを消費するために協力するコンシューマーのセットです。Kafkaは、各パーティションがグループ内の1つのコンシューマーに正確に割り当てられるようにします。10個のパーティションを持つトピックと10個のインスタンスを持つコンシューマーグループがある場合、各インスタンスは1つのパーティションから読み取り、10個のイベントを同時に処理できます。インスタンスが失敗した場合、Kafkaは自動的にそのパーティションをグループ内の別の健全なインスタンスに再割り当てし、高い可用性と耐障害性を確保します。

主要な技術的考慮事項

KafkaでEDAを実装する際、アーキテクトとエンジニアはいくつかの技術的なトレードオフと設計パターンを慎重に検討する必要があります。

イベントソーシング vs. イベント通知

アーキテクチャでイベントを使用する方法は、イベント通知とイベントソーシングの2つに大別されます。

イベント通知（Event Notification）： このパターンでは、イベントには最小限の情報（多くの場合、IDとアクションのみ。例：「注文123作成済み」）が含まれます。コンシューマーは、完全な詳細を取得するためにAPIを介してソースシステムにクエリを実行する必要があります。これによりペイロードサイズは最小限に抑えられますが、サービス間の同期結合が再導入されます。
イベント駆動型状態転送（Event Carried State Transfer）（イベントソーシング）： ここでは、イベントにはコンシューマーが必要とするすべてのデータ（例：完全な注文詳細）が含まれます。コンシューマーはデータの独自のローカルな具体化を維持できるため、同期API呼び出しの必要が完全に排除されます。これによりイベントペイロードサイズは増加し、慎重なスキーマ管理が必要になりますが、最大限の疎結合と回復力が提供されます。

スキーマレジストリによるスキーマ管理

アプリケーションが進化するにつれて、イベントの構造（スキーマ）は必然的に変化します。プロデューサーがイベントの形式を変更し、コンシューマーがそれに対応するように更新されていない場合、コンシューマーはクラッシュします。これを解決するために、組織はスキーマレジストリ（多くの場合ConfluentのSchema Registry）を使用します。

スキーマレジストリは、すべてのスキーマのバージョン管理された履歴を保存します（通常、Avro、Protobuf、またはJSON Schemaを使用）。プロデューサーがメッセージを送信する際、スキーマIDを含めます。コンシューマーはそのIDを使用してレジストリからスキーマを取得し、メッセージを逆シリアル化します。レジストリは互換性ルール（例：後方互換性、前方互換性、完全互換性）も適用し、プロデューサーが既存のコンシューマーを壊すようなイベントを公開できないようにします。

Exactly-Once Semantics (EOS)

分散システムでは、データ損失や重複なしに障害を処理することは非常に困難です。Kafkaは従来、「at-least-once」配信を提供していました。これは、メッセージは確実に配信されますが、再試行の場合には複数回配信される可能性があることを意味します。金融取引のようなアプリケーションでは、これは許容できません。

バージョン0.11以降、KafkaはIdempotent ProducerとTransactional APIを介してExactly-Once Semantics (EOS)をサポートしています。Idempotent Producerは各メッセージにシーケンス番号を割り当て、ブローカーが再試行を重複排除できるようにします。Transactional APIを使用すると、プロデューサーは複数のパーティションにアトミックに書き込むことができます。すべての書き込みが成功するか、または何も成功しないかのどちらかです。これは、あるトピックから読み取り、データを処理し、別のトピックに書き込むストリーム処理アプリケーション（Kafka Streamsなど）にとって非常に重要であり、障害が発生した場合でもすべてのレコードが正確に1回処理されることを保証します。

ログ圧縮

デフォルトでは、Kafkaは時間（例：7日間）またはサイズに基づいてデータを保持します。ただし、一部のトピックはエンティティの最新の状態（例：顧客の現在の住所）の真実のソースとして使用されます。これらのシナリオでは、Kafkaはログ圧縮を提供します。ログ圧縮を有効にすると、Kafkaは各メッセージキーの最後に既知の値を少なくとも1つ保持することを保証します。ブローカーは定期的にログをスキャンし、新しいレコードと同じキーを持つ古いレコードを削除します。これにより、コンシューマーは何年もの履歴変更を処理することなく、システムの完全な最新の状態を迅速に復元できます。

結論

Apache Kafkaを使用したイベント駆動型アーキテクチャへの移行は、単なる技術の置き換えではありません。それは、エンジニアがデータフローとサービス統合を概念化する方法における根本的な変化です。分散コミットログ、パーティション、非同期通信を採用することで、組織は高度にスケーラブルで回復力があり、応答性の高いアプリケーションを構築できます。しかし、成功にはKafkaの内部構造に対する深い理解、スキーマ進化への細心の注意、そしてイベント設計への規律あるアプローチが必要です。正しく実行されれば、現代のデータ集約型アプリケーションの要求に容易に対応できる堅牢な神経系という見返りがあります。

Kafkaを用いたイベント駆動型アーキテクチャ