Kafka

従来のモノリシック アプリケーションでは、複数のエンティティ間でデータの一貫性を維持するのは簡単です。リレーショナル データベース エンジンは、ローカル SQL トランザクション内にラップされた ACID (原子性、一貫性、分離性、耐久性) 保証を提供します。注文の発注、支払いの差し引き、または在庫の予約が途中で失敗した場合、ROLLBACK を呼び出すと、データベースのすべての変更が即座に元に戻されます。 ただし、最新の マイクロサービス アーキテクチャ に移行すると、データ管理が根本的に変わります。ドメインの自律性と独立したスケーラビリティを確保するために、各マイクロサービスはプライベート データベースを所有します。電子商取引のチェックアウトの処理などの 1 つのビジネス操作が、複数のサービス境界とデータベース エンジン (注文の PostgreSQL、支払いの DynamoDB、在庫の Redis など) にまたがるようになりました。 分散マイクロサービスは単一のデータベース トランザクションに依存できないため、ネットワーク境界を越えてデータの一貫性を維持することは、分散システム エンジニアリングにおいて最も困難な問題の 1 つになります。 システムの可用性やパフォーマンスを犠牲にすることなくこれを解決するために、ソフトウェア アーキテクトは Saga パターン を利用します。 この詳細な説明では、従来の分散トランザクションが失敗する理由を調査し、Saga パターンの中核的な仕組みを分析し、コレオグラフィーとオーケストレーションを比較し、分離対策を分析し、Go と Java での実稼働コードの実装を調査し、実際の障害ロールバックを安全に処理する方法を学びます。 根本的な問題: マイクロサービスで 2 フェーズ コミット (2PC) が失敗する理由 Saga パターンを採用する前に、エンジニアはよく次のような質問をします: マイクロサービス全体で従来の 2 フェーズ コミット (2PC / XA)​​ を使用できないのはなぜですか? 2PC の仕組み 2 フェーズ コミットは、中央のトランザクション マネージャーを使用して、複数のデータベース ノードにわたる分散トランザクションを 2 つのフェーズで調整します。

現代のイベント駆動型マイクロサービス（Event-Driven Architecture）では、サービス間を疎結合に保ちつつ状態変更を通知するために、OrderCreated や PaymentProcessed などのイベントが日常的に発行されます。 しかし、イベント発行の完全な信頼性を確保するには大きな課題があります：「データベースの更新」と「イベント発行」の双方を、確実に「両方成功」か「両方失敗」にするにはどうすればよいか？ マイクロサービスがローカルDB（PostgreSQLやMySQL）を更新した直後にメッセージブローカー（KafkaやRabbitMQ）へネットワーク経由で送信しようとすると、ネットワーク障害やタイムアウトによってデータ不整合が発生します。 この問題を根本的に解決するのが Transactional Outbox パターン です。 根本的な課題：二重書き込み問題 (Dual-Write Problem) 二重書き込みを単純に行うと、以下のリスクが生じます： ローカルデータベースへビジネスデータを保存 メッセージブローカーへイベントを発行 DBコミットが成功した後にKafkaへの送信がネットワークエラーで失敗した場合、DBにはデータが存在するのに後続サービスへイベントが届きません。結果：データの不一致。 Transactional Outbox パターンとは？ リレーショナルデータベースの ローカルACIDトランザクション を活用する設計パターンです。 イベントを直接ネットワーク経由で送信するのではなく、ビジネスデータの保存と全く同じトランザクション内で、専用の Outbox テーブル にイベントデータを書き込みます。 ACIDの保証により、両方がコミットされるか、両方がロールバックされるかのいずれかになります。 その後、独立したバックグラウンドプロセス（Message Relay）がOutboxテーブルから読み出し、メッセージブローカーへ発行します。 メッセージリレー戦略：Polling Publisher vs CDC (Debezium) 1. Polling Publisher（ポーリング方式） 定期的なスケジューラで未処理レコード（SELECT * FROM outbox_events WHERE processed = FALSE）を取得し、Kafkaに送信後に更新。