Kafka MirrorMaker 2 (と Kafka Connect)
Apache Kafka 2.4.0 で導入された MirrorMaker 2 は従来の MirrorMaker では課題になっていた部分を解決したものになります。
Mirror Maker 2 は Kafka Connect フレームワークに基づいて開発されているため、Kafka Connect を簡単に紹介してから MirrorMaker2 での変更点を説明します。
Kafka Connect とは
Kafka の本家サイトによると以下のように記載されています。
Kafka Connect is a tool for scalably and reliably streaming data between Apache Kafka and other systems. It makes it simple to quickly define connectors that move large collections of data into and out of Kafka. Kafka Connect can ingest entire databases or collect metrics from all your application servers into Kafka topics, making the data available for stream processing with low latency. An export job can deliver data from Kafka topics into secondary storage and query systems or into batch systems for offline analysis.
Kafka Connect は、Apache Kafka と他のシステム間でスケーラブルかつ確実にデータをストリーミングするためのツールです。Kafka Connect を使用すると、大規模なデータのコレクションを Kafka に出し入れするためのコネクタを簡単に定義することができます。Kafka Connect は、データベース全体をインジェストしたり、すべてのアプリケーションサーバから Kafka トピックにメトリクスを収集したりすることができ、データを低遅延でストリーム処理に利用できるようにします。エクスポートジョブでは、Kafkaトピックからのデータをセカンダリストレージやクエリシステムに配信したり、オフライン分析用のバッチシステムに配信することができます。
わかりやすく言うと、Kafka とKafka 以外のシステムを連携させる際に、プロデューサー、コンシューマーを自身で開発するのではなく、予め一般化されノンコーデイングで利用可能な Kafka Connector を活用することで容易に Kafka に接続してデータの投入・取得を取り扱えるようにするものです。
以下は Red Hat Integration で Tech Preview となっている Camel Kafka Connector の図です。AMQ Streams の両サイドにある source connector と sink connector が Kafka Connect を利用して開発されている Connector になります。
現在は Tech Preview のため、利用可能な Connector は限られていますが、将来利用可能になる Connector はさらに増えるでしょう。
例えば、Camel Kafka Connector には上記の Connector が用意されています。AWS S3 からデータを取得して Kafka に投入、あるいは Kafka からデータを取得して S3 にデータを投入する Connector を利用可能です。
Red Hat が Camel Kafka Connector を開発している理由は OpenShift 4.6 で GA 予定の OpenShfit Serverless Eventing に対応するべく、様々なシステムが発生させるイベントを Camel Kafka Connector を使用してノンコーディングで Kafka に投入/取得し、サーバーレスアプリケーションへ連携するためだと考えられます。
Kafka Mirror Maker のユースケース
異なるデータセンター間のデータレプリケーションやディザスタリカバリが主なユースケースとなるでしょう。
Kafka MirrorMaker2 における変更点
Kafka MirrorMaker2 では上述の Kafka Connect が利用されています。MirrorMaker はソースクラスタからデータを取得する Source、ターゲットクラスタへデータを投入する Sink の役目を両方担います。
双方向レプリケーション(active/active 構成)
従来の MirrorMaker では active/passive のレプリケーションしかできませんでしたが、MirrorMaker 2 では双方向レプリケーションを可能とする active/active のレプリケーションも可能になっています。
- active/passive 構成 : アクティブなクラスタからのデータは、システム障害時のデータ回復のために、例えば、待機するパッシブクラスタに複製されます。
- acitve/active 構成 : 両方のクラスタは、アクティブであり、地理的に異なる場所でローカルに同じデータを利用できるようにしたい場合に指定します。
Kafka のプロデューサー/コンシューマーは active なクラスターにしか接続することができないので passive 構成は active 構成が障害の際にデータ回復の目的で利用することが目的になります。
従来の MirrorMaker を使用した場合、Source 側のトピック名は Sink 側に自動的に作成されていました。
この方式のまま active/active 構成をとると、Source 側に投入されたデータが、Sink 側のパーティションに格納されるとそのデータを再度 Source 側にレプリケーションする…(以下無限ループ)となってしまいます。
そこで、リモートトピックという概念を導入し、下図のように異なるデータセンターから同じ Topic1 に対して書き込みをしたとしても相手側のリモートトピックにレプリケーションされるという方式をとることでこの問題を解決しているようです。
トピック構成の同期
従来の MirrorMaker では active なクラスターのトピックの構成を変更してもターゲット側への構成変更を伝播することはできず、手動で構成を合わせる必要がありました。
しかし、MirrorMaker2 ではトピック・プロパティの構成の同期を実現しています。具体的にはソーストピックを読み取ることができるプリンシパルはリモートトピックも読み込めるように設定されるように ACL 構成も伝播します。リモートトピックに書き込みができるのは MirrorMaker2 だけになります。
オフセット追跡
また、Kafka ではトピックにおけるパーティションでどこまで処理が終わったかを示す __consumer_offsets は従来の MirrorMaker ではレプリケーションされませんでした。そのため、ソースとターゲットでオフセットの違いが生じます。従ってフェイルオーバーの際は問題になることが多かったようです。
MirrorMaker2 ではこれらの問題が完全に解消されました。
リバランスの調整
従来の MirrorMaker ではトピックの変更の度に発生するリバランスによりレイテンシーのスパイクが発生し、さらなるリバランスを引き起こしていました。MirrorMaker2 ではこの仕組みを解消し、頻繁なリバランスが発生しないように変更されています。これは上記のトピック構成の同期のおかげでトピックの変更によるリバランスの必要性が大幅に削減されたことに起因しています。
