Kafka の DR 戦略: リージョンフェイルオーバー設計

Kafka はブローカー内のレプリケーションで単一リージョン障害には強い一方、リージョン断には追加の設計が不可欠です。本稿は、RPO/RTO を起点とした DR 戦略と、MirrorMaker 2 または Cluster Linking によるリージョン間レプリケーションの実務指針をまとめます。

Confluent CCAAK では、耐久性パラメータ、レプリケーション方式、フェイルオーバー時のクライアント挙動やオフセット同期が頻出です。試験と運用の両面を意識し、確実に点が取れる設計・手順を提示します。

まず決めるべきは RPO/RTO と障害モデル

DR 設計の出発点は、想定する障害スコープと SLO（RPO/RTO）の確定です。リージョン断はネットワーク分断や電源喪失を含み、通常はクラスタ間のデータ複製が非同期になるため RPO は 0 になりません。RPO を小さくするほど、リンク帯域・遅延・コストのトレードオフが顕在化します。

クラスタ内の耐久性とクラスタ間の耐久性は分けて考えます。前者は min.insync.replicas、acks、unclean.leader.election.enable などで制御し、後者は MirrorMaker 2 または Cluster Linking の遅延・チェックポイント間隔・障害時の昇格手順で制御します。

• 障害モデルの明確化: AZ 障害、リージョン断、ネットワーク部分断（スプリットブレイン回避）
• SLO の数値化: RPO（例: ≤ 60 秒）、RTO（例: ≤ 15 分）
• 非機能要件: 帯域確保、暗号化、監査、レイテンシ上限
• テスト頻度: 四半期ごとの計画停止による DR ドリルの自動化

耐久性を下支えする代表設定（broker と producer）

# server.properties（クラスタ内の耐久性）
min.insync.replicas=2
unclean.leader.election.enable=false
replica.lag.time.max.ms=30000
# リージョン内のゾーン配置に合わせる
broker.rack=az-a

# プロデューサ設定（書き込みの耐久性）
acks=all
enable.idempotence=true
max.in.flight.requests.per.connection=1
retries=1000000
request.timeout.ms=30000
delivery.timeout.ms=120000

リージョン間レプリケーションの選択肢と比較

Kafka はリージョン間のネイティブ同期レプリケーションを持ちません。一般的な選択肢は MirrorMaker 2（Apache Kafka Connect ベース）と、Confluent の Cluster Linking です。どちらも原則非同期で、RPO はネットワーク遅延と処理遅延の合算で決まります。

MirrorMaker 2 は OSS ベースで柔軟なトポロジを組め、チェックポイントでコンシューマグループのオフセット同期を支援します。Cluster Linking はブローカーレベルのリンクで、ミラートピックの遅延が小さく運用も単純化されます（Confluent 環境前提）。

• 運用管理の単純さを重視するなら Cluster Linking、細かい制御や OSS 純度を重視するなら MirrorMaker 2
• いずれも非同期前提。RPO をゼロに近づけるには帯域・遅延・バッファ監視の強化が不可欠
• 双方向（アクティブ−アクティブ）は重複や順序差分の扱いが難度高。まずはアクティブ−パッシブで手順を固める

リージョン間レプリケーションの全体像

MirrorMaker 2 と Cluster Linking の最小構成例

# MirrorMaker 2（connect-mirror-maker 用プロパティ）
clusters = A, B
A.bootstrap.servers=a1:9092,a2:9092
B.bootstrap.servers=b1:9092,b2:9092
A->B.enabled=true
A->B.topics=orders.*,inventory.*
A->B.emit.checkpoints.enabled=true
replication.policy.class=org.apache.kafka.connect.mirror.IdentityReplicationPolicy
sync.topic.configs.enabled=true
sync.topic.acls.enabled=false

# Cluster Linking（Confluent CLI の一例。実コマンドは環境に依存）
confluent kafka link create dr-link \
  --cluster B \
  --source-cluster A \
  --source-bootstrap-server a1:9092 \
  --link-mode READ_ONLY

# ミラートピック作成
confluent kafka mirror create --link dr-link --topic orders

トピック設計とレプリカ配置

リージョン内の高可用性は replication.factor と rack awareness で担保します。一般に RF=3、min.insync.replicas=2 を基準とし、各パーティションのレプリカを別 AZ に配置します。broker.rack を正しく設定し、パーティション割り当て時にゾーン分散されるようにします。

データ保全を優先する DR 設計では unclean.leader.election.enable=false を徹底します。切り替え前提では、トピック名・スキーマ互換性・クリーンアップポリシー（delete/compact）を両リージョンで一致させ、Cluster Linking のミラートピックは昇格（プロモート）までは書き込み不可である点を理解しておきます。

• RF=3、min.insync.replicas=2、acks=all を基本線に
• broker.rack を AZ 名で設定し、パーティションをゾーン分散
• トピック設定・スキーマ互換性・ACL を事前に整合
• ログ圧縮トピックは tombstone 伝播と遅延を監視し、整合時間を見積もる

代表的なトピック作成コマンド

kafka-topics \
  --bootstrap-server a1:9092 \
  --create \
  --topic orders \
  --partitions 12 \
  --replication-factor 3 \
  --config min.insync.replicas=2 \
  --config cleanup.policy=delete

