第9章 MirrorMaker 2 での AMQ Streams の使用


MirrorMaker 2 を使用して、データセンター内またはデータセンター間で 2 つ以上のアクティブな Kafka クラスター間でデータをレプリケーションします。

MirrorMaker 2 を設定するには、config/connect-mirror-maker.properties 設定ファイルを編集します。必要に応じて、MirrorMaker 2 の分散トレースを有効 にすることができます。

大量のメッセージ処理

設定を調整して、大量のメッセージを処理できます。詳細は、11章大量のメッセージ処理 を参照してください。

注記

MirrorMaker 2 には、MirrorMaker の以前のバージョンではサポートされていない機能があります。ただし、MirrorMaker 2 をレガシーモードで使用するように設定 できます。

9.1. MirrorMaker 2 データレプリケーション

クラスター全体のデータレプリケーションでは、以下を必要とする状況がサポートされます。

  • システム障害時のデータの復旧
  • 分析用のデータの集計
  • 特定のクラスターへのデータアクセスの制限
  • レイテンシーを改善するための特定場所でのデータのプロビジョニング

9.1.1. MirrorMaker 2 の設定

MirrorMaker 2 は、ソース Kafka クラスターからのメッセージを消費し、ターゲット Kafka クラスターに書き込みます。

MirrorMaker 2 は以下を使用します。

  • ソースクラスターからデータを消費するソースクラスターの設定
  • データをターゲットクラスターに出力するターゲットクラスターの設定

MirrorMaker 2 は、クラスター間のデータ転送を管理する コネクター である Kafka Connect フレームワークに基づいています。

MirrorMaker 2 を設定して、ソースクラスターとターゲットクラスターの接続の詳細を含む Kafka Connect デプロイメントを定義し、一連の MirrorMaker 2 コネクターを実行して接続を確立します。

MirrorMaker 2 は次のコネクターで設定されます。

MirrorSourceConnector
ソースコネクターは、トピックをソースクラスターからターゲットクラスターにレプリケーションします。また、ACL をレプリケーションし、MirrorCheckpointConnector を実行する必要があります。
MirrorCheckpointConnector
チェックポイントコネクターは定期的にオフセットを追跡します。有効にすると、ソースクラスターとターゲットクラスター間のコンシューマーグループオフセットも同期されます。
MirrorHeartbeatConnector
ハートビートコネクターは、ソースクラスターとターゲットクラスター間の接続を定期的にチェックします。
注記

User Operator を使用して ACL を管理する場合、コネクターを介した ACL レプリケーションはできません。

ソースクラスターからターゲットクラスターへのデータの ミラーリング プロセスは非同期です。各 MirrorMaker 2 インスタンスは、1 つのソースクラスターから 1 つのターゲットクラスターにデータをミラーリングします。複数の MirrorMaker 2 インスタンスを使用して、任意の数のクラスター間でデータをミラーリングできます。

図9.1 2 つのクラスターにおけるレプリケーション

MirrorMaker 2 レプリケーション

デフォルトでは、ソースクラスターの新規トピックのチェックは 10 分ごとに行われます。頻度は、refresh.topics.interval.seconds をソースコネクター設定に追加することで変更できます。

9.1.1.1. クラスター設定

MirrorMaker 2 は、アクティブ/パッシブ または アクティブ/アクティブ クラスター設定で使用できます。

アクティブ/アクティブのクラスター設定
アクティブ/アクティブ設定には、双方向でデータをレプリケーションするアクティブなクラスターが 2 つあります。アプリケーションはいずれかのクラスターを使用できます。各クラスターは同じデータを提供できます。これにより、地理的に異なる場所で同じデータを利用できるようにします。コンシューマーグループは両方のクラスターでアクティブであるため、レプリケーションされたトピックのコンシューマーオフセットはソースクラスターに同期されません。
active/passive クラスター設定
active/passive 設定には、passive クラスターにデータをレプリケーションする active クラスターがあります。passive クラスターはスタンバイのままになります。システムに障害が発生した場合に、データ復旧に passive クラスターを使用できます。

プロデューサーとコンシューマーがアクティブなクラスターのみに接続することを前提とします。MirrorMaker 2 クラスターはターゲットごとに必要です。

9.1.1.2. 双方向レプリケーション (active/active)

MirrorMaker 2 アーキテクチャーは、アクティブ/アクティブ クラスター設定での双方向レプリケーションをサポートします。

各クラスターは、source および remote トピックの概念を使用して、別のクラスターのデータをレプリケーションします。同じトピックが各クラスターに保存されるため、リモートトピックの名前は MirrorMaker 2 によってソースクラスターを表すように自動的に変更されます。元のクラスターの名前の先頭には、トピックの名前が追加されます。

図9.2 トピック名の変更

MirrorMaker 2 双方向アーキテクチャー

ソースクラスターにフラグを付けると、トピックはそのクラスターにレプリケーションされません。

remote トピックを介したレプリケーションの概念は、データの集約が必要なアーキテクチャーの設定に役立ちます。コンシューマーは、同じクラスター内でソースおよびリモートトピックにサブスクライブできます。これに個別の集約クラスターは必要ありません。

