Confluent Cloud の概要: マネージド Kafka の特徴と試験対策

Confluent Cloud は Apache Kafka をフルマネージドで提供し、スケーリング・アップグレード・修復・監視などの運用をサービス側が担います。開発者はプロデューサ/コンシューマ、スキーマ、接続性、セキュリティ境界に集中できます。

この記事では、クラスタ種別とスケーリング、セキュリティとネットワーキング、スキーマ管理と開発の流れ、可観測性、試験で問われやすいポイントを、安定した公式仕様に基づいて要約します。

Confluent Cloud とは: 提供コンポーネントと責務分界

Confluent Cloud は Kafka ブローカー群、ZooKeeper/KRaft 相当のクラスタ管理、アップグレード、障害復旧、データの暗号化、マルチ AZ 配置（プランにより異なる）をサービスとして提供します。加えて、Schema Registry、ksqlDB、Kafka Connect（マネージドコネクタ）、Cluster Linking などのエコシステム機能を統合的に利用できます。

利用者はトピック設計（パーティション数・保持期間・圧縮・クリーンアップポリシー）、認証・認可（API キー、ACL/RBAC）、ネットワーク接続方式、スキーマ互換性やエラー処理ポリシー、といったアプリケーション境界の選択に注力します。ブローカー設定の多くはサービス側で管理され、ユーザーは直接変更しません（試験では「どの設定が変更可能か」を見分ける力が重要です）。

提供要素: Kafka クラスタ、Schema Registry、ksqlDB、マネージドコネクタ、Cluster Linking、ガバナンス機能群
責務分界: ブローカー運用はサービス、アプリとデータモデリングは利用者
接続性: 公開エンドポイント、VPC ピアリング、PrivateLink/Private Service Connect など（クラウド・リージョンに依存）

Confluent Cloud の論理構成（概要）

クラスタ種別とスケーリング設計

Confluent Cloud のクラスタは一般に Basic / Standard / Dedicated の種別で提供されます。Basic は小規模・検証向け、Standard はより高可用性（多くのリージョンでマルチ AZ）と安定スループット、Dedicated は専用キャパシティとプライベート接続、段階的なスケール（例: CKU ベース）を備えます。具体的な数値・上限はリージョンと時期により変わるため、常に公式ドキュメントの最新値を参照してください。

スケーリングは、パーティション数・レプリカ係数（一般にサービス既定）・保持期間・圧縮方式といったトピック設計とセットで考えます。試験では「スループット不足＝パーティション不足」と短絡せず、プロデューサ側のバッチング設定、acks=all、圧縮、キー分散、コネクタのタスク並列度など総合的に見る姿勢が問われます。

Basic: コスト重視、検証/小規模ワークロード
Standard: 本番向けの可用性とスループット。多くのケースでマルチ AZ
Dedicated: 予測可能な専用容量、段階的スケール、プライベートネットワーキングに対応

観点	Basic/Standard	Dedicated
可用性	Basic はエントリ、Standard は一般にマルチ AZ	マルチ AZ を前提（設計時に要確認）
スケールモデル	共有キャパシティ。上限はプラン依存	専用キャパシティ。段階的スケール（例: CKU 単位）
ネットワーク	公開エンドポイント中心。Standard は一部私設接続に対応可	VPC ピアリング/PrivateLink 等の私設接続に広く対応
ユースケース	検証、低〜中ボリューム本番	高スループット/コンプライアンス要件の本番
ストレージ	保持期間に応じた標準ストレージ	ティアードストレージ等の拡張機能に対応（地域・時期依存）

セキュリティとネットワーキング: 認証・認可・接続性

認証は API Key/Secret（SASL/PLAIN over TLS）を用います。人ではなくサービスアカウント単位で発行し、最小権限の原則に従って ACL または RBAC を設定します。通信は TLS により暗号化され、保存時暗号化もサービス側で行われます。

接続方式は公開エンドポイントに加え、クラウド依存で VPC/VNet ピアリング、PrivateLink/Private Service Connect、IP アロ―リストなどを選べます。コンプライアンス要件が厳しい場合は、Dedicated クラスタとプライベート接続を組み合わせるのが一般的です。

試験観点では、ACL と RBAC の役割の違い（リソースベースの ACL と役割ベースの RBAC）、プロデューサ/コンシューマの ID 分離、キーのローテーション手順、ネットワーク閉域化の選択肢を正確に把握しておくことが重要です。

API キーは環境/クラスタ単位。最小権限で付与
ACL（トピック/グループ/クラスター）、RBAC（権限セット）を併用
プライベート接続オプションはクラウド/リージョンごとに提供状況が異なる

開発者体験とガバナンス: スキーマ、互換性、検証

Schema Registry は Avro/Protobuf/JSON Schema をサポートし、互換性モード（BACKWARD、FORWARD、FULL、TRANSITIVE など）を設定できます。サブジェクト命名戦略（TopicNameStrategy、RecordNameStrategy 等）はクライアント側で選択します。Confluent Cloud ではトピック単位のスキーマ検証を有効化でき、誤ったスキーマの書き込みを早期に防止可能です。

配信保証の観点では、idempotence とトランザクション（EOS v2）を活用します。プロデューサは enable.idempotence=true、acks=all、冪等と整合する in.flight 設定を用い、ストリーム処理ではトランザクション ID を設定して Exactly-once を達成します。試験では、設定の相互依存と失敗時の挙動（再送・順序性）を問う設問がよく出ます。

