MirrorMaker 2で学ぶクラスタ間レプリケーションの基礎

クラスタ間レプリケーションは、DR（災害対策）、リージョン間多活、移行時のダウンタイム削減に直結します。本稿ではKafka Connect上で動くMirrorMaker 2（以下MM2）の基本構造と設定要点を、過不足なく押さえます。

CCAAKではMM2のコンポーネント、トピック命名ポリシー、オフセット同期、内部トピックの役割が頻出です。暗記ではなく公式の振る舞いに即して理解しておきましょう。

基本概念と主なユースケース

MM2はKafka Connectベースのレプリケーション仕組みで、ソースクラスタからターゲットクラスタへトピックデータ、必要に応じてトピック設定やコンシューマグループのオフセット情報を同期します。一般にクラスタには短い別名（エイリアス）を付け、レプリケーションポリシーによってターゲット側のトピック名が決まります。

典型的なユースケースは、DRサイトへの片方向レプリケーション、別リージョンへの配信、段階的クラスタ移行、集約クラスタの構築です。RPO/RTO要件、ネットワーク遅延、対象トピックの粒度を最初に明確化するのが設計の第一歩です。

• DR設計の前提: RPO/RTO、ネットワーク帯域、レイテンシ許容値を数値で決める
• 対象範囲: 正規表現でトピックを選択し、不要な内部/検証用トピックは除外
• データ主権/コンプライアンス: リージョン越境の可否と暗号化方式（SASL_SSL/SSL）を確認

MirrorMaker 2のアーキテクチャ

MM2はKafka Connectの上で3つのコネクタ群として動作します。MirrorSourceConnectorがトピックデータを読み出してターゲットに書き込み、MirrorCheckpointConnectorがコンシューマグループのチェックポイント（ソースとターゲットのオフセット対応情報）を同期し、MirrorHeartbeatConnectorがヘルス確認用のハートビートを送ります。これらは分散Connectワーカー上でタスクとして並列動作します。

トピック命名はデフォルトのDefaultReplicationPolicyにより、ターゲット側では「<ソースエイリアス>.<元トピック名」の形式になります。内部的にはチェックポイント、ハートビート、オフセット同期用の専用トピックがターゲット側に作成され、レプリケーションの整合性維持と監視に利用されます。

• 順序性: パーティション内の順序は維持。クラスタ間のトランザクション整合性（EOSの端から端まで）は提供されない
• 内部トピック: heartbeats、checkpoints、offset-syncs はコンパクション有効・十分なreplication.factorで作成
• 拡張性: Connectのtasks.maxで並列度を上げ、I/Oパス（ソース消費・ターゲット書き込み）をスケールアウト

MM2の論理構成（片方向レプリケーション）

最小構成と基本プロパティ

MM2は単一のプロパティファイルで複数クラスタを定義し、方向ごとに有効化します。正規表現で対象トピックを指定し、内部トピックとターゲット側に作成されるトピックのreplication.factorを十分に確保します。セキュリティはクラスタごとのconsumer/producer/admin接頭辞で指定します（SASL/SSL設定など）。

トピック設定同期やグループオフセット同期は明示的に有効化します。命名ポリシーを変える場合はReplicationPolicyを差し替えますが、移行計画と整合するか慎重に判断してください。

• 方向指定: src->dst.enabled=true で片方向を明確化（双方向はループ防止策が必須）
• 対象選択: source->target.topics に正規表現、除外は source->target.topics.blacklist などを活用
• 内部トピック: heartbeats/checkpoints/offset-syncs のreplication.factorを3以上にするのが実務上の目安

mm2.properties（片方向：src→dst の一例）

clusters=src,dst

src.bootstrap.servers=SRC_BROKERS:9092
dst.bootstrap.servers=DST_BROKERS:9092

# 有効化（方向ごと）
src->dst.enabled=true
# 対象トピック（正規表現）。必要に応じて限定する
src->dst.topics=orders|payments|users
# 例: 除外を使う場合（実装/配布によりプロパティ名が異なることがあるため公式ドキュメントを確認）
# src->dst.topics.blacklist=^_.*

# 命名ポリシー（デフォルトは src.<topic> 形式）
replication.policy.class=org.apache.kafka.connect.mirror.DefaultReplicationPolicy

# 設定とオフセット同期
sync.topic.configs.enabled=true
sync.group.offsets.enabled=true
emit.heartbeats.enabled=true

