Confluent Cloud Kafka の基本ユニット eCKU/CKU から利用プランを考える

はじめに

こんにちは、SREグループの萩原です。

「Chatwork」のサービスにはメッセージデータの永続化を担う Falcon というサブシステムがあります。

今年に入って、その中のコンポーネントである Kafka をマネージドサービスにリプレースする機運が高まってきたことから、Confluent 社が提供している Confluent Cloud Kafka について調査をすすめています。

その中のひとコマを紹介します。

今回は、Confluent Cloud Kafka の基本ユニットである eCKU/CKU で規定されている制限値の特性を基に利用プランについて考えてみます。

※本記事内のスクリーンショットに記載されている値は 2025/06/25 時点のものです。最新の情報は Confluent 社のウェブサイトで確認するようにしてください。

eCKU/CKUの制限値

Confluent Cloud Kafka ではプラン毎にスケールする際の基本ユニットである eCKU/CKU の制限値が定められていて、単位時間あたりのスループットであったり、リクエスト数や接続数が制限値を超えそうになると自動的に eCKU/CKU を追加することでキャパシティを増やす動きになっています。

ちなみに CKU と言う呼称は「Dedicated」プランのみ使用されており、それ以外のプランでは eCKU が使用されるようです。

eCKU/CKU comparison | Confluent Documentation

ただし、プラン内で無制限にスケールできるというわけではなく、各プランにはそれ以上スケールできない eCKU/CKU の上限値が決められています。

Minimum/maximum eCKU requirements | Confluent Documentation

運用中に eCKU/CKU の上限値に達してしまった場合、どのような挙動になるかはとても気になるところですね。

プランの検討

プランの上限値は以下のように規定されています。

Cluster limit comparison | Confluent Documentation

プランの上限値に近いところで運用していると、何らか突発的な外部要因によってその制限を超えてしまうようなアクセスが発生することがあるかもしれません。普通はそのような状況に陥る前の適切なタイミングで上位プランへ移行するような計画が立てられているはずとは思うのですが・・・

制限値を超えて届いたリクエストがまったく受け付けられないような仕様だとすると、かなり安全側に倒して上位プランへの移行計画を考える必要がありそうです。

そもそも、当初考えていたプランのひとつ上のプランを最初から選択することも視野に入ってくるかもしれません。

幸いなことに Confluent 社ではプラン上限に達した際の振る舞いをウェブサイト上で公表してくれています。

Fixed limits and recommended guidelines | Confluent Documentation

ハードリミット (絶対に超えることができない)
推奨値 (一時的な超過を許容する)

推奨値について確認してみたところ、内部ではリソース負荷を監視していて、一定程度以上の超過状態を検知した場合は特別に超過分に応じた eCKU/CKU を割り当てることで追加課金対象として扱われるということでした。

ただし、あくまでも一時的な緊急避難措置ということなので、早急な状況改善を求められることになりますのでこのことを当てにすべきではありません。

また、そのような状況下であっても、ハードリミット要件が緩和されることはありません。

まとめ

結局、どのプランを選択するのが良いのでしょうか？

「Basic」プランでは冗長構成にすることができないため可用性が低く本番環境には向きません。
リージョンによって微妙にバランスが異なりますが、「Standard」プランと「Enterprise」プランの eCKU の価格差が概ね 3 倍くらいなのに対して、eCKU の制限値は3倍強の設定になっている項目が多いようです。将来のサービスの成長見込みにもよりますが、移行前の環境で「Total client connections」が 5,000 (5 eCKU の上限相当) 以上、「Requests」が 7,500 (5 eCKU の上限相当) 以上であるなら、はじめから「Enterprise」プラン以上で考えるのが無難そうです。
Private Link を導入するなどしてよりセキュアな環境を構築したい要件がある場合は「Dedicated」プランを選択することになります。
「Freight」プランはレイテンシーに関する要件が合わないため今回は評価しませんでした。 Introducing Confluent Cloud Freight Clusters

おまけ情報

Kafka のトピックでパーティションを分割したいモチベーションとして最初に頭に浮かぶのは「トピックでどの程度のスループットを処理したいか？」だと思います。

Confluent 社はプラン毎に 1 パーティションで処理できるスループットの上限値の目安を公表しており、トピックのパーティション数を検討する際の参考にすることができます。

Partition limits | Confluent Documentation

最後まで読んでいただきありがとうございました。

お知らせ

最後にお知らせです。 7月11日、12日に開催される「SRE NEXT 2025」にプラチナムスポンサーとしてブース出展します🎉 二日目の12日には13:30〜13:50にTrack Cにて、「『Chatwork』のEKS環境を支えるhelmfileを使用したマニフェスト管理術」というタイトルでスポンサーセッションも行いますのでぜひご参加ください！

sre-next.dev