Apache Kafka クライアント アプリケーションから Azure Event Hubs を使用する場合に推奨される構成を以下に示します。
Java クライアント構成のプロパティ
プロデューサーとコンシューマーの構成
| プロパティ | 推奨値 | 許可される範囲 | Notes |
|---|---|---|---|
metadata.max.age.ms |
180000 (概算) | < 240000 | 低くすると、メタデータの変更をすばやく取得することができます。 |
connections.max.idle.ms |
180000 | < 240000 | Azureは受信する伝送制御プロトコル(TCP)のアイドルを240,000ms > 閉じます。これにより、送信タイムアウトのため期限切れのバッチとして表示されるデッド接続で送信されることがあります。 |
プロデューサーの構成のみ
プロデューサーの構成については、こちらを参照してください。
| プロパティ | 推奨値 | 許可される範囲 | 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 ミリ秒以上です。 プロデューサーのタイムアウトは10,000ms程度の値で安全で、プロデューサーにとって問題にはなりません。 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, 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 | 低くすると、メタデータの変更をすばやく取得することができます。 |
プロデューサーの構成のみ
| プロパティ | 推奨値 | 許可される範囲 | Notes |
|---|---|---|---|
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 サブスクリプションとサービスの制限、クォータ、制約」を参照してください。