ApsaraMQ for Kafka:制限

項目

制限

説明

トピックの総数 (合計パーティション数)

制限あり

Message Queue for Apache Kafka では、ストレージと調整はパーティションレベルで行われます。トピック (または合計パーティション数) が多すぎると、ストレージの断片化が発生し、クラスターのパフォーマンスと安定性が低下する可能性があります。

トピックあたりの最小パーティション数

• サブスクリプションインスタンスと従量課金インスタンス：

  • クラウドストレージを使用するトピック： 2

  • ローカルストレージを使用するトピック： 1

• サーバーレスインスタンス：

  • クラウドネイティブストレージを使用するトピック： 1

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

トピックのパーティション数の削減

サポート対象外

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

ZooKeeper の公開

サポート対象外

Apache Kafka 0.9.0 以降、クライアントは ZooKeeper にアクセスする必要がなくなりました。Message Queue for Apache Kafka で使用される ZooKeeper は部分的に共有されており、セキュリティ上の理由から公開されていません。アプリケーションが ZooKeeper にアクセスする必要はありません。

Message Queue for Apache Kafka がデプロイされているマシンへのログイン

サポート対象外

なし。

サポート対象バージョン

2.2.x から 3.3.x

• 非サーバーレスインスタンスはバージョン 2.2.x から 2.6.x に対応しています。

• サーバーレスインスタンスはバージョン 3.3.x に対応しています。

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

パーティションとトピックの比率

1:1

利用可能なトピックの数は、パーティションの総数に直接関係します。たとえば、 alikafka.hw.2xlarge 仕様のインスタンスを購入し、50 の購入済みパーティションと 1,000 の無料パーティションがある場合、パーティションの総数は 50 + 1,000 = 1,050 となります。この場合、最大 1,050 のトピックを使用できます。

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

サポート対象外

インスタンスがデプロイされると、そのリージョンは固定され、変更できません。リージョンを変更するには、インスタンスを解放し、新しいインスタンスを購入する必要があります。

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

サポート対象

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

メッセージサイズ

10 MB

メッセージは 10 MB を超えることはできません。より大きなメッセージは拒否されます。

モニタリングとアラート

サポート対象

モニタリングデータは 1 分遅延します。

エンドポイント

購入したエディションによります

• 非サーバーレスインスタンス：

  • Standard Edition：デフォルトエンドポイントと SSL エンドポイントに対応しています。

  • Professional Edition：デフォルトエンドポイント、SSL エンドポイント、SASL エンドポイントに対応しています。

• サーバーレスインスタンス：デフォルトエンドポイント、SSL エンドポイント、SASL エンドポイントに対応しています。

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

ダウンタイムやアップグレード中に利用できなくなる可能性があります。

複数のパーティションを持つトピックを作成してください。単一のパーティションを使用する必要がある場合は、ローカルストレージを選択してください。

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

32,767

個々のメッセージが非常に小さい場合は、 batch.size を 16,384 以下の値に設定してください。

項目

制限

説明

非サーバーレスインスタンス

サーバーレス (Basic)

サーバーレス (Standard および Professional)

ハードリミット

ノードあたりの接続数

• 1,000 から開始。

• 実際の生成トラフィックが 100 MB/s 追加されるごとに 1,000 増加。

• 最大： 10,000。

計算式：

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

• 2,000 から開始。

• 予約済みの生成キャパシティが 300 MB/s 追加されるごとに 1,000 増加。

• 最大： 10,000。

計算式：

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

はい

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

接続制限を引き上げるには、してください。

制限を超えると、新しい接続の確立が遅くなり、LRU (Least Recently Used) 接続が切断されます。

ノードあたりの 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 接続数。

制限を超えると、新しい接続の確立が遅くなり、LRU (Least Recently Used) 接続が切断されます。

ノードあたりの接続確立レート

50/秒

150/秒

150/秒

はい

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

制限を超えると、新しい接続の確立が遅くなります。

ノードあたりの SSL 接続確立レート

10/秒

はい

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

制限を超えると、新しい接続の確立が遅くなります。

バッチサイズ

50 パーセンタイル (TP50) が 4 KB 未満のバッチサイズは断片化されていると見なされます。

いいえ

