Kafka Stretched Cluster: マルチAZ構成と注意点

ストレッチクラスタ（Stretched Cluster）は、同一リージョン内の複数AZにブローカやクォーラムノードを分散し、ゾーン障害に耐えるための構成です。Kafkaのレプリケーションやクォーラムの性質上、RTTやISR、ACK設定の理解が欠かせません。

本稿では、マルチAZでの必須設定、失敗しやすいポイント、代替アーキテクチャとの比較をまとめます。CCAAK対策として、試験で問われやすいキーワードも添えています。

ストレッチクラスタの前提と全体像

ストレッチクラスタは、同一リージョン内の複数AZにブローカとクォーラムノード（ZooKeeperまたはKRaftのコントローラ）を配置し、単一AZ喪失時も書き込み・読み取り継続を狙う構成です。鍵となるのは、レプリケーションファクタ、min.insync.replicas、acks、unclean leader election、そしてクォーラム多数派の維持です。

現実的には、AZ間RTTが数ミリ秒以下（目安として1–2ms級）である同一リージョン内に限定するのが定石です。マルチリージョンへ引き伸ばすと遅延が大きくなり、スループット低下や再選出時間増大、タイムアウト増加を招きます。マルチリージョンは原則として非同期レプリケーション（Cluster LinkingやMirrorMaker 2）の適用領域です。

クォーラムノードは奇数台で多数派を確保する配置が基礎です。ZooKeeperなら3台以上、KRaftならコントローラを3台以上にし、AZをまたがって均等配置します。1AZが失われても過半を維持できることが合格ラインです。

• レプリケーションファクタ（RF）は3を基本。各レプリカを別AZへ配置
• min.insync.replicas（minISR）は2、acks=all、unclean.leader.election.enable=false
• broker.rack（またはbroker.rack相当）をAZ名で設定しラックアウェア配置を徹底
• クォーラム（ZooKeeperまたはKRaftコントローラ）は奇数台、AZ分散で多数派維持
• 同一リージョン・マルチAZのみを対象。マルチリージョンは非同期複製を検討

マルチAZに跨るKafkaストレッチクラスタ（概念図）

最小構成例:ラックアウェア設定とトピック作成（例）

# broker（AZごと）
# AZ-A のブローカ
broker.rack=az-a
num.network.threads=3
num.io.threads=8

# AZ-B のブローカ
broker.rack=az-b

# AZ-C のブローカ
broker.rack=az-c

# クラスタ共通の安全側設定
unclean.leader.election.enable=false
min.insync.replicas=2

# KRaftの場合：コントローラは3台（C1,C2,C3）を各AZに1台ずつ
# ZooKeeperの場合：ZKも3台を各AZに分散

# トピック作成：RF=3、minISR=2
kafka-topics.sh --create \
  --topic orders \
  --partitions 12 \
  --replication-factor 3 \
  --config min.insync.replicas=2

# プロデューサ（安全側）
acks=all
retries=2147483647
enable.idempotence=true
delivery.timeout.ms=120000
linger.ms=20
batch.size=131072

# コンシューマ（任意：Closest Replicaを使う場合）
# ブローカ側で replica.selector.class=org.apache.kafka.common.replica.RackAwareReplicaSelector
# クライアント側で client.rack=az-a（所属AZを設定）

レプリケーションとACK/ISRの設計要点

ストレッチクラスタでは、RF=3、min.insync.replicas=2、acks=all が基本線です。これにより、1AZ喪失時もISRに2副本を維持できれば、リーダー交代後も整合性を保った書き込みが継続できます。

unclean.leader.election.enableは必ずfalseにします。ISR外の過去のレプリカをリーダーに選ぶとデータロスが生じ得ます。プロデューサはenable.idempotence=trueと組み合わせ、重複や順序の破壊を避けます。

