Kafka Cluster Linkingで実現するオフセット保持の複製と移行

Cluster Linkingは、ブローカー同士が直接レプリケーションするConfluentの公式機能で、トピックのパーティション・レコード・オフセットを1対1で保持して複製します。これにより、消費者の再バランスやオフセット変換を最小限に抑えた移行やDRが可能になります。

本稿では、オフセット保持を前提にした複製・移行の設計注意点、段階的カットオーバー手順、監視と検証方法を解説し、CCAAK受験で問われやすい差異点もまとめます。

Cluster Linkingの要点とオフセット保持

Cluster Linkingは、宛先クラスタがリンク経由で元クラスタからデータをフェッチするサーバーサイド複製です。MirrorMaker 2のような外部コネクタを介さず、トピック単位の"ミラー"を宛先側に作成して、元トピックのパーティション構成・順序・各レコードのオフセットをそのまま保持します。

オフセットが保持されることで、消費者はクラスタ切替後も同じ数値のオフセットから再開できます。従来必要だったオフセット変換や整合性のための待ち時間が大幅に減り、DR/リージョン移行/ブルーグリーン展開が単純化されます。

• リンクは一方向。宛先は読み取り専用のミラートピックを持ち、書き込みは元クラスタのみ。
• ミラートピックはパーティション数・番号を元と一致させ、各レコードのオフセットを同一に保持。
• 昇格(プロモート)でミラートピックを通常トピックに切替え、以後は宛先でのプロデュースが可能。
• コンシューマグループのコミット情報(_consumer_offsets)は自動転送ではない前提で計画するのが安全。

オフセット保持のイメージ（同一パーティション/同一オフセット）

最小リンク作成（宛先クラスタ側で実行）

# 宛先: リンク作成（プロパティファイルで安全に資格情報を保持）\n# link-src.properties 例\n# bootstrap.servers=src-broker:9092\n# security.protocol=SASL_SSL\n# sasl.mechanism=PLAIN\n# sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username=\"...\" password=\"...\";\n\n# 宛先でリンクを作成\n$ kafka-cluster-links \\\n  --bootstrap-server dest-broker:9092 \\\n  --create --link src-to-dest \\\n  --config-file link-src.properties\n\n# ミラートピック作成（orders を元からミラー）\n$ kafka-mirrors \\\n  --bootstrap-server dest-broker:9092 \\\n  --create --mirror-topic orders --link src-to-dest

オフセット保持の挙動と前提条件

Cluster Linkingでは、ミラートピックの各パーティションは元の同一パーティションからフェッチし、各レコードのオフセット・タイムスタンプ・ヘッダを保持します。これにより、コンシューマはクラスタ切替時にオフセット値の変換を必要とせず、シークの一貫性が得られます。

ただし、以下が満たされていないと、切替時に期待どおりに再開できない可能性があります。特に、ミラー中は宛先側への書き込みができないため、完全なカットオーバーまでは書き込み先が単一であることを守る必要があります。

• パーティション数・番号の一致（ミラートピックは元のパーティション構成を踏襲）。
• キー分散と順序の一貫性（同一キーは同一パーティション）。
• コンシューマグループのコミット情報は宛先に事前移行または手動で整合（後述の手順参照）。
• トランザクション境界はクラスタをまたがない前提で設計。

ミラーの状態確認（遅延・健康度）

# リンク/ミラーの記述\n$ kafka-cluster-links --bootstrap-server dest:9092 --describe --link src-to-dest\n$ kafka-mirrors --bootstrap-server dest:9092 --describe --mirror-topic orders\n\n# 代表的な遅延メトリクス（JMX名は環境によりプレフィックス差異あり）\n# kafka.server: type=ReplicaFetcherManager,name=MaxLag,clientId=*,link=src-to-dest\n# kafka.server: type=MirrorTopicMetrics,name=TimeLag,topic=orders

移行・DR・ブルーグリーンでの使い分け

移行: 既存クラスタ(Source)でプロデュースを継続しながら、宛先(Destination)でミラーを追随させ、十分に追いついたタイミングで昇格し、書き込み先を切替えます。オフセット保持により、消費者は同じオフセットで読み続けられます。

DR: 平常時は片方向にミラー。障害時に宛先でミラーを昇格し、プロデュース/コンシュームを切替えます。復旧後に逆方向の新リンクを張り返す計画（ブレインスプリット回避のため、同時双方向書き込みは避ける）。

• ブルー/グリーン: グリーン側でミラーを作り、昇格してトラフィックを段階的に移す。
• 段階的検証: 一部トピックのみミラー→昇格でローリングに移行。
• 規制/データ所在地: リージョン間複製時は暗号化と認可を独立管理（ACL/RBACは別途配布）。

