すべてのプロダクト
Search

このプロダクト

    ApsaraMQ for Kafka:制限

    ドキュメントセンター

    ApsaraMQ for Kafka:制限

    最終更新日:Nov 09, 2025

    ApsaraMQ for Kafka には、特定のメトリックに制限があります。ApsaraMQ for Kafka を使用する場合、プログラムのエラーを防ぐために、これらの制限を超えないようにする必要があります。

    重要

    サービスレベル契約 (SLA) およびその補償条件は、以下の制限を超えるインスタンス構成によって引き起こされる不安定性には適用されません。

    制限

    次の表に、ApsaraMQ for Kafka の制限を示します。

    制限

    制限

    説明

    Topic とパーティションの総数の制限

    サポート

    ApsaraMQ for Kafka のストレージと調整メカニズムはパーティションの粒度に基づいており、Topic (したがってパーティション) の数が多すぎると、ストレージの断片化が発生し、クラスターのパフォーマンスと安定性が低下します。

    Topic あたりの最小パーティション数

    • サブスクリプションと従量課金:

      • クラウドストレージを使用する Topic の場合、最小値は 2 です。

      • ローカル記憶域を使用する Topic の場合、最小値は 1 です。

    • Serverless エディション:

      • クラウドネイティブストレージを使用する Topic の場合、最小値は 1 です。

    トラフィックが多い場合、単一のパーティションはデータスキューやホットスポットの問題を引き起こす可能性があります。パーティションの数を適切に設定してください。

    Topic のパーティション数の削減

    サポートされていません

    これは Apache Kafka の設計上の制限です。

    ZooKeeper の公開

    サポートされていません

    Apache Kafka V0.9.0 以降のクライアントを使用するために ZooKeeper にアクセスする必要はありません。ApsaraMQ for Kafka の ZooKeeper は部分的に共有されており、セキュリティ上の理由から公開されていません。ZooKeeper の仕組みを理解する必要はありません。

    ApsaraMQ for Kafka がデプロイされているマシンへのログオン

    サポートされていません

    なし。

    バージョン

    バージョン 2.2.x から 3.3.x をサポート

    • 非 Serverless インスタンスはバージョン 2.2.x から 2.6.x をサポートします。

    • Serverless インスタンスはバージョン 3.3.x をサポートします。

    インスタンスのバージョンをスペックアップするには、「インスタンスのバージョンをスペックアップする」をご参照ください。

    パーティションと Topic の比率

    1:1

    利用可能な Topic の数は、パーティションの総数に直接関係します。たとえば、50 パーティションのインスタンス、alikafka.hw.2xlarge スループット仕様、および仕様に含まれる 1,000 のボーナスパーティションを購入した場合、このインスタンスのパーティションの総数は 50 (購入済み) + 1,000 (ボーナス) = 1,050 です。利用可能な Topic の数は 1,050 です。

    説明

    これは非 Serverless インスタンスにのみ適用されます。

    インスタンスリージョンの変更

    サポートされていません

    インスタンスが購入およびデプロイされると、そのリージョンは物理リソースに紐付けられ、変更できません。インスタンスのリージョンを変更するには、インスタンスをリリースして新しいインスタンスを購入してください。

    インスタンスのネットワークプロパティの変更

    サポートされています

    必要に応じてネットワークプロパティを変更できます。詳細については、「インスタンス構成のスペックアップ」をご参照ください。

    メッセージサイズ

    10 MB

    メッセージサイズは 10 MB を超えることはできません。超えた場合、メッセージの送信に失敗します。

    モニタリングとアラート

    サポートされています

    データレイテンシーは 1 分です。

    エンドポイント

    仕様

    • 非 Serverless インスタンス:

      • Standard Edition: デフォルトおよび SSL エンドポイントをサポートします。

      • Professional Edition: デフォルト、SSL、および SASL エンドポイントをサポートします。

    • Serverless インスタンス: デフォルト、SSL、および SASL エンドポイントをサポートします。

    クラウドストレージを使用する単一パーティション

    ダウンタイムまたはスペックアップ中に利用できなくなる可能性があります

    複数のパーティションを作成してください。単一のパーティションを使用する必要がある場合は、ローカル記憶域を使用してください。

    説明

    • この制限は非 Serverless インスタンスにのみ適用されます。Serverless インスタンスのクラウドストレージを使用する単一パーティションは、高可用性を提供します。

    • Topic の作成時にストレージエンジンタイプとしてローカル記憶域を選択できるのは、Professional Edition インスタンスのみです。Standard Edition はこの機能をサポートしていません。

    バッチあたりの最大メッセージ数

    32767

    単一のメッセージが小さい場合は、batch.size を 16384 を超えない値に設定してください。

    説明

    これは非 Serverless インスタンスにのみ適用されます。

    説明

    Topic 仕様に基づく非 Serverless ApsaraMQ for Kafka インスタンスは購入できなくなりました。既存のインスタンスが Topic 仕様に基づいて購入された場合、Topic とパーティションの比率は 1:16 です。Professional Edition インスタンスの場合、Topic の数は、購入した Topic の数 × 2 として計算されます。

    クォータ制限

    次の表に、ApsaraMQ for Kafka のクォータ制限を示します。これらの制限を超えると、安定性の問題が発生する可能性があります。「その他の制限」セクションでは、サーバーに悪影響を及ぼす可能性のあるシナリオについて説明しています。サーバーの過負荷とそれに関連する安定性の問題を回避するために、これらのシナリオでは注意が必要です。

    特に明記されていない限り、これらの制限は各クラスターに適用されます。クォータの引き上げをリクエストするには、チケットを送信してください。

    表では、// は整数除算を表し、最も近い整数に切り捨てられます。

    制限

    条件

    説明

    サブスクリプション/従量課金インスタンス

    Serverless (Basic Edition)

    Serverless (Standard/Professional Edition)

    接続数 (シングルノード)

    • 1,000 接続から開始します。

    • 実際のメッセージ送信トラフィックが 100 MB/s 増加するごとに、接続数が 1,000 増加します。

    • 上限は 10,000 です。

    式:

    C = min(10000, 1000 + (F // 100) × 1000)

    • 1,000 接続から開始します。

    • 予約済み送信容量が 300 MB/s 増加するごとに、接続数が 1,000 増加します。

    • 上限は 10,000 です。

    式:

    C = min(10000, 1000 + (F // 300) × 1000)

    単一のブローカーへの TCP 接続数。

    より高い接続制限が必要な場合は、チケットを送信してください。

    インターネット (SSL) 接続数 (シングルノード)

    • 200 接続から開始します。

    • 実際のメッセージ送信トラフィックが 100 MB/s 増加するごとに、接続数が 100 増加します。

    • 上限は 1,000 です。

    式:

    C = min(1000, 200 + (F // 100) × 100)

    • 200 接続から開始します。

    • 予約済み送信容量が 300 MB/s 増加するごとに、接続数が 100 増加します。

    • 上限は 1,000 です。

    式:

    C = min(1000, 200 + (F // 300) × 100)

    単一のブローカーへのインターネット (SSL) TCP 接続数。

    接続周波数 (シングルノード)

    50/秒

    150/秒

    150/秒

    クライアントからサーバーへの 1 秒あたりの接続試行回数。これには、認証の失敗などの理由による失敗した接続も含まれます。

    インターネット (SSL) 接続周波数 (シングルノード)

    10/秒

    クライアントからサーバーへの 1 秒あたりのインターネット (SSL) 接続試行回数。これには、認証の失敗などの理由による失敗した接続も含まれます。

    バッチサイズ

    50 パーセンタイル (TP50) のバッチサイズが 4 KB 未満の場合は、断片化された送信と見なされます。

    送信クライアントによってメッセージがバッチ処理された後の PRODUCE リクエスト内のメッセージバッチのサイズ。バッチ処理機能を向上させるには、バージョン 2.4 以降のクライアントを使用してください。詳細については、「送信パフォーマンスの向上 (断片化された送信リクエストの削減)」をご参照ください。

    送信リクエスト周波数 (クラスター)

    • 10,000 リクエスト/秒から開始します。

    • 実際のメッセージ送信トラフィックが 20 MB/s 増加するごとに、リクエスト数が 2,000/秒増加します。

    式:

    R = 10000 + (F // 20) × 2000

    • 10,000 リクエスト/秒から開始します。

    • 予約済み送信容量が 300 MB/s 増加するごとに、リクエスト数が 5,000/秒増加します。

    式:

    R = 10000 + (F // 300) × 5000

    • 10,000 リクエスト/秒から開始します。

    • 予約済み送信容量が 60 MB/s 増加するごとに、リクエスト数が 2,000/秒増加します。

    式:

    R = 10000 + (F // 60) × 2000

    クライアントによって 1 秒あたりに送信される PRODUCE リクエストの数。

    より高いリクエスト制限が必要な場合は、チケットを送信してください。

    消費リクエスト周波数 (クラスター)

    • 5,000 リクエスト/秒から開始します。

    • 実際のメッセージ使用トラフィックが 20 MB/s 増加するごとに、リクエスト数が 1,000/秒増加します。

    式:

    R = 5000 + (F // 20) × 1000

    • 5,000 リクエスト/秒から開始します。

    • 予約済みサブスクリプション容量が 100 MB/s 増加するごとに、リクエスト数が 2,500/秒増加します。

    式:

    R = 5000 + (F // 100) × 2500

    • 5,000 リクエスト/秒から開始します。

    • 予約済みサブスクリプション容量が 20 MB/s 増加するごとに、リクエスト数が 1,000/秒増加します。

    式:

    R = 5000 + (F // 20) × 1000

    クライアントによって 1 秒あたりに送信される FETCH リクエストの数。

    より高いリクエスト制限が必要な場合は、チケットを送信してください。

    使用者オフセットコミット周波数 (シングルノード)

    • 100 リクエスト/秒から開始します。

    • 実際のメッセージ送信トラフィックが 100 MB/s 増加するごとに、リクエスト数が 100/秒増加します。

    • 上限は 1,000 リクエスト/秒です。

    式:

    R = min(1000, 100 + (F // 100) * 100)

    • 100 リクエスト/秒から開始します。

    • 予約済み送信容量が 100 MB/s 増加するごとに、リクエスト数が 100/秒増加します。

    • 上限は 1,000 リクエスト/秒です。

    式:

    R = min(1000, 100 + (F // 100) × 100)

    クライアントによって 1 秒あたりに送信される `OFFSET_COMMIT` リクエストの数。

    より高いリクエスト制限が必要な場合は、チケットを送信してください。

    メタデータリクエスト周波数 (クラスター)

    • 100 リクエスト/秒から開始します。

    • 実際のメッセージ送信トラフィックが 100 MB/s 増加するごとに、リクエスト数が 100/秒増加します。

    • 上限は 1,000 リクエスト/秒です。

    式:

    R = min(1000, 100 + (F // 100) * 100)

    • 100 リクエスト/秒から開始します。

    • 予約済み送信容量が 100 MB/s 増加するごとに、リクエスト数が 100/秒増加します。

    • 上限は 1,000 リクエスト/秒です。

    式:

    R = min(1000, 100 + (F // 100) × 100)

    サーバーがクライアントから受信するメタデータリクエストの数 (METADATA、INIT_PRODUCER_ID、CREATE_ACL、JOIN_GROUP など)。

    警告

    リクエストが多すぎると、クラスターの安定性に影響を与える可能性があります。

    最大パーティション数

    各インスタンス仕様の最大パーティション数については、「インスタンスのパーティション」をご参照ください。

    パーティションの数には、作成するさまざまな種類の Topic のパーティションが含まれます。

    より高いパーティション制限が必要な場合は、チケットを送信してください。

    パーティションの作成/削除周波数 (クラスター)

    10 秒あたり 900 パーティション

    この制限には、コンソール、OpenAPI、または Kafka Admin から開始されるすべてのパーティション操作が含まれます。

    使用者グループの数 (クラスター)

    クラスターあたり 2,000。

    推奨される Topic とグループのサブスクリプション比率は 1:1 であり、3:1 を超えてはなりません。

    使用する使用者グループの数。

    グループ数に高い制限が必要な場合は、チケットを送信してください。

    警告

    使用者グループの数が多すぎると、サーバー側の調整負荷とメタデータ管理の複雑さが増加する可能性があります。これは、パフォーマンスとエラー回復時間に影響を与える可能性があります。

    メッセージフォーマットバージョン

    メッセージの送受信には、V1 より後のメッセージフォーマットバージョンを使用する必要があります。

    バージョン 2.4 以降のクライアントを使用してください。

    警告

    古い Kafka メッセージフォーマットを使用すると、サーバー側の CPU 使用率の増加、スループットの低下、互換性やセキュリティの問題などの問題が発生する可能性があります。

    その他の制限

    • GZIP などの圧縮アルゴリズムを有効にすると、より多くのサーバーリソースが消費されます。これは、サービスのレイテンシーとスループットに影響します。

    • Producer Id を使用して多数のトランザクションを高頻度で初期化すると、メモリオーバーフローやサーバーの過負荷が発生し、安定性に影響を与える可能性があります。このため、transactional.id.expiration.ms カーネルパラメーターは 15 分に設定されています。特別な要件がある場合は、チケットを送信してください。

    • 無効なメッセージタイムスタンプのブロック: message.timestamp.type が `CreateTime` に設定されている場合、ブローカーのタイムスタンプとメッセージのタイムスタンプの差が message.timestamp.difference.max.ms パラメーターの値を超えると、ブローカーはメッセージを拒否します。この設定により、不正なタイムスタンプ構成を防ぎます。タイムスタンプが早すぎると、ログセグメントはすぐに削除されます。タイムスタンプが未来すぎると、ログセグメントは削除できません。

    • 圧縮された Topic への異常な書き込みがクラスターのストレージを埋め尽くし、ダウンタイムを引き起こすのを防ぐため、圧縮された Topic パーティションのデフォルトのストレージ制限は 5 GB です。特別な要件がある場合は、チケットを送信してください。

    • インスタンスの CPU 使用率が 85% を超えると、インスタンスクラスターの安定性に影響が及ぶ可能性があります。これにより、メッセージの送受信時にダウンタイムやロングテールレイテンシージッターなどの問題が発生する可能性があります。

    • Kafka のパフォーマンスはクラスターによってサポートされます。メッセージの送信動作やパーティションの割り当てに偏りがある場合、クラスターは完全な能力を発揮できません。

    • オープンソースのトランザクションメッセージには、多くの既知の未修正の問題があります。注意して使用してください。例については、「KAFKA-12671」をご参照ください。その他の問題の詳細については、「KAFKA ISSUES」をご参照ください。

    • Kafka は、リバランス中など、多くのシナリオでメッセージを再消費する可能性があります。再消費されたメッセージがサービスに影響を与えるのを防ぐために、消費ロジックにべき等性チェックを実装する必要があります。

    なし