PRODUCE リクエスト内のメッセージバッチのサイズ。断片化されたバッチ (高頻度で小さいバッチ) は、サーバーの CPU 負荷を増加させ、クラスターの安定性に影響を与えます。バッチ処理を改善するには、クライアントバージョン 2.4 以降を使用してください。詳細については、「送信パフォーマンスの向上 (断片化されたリクエストの削減)」をご参照ください。

クラスターあたりの Produce リクエストレート

• 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 リクエストの数。リクエストレートが高いと、サーバーの CPU 負荷が増加し、クラスターの安定性に影響を与える可能性があります。

リクエスト制限を引き上げるには、してください。

クラスターあたりの FETCH リクエストレート

• 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 秒あたりのリクエスト数が 1,000 増加します。

計算式：

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

いいえ

クライアントからの 1 秒あたりの FETCH リクエストの数。リクエストレートが高いと、サーバーの CPU 負荷が増加し、クラスターの安定性に影響を与える可能性があります。

リクエスト制限を引き上げるには、してください。

ノードあたりのオフセットコミットレート

• 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 リクエストの数。リクエストレートが高いと、サーバーの CPU 負荷が増加し、クラスターの安定性に影響を与える可能性があります。

リクエスト制限を引き上げるには、してください。

クラスターあたりのメタデータリクエストレート

• 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。

最大パーティション数

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

はい

すべてのトピックにわたるパーティションの総数。制限を超えた場合、新しいトピックを作成したり、パーティションを追加したりすることはできません。

パーティション制限を引き上げるには、してください。

クラスターあたりのパーティション作成/削除レート

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

いいえ

これには、コンソール、API、または Kafka Admin ツールを介して実行されるすべてのパーティション操作が含まれます。

クラスターあたりのコンシューマーグループ数

クラスターあたり 2,000

トピックとグループの推奨サブスクリプション比率は 1:1 であり、3:1 を超えないようにしてください。

いいえ

クライアントが使用するコンシューマーグループの数。

グループ制限を引き上げるには、してください。

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

メッセージの生成と消費のためのメッセージフォーマットバージョンは V1 以降である必要があります。

はい

クライアントバージョン 2.4 以降の使用を推奨します。

無効なタイムスタンプのインターセプト

message.timestamp.type=CreateTime の場合、ブローカーは、受信時のブローカーのタイムスタンプとメッセージ内のタイムスタンプの差が、設定された message.timestamp.difference.max.ms 値を超えるとメッセージを拒否します。この設定は、不正なタイムスタンプ設定を防ぎます。タイムスタンプが過去に設定されすぎると、ログセグメントがすぐに削除される可能性があります。未来に設定されすぎると、ログセグメントがまったく削除されない可能性があります。

はい

クライアントは明確なエラー： INVALID_TIMESTAMP (32, "The timestamp of the message is out of acceptable range.") を受け取ります。

圧縮トピックのサイズ制限

圧縮トピックはデフォルトでは有効になっていません。

はい

異常な書き込みパターンがクラスターのストレージを枯渇させ、クラッシュを引き起こすのを防ぐため、圧縮トピックはデフォルトで無効になっています。

この機能が必要な場合は、チケットを起票してください。

その他の制限

• GZIP などの圧縮アルゴリズムを有効にすると、より多くのサーバーリソースが消費され、レイテンシーが増加し、スループットが低下する可能性があります。

• Producer Id を取得するために多数のトランザクションを高頻度で初期化すると、メモリ不足 (OOM) エラーやサーバーの過負荷が発生し、安定性に影響を与える可能性があります。このため、transactional.id.expiration.ms カーネルパラメーターを 60 分に調整しました。特定の要件がある場合は、してください。

• インスタンスの CPU 使用率が 85% を超えると、クラスターの安定性に影響を与え、ダウンタイムやメッセージの生成・消費におけるロングテールレイテンシーの変動などの問題が発生する可能性があります。

• Kafka のパフォーマンスはクラスターに依存します。生成動作やパーティション割り当てが偏っている場合、クラスターのキャパシティを完全に使用できない可能性があります。

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

• Kafka では、リバランス中など、さまざまなシナリオでメッセージの重複が発生する可能性があります。重複メッセージによるビジネスへの影響を防ぐため、べき等な消費ロジックを実装してください。

いいえ

なし