昇格（プロモート）と書き込み切替の最小シーケンス

# 1) 生産を短時間停止（ソースの最終レコードまで追いつかせる）\n# 2) 宛先でミラーを昇格（以後、通常トピック）\n$ kafka-mirrors --bootstrap-server dest:9092 --promote --mirror-topic orders\n# 3) プロデューサのbootstrap.serversを宛先に変更して再開\n# 4) コンシューマは同じgroup.id/オフセットで継続（次節のオフセット整合参照）

オフセット保持を活かしたカットオーバー手順

Cluster Linkingはレコードのオフセットを保持しますが、コンシューマグループのコミットは別トピックに格納されるため、自動移行を前提にしないのが安全です。以下は停止時間を最小化しつつ、同一オフセットで切替えるための現実的な手順です。

なお、auto.offset.reset=latest/earliest の既定挙動に依存すると再開位置がズレるため、宛先でのグループオフセットを明示的に整合させます。

• 前提: ソースと宛先で対象トピック名・パーティション構成を一致。ミラーのラグが十分に小さい状態を確認。
• 短時間の生産停止→昇格→生産再開の順。消費は必要に応じて一時停止し、昇格直後に再開。
• グループオフセットは宛先で同一数値に手動設定（例: kafka-consumer-groups --reset-offsets --to-offset）。

グループオフセットの事前整合（例: 単一トピック・少数パーティション）

# 1) ソースで現在のコミット位置を確認\n$ kafka-consumer-groups --bootstrap-server src:9092 --describe --group app-g1 \\n  --topic orders\n# 出力から各partitionのCURRENT-OFFSETを控える（p0=1043, p1=879 など）\n\n# 2) 宛先で同じgroup.idに対し、手動で同値を設定\n$ kafka-consumer-groups --bootstrap-server dest:9092 --group app-g1 \\n  --topic orders --reset-offsets --to-offset 1043 --partition 0 --execute\n$ kafka-consumer-groups --bootstrap-server dest:9092 --group app-g1 \\n  --topic orders --reset-offsets --to-offset 879  --partition 1 --execute\n\n# 3) ミラーを昇格し、コンシューマ/プロデューサを宛先に切替\n$ kafka-mirrors --bootstrap-server dest:9092 --promote --mirror-topic orders

運用・監視指標とトラブルシュート

遅延は切替可否判断の核心です。TimeLag/RecordsLag、リンクのヘルス、フェッチエラーの有無をモニタリングし、ラグしきい値を定めます。ネットワーク帯域やretention.msの差異で進行が詰まるケースに注意します。

設定ドリフトは意図せぬ挙動の原因です。cleanup.policy, min.insync.replicas, compression.type など、ミラー作成時点の設定を確認し、昇格後に必要なら明示的に変更します。ACL/RBACは別管理とし、切替前にアクセス権を先行配布します。

• Lag監視: MirrorTopicMetrics(TimeLag/RecordsLag)、リンク状態(Established/Failed)。
• 帯域制御: レプリケーション帯域の上限/下限、ピーク時間帯の調整。
• 検証: 宛先でのサンプルコンシュームでオフセット整合をスポット確認。

簡易ヘルスチェックと遅延取得の例

# Describeでリンクとミラーの状態を点検\n$ kafka-cluster-links --bootstrap-server dest:9092 --describe --link src-to-dest | sed -n '1,200p'\n$ kafka-mirrors --bootstrap-server dest:9092 --describe --mirror-topic orders\n\n# JMXをcurl/jolokia等で取得し、TimeLagがしきい値未満であることを確認\n# 例: curl http://jolokia:8778/jolokia/read/kafka.server:type=MirrorTopicMetrics,name=TimeLag,topic=orders

CCAAKで問われやすいポイント整理

Cluster Linkingは「レコードのオフセット保持」が最大の差別化点です。MirrorMaker 2のOffset Syncのような変換が不要であること、ミラートピックは宛先で読み取り専用であること、昇格で通常トピックになることを押さえます。

試験では、どのレイヤで機能が提供されるか（ブローカー/Connect）、切替時に必要な操作（昇格・グループオフセット整合）、二重書き込み回避などの設計判断が頻出です。

• オフセット保持＝消費位置の数値同一。グループコミットは別管理が基本。
• ミラー中は宛先への書き込み不可。昇格後に書き込み可。
• Cluster Linkingはサーバーサイド。MM2はConnectベース。

要点チェック（擬似コマンドによる暗記用メモ）

# create link -> create mirror -> catch up -> promote -> switch clients\n# オフセット保持: 変換不要。グループオフセット: 手動整合/移行を計画。

問題で確認

よくある質問