フェイルオーバーの流れとクライアント設計

計画フェイルオーバーでは、まずプライマリ側の書き込みを停止し、リージョン間のレプリケーション遅延とチェックポイントの到達を確認してから DR 側を昇格させます。非計画時は、直近のチェックポイントに基づきコンシューマオフセットを翻訳し、重複許容の設計（冪等プロデューサ、トランザクション、下流の冪等性）で吸収します。

クライアントはブートストラップ先をリージョン冗長化し、DNS/TLS SNI/負荷分散で切り替えやすくします。プロデューサは enable.idempotence と適切な delivery.timeout.ms、コンシューマはグループの静的メンバーシップ（group.instance.id）で大規模リバランスを抑制します。

• 計画切替: 書き込み停止 → 遅延閾値確認 → DR 側プロモート → DNS/設定切替
• 非計画切替: オフセット翻訳を実施、重複は下流で許容・除外
• クライアントの多リージョン接続先とタイムアウトを明示的に調整
• 監視に基づく自動化（閾値超過でアラート、手順の段階実行）

フェイルオーバー手順のサンプル（計画・MM2/CL）

# 1) プライマリ側の書き込みを停止
# 2) リージョン間遅延を確認（例: 60 秒以下）
#    - MM2: replication-latency-ms、checkpoints の遅延
#    - CL: ミラートピックの lag メトリクス
# 3) DR 側の昇格
#    Cluster Linking（例。環境によりコマンドは異なる）
confluent kafka mirror failover --link dr-link --topics 'orders.*'

# 4) クライアントの接続先を切替（DNS/設定配布）
# 5) 書き込み再開

# 非計画時（MM2 オフセット翻訳の概念例）
# 事前に MirrorCheckpointConnector を有効化している前提
# 翻訳されたオフセットに基づきコンシューマグループを調整
kafka-consumer-groups \
  --bootstrap-server b1:9092 \
  --group app-g \
  --reset-offsets --topic orders --to-offset <translated-offset> --execute

フェイルバックと双方向整合性

DR 側で稼働を継続した後にプライマリへ戻す場合、DR 側を真実の源泉として逆方向のレプリケーションを張り直し、差分が取り切れてからトラフィックを戻します。アクティブ−パッシブであれば単方向の切替で済むため、手順を自動化しやすいです。

アクティブ−アクティブは同一キーへの同時更新や順序差分が発生し得るため、重複排除キー設計や下流の upsert/整合ロジックが必須です。トランザクションはクラスタを越えては効かない点に注意し、必要に応じて一意キーと冪等処理で補います。

• フェイルバック前に DR→プライマリの遅延が 0 近傍であることを確認
• スキーマ・ACL・トピック設定の再整合をチェックリスト化
• アクティブ−アクティブはまず限定トピック・限定ワークロードで検証

フェイルバックのためのリンク再作成例

# Cluster Linking（DR -> Primary に逆リンクを作成）
confluent kafka link create backfill \
  --cluster A \
  --source-cluster B \
  --source-bootstrap-server b1:9092 \
  --link-mode READ_ONLY

# MirrorMaker 2（双方向を有効化）
clusters = A, B
A->B.enabled=true
B->A.enabled=true
# フェイルバック時は B->A の topics を対象に限定

CCAAK 試験対策とチェックリスト

試験では、クラスタ内耐久性とリージョン間 DR の切り分け、設定の意味と副作用、切替時のオフセット同期やクライアント挙動が問われます。非同期レプリケーション前提で RPO は 0 にならない点、unclean leader election を許可しない設計、min.insync.replicas と acks の関係を確実に押さえます。

運用では、UnderReplicatedPartitions、ActiveControllerCount、ミラーレイテンシ、リンク健全性を常時監視し、アラートと自動手順を連動させます。

• min.insync.replicas は acks=all と組み合わせて有効。ISR 未達時は書き込みを拒否し RPO を守る
• unclean.leader.election.enable=false でデータ喪失を抑止（RTO は伸び得る）
• MirrorMaker 2 はチェックポイントでオフセット翻訳、Cluster Linking はミラートピック昇格でシンプル切替
• アクティブ−アクティブは重複・順序差の扱いが必須。まずはアクティブ−パッシブ
• 監視メトリクス: UnderReplicatedPartitions、Mirror lag/replication-latency-ms、ActiveControllerCount==1、リンク状態

Prometheus 風アラート例（抜粋）

alert: KafkaUnderReplicatedPartitions
expr: kafka_server_replicamanager_underreplicatedpartitions > 0
for: 5m
labels:
  severity: critical
annotations:
  summary: Under-replicated partitions detected

alert: ActiveControllerCountNotOne
expr: kafka_controller_kafkacontroller_activecontrollercount != 1
for: 1m
labels:
  severity: warning
annotations:
  summary: Active controller count is not 1

alert: MirrorLagHigh
expr: mm2_replication_latency_ms > 60000
for: 2m
labels:
  severity: warning
annotations:
  summary: MirrorMaker 2 replication latency exceeds 60s

問題で確認

よくある質問