Message Queue for Apache Kafka のクライアントパラメータ - ApsaraMQ for Kafka

このトピックでは、Message Queue for Apache Kafka のクライアントパラメータの設定ルールについて説明します。ビジネス要件に基づいて、これらのパラメータに適切な値を指定することをお勧めします。

次の表に、さまざまなクライアントのパラメータを示します。

表 1. プロデューサークライアントパラメータ
パラメータ	説明
retries	送信に失敗したメッセージに対して許可される再試行回数。
retry.backoff.ms	メッセージの送信に失敗した場合の再試行間隔。このパラメータを 1000 に設定することをお勧めします。単位：ミリ秒。
acks	メッセージ送信の永続化メカニズム。メッセージ送信のパフォーマンスを向上させるために、このパラメータを `1` に設定することをお勧めします。このパラメータを `0` に設定すると、ブローカーから応答は返されません。このモードでは、メッセージ送信のパフォーマンスは高いですが、データ損失のリスクも高くなります。このパラメータを `1` に設定すると、データがリーダーに書き込まれたときに応答が返されます。このモードでは、メッセージ送信のパフォーマンスとデータ損失のリスクは中程度です。リーダーで障害が発生した場合、データ損失が発生する可能性があります。このパラメータを `all` に設定すると、データがリーダーに書き込まれ、フォロワーに同期されたときに応答が返されます。このモードでは、メッセージ送信のパフォーマンスは低いですが、データ損失のリスクは低くなります。データ損失は、リーダーとフォロワーが同時に失敗した場合にのみ発生します。
batch.size	各パーティションに配信されるキャッシュされたメッセージの量。キャッシュされたメッセージの量が指定された上限に達すると、ネットワークリクエストがトリガーされます。その後、プロデューサーはメッセージをバッチでブローカーに送信します。batch.size パラメータを小さい値に設定すると、メッセージ送信のパフォーマンスと安定性に影響を与える可能性があります。デフォルト値 16384 を使用することをお勧めします。単位：バイト。
linger.ms	キャッシュ内の各メッセージの最大保存期間。メッセージが最大保存期間を超えてキャッシュに保存されている場合、プロデューサーは batch.size パラメータを使用せずに、メッセージをすぐにブローカーに送信します。ビジネス要件に基づいて、linger.ms パラメータを 100 ～ 1000 の範囲の値に設定することをお勧めします。単位：ミリ秒。
partitioner.class	パーティション分割に使用する戦略。メッセージ送信のパフォーマンスを向上させるために、スティッキーパーティション分割戦略を使用することをお勧めします。プロデューサークライアントのバージョンが 2.4 以降の場合、スティッキーパーティション分割戦略がデフォルトで使用されます。
buffer.memory	クライアントのメモリプールのサイズ。このパラメータを小さい値に設定すると、メモリを申請するために消費される時間が長くなる可能性があります。これにより、メッセージ送信のパフォーマンスが低下したり、メッセージ送信がタイムアウトしたりします。このパラメータを `batch.size パラメータの値 × パーティション数 × 2` 以上の値に設定することをお勧めします。単位：バイト。

表 2. コンシューマークライアントパラメータ
パラメータ	説明
fetch.min.bytes	コンシューマーがブローカーからプルできる最小データ量。このパラメータを設定する前に、プロデューサーによって送信されるメッセージの数を評価する必要があります。このパラメータに過度に大きい値を設定すると、コンシューマーがメッセージを消費するときにメッセージの遅延が増加する可能性があります。このパラメータに過度に小さい値を設定すると、コンシューマーがメッセージをプルする頻度が増加する可能性があります。単位：バイト。
fetch.max.wait.ms	ブローカーが応答を返すまで待機する最大時間。単位：ミリ秒。ローカルストレージを使用し、fetch.min.bytes パラメータを設定した場合、fetch.min.bytes パラメータで指定された値に達すると、ブローカーは応答を返します。fetch.max.wait.ms パラメータで指定された時間が経過すると、fetch.min.bytes パラメータで指定された値に達したかどうかに関係なく、応答が返されます。クラウドストレージを使用する場合、fetch.min.bytes パラメータで指定された時間が経過するまで待機するのではなく、新しいデータが送信されるとすぐにブローカーは応答を返します。
max.partion.fetch.bytes	各パーティションが返す最大データ量。単位：バイト。
session.timeout.ms	コンシューマーがハートビートを送信する間隔。間隔内にハートビートが送信されない場合、ブローカーはコンシューマーが停止していると判断し、リバランスがトリガーされます。リバランス中、クライアントはデータの消費を停止し、リバランスが完了するまで待機します。このパラメータを 30000 ～ 60000 の範囲の値に設定することをお勧めします。単位：ミリ秒。有効な値：6000 ～ 300000。
max.poll.records	poll() の 1 回の呼び出しで返されるメッセージの最大数。このパラメータに過度に大きい値を設定した場合、できるだけ早くメッセージ消費ロジックを処理する必要があります。メッセージ消費ロジックの処理速度が遅い場合、poll() の次の呼び出しのデータに影響します。その結果、session.timeout.ms パラメータで指定された間隔中にハートビートが送信されず、リバランスがトリガーされます。このパラメータを `<1 秒あたりに各スレッドで消費されるメッセージ数> × <メッセージを消費するスレッド数> × <session.timeout.ms パラメータで指定された値（秒）>` より小さい値に設定することをお勧めします。重要 Java Client 0.10.1 以降のバージョンでは、ハートビートの送信に別のスレッドが使用されます。以前のバージョンの Java Client または別の言語のクライアントを使用する場合は、データ処理時間とハートビート送信間隔に関連するパラメータに適切な値を指定する必要があります。これにより、頻繁なリバランスが通常の消費に影響を与えるのを防ぐことができます。
max.poll.interval.ms	poll() の呼び出し間の最大間隔。このパラメータは、Java Client 0.10.1 以降のバージョンでのみ必要です。コンシューマーが session.timeout.ms パラメータで指定された間隔中に poll() を呼び出さない場合、ブローカーはコンシューマーが停止していると判断し、リバランスがトリガーされます。したがって、このパラメータに適切な値を設定する必要があります。このパラメータを `<メッセージの消費に要する時間> × <poll() によってプルされるデータレコードの数>` より大きい値に設定することをお勧めします。ほとんどの場合、デフォルト値を使用できます。単位：ミリ秒。デフォルト値：300000。
enable.auto.commit	コンシューマーオフセットを自動的にコミットするかどうかを指定します。有効な値： true false デフォルト値：true。
auto.commit.interval.ms	コンシューマーオフセットが自動的にコミットされる間隔。デフォルト値：1000。単位：ミリ秒。
auto.offset.reset	コンシューマーオフセットのリセットに使用されるポリシー。 latest：コンシューマーオフセットを最新のオフセットにリセットします。 earliest：コンシューマーオフセットを最も古いオフセットにリセットします。 none：コンシューマーオフセットをリセットしません。説明無効なオフセットが存在する場合に、コンシューマーが最初からメッセージを消費しないように、このパラメータを earliest ではなく latest に設定することをお勧めします。これにより、コンシューマーがメッセージを繰り返し消費するのを防ぐことができます。コンシューマーオフセットを手動で管理する場合は、このパラメータを none に設定できます。