Confluent Cloud と自前運用の比較：コスト・運用・機能差をCCAAK視点で整理

Kafka を使う際、Confluent Cloud を選ぶか、自前でクラスタを設計・運用するかは、TCOとリスクプロファイルに直結します。本稿は公式ドキュメントの一般的な挙動に基づき、意思決定に必要な観点を整理します。

資格対策では、クラスタ設計・セキュリティ・可用性・スケーリングの基礎が問われやすいので、Cloud/自前の違いを概念として説明できるようにしておきましょう。

アーキテクチャ概観：マネージド vs 自前

Confluent Cloud はKafkaブローカー、ZooKeeper/KRaft、スケーリング、パッチ適用、監視の多くをSaaSとして抽象化します。利用者はAPIキーやネットワーク接続、トピック設計、スキーマ設計、ACL/RBACなどアプリ寄りの責務に集中できます。

自前運用は、ブローカー台数やインスタンスタイプ選定、ストレージ/ネットワーク設計、Rolling upgrade、監視・アラート、障害対応、バックアップ/ディザスタリカバリなど、クラスタライフサイクル全体を自組織で担います。

• 管理境界：CloudはSaaSのSLO/SLA内で動作。自前はOS/ミドルウェア/ネットワークまで自責。
• ネットワーク：Cloudはプライベート接続（例：プライベートリンクやVPCピアリング等）を用意。自前はVPC設計と証明書配布まで自作。
• スケール：CloudはプランやAPIでスケール。自前はブローカー追加とパーティション再配置が必要。

接続と運用境界（概念図）

最小構成の作成例（Cloud と OSS）

# Confluent Cloud（CLIの一例：プラン名やオプションはアカウント/リージョンで異なる）
confluent kafka cluster create my-cluster \
  --cloud aws \
  --region ap-northeast-1 \
  --type basic

# トピック作成（保持期間やパーティション数を指定）
confluent kafka topic create orders \
  --partitions 6 \
  --config retention.ms=604800000

# 自前（OSS Kafka）でのトピック作成例
kafka-topics.sh --create \
  --topic orders \
  --partitions 6 \
  --replication-factor 3 \
  --bootstrap-server broker1:9092

コストモデルの比較

Confluent Cloud は概ね従量課金（例：データ入出力、ストレージ、スループット容量単位など）とプラン料金の組み合わせです。利用量が読みにくいPoCや段階的拡大には適合しやすく、キャパシティ余剰のリスクを抑えられます。

自前運用はインフラ費（VM/ベアメタル、ストレージ、ネットワーク）に加え、運用要員の人件費、監視/バックアップ基盤費、可用性を確保するための冗長コストが乗ります。高稼働率・安定したトラフィックであれば、単価は下げやすい一方、ピークに合わせた過剰プロビジョニングが発生しがちです。

試験観点では、保持期間と複製係数がストレージコストを支配し、パーティション設計とバッチ/圧縮がネットワーク/CPU効率に影響する、という因果を説明できることが重要です。

• 保持期間はコストに直結：不要データは短く保持、ログ圧縮はユースケースに応じて使い分け。
• ネットワーク課金は下り（egress）を意識：集約/フィルタ/圧縮で削減。
• スループットはパーティション数と並行度で伸ばすが、過剰分割はメタデータ負荷を増やす。

ざっくり見積りのメモ（ストレージ/ネットワーク）

# 1日の入力データ量(GB) = (平均イベントサイズ(Byte) * 1日のイベント数) / 1024^3
# 保持ストレージ(GB) ≈ 入力データ量(GB) * 保持日数 * 複製係数
# 出力量(GB) ≈ 入力量(GB) * 平均購読者数 * フィルタ係数
# 圧縮を使う場合は、データ圧縮率(例: 0.3〜0.7)を掛け合わせて見積ると現実的
# 例: 1KBのイベントを1日20億件、保持7日、RF=3
# 入力 ≈ (1024 * 2e9) / 1024^3 ≈ 1907GB/日 → 保持 ≈ 1907 * 7 * 3 ≈ 40TB強

運用責任とSLA

Confluent Cloud では、ノード障害時の置換、ディスク障害時の再同期、クラスタのスケール、パッチ適用、監視基盤などがサービスに組み込まれます。ユーザーはトピック/スキーマ/ACL/RBAC/接続の運用に集中できます。

自前運用は、障害対応Runbook、監視閾値チューニング、ローリングアップグレード、容量計画、パーティション再配置、証明書ローテーション、バックアップとDR演習までが自責です。SLA/SLOは自組織で定義・測定・改善します。

• Cloud: 障害検知・切替・復旧の自動化レベルが高い。
• 自前: メンテナンスウィンドウ確保と可観測性の整備が必須。
• 試験: ローリングリスタート、リバランス、フェイルオーバーの手順理解が問われる。

代表的な運用コマンド（比較）

# Cloud: パーティション数の増加
confluent kafka topic update orders --partitions 12

