アプリケーション・モダナイゼーション：マイクロサービス間のデータ同期

レッドハットのソリューションアーキテクトの森です。

マイクロサービスについて、前回はそのアーキテクチャの概要から利点、そして課題についてまとめました。今回はマイクロサービス間のデータ同期の手法についてご紹介していきます。

前回の記事はこちらです。

rheb.hatenablog.com

Outboxパターンと Change Data Capture によるデータ同期

マイクロサービスにおいては、基本的には各サービスとデータベースは1:1とするモデルを推奨しています。そのため、サービス間のデータベースの同期を取るしくみについて考慮が必要です。データベース間の同期を取るための方法の1つとして、データベース処理とメッセージを併用する Transactional Outbox と Transactionlog tailing があります。

Transactional Outbox の実体はデータベースのテーブルであり、マイクロサービスのデータを格納するデータベースの中に同居します。そして、データに対する処理を通知するイベント情報を格納し、共有するために用いられます。それらは同一のデータベースに共存しているので、ローカルトランザクションでもお互いの内容は即時に同期を取ることができます。Transaction log tailing は、Outboxテーブルのトランザクションログへのログエントリを監視をする Transaction log miner を用意します。これは、データベースのトランザクションログ上に書き出された新たなログエントリを取得し、メッセージブローカーにメッセージを発行して、後続のサービスにおけるトランザクション処理につなげます。

異常系の処理として、たとえば注文サービスによるデータ処理は成功したものの、在庫サービスの処理で何らかの不具合が発生した場合には、在庫サービスは在庫テーブルへの処理をロールバックし、Outboxテーブル、Transaction log miner、メッセージブローカーを介して在庫サービスにおけるデータ処理失敗のイベントを通知します。

トランザクションログを監視するミドルウェアとして、レッドハットでは Debezium を提供しています。これは、Kafka Connect の機能を利用したデータベースへのコネクタで、指定されたデータベースに接続し、トランザクションログを読み取り、それを Kafka のメッセージとして発行します。

上記のしくみでデータベース間の同期を取ることができますが、厳密には各データベースの整合性が取れるまでには数百ミリ秒~数秒単位のラグが発生します。つまり、常時データベース間の整合性が取れていなければならない場合には適用できませんが、「結果整合性」が許容できる場合に活用できる方法です。この結果整合性が許容できるかどうか、というのは業務ドメインのエキスパートも交えて判断する必要があります。業務ドメインのエキスパートも巻き込んで、必要とされる要件を洗い出し、データベース間の同期/整合性の設計を行っていきましょう。