1. Home
  2. Cloud
  3. Confluent Cloud クラスター

重要

このページの日本語コンテンツは古くなっている可能性があります。最新の英語版コンテンツをご覧になるには、こちらをクリックしてください。

クラスタータイプごとの Confluent Cloud の機能と制限

一部の機能は、クラスタータイプに関係なく、すべての Confluent クラスターでサポートされます。ただし、選択する Confluent Cloud クラスタータイプによって、クラスターの機能、制限、料金が異なります。

クラスタータイプには次のものがあります。

重要

このトピックで紹介する制限はプランニングを目的としており、パフォーマンスを保証するものではありません。パフォーマンスは、各構成に応じて異なります。

For per-topic settings and limits, see Confluent Cloud のクラスターとトピックの構成設定. For quotas that apply to organizations, environments, clusters, and accounts, see Confluent Cloud のサービスクォータ. To monitor the performance of your clusters, see Metrics API.

すべての Confluent Cloud クラスタータイプで以下の機能がサポートされます。

機能 詳細
Kafka ACL 詳細については、「Confluent Cloud のアクセス制御リスト（ACL）の使用」を参照してください。
保存データの暗号化 Confluent Cloud は、保存用のすべてのデータストレージに、暗号化されたボリュームを使用します。
転送データの暗号化 Confluent Cloud では、すべての接続に SSL/TLS 1.2 を使用する必要があります。
「厳密に 1 回」のセマンティクス 詳細については、「処理の保証」を参照してください。
完全マネージド型レプリカ配置 Confluent Cloud では、レプリカ配置を管理して、レプリカを複数のブローカーに分散して配置します。マルチゾーンクラスターの場合も、Confluent Cloud により、レプリカが複数のアベイラビリティゾーンに分散して配置されます。
キーベースの圧縮ストレージ 詳細については、「ログ圧縮」を参照してください。
UI: コンシューマーラグ 詳細については、「コンシューマーラグのモニタリング」を参照してください。
トピック管理 詳細については、「トピックの作成、編集、削除」を参照してください。
稼働率 SLA 詳細については、「Confluent Cloud Service Level Agreement」を参照してください。

ベーシッククラスター

ベーシッククラスターは、開発のユースケースを想定して設計されています。 ベーシッククラスターでは、以下がサポートされます。

  • 稼働率 99.5% の SLA
  • 最大 100 MB/秒のスループットと 5 TB のストレージ。
  • 料金がかかるのは、受信量、送信量、ストレージ、およびパーティションのみです。クラスターの基本料金はありません。
  • Confluent Cloud Console を使用して、いつでもシングルゾーンのベーシッククラスターから シングルゾーンのスタンダードクラスター にアップグレードできます。

ベーシッククラスターの制限（クラスター単位）

ディメンション 制限 詳細な説明
受信量 最大 100 MBps

1 秒間にクラスターに生成できるバイト数。

Available in the Metrics API as received_bytes (convert from bytes to MB).

Kafka を自己管理している場合は、プロデューサーの outgoing-byte-rate メトリクス と ブローカーの kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec メトリクス から、スループットを確認できます。

このディメンションの使用量を減らすには、メッセージを圧縮 するという方法があります。圧縮には lz4 をお勧めします。gzip は、クラスターに高いオーバヘッドが生じるので推奨されません。
送信量 最大 100 MBps

1 秒間にクラスターから消費できるバイト数。

Available in the the Metrics API as sent_bytes (convert from bytes to MB).

Kafka を自己管理している場合は、コンシューマーの incoming-byte-rate メトリクス と ブローカーの kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec から、スループットを確認できます。

このディメンションの使用量を減らすには、メッセージを圧縮する、各コンシューマーが必要なトピックからのみ消費を行うようにする、という方法があります。圧縮には lz4 をお勧めします。gzip は、クラスターに高いオーバヘッドが生じるので推奨されません。
ストレージ（レプリケーション前） 最大 5 TB

Number of bytes that can be retained on the cluster, pre-replication.

Available in the Metrics API as retained_bytes (convert from bytes to TB). The returned value is pre-replication.