# 自前: パーティション再配置（例）
# 1) 割当案の生成
echo '{"version":1,"partitions":[{"topic":"orders","partition":0,"replicas":[1,2,3]}]}' > reassignment.json
kafka-reassign-partitions.sh --bootstrap-server broker1:9092 --reassignment-json-file reassignment.json --execute

# 自前: ブローカーのローリング再起動（例）
# 順に停止→起動。実環境はオーケストレータ/Automationを使用。
kafka-server-stop.sh && sleep 10 && kafka-server-start.sh -daemon /etc/kafka/server.properties

セキュリティとネットワーク

Cloud では転送中の暗号化（TLS）とAPI Key/Secretによる認証、RBACやACL、監査ログなどが提供されます。プライベート接続オプションを利用すればネットワーク露出を最小化できます。

自前では TLS 証明書の発行/展開/ローテーション、SASL メカニズム（例：SCRAM/OAUTHBEARER）の選定、ACL設計、ネットワーク分離（サブネット/SG/NACL）を自組織で設計・運用します。

試験では、ACL/RBACの適用単位、SASL/TLSの設定、クライアント設定の正否、ネットワーク経路の最適化（NAT/プロキシ/帯域制御）などが理解ポイントです。

• 最小権限の原則：プロデューサとコンシューマで権限を分離。
• 証明書/秘密情報は安全に配布・更新（自前は特に自動化が重要）。
• プライベート接続時はDNS解決・CIDR・帯域を事前に計画。

クライアント設定例（SASL_SSL）

# Confluent Cloud 例（PLAIN over TLS）
bootstrap.servers=xxxx.gcp.confluent.cloud:9092
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
  username="<API_KEY>" password="<API_SECRET>";
# 必要に応じてCA証明書バンドルを設定

# 自前（SCRAM-SHA-512 例）
bootstrap.servers=broker1:9093,broker2:9093
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="app-producer" password="********";

機能差とエコシステム統合

Confluent Cloud はマネージドのコネクタ、Schema Registry、ksqlDB、ガバナンス機能、Cluster Linking などを提供します。インフラ運用を極小化しながら、イベント駆動のフルマネージド体験を得られます。

自前運用はOSS/商用コンポーネントを組み合わせて同等機能を構築できますが、互換性検証・運用の複雑度が上がります。MirrorMaker 2 などを活用したレプリケーションも自設計が必要です。

試験観点では、スキーマ互換性、ログ圧縮ポリシー、ストリーム処理の基礎、コネクタの信頼性（Exactly-onceや再試行戦略）が理解ポイントです。

• Cloud: マネージドコネクタ/Schema Registry/ksqlDB/ガバナンスが統合。
• 自前: コンポーネント選定と運用の自由度が高いが、標準化が課題。
• どちらでも: スキーマ進化と互換性ルールを体系的に管理する。

ksqlDB の簡易サンプル（クレンジング）

CREATE STREAM pageviews_raw (user_id VARCHAR, url VARCHAR, ts BIGINT)
  WITH (KAFKA_TOPIC='pageviews', VALUE_FORMAT='JSON');

CREATE STREAM pageviews_clean AS
  SELECT user_id, url, ts
  FROM pageviews_raw
  WHERE url IS NOT NULL EMIT CHANGES;

試験対策の要点と実務Tips

CCAAKでは、クラスタの可用性設計（RF、ISR、acks、min.insync.replicas）、スループット計画（パーティション、バッチ、圧縮）、保持戦略（retention.ms/bytes、ログ圧縮）、セキュリティ（SASL/TLS、ACL/RBAC）が頻出です。

Cloudと自前の対比としては、誰が何を管理するか、どのメトリクスをどこで観測できるか、スケールや障害時の操作がどう異なるかを言語化できると有利です。

• 保持戦略: retention.ms / retention.bytes / log.cleanup.policy(delete|compact) の適用を使い分ける。
• 可用性: acks=all と min.insync.replicas の関係、ISRからのアウト時の挙動。
• スループット: 圧縮（producer/topic/broker）、linger.ms、batch.size の効果を理解。
• セキュリティ: ACLのプリンシパル/リソース/操作/パターンの粒度、RBACの役割範囲。
• 運用: リバランスとローリングアップグレードの基本手順。

ACL の付与例（Cloud と自前）

# Confluent Cloud（CLI）
confluent kafka acl create --allow \
  --operation WRITE --topic orders --principal User:svc-producer
confluent kafka acl create --allow \
  --operation READ --topic orders --principal User:svc-consumer --consumer-group cg-orders

# 自前（kafka-acls.sh）
kafka-acls.sh --authorizer-properties zookeeper.connect=zk:2181 \
  --add --allow-principal User:svc-producer --operation Write --topic orders
kafka-acls.sh --authorizer-properties zookeeper.connect=zk:2181 \
  --add --allow-principal User:svc-consumer --operation Read --topic orders --group cg-orders

問題で確認

よくある質問