互換性は原則 BACKWARD 互換を基本に、下流要件で調整
サブジェクト命名は組織標準を決めて逸脱を抑止
スキーマ検証を用いて本番トピックを保護

Java プロデューサ（Confluent Cloud 向け最小構成例）

Properties props = new Properties();
props.put("bootstrap.servers", "<broker-endpoint>:9092");
props.put("security.protocol", "SASL_SSL");
props.put("sasl.mechanism", "PLAIN");
props.put("sasl.jaas.config", "org.apache.kafka.common.security.plain.PlainLoginModule required username='\u003cAPI_KEY\u003e' password='\u003cAPI_SECRET\u003e';");
// 配信保証（冪等）
props.put("enable.idempotence", "true");
props.put("acks", "all");
props.put("max.in.flight.requests.per.connection", "5"); // idempotence と整合
props.put("compression.type", "lz4");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

KafkaProducer<String, String> p = new KafkaProducer<>(props);
p.send(new ProducerRecord<>("orders", "k1", "v1"), (md, ex) -> { /* handle */ });
p.flush();
p.close();

運用と可観測性: メトリクス、制限、変更可能な設定

Confluent Cloud はマネージドのため、ブローカー設定の多くは固定/非公開です。利用者が操作可能なのは主にトピック設定（保持期間、パーティション数の増加、圧縮、cleanup.policy=delete/compact 等）とアクセス制御です。レプリケーション係数などサービス既定のコア設定は変更できない前提で設計します。

監視はコンソール、アラート、Cloud Metrics API で行えます。プロデューサ/コンシューマのレイテンシ、スループット、エラー率、コンシューマラグなどを外部監視に統合し、SLO を定義します。ログ転送やアラート連携はクラウド/リージョンやプランにより提供機能が異なるため、導入前に確認します。

変更時の考慮: パーティション数は増やせますが減らせません。増加後はキー分散が偏っていないかを検証し、順序性の境界（パーティション内のみ保証）を理解しておくことが重要です。保持期間やコンパクション設定の変更は下流システム（リプレイ/リカバリ戦略）に影響します。

Cloud Metrics API を活用し、外部 APM と可視化を統合
SLO/SLI をトピック単位で定義（遅延、エラー、ラグ）
変更は段階的に。本番はカナリアで検証

試験対策の要点（CCDAK / CCAAK）

CCDAK はデータモデリング/配信保証/クライアント設定、CCAAK は運用・セキュリティ・スケーリングに比重があります。Confluent Cloud 前提の設問では、マネージド環境で調整可能なパラメータの範囲、ネットワーク閉域化、スキーマ検証、Cluster Linking による移行・災対、マネージドコネクタの並列度・エラーハンドリングなどが問われがちです。

模試観点では、次のような引っかけに注意します。Dedicated でのみ選べるプライベート接続、レプリケーション係数の変更可否、ブローカー設定よりクライアント調整が先、スキーマ互換性モードの選定、トピック単位のスキーマ検証有効化、Partition を増やすと全体順序は保証されない、などです。

できる/できないの線引きを暗記する（特にネットワークとブローカー設定）
まずはクライアント側チューニングでボトルネックを除去
スキーマ互換性と検証は本番トピックで必須化

問題で確認

CCDAK / CCAAK

問題 1

本番ワークロードで、組織のネットワークからパブリックインターネットを通さずに接続し、将来的にスループットを段階的に拡張したい。また、誤ったスキーマを書き込まないようにブローカー側で検証したい。この要件を最も満たす構成はどれか。

Dedicated クラスタ + PrivateLink（または同等のプライベート接続）+ トピック単位のスキーマ検証 + Schema Registry
Basic クラスタ + 公開エンドポイント + クライアント側のみでスキーマ検証
Standard クラスタ + VPC ピアリングなし + レプリケーション係数を手動で 2 に下げる
Dedicated クラスタ + 公開エンドポイントのみ + スキーマ互換性なし

正解: A

プライベート接続と段階的スケールは Dedicated が適合しやすい。スキーマ整合性は Schema Registry に加え、トピックのスキーマ検証を有効化する。Basic は本番/閉域要件に不十分、Standard 単独ではプライベート接続の選択肢が制限されうる。レプリケーション係数はサービス既定で変更不可が前提。

よくある質問

オンプレミス Kafka から Confluent Cloud へはどう移行すべきですか？

互換バージョンなら Cluster Linking を第一候補に検討します（継続レプリケーションでダウンタイム最小化）。要件により MirrorMaker 2（マネージド Connect）も選択肢です。いずれも ACL/RBAC・スキーマの先行整備、トピック設定（保持/パーティション）の差異吸収、プロデューサ/コンシューマの段階的切替計画が鍵です。

パーティション数は自動で増えますか？性能不足時はどう対処しますか？

自動では増えません。パーティションは手動で増加可能（減少は不可）。性能不足時は、パーティション増加に加え、プロデューサのバッチ/圧縮/acks、キー分散、コネクタのタスク並列度、コンシューマの並列化とフェッチサイズなど、クライアント側の最適化を併用します。

Schema Registry の認証は Kafka の API キーと共通ですか？

Schema Registry は専用エンドポイントで提供され、別の API Key/Secret を発行して Basic 認証（HTTPS）で利用するのが一般的です。接続先 URL と資格情報のスコープを取り違えないように、クライアント設定を分けて管理してください。

この記事で学んだ内容を問題で確認しましょう

16,000問以上の問題で実力チェック

無料で問題を解いてみる

この記事の著者

NicheeLab編集部

データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。