Confluent Certified Administrator (CCAAK) 対策: 出題範囲・配点の考え方・運用観点の要点

本記事は、Kafka/Confluent Platformの公式動作と安定概念に基づき、CCAAKの出題傾向に合わせて運用要点を凝縮しています。

配点は公式に詳細非公開ですが、実務比重の高い領域（設計・運用・セキュリティ・監視）で失点しない準備を重視します。

試験概要と配点の考え方（非公開情報の扱い方）

CCAAKは選択式中心で、Kafka/Confluent Platformの管理・運用に必要な設計判断、セキュリティ設定、監視・トラブルシュートを横断的に問います。公式シラバスは変更される可能性があるため、常にConfluentの認定ページとdocs.confluent.ioを基準に用語と機能差分を確認してください。

配点の詳細は公表されていません。実務観点では、クラスタ設計（レプリケーション、ISR、ラックアウェアネス）、セキュリティ（TLS/SASL、ACL、RBAC）、運用（ローリングアップグレード、リバランス、監視指標、スロットリング）、データ移行（MirrorMaker 2 / Cluster Linking）の重みが高く、周辺ツール（Control Center、Cruise Control、CLI群、JMX/監視）の理解が差になります。

• 学習の優先度付け: 設計/セキュリティ/監視/トラブルシュート → 高、ツール詳細の暗記 → 中、周辺エコシステムの広さ → 低〜中
• 非公開の配点対策: 実務で「事故が起きやすい箇所」を深く（min.insync.replicas、acks=all、クォータ、U/Rパーティション、認証失敗）
• 出題形式対策: 設定名と効果、トレードオフ、デフォルト値の方向性を選択肢比較で即断できるようにする

設計の要点: レプリケーション、ISR、ラックアウェアネス、コントローラ

Kafkaの可用性設計は、トピックのreplication.factor、min.insync.replicas、プロデューサのacksの組み合わせで耐障害性を定義します。実務・試験ともに、replication.factor=3、min.insync.replicas=2、acks=allが基準解として頻出です。ISRが縮むとmin.insync.replicasに満たず、プロデュース失敗（NOT_ENOUGH_REPLICAS）を引き起こすことがあります。

ラックアウェアネス（broker.rack）を設定し、トピックの割当で複数ラックにレプリカを分散させると、ラック障害時のRPO/RTOを改善できます。コントローラはリーダー選出とメタデータ管理を司ります。運用ではコントローラの安定性（メタデータ伝播遅延やZooKeeper/KRaftの健全性）も監視対象です。ZookeeperベースとKRaft（自己管理メタデータ）は共存期があるため、両方の言及に対応できると安全です。

• 基本式: データ損失回避 ＝ acks=all かつ min.insync.replicas ≥ 2 かつ replication.factor ≥ min.insync.replicas + 1
• U/R（Under-ReplicatedPartitions）> 0 は即アラート。ISR復帰条件（replica.lag、ネットワーク/ディスクI/O）を確認
• unclean.leader.election.enable=false が安全側。やむを得ない状況でtrueはデータ不整合のリスク
• rack感度: broker.rack を設定し、割当ポリシーがラック分散を満たすかを点検

Kafkaクラスタの論理構成とレプリケーション

トピック設定とクォータ: スループットと保全性の両立

トピック設計は、保持戦略（retention.ms / retention.bytes / cleanup.policy）、セグメントサイズ（segment.bytes / segment.ms）、コンパクション閾値（min.cleanable.dirty.ratio）などのトレードオフを理解します。ログコンパクションは最新キー値を残しつつ領域を削減しますが、読み出しパターンとレイテンシへの影響を考慮します。

クォータ（producer/consumer/client-id/user単位）はノイジーネイバー対策の基本です。スループット（bytes）、リクエストレート、接続数に対する制御を適用し、スロットリングが発生した場合の監視イベントと相関させます。

• 保持戦略: cleanup.policy=delete or compact or compact,delete
• 耐障害: min.insync.replicas と acks の組み合わせを設計段で固定
• スループット: segment.bytes と flush系は過度に小さくしない（I/O過多回避）
• クォータ種別: producer_byte_rate / consumer_byte_rate / request_percentage / controller_mutation_rate など

代表的なトピック作成とクォータ設定（Apache Kafka CLI）

kafka-topics.sh --bootstrap-server broker:9092 \
  --create --topic orders \
  --partitions 12 --replication-factor 3 \
  --config min.insync.replicas=2 \
  --config cleanup.policy=compact,delete \
  --config retention.ms=259200000 \
  --config segment.bytes=1073741824

# クォータ: クライアントID単位で生産スループットを制限（1MB/s）
kafka-configs.sh --bootstrap-server broker:9092 \
  --alter --add-config 'producer_byte_rate=1048576' \
  --entity-type clients --entity-name app-producer

