Kafka関連資格の全体像：CCDAK・CCAAK・Confluent Cloudの要点整理

Kafkaの資格は、アプリ開発寄りのCCDAKと、運用寄りのCCAAKに大別される。加えて、マネージド環境であるConfluent Cloudの設計・運用観点は両試験の理解を補強する。

本稿は、出題ドメインを実務での意思決定に結びつけて整理する。安定機能に絞り、CLI・設定値・設計原則の粒度で持ち帰れる形にした。

資格の位置づけと最短で押さえるべき比較軸

CCDAKは「Kafkaを使って正しくデータを流し、処理し、スキーマを管理できるか」を問う。CCAAKは「クラスターを設計・保護・運用し、SLAを守るための設定を理解しているか」を問う。Confluent Cloudは、これらの知識をマネージド環境に写像する力を要求する。

両試験に共通する土台は、パーティションとレプリケーション、配信保証（at-least/at-most/exactly-once）、コンシューマグループ、スキーマ互換性、セキュリティ（TLS/SASL/ACL）である。Confluent Cloudでは、同概念にRBAC・ネットワーキング（プライベート接続）・クォータといった管理要素が加わる。

• 可用性の基礎: レプリケーション係数とISR、min.insync.replicasとacks=allの関係は頻出
• 順序保証はパーティション単位。キー設計とパーティショナーの挙動をセットで覚える
• スキーマは互換性モードを運用ルールにする（後方互換をデフォルトにすると安全）
• CloudではRBACとAPIキー/サービスアカウント、ネットワーク接続方式（公開/ピアリング/Private Link）を整理

Kafkaの基本データフロー（試験で問われる単位感）

topic作成と可用性の基本（acksとmin.insync.replicas）

kafka-topics.sh --create --topic orders --partitions 6 --replication-factor 3 --bootstrap-server broker:9092
# 書き込み側（プロデューサ）
acks=all
enable.idempotence=true
retries=2147483647
max.in.flight.requests.per.connection=5
# ブローカー/トピック側（ISR維持を前提にデータ損失を抑える）
min.insync.replicas=2

配信保証とオフセット運用：落とし穴を避ける設計

at-least-onceはデフォルト実装が容易だが重複処理を許容する設計（冪等なシンクやデデュープ）が必要。at-most-onceは処理前コミットで実現するがロスの可能性がある。exactly-onceはプロデューサの冪等化とトランザクション、シンク側の整合を含むパイプライン設計が鍵。

コンシューマのオフセットはグループ単位でKafkaに保持される。auto-commitは簡便だが再均衡直後の処理/コミットタイミングに注意。高信頼が要る場合は手動コミット＋明示的なポーリング/処理/コミットの順序制御を推奨。

• 順序保証は「同一キーを同一パーティションへ」が前提。キー無しの場合はバージョンにより粘着型パーティショナーが使われ、短時間に同一パーティションへ連続送信されやすい
• 重複防止はプロデューサ冪等化だけでは不十分。シンク側のupsertや一意キー制約と組み合わせる
• 再均衡での停止時間は割り当て戦略と処理時間に依存。長時間処理はバッチ分割かDLQに逃がす

プロデューサEOSとコンシューマ手動コミットの最低限

# Producer (Java properties)
enable.idempotence=true
acks=all
transactional.id=orders-tx-01
# Consumer (Java pseudo flow)
while (running) {
  ConsumerRecords<K,V> rs = c.poll(Duration.ofSeconds(1));
  for (r: rs) { process(r); }
  c.commitSync();
}
# at-most-onceの例（推奨しない）：commitSync() を process() の前に呼ぶ

スキーマ管理と互換性：後方互換を軸に運用ルール化する

Schema Registryはスキーマの進化を互換性モードで制御する。一般的な運用既定は後方互換（BACKWARD または BACKWARD_TRANSITIVE）で、既存コンシューマを壊さない。双方向進化が必要ならFULL系を検討するが、運用負荷が上がる。

サブジェクト名規則（TopicNameStrategy/RecordNameStrategyなど）はマルチイベントのトピック設計に直結する。トピック内の複数型を許容するならRecordNameStrategyを、1トピック1イベント型ならTopicNameStrategyが単純。

• 後方互換ではフィールド追加はデフォルト値付きで可能、削除は非推奨
• 自動登録は安全策と監査のバランスを見て選ぶ（ステージングのみ自動、本番は手動など）
• Serdes設定はプロデューサ/コンシューマの両方に適用し、互換性違反は早期に検知する

互換性モードの設定とスキーマ登録の基本

# 後方互換をグローバルに設定
curl -s -X PUT -H 'Content-Type: application/json' \
  --data '{"compatibility": "BACKWARD"}' \
  http://schema-registry:8081/config

# サブジェクト単位で上書き（orders-value に FULL_TRANSITIVE）
curl -s -X PUT -H 'Content-Type: application/json' \
  --data '{"compatibility": "FULL_TRANSITIVE"}' \
  http://schema-registry:8081/config/orders-value