# 並列度と冗長性
tasks.max=4
replication.factor=3
checkpoints.topic.replication.factor=3
heartbeats.topic.replication.factor=3
offset-syncs.topic.replication.factor=3

# メタデータの更新間隔
refresh.topics.interval.seconds=60
refresh.groups.interval.seconds=60

# セキュリティ例（必要に応じて admin/producer/consumer の各接頭辞で設定）
src.consumer.security.protocol=SASL_SSL
src.consumer.sasl.mechanism=PLAIN
src.consumer.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="user" password="pass";

dst.producer.security.protocol=SASL_SSL
dst.producer.sasl.mechanism=PLAIN
dst.producer.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="user" password="pass";

# 必要に応じて管理クライアント
# dst.admin.security.protocol=SASL_SSL

トピック命名・設定同期とオフセット同期の理解

命名はReplicationPolicyに従います。DefaultReplicationPolicyではターゲット側のトピック名は「<ソースエイリアス>.<元名>」になり、衝突やループを避けやすくなります。IdentityReplicationPolicyを使うと同名トピックになりますが、双方向構成ではループ回避が難しく実務では慎重な設計が必要です。

オフセット同期はMirrorCheckpointConnectorとoffset-syncsにより行われ、sync.group.offsets.enabledを有効にすると、同一のgroup.idでターゲットにフェイルオーバーした際に、直近の整合した位置から再開しやすくなります。確実な移行には、ソース側コンシューマを停止→チェックポイントがターゲットへ反映されるのを待機→ターゲット側で同じgroup.idを起動、という手順が推奨です。

• 前提: ソース側のコンシューマは定期的にコミットしていること（オート/明示いずれでも可）
• 順序と重複: パーティション内順序は維持されるが、クラスタ間での厳密なEOSは非対応。重複耐性のある処理設計が無難
• トピック設定: sync.topic.configs.enabledで主要な設定を同期。ACLやクォータは環境依存で、別途の管理が必要なことが多い

運用・監視・チューニングの要点

監視はConnectワーカーと各コネクタ/タスクのJMXメトリクス、ターゲット側のheartbeats・checkpoints・offset-syncsトピックのレイテンシやサイズを中心に行います。レプリケーションラグはラグメトリクスやコンシューマラグの可視化で追跡します。

チューニングは並列度（tasks.max）、ソース側コンシューマのフェッチ/バッチ設定、ターゲット側プロデューサのバッチング（linger.ms, batch.size）などが有効です。ネットワークの帯域/RTTがボトルネックになりやすいため、リージョン間では圧縮（compression.type）も検討します。

• 内部トピックはcleanup.policy=compactを維持し、replication.factorを十分に確保
• トピック自動作成を前提にせず、必要に応じて事前作成 or 設定同期を明示的に有効化
• 双方向時はループ防止（自クラスタ由来メッセージの再取り込み抑止）を必ず設計に含める

MirrorMaker（旧）/ MirrorMaker 2 / Cluster Linkingの比較

運用や試験対策では、旧MirrorMakerとの違い、そしてConfluentのCluster Linking（製品機能）との住み分けを理解しておくと混乱を防げます。MM2はConnectベースで拡張性と可観測性が高く、オフセット/設定同期の仕組みを備えます。一方、Cluster Linkingはクラスタ間でのブローカー間リンクにより管理を単純化する設計です（Confluentの提供機能）。

• MM2はOSS Kafkaで一般的に利用可能。Cluster LinkingはConfluentプラットフォーム/Cloudの機能
• 試験ではMM2の3コネクタ構成、デフォルト命名、内部トピックの役割が狙われやすい

CCAAK試験対策の要点

MM2は3つのコネクタ（Source/Checkpoint/Heartbeat）で構成され、Kafka Connect上で動作する点を押さえる。デフォルトのReplicationPolicyではターゲットのトピック名にソースエイリアスの接頭辞が付く。

sync.group.offsets.enabled と sync.topic.configs.enabled を必要に応じて有効化する。内部トピック（heartbeats, checkpoints, offset-syncs）はcompactかつ十分なreplication.factorで運用する。クラスタ間のEOSは提供されないため、重複に強いコンシューマ設計が前提。

• 片方向レプリケーションの最小プロパティを再現できること
• フェイルオーバー手順（停止→チェックポイント反映→起動）を説明できること
• 旧MirrorMaker/Cluster Linkingとの違いを1行で言えること

問題で確認

よくある質問