You can configure policy settings retention.bytes and retention.ms at a topic level so you can control exactly how much and how long to retain data in a way that makes sense for your applications and helps control your costs. If you exceed configured maximum retention values, producers will be throttled to prevent additional writes, which will register as non-zero values for the producer client produce-throttle-time-max and produce-throttle-time-avg metrics.

Kafka を自己管理している場合は、ストレージの所要量について理解するために、クラスターのディスクスペースの使用量を調べることができます。

このディメンションの使用量を減らすには、メッセージを圧縮する、保存設定を減らす、という方法があります。圧縮には lz4 をお勧めします。gzip は、クラスターに高いオーバヘッドが生じるので推奨されません。
パーティション数（レプリケーション前） 最大 2048

Maximum number of partitions that can exist on the cluster at one time, before replication. All topics that the customer creates as well as internal topics that are automatically created by Confluent Platform components--such as ksqlDB, Kafka Streams, Connect, and Control Center--count towards the cluster partition limit. The automatically created topics are prefixed with an underscore (_), created using the Cloud Console, Confluent Cloud CLI, Kafka AdminAPI, Confluent Control Center, Kafka Streams applications, and ksqlDB. However, topics that are internal to Kafka itself (e.g., consumer offsets) are not visible in the Cloud Console, and do not count against partition limits or toward partition billing.

Available in the Metrics API as partition_count.

Attempts to create additional partitions beyond this limit will fail with an error message.

Kafka を自己管理している場合は、kafka.controller:type=KafkaController,name=GlobalPartitionCount メトリックから、パーティションの使用量を確認できます。詳細については、「ブローカーセクション」を参照してください。

このディメンションの使用量を減らすには、未使用のトピックを削減する、パーティション数が少ないトピックを新規作成する、という方法があります。初期パーティション数が少なすぎる場合は、Kafka 管理インターフェイスを使用して既存トピックのパーティション数を増やす ことができます。
クライアント接続の総数 最大 1000

一度に開くことができるクラスターへの TCP 接続数。

Available in the Metrics API as active_connection_count.

