Confluent Cloud無料枠の活用: 学習用クラスタ構築と実機演習（CCDAK/CCAAK対策）

Confluent CloudはKafkaの運用をマネージドで肩代わりしてくれるため、学習コストとリスクを抑えた実機演習に向いています。無料枠/トライアルクレジットの範囲で、CCDAK/CCAAKの要点を確実に手を動かして確認する手順をまとめました。

価格や特典はプロモーションにより変動します。数値や上限は必ず公式ドキュメントとコンソールの表示を優先し、課金が発生しやすい機能（コネクタ、ksqlDB等）は本稿では必要最小限に留めます。

無料枠の前提と学習計画（安全運転の基本）

Confluent Cloudの無料枠/トライアルは、使用量に応じた従量課金がクレジットから差し引かれる仕組みが一般的です。金額や有効期限は変動するため、数値の暗記ではなく、どこでコストが増えるかを構造で押さえてください。

学習ではBasic相当のKafkaクラスタを1つ、トピック数とパーティション数は最小で開始し、Schema RegistryとAPIキー、ACL/RBACの一連の流れをひと通り体験します。CCDAKはプロデューサ/コンシューマ、パーティション設計、スキーマ進化の実践を重視。CCAAKはアクセス制御、権限境界、監視/運用の基礎を重視します。

• コストの主因になりやすいのは、クラスタ稼働、パーティション数、保持期間、スループット、付加サービス（コネクタ、ksqlDB等）。まずは小さく作る。
• Confluent Cloudではブローカー台数や複製係数の多くがサービス側で適切に管理されるため、試験学習ではトピック設計とクライアント挙動に集中できる。
• 試験対策では、順序保証（キー単位）、再処理（保持/コンパクション）、消費者グループのリバランス、セキュリティ（SASL_SSL、ACL、RBAC）などの安定概念を押さえる。

学習開始前の安全チェックリスト（抜粋）

- トピックは最小限（例: 1〜2個、各1〜3パーティション）
- 保持期間は短め（例: 1〜24時間）に設定して開始
- コネクタ/ksqlDBは無効のまま開始
- 利用終了後は必ずAPIキーと環境/クラスタ/トピックを削除
- クレジット残高/明細は作業前後に確認

学習用クラスタ設計（トピック、パーティション、スキーマ）

無料枠では、読み書きの実験に足る最小構成が原則です。まずは1トピック・1〜3パーティションで開始し、キーによる順序保証や消費者グループの拡張性を手を動かして確かめます。トピックの複製係数やブローカー構成はマネージド側の既定を尊重し、学習コストを下げます。

スキーマはSchema Registryを利用し、後方互換のスキーマ進化を実験します。最初は必須フィールドを減らす変更（後方互換性の確保）から始め、非互換変更を敢えて投入してエラーを観察し、互換性設定の意味を体感します。

• パーティション数は並列性と順序保証のトレードオフ。キー単位で順序保証したい場合はキーを固定し、並列性を上げたい場合はパーティションを増やすが、無料枠では慎重に。
• 保持戦略は2系統で学ぶ: 時間保持（retention.ms）とコンパクション（cleanup.policy=compact）。再処理の要件に応じて使い分ける。
• Schema Registryの互換性は後方/前方/双方向などから選択。学習では後方互換から開始すると安全。

トピック作成の最小例（CLI、保持時間短縮）

confluent login --save
confluent environment create learn-env
confluent environment use <ENV_ID>
confluent kafka cluster create learn-basic --type basic --cloud aws --region ap-northeast-1
confluent kafka cluster use <CLUSTER_ID>
# APIキー発行（後でクライアントで使用）
confluent api-key create --resource <CLUSTER_ID> --description learn-key
# トピック（1パーティション、保持1時間の例）
confluent kafka topic create orders --partitions 1 --config retention.ms=3600000

無料枠でのセットアップ手順（UI/CLI併用、最短ルート）

初回はWeb UIで環境とKafkaクラスタを用意し、続けてCLIでAPIキー、トピック、ACLを作ると迷いが少なくなります。クレジットが消費されるのは主にクラスタ稼働時間とデータ転送・保存です。最短で作り、最短で検証し、速やかにクリーンアップするのが基本動作です。

Schema Registryは同一環境で有効化しておくと、後続のスキーマ演習がスムーズです。リージョンやクラウド事業者は学習の可用性に大差が出にくいため、近接・低レイテンシで選びます。

• CLIのcontextはenvironmentとclusterを正しく指すことを常に確認
• APIキーは人物用（対話操作）とサービスアカウント用（アプリ）を分ける
• 作業ごとにクレジット/請求ダッシュボードを確認しコスト異常を早期検知

学習用の極小アーキテクチャ（無料枠向け）

 [Producer App] --(SASL_SSL)--> [Confluent Cloud Kafka] --(group subscribe)--> [Consumer App]
                           \                                          /
                            \-- Schema (Registry) --------------------/

説明:
- Producer/Consumerは同一リージョンから接続し外部転送料を抑制
- Schema Registryを併用して後方互換のスキーマ進化を演習
- RBAC/ACLはクラスタ単位で最小権限付与

