ApsaraMQ for Kafka:制限事項

制限事項

制限値

説明

Topic の最大数 (合計パーティション数)

サポートされています

ApsaraMQ for Kafka は、パーティションレベルでデータを保存し、調整します。Topic やパーティションが多すぎると、ストレージの断片化が発生し、クラスターのパフォーマンスと安定性が低下します。

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

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

  • Topic：クラウドストレージ。最小値：2。

  • ローカル記憶域の場合、Topic 設定の最小値は 1 です。

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

  • この Topic はクラウドネイティブストレージを対象としており、最小値は 1 です。

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

Topic のパーティション数を減らす

サポートされていません

これは Apache Kafka の設計による制限です。

ZooKeeper の公開

サポートされていません

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

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

サポートされていません

なし。

バージョン

2.2.x から 3.3.x

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

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

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

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

1:1

利用可能な Topic 数は、パーティションの総数と同じです。たとえば、50 パーティションのインスタンスを購入し、alikafka.hw.2xlarge トラフィックスペックを選択して、1,000 の無料パーティションを受け取った場合、合計パーティション数は 50 + 1,000 = 1,050 となります。したがって、最大 1,050 の Topic を作成できます。

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

サポートされていません

購入およびデプロイ後、インスタンスのリージョンは物理リソースに密接にバインドされているため、変更できません。別のリージョンを使用するには、インスタンスをリリースして新しいインスタンスを購入してください。

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

サポートされています

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

メッセージサイズ

10 MB

メッセージは 10 MB を超えてはなりません。より大きなメッセージは送信に失敗します。

監視とアラート

サポートされています

データには 1 分の遅延があります。

アクセスポイント

購入仕様

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

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

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

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

単一パーティションのクラウドストレージ

故障やアップグレード中に利用できなくなる可能性があります

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

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

32,767

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

制限事項

条件

説明

サブスクリプションインスタンスおよび時間単位の従量課金インスタンス

サーバーレス (Basic Edition)

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

ノードあたりの接続数

• 基本接続数：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 接続数。

接続上限の引き上げを申請するには、チケットを送信してください。

ノードあたりのインターネット (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 接続数。

ノードあたりの 1 秒あたりの接続試行回数

50 回/秒

150 回/秒

150 回/秒

認証エラーによる失敗した試行を含む、クライアントからサーバーへの 1 秒あたりの接続試行回数。

ノードあたりの 1 秒あたりのインターネット (SSL) 接続試行回数

10 回/秒

認証エラーによる失敗した試行を含む、クライアントからサーバーへの 1 秒あたりのインターネット (SSL) 接続試行回数。

バッチサイズ

バッチサイズの 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 を超えないようにしてください。

使用されるコンシューマーグループの数。

より高い制限をリクエストするには、してください。

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

produce および consume 操作の両方で、メッセージフォーマットバージョンは V1 より大きい必要があります。

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

その他の制限

• GZIP などの圧縮アルゴリズムを有効にすると、サーバーリソースの消費量が増え、レイテンシーが増加し、スループットが低下します。

• トランザクション Producer Id の頻繁な初期化は、メモリオーバーフローやサーバーの過負荷を引き起こし、安定性に影響を与える可能性があります。カーネルパラメーター transactional.id.expiration.ms は 15 分に設定されています。特別な要件がある場合は、してください。

• 無効なメッセージタイムスタンプはブロックされます。message.timestamp.type=CreateTime の場合、ブローカーは、受信タイムスタンプとメッセージタイムスタンプの差が message.timestamp.difference.max.ms を超えるとメッセージを拒否します。これにより、不正なタイムスタンプ設定を防ぎます。タイムスタンプが小さすぎると LogSegment が即座に削除され、大きすぎると削除が妨げられます。

• コンパクト Topic への異常な書き込みによるストレージの枯渇を防ぐため、コンパクト Topic パーティションあたりのデフォルトのストレージ制限は 5 GB です。特別な要件がある場合は、してください。

• インスタンスの CPU 使用率が 85% を超えると、故障や、produce または consume 操作におけるロングテールレイテンシージッターなどの不安定性を引き起こす可能性があります。

• Kafka のパフォーマンスはクラスターリソースに依存します。メッセージの配信やパーティションの割り当てが偏っていると、クラスターの容量を最大限に活用できません。

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

• Kafka はリバランス中に重複したメッセージを配信する可能性があります。ビジネスへの影響を避けるため、消費ロジックにべき等性チェックを実装してください。

なし