Kafka を自己管理している場合は、ブローカーの kafka.server:type=socket-server-metrics,listener={listener_name},networkProcessor={#},name=connection-count メトリクス から、使用している接続数を確認できます。

この値は、プロデューサークライアントの数、コンシューマークライアントの数、クラスター用にプロビジョニングされる CKU の数、パーティションのキーの戦略、クライアントごとの生成パターン、クライアントごとの消費パターンなど、いくつかの要因によって大きく変わります。

このディメンションの使用量を減らすには、クラスターに接続するクライアントの総数を減らすという方法があります。
接続試行回数 1 秒あたり最大 80 回

1 秒間に作成できるクラスターへの新規 TCP 接続の最大数。これは、成功した認証回数と失敗した認証試行回数を加えた数を意味します。

Available in the Metrics API as successful_authentication_count (only includes successful authentications, not unsuccessful authentication attempts).

If you are self-managing Kafka, you can look at the rate of change for the kafka.server:type=socket-server-metrics,listener={listener_name},networkProcessor={#},name=connection-count metric and the Consumer connection-creation-rate metric to understand how many new connections you are creating. For details, see Broker Metrics and Global Connection Metrics. .

このディメンションの使用量を減らすには、クラスターへの接続の維持期間を長くするという方法があります。
リクエスト数 1 秒あたり最大 15000

1 秒間におけるクラスターへのクライアントリクエストの数。

Available in the the Metrics API as request_count.

Kafka を自己管理している場合は、ブローカーの kafka.network:type=RequestMetrics,name=RequestsPerSec,request={Produce FetchConsumer FetchFollower} メトリクス と クライアントの request-rate メトリクス から、リクエスト量を確認できます。

このディメンションの使用量を減らすには、プロデューサーのバッチ処理構成 または コンシューマークライアントのバッチ処理構成 を調整する、非アクティブのクライアントをシャットダウンする、という方法があります。
メッセージサイズ 最大 8 MB トピックレベルでのメッセージサイズのデフォルトについては、「すべてのクラスタータイプのカスタムのトピック設定」を参照してください。
クライアントバージョン 最小 0.11.0 なし
リクエストサイズ 最大 100 MB なし
フェッチバイト数 最大 55 MB なし
API キー数 最大 50 なし
パーティションの作成および削除 5 分間あたり最大 250 個

パーティションの作成と削除のレート制限に達した場合、次のようになります。

  • Kafka 2.7 より前のクライアントの場合:

    クラスターは常に、1 つのリクエストに含まれているすべてのパーティションの作成と削除を受け入れて処理し、その後、変更レートがクォータを下回るまでクライアントの接続をスロットルします。

  • Kafka 2.7 以降のクライアントの場合:

    クラスターは、クォータまでのパーティションの作成と削除のみを受け入れて処理します。同じリクエストに含まれている他のパーティションの作成と削除はすべて、THROTTLING_QUOTA_EXCEEDED エラーで拒否されます。デフォルトでは、default.api.timeout.ms に達するまで、管理クライアントはこのエラーの処理を自動的に再試行します。自動再試行がクライアントで無効になっている場合は、THROTTLING_QUOTA_EXCEEDED エラーがすぐにクライアントに返されます。
1 Kafka クラスターあたりのコネクタータスク数 最大 250 個 1 コネクターあたり 1 タスク
ACL の数 最大 1000 なし

ベーシッククラスターの制限（パーティション単位）

以下のパーティションの制限はベンチマーキングに基づいており、プランニングを目的とした実践的なガイドラインとすることを意図しています。パーティションごとのパフォーマンスは各構成に応じて異なり、これらのベンチマークはパフォーマンスを保証するものではありません。

ディメンション 制限
1 パーティションあたりの受信量 ～ 5 MBps
1 パーティションあたりの送信量 ～ 15 MBps
1 パーティションあたりのストレージ Unlimited
Storage per Partition for Compacted Topics Max 250GB

Cluster Linking capabilities on a Basic cluster

  • A Basic cluster can be a source cluster of a cluster link (can send data).
  • A Basic cluster cannot be a destination cluster (cannot receive data).

詳細については、Cluster Linking のドキュメントの「サポートされるクラスタータイプ」を参照してください。

スタンダードクラスター

スタンダードクラスターは、本番環境対応の機能と性能を利用できるように設計されています。 スタンダードクラスターでは、以下がサポートされます。

スタンダードクラスターの制限（クラスター単位）

ディメンション 制限 詳細な説明
受信量 最大 100 MBps

1 秒間にクラスターに生成できるバイト数。

Available in the Metrics API as received_bytes (convert from bytes to MB).

Kafka を自己管理している場合は、プロデューサーの outgoing-byte-rate メトリクス と ブローカーの kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec メトリクス から、スループットを確認できます。

このディメンションの使用量を減らすには、メッセージを圧縮 するという方法があります。圧縮には lz4 をお勧めします。gzip は、クラスターに高いオーバヘッドが生じるので推奨されません。
送信量 最大 100 MBps

1 秒間にクラスターから消費できるバイト数。

Available in the the Metrics API as sent_bytes (convert from bytes to MB).

Kafka を自己管理している場合は、コンシューマーの incoming-byte-rate メトリクス と ブローカーの kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec から、スループットを確認できます。

このディメンションの使用量を減らすには、メッセージを圧縮する、各コンシューマーが必要なトピックからのみ消費を行うようにする、という方法があります。圧縮には lz4 をお勧めします。gzip は、クラスターに高いオーバヘッドが生じるので推奨されません。
ストレージ（レプリケーション前） 無制限

Number of bytes that can be retained on the cluster, pre-replication. Standard Confluent Cloud clusters support infinite storage. This means there is no maximum size limit for the amount of data that can be stored on the cluster.

Available in the Metrics API as retained_bytes (convert from bytes to TB). The value returned is pre-replication.

You can configure policy settings retention.bytes and retention.ms at a topic level so you can control exactly how much and how long to retain data in a way that makes sense for your applications and helps control your costs. If you exceed configured maximum retention values, producers will be throttled to prevent additional writes, which will register as non-zero values for the producer client produce-throttle-time-max and produce-throttle-time-avg metrics.

Kafka を自己管理している場合は、ストレージの所要量について理解するために、クラスターのディスクスペースの使用量を調べることができます。

このディメンションの使用量を減らすには、メッセージを圧縮する、保存設定を減らす、という方法があります。圧縮には lz4 をお勧めします。gzip は、クラスターに高いオーバヘッドが生じるので推奨されません。
パーティション数（レプリケーション前） 最大 2048

Maximum number of partitions that can exist on the cluster at one time, before replication. All topics that the customer creates as well as internal topics that are automatically created by Confluent Platform components--such as ksqlDB, Kafka Streams, Connect, and Control Center--count towards the cluster partition limit. The automatically created topics are prefixed with an underscore (_), created using the Cloud Console, Confluent Cloud CLI, Kafka AdminAPI, Confluent Control Center, Kafka Streams applications, and ksqlDB. However, topics that are internal to Kafka itself (e.g., consumer offsets) are not visible in the Cloud Console, and do not count against partition limits or toward partition billing.

Available in the Metrics API as partition_count.

Attempts to create additional partitions beyond this limit will fail with an error message.

Kafka を自己管理している場合は、kafka.controller:type=KafkaController,name=GlobalPartitionCount メトリックから、パーティションの使用量を確認できます。詳細については、「ブローカーセクション」を参照してください。

このディメンションの使用量を減らすには、未使用のトピックを削減する、パーティション数が少ないトピックを新規作成する、という方法があります。初期パーティション数が少なすぎる場合は、Kafka 管理インターフェイスを使用して既存トピックのパーティション数を増やす ことができます。
クライアント接続の総数 最大 1000

一度に開くことができるクラスターへの TCP 接続数。

Available in the Metrics API as active_connection_count.

Kafka を自己管理している場合は、ブローカーの kafka.server:type=socket-server-metrics,listener={listener_name},networkProcessor={#},name=connection-count メトリクス から、使用している接続数を確認できます。

この値は、プロデューサークライアントの数、コンシューマークライアントの数、クラスター用にプロビジョニングされる CKU の数、パーティションのキーの戦略、クライアントごとの生成パターン、クライアントごとの消費パターンなど、いくつかの要因によって大きく変わります。

このディメンションの使用量を減らすには、クラスターに接続するクライアントの総数を減らすという方法があります。
接続試行回数 1 秒あたり最大 80 回

1 秒間に作成できるクラスターへの新規 TCP 接続の最大数。これは、成功した認証回数と失敗した認証試行回数を加えた数を意味します。

Available in the Metrics API as successful_authentication_count (only includes successful authentications, not unsuccessful authentication attempts).

If you are self-managing Kafka, you can look at the rate of change for the kafka.server:type=socket-server-metrics,listener={listener_name},networkProcessor={#},name=connection-count metric and the Consumer connection-creation-rate metric to understand how many new connections you are creating. For details, see Broker Metrics and Global Connection Metrics. .

このディメンションの使用量を減らすには、クラスターへの接続の維持期間を長くするという方法があります。
リクエスト数 1 秒あたり最大 15000

1 秒間におけるクラスターへのクライアントリクエストの数。

Available in the the Metrics API as request_count.

Kafka を自己管理している場合は、ブローカーの kafka.network:type=RequestMetrics,name=RequestsPerSec,request={Produce FetchConsumer FetchFollower} メトリクス と クライアントの request-rate メトリクス から、リクエスト量を確認できます。

このディメンションの使用量を減らすには、プロデューサーのバッチ処理構成 または コンシューマークライアントのバッチ処理構成 を調整する、非アクティブのクライアントをシャットダウンする、という方法があります。
メッセージサイズ 最大 8 MB トピックレベルでのメッセージサイズのデフォルトについては、「すべてのクラスタータイプのカスタムのトピック設定」を参照してください。
クライアントバージョン 最小 0.11.0 なし
リクエストサイズ 最大 100 MB なし
フェッチバイト数 最大 55 MB なし
API キー数 最大 100 To request an increase for this limit, contact Confluent Support.
パーティションの作成および削除 5 分間あたり最大 500 個

パーティションの作成と削除のレート制限に達した場合、次のようになります。

  • Kafka 2.7 より前のクライアントの場合:

    クラスターは常に、1 つのリクエストに含まれているすべてのパーティションの作成と削除を受け入れて処理し、その後、変更レートがクォータを下回るまでクライアントの接続をスロットルします。

  • Kafka 2.7 以降のクライアントの場合:

    クラスターは、クォータまでのパーティションの作成と削除のみを受け入れて処理します。同じリクエストに含まれている他のパーティションの作成と削除はすべて、THROTTLING_QUOTA_EXCEEDED エラーで拒否されます。デフォルトでは、default.api.timeout.ms に達するまで、管理クライアントはこのエラーの処理を自動的に再試行します。自動再試行がクライアントで無効になっている場合は、THROTTLING_QUOTA_EXCEEDED エラーがすぐにクライアントに返されます。
1 Kafka クラスターあたりのコネクタータスク数 最大 250 個 なし
ACL の数 最大 1000 なし

スタンダードクラスターの制限（パーティション単位）

以下のパーティションの制限はベンチマーキングに基づいており、プランニングを目的とした実践的なガイドラインとすることを意図しています。パーティションごとのパフォーマンスは各構成に応じて異なり、これらのベンチマークはパフォーマンスを保証するものではありません。

ディメンション 制限
1 パーティションあたりの受信量 ～ 5 MBps
1 パーティションあたりの送信量 ～ 15 MBps
1 パーティションあたりのストレージ Unlimited
Storage per Partition for Compacted Topics Max 250GB

Cluster Linking capabilities on a Standard cluster

  • スタンダードクラスターはクラスターリンクの 送信元 クラスターになることができる（データを送信できる）。
  • スタンダードクラスターは 送信先 クラスターになることができない（データを受信できない）。

詳細については、Cluster Linking のドキュメントの「サポートされるクラスタータイプ」を参照してください。

専用クラスター

専用クラスターは、トラフィックが多い、またはプライベートネットワーク接続を要する、重要なワークロードの本番環境に対応できるように設計されています。 専用クラスターでは、以下がサポートされます。

専用クラスターは、Confluent Unit for Kafka (CKU) 単位でプロビジョンされ、請求されます。CKU は、事前に割り当てられた量のリソースを提供する、Confluent Cloud での水平拡張性の単位です。1 CKU でどれくらいの量を取り込んでストリームできるかは、クライアントアプリケーションの設計やパーティショニング方法など、さまざまな要因によって決まります。

CKU の制限（専用クラスター単位）

専用クラスターは、CKU を整数単位で上限まで購入できます。

  • クレジットカードによるお支払いの場合、上限は専用クラスターごとに 4 CKU です。
  • クラウドプロバイダーの一括請求によるお支払いまたは請求書によるお支払いの場合、上限は専用クラスターごとに 24 CKU です。リクエストに応じて、最大 100 CKU までのクラスターに対応可能です。

To provision a cluster with more CKUs than the upper limit, contact Confluent Support.

シングルゾーンクラスターの CKU は 1 つ以上です。マルチゾーンクラスターは、最小 2 CKU を必要とし、高可用性を提供します。クラスター作成後にゾーンの可用性を変更することはできません。

CKU 単位の制限

CKU によって、クラスターの処理能力が決まります。Confluent Cloud クラスターでは、特定のワークロードに想定されるパフォーマンスは、メッセージサイズ、パーティション数など、さまざまなディメンションによって決まります。

CKU ディメンションには、2 つのカテゴリがあります。

  • 超過できない 固定制限 があるディメンション。
  • クラスターの全体的な負荷量に応じて超過可能な柔軟な ガイドライン があるディメンション。

ディメンションの推奨ガイドラインは、ディメンション全体で最適化されたワークロードに対して計算され、高い CKU 使用率を実現します。これは、クラスター負荷メトリック で測定されます。あるディメンションの推奨ガイドラインを超える構成を使用して、そのディメンションでより高いパフォーマンスを達成することもできますが、通常は、他のディメンションの使用量が推奨ガイドラインまたは固定制限より少ない場合のみです。

また、すべてのディメンションでの使用量パターンがワークロードに影響するため、特定のディメンションに対して推奨されるガイドラインが達成できないことがあります。たとえば、パーティション制限に達すると、CKU スループットの最大のガイドラインには達しない可能性があります。

お使いのクラスターの クラスター負荷メトリック をモニタリングし、使用量パターンとクラスター使用率の相関を確認する必要があります。

クラスターの負荷メトリックが高い場合、クラスターの可用性を維持するために新規の接続が遅れたり、クライアントがスロットリングされたりする可能性があります。このスロットリングは、プロデューサークライアントの produce-throttle-time-max メトリックと produce-throttle-time-avg メトリック、および コンシューマークライアントの fetch-throttle-time-max メトリックと fetch-throttle-time-avg メトリック にゼロ以外の値として記録されます。

次の表を使用して、特定のワークロードで使用する場合の最小 CKU 数、ディメンションのモニタリング方法、および特定ディメンションの使用を削減するための推奨事項を決定してください。

固定制限があるディメンション

次の表は、超過できない固定の上限があるディメンションの一覧です。

ディメンション 1 CKU あたりの最大値 詳細
ストレージ（レプリケーション前） 無制限

Number of bytes that can be retained on the cluster, pre-replication. Dedicated clusters have infinite storage, which means there is no maximum size limit for the amount of data that can be stored on the cluster.

Available in the Metrics API as retained_bytes (convert from bytes to TB). The returned value is pre-replication.

You can configure policy settings retention.bytes and retention.ms at a topic level so you can control exactly how much and how long to retain data in a way that makes sense for your applications and helps control your costs. If configured retention values are exceeded, producers will be throttled to prevent additional writes, which will register as non-zero values for the producer client produce-throttle-time-max and produce-throttle-time-avg metrics.

Kafka を自己管理している場合は、ストレージの所要量について理解するために、クラスターのディスクスペースの使用量を調べることができます。

このディメンションの使用量を減らすには、メッセージを圧縮する、保存設定を減らす、という方法があります。圧縮には lz4 をお勧めします。gzip は、クラスターに高いオーバヘッドが生じるので推奨されません。
パーティション数（レプリケーション前） 4,500 パーティション（すべての CKU の合計で最大 100,000 パーティション）

Maximum number of partitions that can exist on the cluster at one time, before replication. All topics that the customer creates as well as internal topics that are automatically created by Confluent Platform components--such as ksqlDB, Kafka Streams, Connect, and Control Center--count towards the cluster partition limit. The automatically created topics are prefixed with an underscore (_), created using the Cloud Console, Confluent Cloud CLI, Kafka AdminAPI, Confluent Control Center, Kafka Streams applications, and ksqlDB. However, topics that are internal to Kafka itself (e.g., consumer offsets) are not visible in the Cloud Console, and do not count against partition limits or toward partition billing.

Available in the Metrics API as partition_count.

Attempts to create additional partitions beyond this limit will fail with an error message.

Kafka を自己管理している場合は、kafka.controller:type=KafkaController,name=GlobalPartitionCount メトリックから、パーティションの使用量を確認できます。詳細については、「ブローカーセクション」を参照してください。

このディメンションの使用量を減らすには、未使用のトピックを削減する、パーティション数が少ないトピックを新規作成する、という方法があります。初期パーティション数が少なすぎる場合は、Kafka 管理インターフェイスを使用して既存トピックのパーティション数を増やす ことができます。
接続試行回数 1 秒あたり 250 回の接続試行回数

1 秒間に作成できるクラスターへの新規 TCP 接続の最大数。これは、成功した認証回数と失敗した認証試行回数を加えた数を意味します。

この最大値を超えると、接続試行が拒否される可能性があります。

Kafka を自己管理している場合は、kafka.server:type=socket-server-metrics,listener={listener_name},networkProcessor={#},name=connection-count メトリックと、コンシューマーの connection-creation-rate メトリックの変化率から、作成している新規接続数を確認できます。詳細については、「ブローカーのメトリクス」と「グローバルコネクションメトリクス」を参照してください。.このディメンションの使用量を減らすには、クラスターへの接続の維持期間を長くするという方法があります。

専用クラスターの制限（クラスター単位）

専用クラスターに CKU を追加して、トラフィックの多いワークロードに対応できる処理能力にすることができます。ただし、CKU 数を増やしても、このテーブルに記載している制限は変わりません。クォータと制限の詳細については、「Confluent Cloud のサービスクォータ」および「すべてのクラスタータイプのカスタムのトピック設定」を参照してください。

ディメンション 制限
メッセージサイズ 最大 20 MB（トピックレベルでのメッセージサイズのデフォルトについては、「すべてのクラスタータイプのカスタムのトピック設定」を参照してください）
クライアントバージョン 最小 0.11.0
リクエストサイズ 最大 100 MB
フェッチバイト数 最大 55 MB
パーティション数 CKU 数によって異なります。最大数は 100,000。
API キー数 Max 2000. To request an increase for this limit, contact Confluent Support.
パーティションの作成および削除 Max 5000 per 5 minute period .. includes:: ../includes/partition-crud-ux.rst
1 Kafka クラスターあたりのコネクタータスク数 最大 250 個
ACL の数 最大 10000 個

専用クラスターの制限（パーティション単位）

専用クラスターに CKU を追加して、トラフィックの多いワークロードに対応できる処理能力にすることができます。ただし、CKU 数を増やしても、このテーブルに記載している制限は変わりません。

以下のパーティションの制限はベンチマーキングに基づいており、プランニングを目的とした実践的なガイドラインとすることを意図しています。パーティションごとのパフォーマンスは各構成に応じて異なり、これらのベンチマークはパフォーマンスを保証するものではありません。

ディメンション 制限
1 パーティションあたりの受信量 最大 10 MBps（プロデューサーの合計スループット）
1 パーティションあたりの送信量 最大 30 MBps（コンシューマーの合計スループット）
1 パーティションあたりのストレージ Unlimited
Storage per Partition for Compacted Topics Max 250GB

専用クラスターのプロビジョニングおよびサイズ変更の時間

プロビジョニング時間

専用クラスターの初期プロビジョニングにかかる推定時間は、クラスターのサイズと利用するクラウドプロバイダーによって決まります。クラウドプロバイダーとは関係なく、プロビジョニングに 24 時間以上かかる場合があります。プロビジョニングに 24 時間以上かかる場合は、Confluent サポート にお問い合わせください。

プロビジョニング時間は Confluent SLA に含まれないことに注意してください。

  • AWS: 想定されるプロビジョニング時間は、1 CKU あたり 1 時間です。AWS 上の 2 CKU の専用クラスターは、約 2 時間でプロビジョニングが完了すると推定されます。
  • GCP: 想定されるプロビジョニング時間は、1 CKU あたり 1 時間です。GCP 上の 2 CKU の専用クラスターは、2 時間でプロビジョニングが完了すると推定されます。
  • Azure: 想定されるプロビジョニング時間は、1 CKU あたり 2 時間半です。Azure 上の 2 CKU の専用クラスターは、5 時間でプロビジョニングが完了すると推定されます。

プロビジョニングが完了するとメールが届きます。

サイズ変更の時間

When a cluster is not heavily loaded, expansion and shrink times are generally similar to expected provisioning times (single-digit hours). When a cluster is under heavy load, resizing can take longer.

Resizing a cluster should take about 1-2 hours per CKU.

サイズ変更の処理中に、アプリケーションにリーダー選出の影響が出る場合がありますが、それ以外のパフォーマンスへの影響はありません。サポート対象の Kafka クライアントは、このような変更を適切に処理します。サイズ変更処理が完了すると E メールが届きます。

専用クラスターの Cluster Linking の制限

専用クラスターは、ネットワークのタイプと関連するその他のクラスターに応じて、クラスターリンクの 送信元 にも 送信先 にもなることができます。詳細については、Cluster Linking のドキュメントの「サポートされるクラスタータイプ」を参照してください。