Apache Kafka クライアントに推奨される構成
Apache Kafka クライアント アプリケーションから Azure Event Hubs を使用する場合に推奨される構成を以下に示します。
Java クライアント構成のプロパティ
プロデューサーとコンシューマーの構成
| プロパティ | 推奨値 | 許可される範囲 | Notes |
|---|---|---|---|
metadata.max.age.ms |
180000 (概算) | < 240000 | 低くすると、メタデータの変更をすばやく取得することができます。 |
connections.max.idle.ms |
180000 | < 240000 | 240,000 ミリ秒を超えてアイドル状態の受信 TCP は Azure によって閉じられますその結果、配信不能の接続での送信が発生する可能性があります (送信タイムアウトのために期限切れのバッチとして表示されます)。 |
プロデューサーの構成のみ
プロデューサーの構成については、こちらを参照してください。
| プロパティ | 推奨値 | 許可される範囲 | Notes |
|---|---|---|---|
max.request.size |
1000000 | < 1046528 | 1,046,528 バイトを超える要求が送信されると、サービスによって接続は閉じられます。 "この値は変更する必要があり、高スループットの生成シナリオで問題が発生します。 " |
retries |
> 0 | 場合によっては、delivery.timeout.ms の値を増やす必要があります。ドキュメントを参照してください。 | |
request.timeout.ms |
30000 .. 60000 | > 20000 | Event Hubs の内部的な既定値は、最小の 20,000 ミリ秒に設定されています。 "タイムアウト値がそれより短い要求は受け入れられますが、クライアントの動作は保証されません。" request.timeout.ms が推奨値の 600,000 以上であり、session.timeout.ms が推奨値の 300,000 以上であることを確認してください。 これらの設定が低すぎると、コンシューマーがタイムアウトとなり、再調整が発生する可能性があります (これにより、より多くのタイムアウトが発生したり、より多くの再調整が発生したりします)。 |
metadata.max.idle.ms |
180000 | > 5000 | プロデューサーでアイドル状態のトピックのメタデータがキャッシュされる期間を制御します。 トピックが最後に作成されてからの経過時間がメタデータのアイドル期間を超えた場合、トピックのメタデータは忘れられ、次のアクセスでメタデータ フェッチ要求が強制的に実行されます。 |
linger.ms |
> 0 | 高スループットのシナリオでは、バッチ処理を利用するために、待機値を許容可能な最大値と等しくする必要があります。 | |
delivery.timeout.ms |
数式 (request.timeout.ms + linger.ms) * retries に従って設定します。 |
||
compression.type |
none |
現在、圧縮はサポートされていません。 |
コンシューマーの構成のみ
コンシューマーの構成については、こちらを参照してください。
| プロパティ | 推奨値 | 許可される範囲 | Notes |
|---|---|---|---|
heartbeat.interval.ms |
3000 | 既定値は 3000 であり、変更することはできません。 | |
session.timeout.ms |
30000 | 6000 .. 300000 | 30000 から開始します。ハートビートを逃したために再調整が頻繁に発生する場合は増やします。 request.timeout.ms が推奨値の 600,000 以上であり、session.timeout.ms が推奨値の 300,000 以上であることを確認してください。 これらの設定が低すぎると、コンシューマーがタイムアウトとなり、再調整が発生する可能性があります (これにより、より多くのタイムアウトが発生したり、より多くの再調整が発生したりします)。 |
max.poll.interval.ms |
300000 (既定値) | >session.timeout.ms | 再調整タイムアウトに使用されるため、低すぎる設定にしないでください。 session.timeout.ms より大きくする必要があります。 |
librdkafka の構成プロパティ
メインの librdkafka 構成ファイル (リンク) には、以下のプロパティの詳細な説明が含まれています。
プロデューサーとコンシューマーの構成
| プロパティ | 推奨値 | 許可される範囲 | Notes |
|---|---|---|---|
socket.keepalive.enable |
true | 接続がアイドル状態になることが予想される場合に必要です。 240,000 ミリ秒を超えてアイドル状態の受信 TCP は Azure によって閉じられます。 | |
metadata.max.age.ms |
~ 180000 | < 240000 | 低くすると、メタデータの変更をすばやく取得することができます。 |
プロデューサーの構成のみ
| プロパティ | 推奨値 | 許可される範囲 | メモ |
|---|---|---|---|
retries |
> 0 | 既定値は 2147483647 です。 | |
request.timeout.ms |
30000 .. 60000 | > 20000 | Event Hubs の内部的な既定値は、最小の 20,000 ミリ秒に設定されています。 librdkafka の既定値は 5000 であり、問題が発生する可能性があります。 "タイムアウト値の低い要求は受け入れられますが、クライアントの動作は保証されません。 " |
partitioner |
consistent_random |
librdkafka のドキュメントを参照してください | consistent_random は既定値であり、最適です。 空のキーと null キーは、ほとんどの場合に最適に処理されます。 |
compression.codec |
none |
圧縮は現在サポートされていません。 |
コンシューマーの構成のみ
| プロパティ | 推奨値 | 許可される範囲 | Notes |
|---|---|---|---|
heartbeat.interval.ms |
3000 | 既定値は 3000 であり、変更することはできません。 | |
session.timeout.ms |
30000 | 6000 .. 300000 | 30000 から開始します。ハートビートを逃したために再調整が頻繁に発生する場合は増やします。 |
max.poll.interval.ms |
300000 (既定値) | >session.timeout.ms | 再調整タイムアウトに使用されるため、低すぎる設定にしないでください。 session.timeout.ms より大きくする必要があります。 |
その他の注意事項
構成に関連する一般的なエラー シナリオについては、次の表を確認してください。
| 現象 | 問題 | 解決策 |
|---|---|---|
| 再調整によるオフセット コミットの失敗 | poll() の呼び出しの間にコンシューマーが待機する時間が長すぎて、サービスによってコンシューマーがグループから削除されます。 | いくつかのオプションがあります。
|
| 高生成スループットでのネットワーク例外 | Java クライアント + 既定の max.request.size を使用していますか。 要求が大きすぎる可能性があります。 | 上記の Java 構成を参照してください。 |
次のステップ
すべての Azure サービスのクォータと制限については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。