CLIによる環境〜APIキー発行の最短コマンド列（例）

confluent login --save
confluent environment create learn-env && confluent environment use <ENV_ID>
confluent kafka cluster create learn-basic --type basic --cloud aws --region ap-northeast-1 && confluent kafka cluster use <CLUSTER_ID>
confluent schema-registry cluster enable --cloud aws --geo ap-southeast-1  # 例: リージョンはUIの案内に合わせる
confluent iam service-account create sa-app --description "for app"
confluent api-key create --resource <CLUSTER_ID> --service-account <SA_ID> --description app-key

実機演習（開発者向け: CCDAKの核心）

プロデューサ/コンシューマの基本、キーによる順序保証、再処理を体験します。まずは同期送信でエラーハンドリングを可視化し、次に非同期送信とコールバックでスループットの差を観察します。コンシューマはオートコミットと手動コミットの差を確認し、グループリバランス時の挙動を小さな並列度で確かめます。

スキーマは最小フィールドから開始し、後方互換を保った追加を行います。互換性を破る変更を敢えて試し、プロデュース時に拒否されることを確認すると、試験の理論が腹落ちします。

• キー付きレコードで同一キーの順序保証を確認
• 手動コミットで少量の重複を許容しつつ再処理（at-least-once）を体験
• スキーマ進化の互換性モードを切り替え、失敗の理由をログで説明できるようにする

Python Producer（confluent-kafka、SASL_SSL、最小例）

from confluent_kafka import Producer
import json

conf = {
    'bootstrap.servers': '<BOOTSTRAP_SERVERS>',
    'security.protocol': 'SASL_SSL',
    'sasl.mechanisms': 'PLAIN',
    'sasl.username': '<API_KEY>',
    'sasl.password': '<API_SECRET>'
}

p = Producer(conf)

def delivery(err, msg):
    if err:
        print(f'Delivery failed: {err}')
    else:
        print(f'Delivered to {msg.topic()} [{msg.partition()}] @ {msg.offset()}')

for order_id in range(1, 6):
    key = f"order-{order_id % 2}"  # 同一キーの順序を確認
    val = json.dumps({'id': order_id, 'amount': 100 + order_id})
    p.produce('orders', key=key, value=val, callback=delivery)
    p.poll(0)

p.flush()
# コンシューマ側では group.id を設定し、auto.offset.reset=earliest で再処理の挙動を確認

実機演習（管理者向け: CCAAKの要点）

Confluent Cloudではブローカー運用の多くが抽象化されますが、学習ではアクセス制御と権限境界、監視、セキュリティ設定に集中します。特にACLとRBACの役割分担を明確にし、サービスアカウント単位の最小権限を実践します。

メトリクスはコンソールとCLI/APIで確認し、遅延やスループット、エラー率の基本的な読み方を押さえます。無料枠では長時間の負荷試験は避け、短時間の観測とクリーンアップを徹底します。

• RBACでクラスタ管理者と開発者ロールを分離
• ACLで特定トピックへのRead/Writeを限定
• キー/シークレットのローテーション手順をスクリプト化して再現可能に

ACLとRBACの最小例（CLI）

# RBAC: Kafka開発者にDeveloperRead/Writeを付与（リソースはKafkaクラスタ）
confluent iam rbac role-binding create \
  --principal User:<SA_ID> \
  --role DeveloperWrite \
  --cloud-cluster <CLUSTER_ID>

confluent iam rbac role-binding create \
  --principal User:<SA_ID> \
  --role DeveloperRead \
  --cloud-cluster <CLUSTER_ID>

# ACL: 特定トピックordersへの許可（より細粒度）。
confluent kafka acl create \
  --allow \
  --service-account <SA_ID> \
  --operation READ \
  --topic orders

confluent kafka acl create \
  --allow \
  --service-account <SA_ID> \
  --operation WRITE \
  --topic orders

コスト管理とクリーンアップ（無料枠を守る運用）

コスト最適化は開始前の設計と終了後の確実な削除がすべてです。実験はバッチ化し、連続で行い、環境を開きっぱなしにしない運用習慣を付けます。保持期間とパーティション数は常に見直し、不要トピックは即削除します。

Confluent Cloudは請求ダッシュボードと使用量メトリクスが充実しています。実験単位でスクリーンショットやCLIログを残すと、後で試験復習やチーム共有にも役立ちます。

• 保持時間短縮、低パーティション、同一リージョン接続でネットワーク費を抑制
• コネクタ/ksqlDBは明確な目的がある場合のみ短時間で有効化
• 終了時はAPIキー→トピック→クラスタ→環境の順で削除し取り残しを防止

クリーンアップの標準手順（CLI）

# コンシューマ/プロデューサ停止後に実施
confluent kafka topic delete orders
confluent api-key delete <API_KEY_ID>
confluent kafka cluster delete <CLUSTER_ID>
confluent environment delete <ENV_ID>
# 削除前に請求ダッシュボードで当日分の増分を確認

問題で確認

よくある質問