9.1.1.3. 一方向レプリケーション (active/passive)

MirrorMaker 2 アーキテクチャーは、active/passive クラスター設定での一方向レプリケーションをサポートします。

active/passive のクラスター設定を使用してバックアップを作成したり、データを別のクラスターに移行したりできます。この場合、リモートトピックの名前の自動変更は推奨しません。

IdentityReplicationPolicy をソースコネクター設定に追加することで、名前の自動変更をオーバーライドできます。この設定が適用されると、トピックには元の名前が保持されます。

9.1.2. トピック設定の同期

MirrorMaker 2 は、ソースクラスターとターゲットクラスター間のトピック設定の同期をサポートします。MirrorMaker 2 設定でソーストピックを指定します。MirrorMaker 2 はソーストピックを監視します。MirrorMaker 2 は、ソーストピックへの変更を検出し、リモートトピックに伝達します。変更には、欠けているトピックおよびパーティションの自動作成が含まれる場合があります。

注記

ほとんどの場合、ローカルトピックに書き込み、リモートトピックから読み取ります。リモートトピックでは書き込み操作ができないわけではありませんが、使用しないようにしてください。

9.1.3. オフセットの追跡

MirrorMaker 2 は、内部トピックを使用してコンシューマーグループのオフセットを追跡します。

offset-syncs トピック
offset-syncs トピックは、レプリケーションされたトピックパーティションのソースおよびターゲットオフセットをレコードメタデータからマッピングします。
checkpoints トピック
checkpoints トピックは、各コンシューマーグループでレプリケーションされたトピックパーティションのソースおよびターゲットクラスターで、最後にコミットされたオフセットをマッピングします。

これらは MirrorMaker 2 によって内部的に使用されるため、これらのトピックと直接対話することはありません。

MirrorCheckpointConnector は、オフセット追跡用の チェックポイント を発行します。checkpoints トピックのオフセットは、設定によって事前に決定された間隔で追跡されます。両方のトピックは、フェイルオーバー時に正しいオフセットの位置からレプリケーションの完全復元を可能にします。

offset-syncs トピックの場所は、デフォルトで source クラスターです。offset-syncs.topic.location コネクター設定を使用して、これを target クラスターに変更することができます。トピックが含まれるクラスターへの読み取り/書き込みアクセスが必要です。ターゲットクラスターを offset-syncs トピックの場所として使用すると、ソースクラスターへの読み取りアクセス権しかない場合でも、MirrorMaker 2 を使用できるようになります。

9.1.4. コンシューマーグループオフセットの同期

__consumer_offsets トピックには、各コンシューマーグループのコミットされたオフセットに関する情報が保存されます。オフセットの同期は、ソースクラスターのコンシューマーグループのコンシューマーオフセットをターゲットクラスターのコンシューマーオフセットに定期的に転送します。

オフセットの同期は、特に active/passive 設定で便利です。アクティブなクラスターがダウンした場合、コンシューマーアプリケーションを passive (スタンバイ) クラスターに切り替え、最後に転送されたオフセットの位置からピックアップできます。

トピックオフセットの同期を使用するには、sync.group.offsets.enabled を checkpoint コネクター設定に追加し、プロパティーを true に設定して、同期を有効にします。同期はデフォルトで無効になっています。

ソースコネクターで IdentityReplicationPolicy を使用する場合は、チェックポイントコネクター設定でも設定する必要があります。これにより、ミラーリングされたコンシューマーオフセットが正しいトピックに適用されます。

コンシューマーオフセットは、ターゲットクラスターでアクティブではないコンシューマーグループに対してのみ同期されます。コンシューマーグループがターゲットクラスターにある場合、Synchronization を実行できず、UNKNOWN_MEMBER_ID エラーが返されます。

同期を有効にすると、ソースクラスターからオフセットの同期が定期的に行われます。この頻度は、sync.group.offsets.interval.seconds および emit.checkpoints.interval.seconds をチェックポイントコネクター設定に追加することで変更できます。これらのプロパティーは、コンシューマーグループのオフセットが同期される頻度 (秒単位) と、オフセットを追跡するためにチェックポイントが生成される頻度を指定します。両方のプロパティーのデフォルトは 60 秒です。refresh.groups.interval.seconds プロパティーを使用して、新規コンシューマーグループのチェック頻度を変更することもできます。デフォルトでは 10 分ごとに実行されます。

同期は時間ベースであるため、コンシューマーによって passive クラスターへ切り替えられると、一部のメッセージが重複する可能性があります。

注記

Java で作成されたアプリケーションがある場合は、RemoteClusterUtils.java ユーティリティーを使用して、アプリケーションを通じてオフセットを同期できます。ユーティリティーは、checkpoints トピックからコンシューマーグループのリモートオフセットを取得します。

9.1.5. 接続性チェック

MirrorHeartbeatConnectorheartbeat を発行して、クラスター間の接続を確認します。

内部 heartbeat トピックは、ソースクラスターからレプリケーションされます。ターゲットクラスターは、heartbeat トピックを使用して次のことを確認します。

  • クラスター間の接続を管理するコネクターが稼働しているかどうか
  • ソースクラスターが利用可能かどうか
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る