Apache Kafka クライアントに推奨される構成
Apache Kafka クライアント アプリケーションから Azure Event Hubs を使用する場合に推奨される構成を以下に示します。
Java クライアント構成のプロパティ
プロデューサーとコンシューマーの構成
| プロパティ | 推奨値 | 許可される範囲 | Notes |
|---|---|---|---|
metadata.max.age.ms |
180000 (概算) | < 240000 | 低くすると、メタデータの変更をすばやく取得することができます。 |
connections.max.idle.ms |
180000 | < 240000 | Azure では、受信送信制御プロトコル (TCP) アイドル状態 > 240,000 ミリ秒を閉じます。この場合、送信タイムアウトのため、送信が停止した接続で送信される可能性があります (期限切れのバッチとして表示されます)。 |
プロデューサーの構成のみ
プロデューサーの構成については、こちらを参照してください。
| プロパティ | 推奨値 | 許可される範囲 | Notes |
|---|---|---|---|
max.request.size |
1000000 | < 1046528 | 1,046,528 バイトを超える要求が送信されると、サービスは接続を閉じます。 この値 must 変更され、高スループットの生成シナリオで問題が発生します。 |
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 |
uncompressed, gzip |
現在、gzip 圧縮のみがサポートされています。 |
コンシューマーの構成のみ
コンシューマーの構成については、こちらを参照してください。
| プロパティ | 推奨値 | 許可される範囲 | 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 構成ファイル (link) には、次のセクションで説明するプロパティの拡張説明が含まれています。
プロデューサーとコンシューマーの構成
| プロパティ | 推奨値 | 許可される範囲 | Notes |
|---|---|---|---|
socket.keepalive.enable |
true | 接続がアイドル状態になることが予想される場合に必要です。 Azure では、受信 TCP アイドル > 240,000 ミリ秒を閉じます。 | |
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, gzip |
現在、gzip 圧縮のみがサポートされています。 |
コンシューマーの構成のみ
| プロパティ | 推奨値 | 許可される範囲 | 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 サブスクリプションとサービスの制限、クォータ、制約」を参照してください。