再試行

Kafka クライアントは再接続ロジックを提供しますが、プロデューサーに対して明示的に再接続を有効にする必要があります。 詳細については 、 retries プロパティを参照してください。 接続は 60 秒以内に再接続されます。

重複

再試行を有効にすると、メッセージが重複する可能性があります。 接続が失われたタイミングによっては、プロデューサーはメッセージがサーバーによって正常に処理されたかどうかを判断できない場合があるため、再接続時にメッセージを再度送信する必要があります。 重複メッセージを予期するようにアプリケーションを設計します。

重複を許容できない場合は、idempotentプロデューサー機能 ( Kafka 1.1 以降) を使用して、再試行中に重複が発生しないようにすることができます。 詳細については 、 enable.idempotence プロパティを参照してください。

標準プランの具体的なガイダンス

スループットのガイダンス情報については、制限と割り当て量 - 標準を参照してください。

エンタープライズ・プランの具体的なガイダンス

スループットのガイド情報は、制限と割り当て量 - エンタープライズを参照してください。

測定

アプリケーションのパフォーマンスを把握するために、アプリケーションを装備します。 例えば、送受信されたメッセージの数、メッセージ・サイズ、および戻りコードなどです。 アプリケーションの使用状況を理解すると、トピックに関するメッセージの保存期間など、リソースを適切に構成するのに役立ちます。

彩度

クラスターに生成できるトラフィックの限度に近づくと、プロデューサーがスロットルされ始め、待ち時間が増加し、最終的にタイムアウト・エラーなどのエラーが発生します。 構成によっては、メッセージの一貫性と耐久性も影響を受ける可能性があります。 詳しくは、メッセージの一貫性と耐久性を参照してください。

プロデューサーacksモード

すべてのメッセージが複製されますが、アプリケーションは、プロデューサーのモードプロパティである acks を使用することで、生成したメッセージがサービスに転送される際の堅牢性を制御することができます。 このプロパティーによって、スピードを取るかメッセージ損失のリスクを取るかを選択できます。 Kafka 3.0では、デフォルトのクライアント設定は acks=all (このバージョンより前は acks=1 でした) です。 acks=all の設定は、接続先のブローカーとクラスター内の少なくとも 1 つのブローカーの両方がメッセージの受信を確認するとすぐに、プロデューサーが成功を返すことを意味します。 acks=all を使用する利点は、最高レベルの耐久性を提供し、メッセージ・データの損失に対する保護を提供することです。

同期レプリカ

Event Streams が使用する構成では、 Kafka は、各パーティション・レプリカのリーダーになるブローカーを 1 つ選択し、フォロワーになるブローカーを 2 つ選択します。 クライアントからのメッセージ・データは、パーティションのリーダーに送信され、フォロワーに複製されます。 フォロワーがリーダーについている場合、それらのフォロワーは「同期」レプリカと見なされます。 リーダーは、定義上、常に同期していると見なされます。

おそらく保守がブローカーに適用されているためにパーティションのリーダーが使用不可になった場合、 Kafka は自動的に他の同期レプリカのいずれかを選択して、新しいリーダーになります。 このプロセスは迅速に行われ、 Kafka クライアントによって自動的に処理されます。

クリーンでないリーダーの選挙

Event Streams は、クリーンでないリーダー選択を無効にします。 この設定は変更できません。

クリーンでないリーダーの選出 という用語は、パーティションのすべての同期レプリカが使用不可になった場合に、 Kafka がどのように対応するかを示しています。 クリーンでないリーダー選択が有効になっている場合、 Kafka は、同期しているかどうかに関係なく、パーティションのリーダーとして使用可能になる最初のレプリカを作成することによってリカバリーします。 これにより、リーダーとして選出されたレプリカが前のリーダーからすべてのメッセージ・データを複製していない場合、メッセージ・データが失われる可能性があります。 クリーンでないリーダー選択が無効になっている場合 ( Event Streamsの場合と同様)、 Kafka は同期レプリカが使用可能になるのを待機し、そのレプリカがパーティションの新しいリーダーになることを選択します。 これにより、クリーンでないリーダー選択が有効になっている場合に発生する可能性があるメッセージ・データ損失の可能性を回避できます。 トレードオフとして、リカバリーにかかる時間が長くなることがあります。これは、 Kafka が特定のブローカーがオンラインに戻るのを待機してからでないと、クライアントがメッセージ・データを生成してコンシュームできないことがあるためです。