# 例: Avroスキーマ登録（値側）
curl -s -X POST -H 'Content-Type: application/vnd.schemaregistry.v1+json' \
  --data '{"schema": "{\"type\":\"record\",\"name\":\"Order\",\"fields\":[{\"name\":\"id\",\"type\":\"string\"}]}"}' \
  http://schema-registry:8081/subjects/orders-value/versions

ストリーム処理：Kafka StreamsとksqlDBの設計判断

Kafka Streamsはアプリに埋め込むライブラリで、状態管理（State Store）や再分配（repartition）、処理保証（at-least/ exactly_once_v2）を細かく制御できる。ksqlDBは宣言的にストリーム/テーブル変換を記述し、永続クエリで継続実行する。

再分配はキー変更を伴う演算で発生し、内部トピックが作られる。大規模処理ではこの内部トピックのパーティション数とリテンション、監視を忘れない。

• processing.guarantee=exactly_once_v2 はソース・シンクがKafkaである構成と相性が良い
• State Storeはchangelogで耐障害化。ローカルストレージサイズとクリーニングを計画
• ksqlDBの永続クエリはスケールアウトに合わせてパーティション数を先に設計

Kafka Streams最小トポロジ（集計の骨格）

Properties p = new Properties();
p.put(StreamsConfig.APPLICATION_ID_CONFIG, "orders-agg");
p.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "broker:9092");
p.put(StreamsConfig.PROCESSING_GUARANTEE_CONFIG, "exactly_once_v2");
StreamsBuilder b = new StreamsBuilder();
KStream<String, Order> s = b.stream("orders");
KTable<String, Long> t = s.groupByKey().count();
t.toStream().to("orders-count");
KafkaStreams app = new KafkaStreams(b.build(), p);
app.start();

Confluent Cloudの観点：マネージドで変わる責務と設定

Confluent Cloudではブローカーの配置/パッチ適用はサービス側の責務となり、利用者は論理設計（トピック数・パーティション設計）、アクセス制御（RBAC/ACL）、接続（インターネット/プライベート接続）に集中する。

監視は内蔵メトリクスでレイテンシやスループット、コンシューマラグを可視化できる。クォータや上限（APIコール、パーティション数など）はプランに依存するため、設計前に確認する。

• 認証はAPIキー＋シークレット。サービスアカウント単位で払い出し、RBACで権限最小化
• ネットワークはパブリックエンドポイント、VPC Peering、Private Link等から選択
• 専用クラスターは隔離性とスループットが読みやすい。Basic/Standardは手軽さ重視

ccloud CLIでの最小フロー（環境→クラスター→トピック→ACL）

ccloud environment create dev
ccloud environment use <env-id>
ccloud kafka cluster create dev-cluster --cloud aws --region ap-northeast-1 --type standard
ccloud kafka cluster use <lkc-id>
ccloud api-key create --resource <lkc-id>
ccloud kafka topic create orders --partitions 6
# RBAC/ACL例（クライアントに書き込み、コンシューマグループに読み取り）
ccloud kafka acl create --allow --service-account sa-123 --operation WRITE --topic orders
ccloud kafka acl create --allow --service-account sa-123 --operation READ --topic orders
ccloud kafka acl create --allow --service-account sa-123 --operation READ --group orders-app

学習ロードマップ：試験合格と実務適用の同時達成

まずはローカルで「作る→流す→読む→壊す→直す」を一巡。次にSchema RegistryとStreams/ksqlDBを加え、最後にConfluent Cloudで同じことを繰り返して差分を言語化する。各ステップで、設定値を根拠付きで説明できる状態を目指す。

模擬演習は、可用性・配信保証・スキーマ進化・セキュリティで最低1問ずつ自作する。設計理由を30秒で話せるかが合格ラインの目安になる。

• Day1: ローカル単一ブローカーでProducer/Consumer。オフセットの手動コミット体験
• Day2: 複数ブローカー＋レプリケーション。acks/min.insync.replicasの挙動を検証
• Day3: Schema Registryと後方互換の破壊/修復シナリオを試す
• Day4: Streams/ksqlDBで集計と再分配。内部トピックの監視確認
• Day5: Confluent Cloudで同様の流れ。RBAC/接続/クォータを点検

最小Docker Compose（学習用の骨組み）

services:
  broker:
    image: confluentinc/cp-kafka:7.6.1
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:9092
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://broker:9092
    ports: ["9092:9092"]
  zookeeper:
    image: confluentinc/cp-zookeeper:7.6.1
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
  schema-registry:
    image: confluentinc/cp-schema-registry:7.6.1
    environment:
      SCHEMA_REGISTRY_KAFKASTORE_BOOTSTRAP_SERVERS: PLAINTEXT://broker:9092
      SCHEMA_REGISTRY_HOST_NAME: schema-registry
    ports: ["8081:8081"]

問題で確認

よくある質問