こんにちは。みらい翻訳のバックエンドエンジニアのtoshと申します。

弊社では既存のシステムのマイクロサービス化を目指しており、そのための基盤の整備や技術検証を進めている段階です。

今回は現在技術検証を進めているDebeziumと、これを導入することにより、マイクロサービス化を推進する上でどのような効果があるのかを紹介したいと思います。

Debeziumとは

Debezium Documentation :: Debezium Documentation

DebeziumはDBに対するデータ操作をキャプチャしてイベントストリームに変換してくれる分散プラットフォームです。
Apache Kafkaをベースに実装されており、Kafka Connectベースのコネクタを利用してDBをモニターすることができます。
既存DBに対するデータ操作をKafkaのメッセージに変換することができるので、レガシーシステムなどでアプリケーションに手を入れたくないけど、データだけ抜き出してリアルタイム処理したい際や、別システムにデータを流用したいという場合に便利なソフトウェアです。(詳細は後述)
また、イベントログはKafkaが保持してくれているので、データを利用する側(consumer)が止まってもイベントログが失われることはなく、consumerを復旧させれば処理を再開することが可能です。

例: debeziumを使ってとあるデータストアのデータを別のデータストアにマイグレーションをする

debeziumを使ってとあるデータストアのデータを別のデータストアにマイグレーションをする例

Apache Kafkaとは

Apache Kafka

Apache Kafkaはオープンソースの分散型イベントストリーミングプラットフォームです。
ハイパフォーマンスデータパイプライン、ストリーミングアナリティクス、データ統合、
ミッションクリティカルなアプリケーションなどに利用されています。
また、スケーラブルで可用性・耐障害性も高いのが特徴です。

Kafka Connectとは

KafkaとRDBMSやKVSなどその他のシステム間でデータを連携するためのスケーラブルなツールです。
Debeziumを利用する際には、Debeziumのコネクタ構成ファイルを作成し、Kafka ConnectのConnectorのREST APIを使用してKafka Connectのクラスタにコネクタ構成を追加します。

Change Data Capture(CDC)とは

CDCは、データベースに起こった変更イベントをキャプチャして、別のイベントを発火させるパターンです。
実装方法は何パターンかあります。

バッチで行う
トリガーを使う
トランザクションログを監視する

Debeziumは３つ目のトランザクションログを利用してCDCを行うツールです。
トランザクションログをイベントストリームとして処理して、他のデータベースやソフトウェア(例えば Elastic Search)に伝播させ、データベースの反映、インデックスの更新など様々なアクションを取ることができます。

Outboxパターンについて

Outboxパターンは、イベントをOutboxテーブルに書き込み、書き込まれたデータをイベントとして処理するパターンです。
CDCと組み合わせて使う場合、Outboxテーブルの更新イベントをDebeziumに監視させて、Pub/Subモデルを使って様々なシステムにイベントを送信することができます。

f:id:tosh_m:20211208112129j:plain — CDCでイベントを様々なシステムに伝搬させる例

マイクロサービスアーキテクチャへの活用方法

参考:

Red Hat Integration – Change Data Capture Tech Preview | by Kenta Kosugi | Medium

マイクロサービスのための分散データ〜イベントソーシング vs チェンジデータキャプチャ - 赤帽エンジニアブログ

上記のCDC + Outboxパターンはマイクロサービスアーキテクチャを採用している組織の場合、分散システム間の連携に使うこともできます。

下記の例は、ECサイトで注文後、別システムで決済処理と在庫引当処理を別システムで行う例です。
最後に注文状況の問い合わせもしています。注文状況は、決済処理や在庫処理の結果によって変化するものとお考えください。

f:id:tosh_m:20211208112215j:plain — ECサイトで注文処理後、注文データを決済システムと在庫管理システムに連携させる例

上記の図を見てお気づきの方もいらっしゃるとは思いますが、上記の例はイベントソーシングと非常によく似ています。
分散システム間の連携手法としては、イベントソーシング+CQRSなどのパターンの方がメジャーかなと思っています。どちらのパターンも、クエリに対しては結果整合性モデルなのですが、書き込み処理は若干の違いがあると考えています。(本記事ではイベントソーシングやCQRSについての説明は割愛します)

イベントソーシング+CQRSはジャーナルへの大量のデータ書き込みがある場合等の特定のユースケースには非常に強いものの、デメリットもあると考えています。
一点目はエラー発生時のデータの一貫性の問題です。データストアが２種類存在するのが一般的であるため(イベントのスナップショットDBと、別DBやメッセージングシステムへのデータ書き込み)、コマンド発行時のスナップショットの永続化とイベントストアへの書き込みを同一トランザクションとできません。そのため、どちらかが失敗した際のハンドリングがアプリケーション依存となります。(2フェーズコミットの問題)
別システムを同じアーキテクチャで構築しようとした場合、常にこの問題がつきまといます。アプリケーションレイヤーで適切なエラーハンドリングが必要になります。

対して、CDCはDBの更新に対して特定の処理をフックさせるモデルなので、データの一貫性があり、データの損失の心配もありません。また、一度基盤を構築してしまえばそれ以降の実装はシンプルになると思います。弊社の場合、主要なデータストアとしてAmazon Aurora for PostgreSQLを使っています。例えば、すでにCDC基盤を構築しており、既存のCDCシステムでは対応していないテーブルに対してCDCを実施しようとした場合、publication(トランザクションログを送信する対象テーブルをまとめてあるデータ)の対象テーブルを追加すれば、Debeziumが自動でKafkaのトピックを作成してストリーミング処理をさせることができます。
CDCのデメリットですが、トランザクションログを読み取ってKafkaに連携する際のレイテンシがある点です。そのためのチューニングが必要になる可能性があります。

また、Debeziumの説明の箇所でも記載しましたが、レガシーシステムを新システムにリプレースする際にも使えます。
レガシーアプリケーションに手を入れずにデータをコピーさせることにより、データストアの移行に用いることができます。トリガーでほぼ同じような処理を実行させることもできますが、トリガーには以下のような弊害もあります。