Kafka試験の問題例: 主要ドメイン別サンプルと実務ポイント

ConfluentのCCDAKとCCAAKは、開発・運用双方の観点でKafkaの安全な利用と予測可能な挙動を問います。本稿は、過去の出題傾向と公式ドキュメント準拠の安定仕様をベースに、主要ドメインごとに“試験で問われやすい判断ポイント”を短く押さえます。

サンプル問題はあくまで演習用のイメージです。実務でも役立つ設定値やトレードオフを添えているので、手元のクラスタで再現しながら確認してください。

配信保証と重複/欠落の制御

Kafkaのメッセージ配信は、少なくとも1回、厳密に1回、高々1回の3パターンで整理できます。プロデューサ側ではacks、retries、enable.idempotence、max.in.flight.requests.per.connectionの組み合わせ、コンシューマ側ではオフセットコミットのタイミング、さらにトランザクションと読み取り分離レベルが結果を左右します。

厳密に1回の処理（Exactly-Once Semantics, EOS）は、idempotent producerとトランザクション、そしてread_committedでの読み取りを前提に、Kafka内のread-process-writeを単一の原子的単位として扱うときに達成可能です。外部システムまで含めた“厳密に1回”は、その外部がトランザクション連携をサポートしない限り保証できません。

• 少なくとも1回: 欠落は避けるが重複が起こり得る。retries>0、acks=allが定番。重複は下流で排除する。
• 高々1回: 欠落の可能性を許容し、重複は起こさない。コミットを送信前に行うのが典型的だが、通常の業務シナリオでは採用は限定的。
• 厳密に1回: enable.idempotence=true、acks=all、transactional.id設定、コンシューマはisolation.level=read_committed。Streams APIはEOSを簡便に扱える。
• max.in.flight.requests.per.connectionは再試行時の順序入れ替わりを防ぐため、EOSでは通常1〜5の低めに設定する。

プロデューサ〜ブローカ〜コンシューマの流れ（EOS時）

プロデューサ設定例（EOS）

bootstrap.servers=broker:9092
aacks=all
enable.idempotence=true
retries=2147483647
max.in.flight.requests.per.connection=5
transactional.id=orders-txn-01

パーティショニングとキー設計

順序保証はパーティション単位です。特定キーでの順序維持が必要なら、必ずキーを設定します。キーなしの場合、現行クライアントのデフォルトはスティッキー・パーティショナーで、短時間は同一パーティションにまとめて送るためスループット改善が見込めますが、厳密な順序制御はできません。

ホットパーティションを避けるには、キーのカーディナリティ確保、パーティション数とコンシューマ並列度の計画、必要に応じたカスタムパーティショナーが有効です。パーティション数の増加は後方互換で可能ですが、減少は困難である点に注意します。

• 順序保証が必要なイベント・エンティティ単位でキーを固定する。
• スティッキー・パーティショナーによりキーなしでもバッチ効率は向上するが、順序要件には使わない。
• パーティション数は消費側の最大並列度×余裕で見積もる。増やすとキー→パーティションのマッピングが変化する可能性がある点に留意。

Java Producerのキー指定イメージ

producer.send(new ProducerRecord<>("orders", customerId, payload));
// customerIdで順序保証（同一キーは同一パーティション）

保持ポリシーとログ・クリーニング

保持期間はretention.ms、サイズはretention.bytesで制御します。セグメント境界（segment.ms/segment.bytes）を超えて初めて削除対象になります。cleanup.policyがdeleteのとき、古いセグメントが期限やサイズ超過で削除されます。

cleanup.policy=compactでは、同一キーの最新レコードを残し、それ以前は圧縮対象になります。削除はキーに対するトゥームストーンを書き込み、一定時間（delete.retention.ms）経過後に物理削除されます。コンパクションは最終的整合であり、即時ではありません。