• RF=3、min.insync.replicas=2、acks=all（RPO=0を狙う構成）
• unclean.leader.election.enable=false（安全側）
• プロデューサ：idempotence有効、delivery.timeout.msの見直し（AZ間遅延を考慮）
• replica.lag.time.max.msは実遅延に合わせて調整（過度に厳しいとISR脱落が増える）
• 復旧時はレプリカ再同期の帯域制御（replication.quota）で本番トラフィックを守る

ラックアウェア配置とパーティションリーダーのバランス

broker.rackを各AZ名で設定し、トピック作成時にレプリカを別AZへ分散させます。これが崩れると、AZ障害時に複数レプリカを同時に失い、minISRを割って書き込み不可に陥ります。

リーダーの偏りはクロスAZトラフィックと待ち時間を増やします。定期的なPreferred Leader Electionでバランスを取り、プロデューサのホットパーティション化を避けます。

• broker.rack=az-a/az-b/az-c を明示し、ラックアウェアを有効化
• トピック作成時のレプリカ割当を確認（必要なら手動割当）
• リーダー偏りの監視（各AZのリーダー数・ネットワーク出力）
• 定期のPreferred Leader Electionで均衡化
• （任意）Closest Replicaを使う場合、ブローカ側のreplica.selector.classとclient.rackを設定

障害シナリオと復旧運用

AZ喪失時、クォーラム多数派が維持されていればクラスタは稼働を継続します。失われたAZにリーダーが多い場合、フェイルオーバーに伴い一時的なスループット低下やレイテンシ上昇が発生します。

AZ復旧後は大量の再同期が走ります。運用手順として、レプリケーションスロットルを適用し、業務時間帯の影響を緩和します。完全復旧後、必要に応じてPreferred Leader Electionで平準化します。

• ゾーン障害時：UNCLEAN禁止、ISR内からの自動選出でデータ整合を維持
• クォーラム（ZK/KRaft）の多数派維持が前提。偶数台や偏った配置はNG
• 復旧時：レプリケーション帯域の制御、fetch/replicaスレッドの監視
• 再同期完了後にリーダー平準化（Preferred Leader Election）
• 運用RunbookにRTO/RPO要件、閾値、ロールバック条件を明記

ネットワーク・ストレージとチューニングの勘所

クロスAZ通信は待ち時間だけでなく、クラウド課金の観点でもコスト要因です。圧縮（lz4やzstd）と適切なバッチングで往復回数を抑え、リーダーの配置を平準化してAZ間トラフィックの偏りを避けます。

ストレージは一般にJBODでよく、耐久性はレプリケーションに委ねます。セグメントサイズ・ページキャッシュとネットワーク帯域のバランスを取り、復旧時の再同期ウィンドウが過大にならないよう監視します。

• プロデューサ：linger.ms/batch.sizeでバッチング、圧縮にlz4/zstd
• ブローカ：socket送受信バッファ、num.network.threads/num.io.threadsの適正化
• replica.fetch.max.bytes/fetch.max.bytes はスループットと待ち時間を見て調整
• TLS有効時は暗号スイートを見直し、NIC/CPUのボトルネックを監視
• クロスAZ課金・帯域を可視化し、SLOとコストを継続評価

CCAAK対策:出題されやすい要点と落とし穴

試験では、安全側の構成値、ラックアウェア、クォーラム多数派、マルチAZとマルチリージョンの適用境界が頻出です。単一解に見えても、前提（RTT、RPO要件、コスト）が暗に与えられていることがあります。設問の前提を読み落とさないでください。

• RF=3、minISR=2、acks=all、unclean.leader.election.enable=false
• broker.rackでAZを明示し、レプリカを異なるAZへ分散
• クォーラムは奇数台、AZ分散で多数派維持（ZK/KRaftいずれも同様の原理）
• ストレッチは同一リージョン向け。マルチリージョンはCluster Linking/MM2
• Closest Replicaはブローカ設定とclient.rackの双方が必要（デフォルトはリーダー読み）
• RPO=0を主張するなら、acks=allとminISRを満たす前提を明記

問題で確認

よくある質問