# ユーザー単位（SASL/SCRAM等のユーザー名）で消費スループットを制限（2MB/s）
kafka-configs.sh --bootstrap-server broker:9092 \
  --alter --add-config 'consumer_byte_rate=2097152' \
  --entity-type users --entity-name alice

セキュリティ: TLS/SASL、ACL、RBACの要点

Kafkaの通信はTLSで暗号化し、SASLまたはmTLSで認証します。SASLメカニズムはPLAIN、SCRAM、OAUTHBEARER、GSSAPIなどがあります。ブローカー側はlisteners、listener.name.<...>.ssl.*、sasl.enabled.mechanisms、sasl.mechanism.inter.broker.protocolを正しく整合させます。

認可はACLが基本です。リソース種別（Topic、Group、Cluster、TransactionalId）、パターン種別（LITERAL/PREFIXED）、操作（READ/WRITE/DESCRIBE/IDEMPOTENT_WRITEなど）を組み合わせ、最小権限で付与します。Confluent Platform/CloudではRBACを用いて役割ベースに集約することも可能で、運用の一貫性が向上します。

• mTLSは証明書管理が鍵。サーバー/クライアント双方のCA信頼関係を明示
• SASL/SCRAMはユーザー作成とシークレット保全を標準化（自動化・ローテーション）
• ACLはプリンシパル命名とPREFIXEDの使い分けを定義。Group単位のREAD権限漏れに注意
• RBAC（Confluent）は中央管理と監査が容易。ACLと混在時の評価順序・スコープを理解する

監視・運用: 重要メトリクス、ローリング更新、データ移行の比較

監視はJMX/ログ/Control Centerを併用し、遅延・スロットリング・U/R・ディスク使用率・ネットワークアイドルを多面的に見るのが基本です。異常検知は症状→原因→対処を短絡できるアラート設計に落とします。

データ移行・複製はMirrorMaker 2（MM2）とCluster Linkingでアプローチが異なります。試験では特性差、RPO/RTO、依存関係、順序保証の扱いが問われやすいです。

• 主要JMX例: kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions
• 待ち行列/遅延: RequestQueueTimeMs、Fetch/Produce purgatoryサイズ
• ネットワーク/スレッド: NetworkProcessorAvgIdlePercent
• トラフィック: BytesInPerSec / BytesOutPerSec、レプリケーション帯域の頭打ち検出
• ローリング更新: 互換性行列とインターバージョンのサポートを確認し、コントローラ/ブローカー順序を踏襲

トラブルシューティング頻出パターンとCLI手順

プロデュース失敗はacks=allとmin.insync.replicas不整合、ISR縮小、ブローカー間のTLS不整合で再現します。消費遅延はグループリバランス過多、スロットリング、古いコンシューマ設定（max.poll.interval.ms、fetch.min.bytes）で悪化します。

優先対応は、影響範囲の特定（特定トピック/パーティション/ラック）、制限要因の切り分け（ネットワーク、ディスク、スレッド、クォータ）、設定/コード両面の一次仮説検証（acksやバッチ、圧縮、GC/ページキャッシュ）です。

• U/R > 0: ネットワーク遅延/ディスク帯域/replica.fetch.wait.max.ms を点検。必要に応じてレプリカの手動リーダー選出
• スロットリング: broker側でThrottledRequestsやQuotaViolationをログ確認 → クォータ再調整
• 認証失敗: サーバ/クライアントのSASL/TLSメカニズム不一致、証明書CN/SAN不整合を確認
• ラグ増大: consumer groupのコミット間隔、max.in.flight.requests、fetch系設定とブローカーの帯域を相関分析

現場で即使う診断コマンド例

# ラグ確認（グループ単位）
kafka-consumer-groups.sh --bootstrap-server broker:9092 \
  --group app-group --describe

# U/Rやリーダーの状態確認（メトリクスと併用）
# JMXは省略、ログからの抜粋
grep -E 'UnderReplicatedPartitions|Throttled|Quota' /var/log/kafka/server.log | tail -n 50

# トピック詳細（保持/ISR/割当）
kafka-topics.sh --bootstrap-server broker:9092 \
  --describe --topic orders

# クラスタのACL確認
kafka-acls.sh --bootstrap-server broker:9092 --list

# 簡易通信用（TLS/SASLの切り分けにも活用）
kcat -b broker:9093 -X security.protocol=SASL_SSL \
  -X sasl.mechanisms=SCRAM-SHA-512 \
  -X sasl.username=alice -X sasl.password=secret \
  -t orders -P -l <<< 'smoke-test'

# 必要に応じて安全側のリーダー選出（計画停止時）
# kafka-leader-election.sh --bootstrap-server broker:9092 --election-type PREFERRED --topic orders

問題で確認

よくある質問