• 時刻基準の保持はレコードタイムスタンプに依存。record.timestamp.type=CreateTime/LogAppendTimeの違いに注意。
• compact+deleteの併用で最新値保持と古いセグメント削除を両立できる。
• min.cleanable.dirty.ratioやsegmentサイズのチューニングでクリーニング効率を調整。

保持・コンパクションの代表設定（トピック単位）

kafka-topics.sh --bootstrap-server broker:9092 \
  --alter --topic users \
  --config cleanup.policy=compact,delete \
  --config retention.ms=604800000 \
  --config segment.ms=3600000

レプリケーションと耐障害性

レプリケーション係数（例: 3）とISR（In-Sync Replicas）が可用性の基礎です。acks=allはISRの全レプリカへの追従を待ってから成功を返します。min.insync.replicasは書き込みに必要なISR数の下限で、acks=allと併用することで障害時の持続性を高めます。

リーダー選出では、原則としてISRから選ばれます。unclean.leader.election.enable=falseで不整合なフォロワからの選出を禁止し、データ損失を回避します（ただし停止時間は伸びる可能性）。ラックアウェアネスはブローカの配置情報を使って、レプリカを異なるラックに分散します。

• RF=3, min.insync.replicas=2, acks=allは堅牢な組み合わせ。ISRが1に落ちると書き込み拒否となるが、データ損失耐性は高い。
• unclean.leader.electionを無効化してデータ完全性を優先。可用性とのトレードオフを理解する。
• ブローカ障害時の再割り当てとリバランスの監視を習慣化する。

代表的なサーバ設定の要点

min.insync.replicas=2
unclean.leader.election.enable=false
# ラックアウェアネス
broker.rack=az1

スキーマ管理と互換性（Schema Registry）

Schema RegistryはAvro/Protobuf/JSON Schemaを管理し、互換性モード（BACKWARD, FORWARD, FULL など）をポリシー化します。一般的なイベント追加にはBACKWARD互換が選ばれます。削除や必須フィールドの追加は後方互換を壊すため、試験では“不適切”な変更として問われがちです。

Confluentのワイヤフォーマットは先頭バイトのマジック値（0）に続けてスキーマIDを埋め込みます。クライアントはこのIDを使ってデシリアライズし、互換性チェックは登録時に適用されます。

• BACKWARD: 新コンシューマは旧データを読める。フィールド追加はデフォルト値付きで。
• FORWARD: 旧コンシューマが新データを読める。将来互換を重視。
• FULL: 双方向互換。制約が最も厳しい。
• Subject naming strategyとトピックのキー/値で互換性ポリシーを分ける設計が有効。

互換性モード設定（例）

curl -s -X PUT -H "Content-Type: application/json" \
  --data '{"compatibility":"BACKWARD"}' \
  http://schema-registry:8081/config/subjects/orders-value

セキュリティと運用ベーシックス

暗号化はTLS、認証はSASL/PLAIN, SASL/SCRAM, OAuthBearer, mTLSなどが選べます。ACLはリソース（Topic, Group, Cluster など）×操作（Read, Write, Create, Describe など）で付与します。運用ではACLのプリンシパルとパターン（literal/prefix）を明確に管理します。

コンシューマラグの監視、クォータの設定、段階的なローリングアップグレード、協調的リバランスの活用などが安定運用の要点です。協調的（cooperative-sticky）リバランスは再均衡時の停止を最小化します。

• リスナーごとにSASL/TLS設定を分離し、外部/内部の経路を明確化する。
• ACLは最小権限付与。Group権限の漏れで他チームのコンシューマに影響しやすい点に注意。
• 組織標準の証明書管理・キー更新フローをKafkaに統合する。

ACL付与例（プロデューサにWrite、コンシューマにRead）

kafka-acls.sh --bootstrap-server broker:9092 \
  --add --allow-principal User:alice \
  --operation Write --topic payments
kafka-acls.sh --bootstrap-server broker:9092 \
  --add --allow-principal User:bob \
  --operation Read --topic payments --group payments-cg

問題で確認

よくある質問