重要
このページの日本語コンテンツは古くなっている可能性があります。最新の英語版コンテンツをご覧になるには、こちらをクリックしてください。
可用性のための最適化¶
高可用性のために最適化するには、障害状況からできる限り速くリカバリできるように Kafka アプリケーションをチューニングする必要があります。
このページの構成パラメーターには、広範囲の値が指定できるものがあります。設定できる値は、必要な要件や、メッセージの平均サイズ、パーティション数といったその他の要因、さらには環境内で生じる他のさまざまな差によって影響を受けます。したがって、ベンチマークテスト を行うとアプリケーションおよび環境の構成の検証に役立ちます。
最小同期レプリカ数¶
プロデューサーで acks=all
または acks=-1
を設定した場合は、構成パラメーター min.insync.replicas
で、書き込みが成功したと見なされるために、書き込みの確認応答を返さなければならない最小レプリカ数を指定します。この最小数が満たされない場合、プロデューサーでは例外が生成されます。ISR が少ない場合、この最小値が高いほどプロデューサーの送信が失敗する可能性が高くなり、パーティションの可用性が低下します。一方で、この値を低く設定すると(たとえば、min.insync.replicas=1
など)、システムはより多くのレプリカの失敗を許容できます。レプリカ数の最小数が満たされている限り、プロデューサーのリクエストは成功し続け、パーティションの可用性は向上します。
コンシューマーの失敗¶
コンシューマーグループ内のコンシューマーは、処理の負荷を分担できます。あるコンシューマーが予期せず失敗した場合、Kafka はその失敗を検出し、コンシューマーグループ内の残りのコンシューマー間でパーティションのバランス調整を行います。コンシューマーの失敗は、ハード側の障害(SIGKILL
など)の場合もあればソフト側の障害(セッションタイムアウトの満了など)の場合もあります。これらの障害は、コンシューマーがハートビートを送信できない場合、または poll()
呼び出しを送信できない場合に検出されることがあります。コンシューマーの存続は、ハートビートによって(KIP-62 以降はバックグラウンドスレッドで)維持されます。構成パラメーター session.timeout.ms
で、失敗したハートビートを検出するために使用するタイムアウトを指定します。ネットワーク遅延の可能性を考慮してソフト障害を回避するためには、セッションタイムアウトの値を増やしてください。ソフト障害が最もよく発生するのは、長すぎて処理できないメッセージのバッチが poll()
から返された場合や、JVM/Java 仮想マシン GC の一時停止が長すぎる場合の 2 つのケースです。メッセージ処理に非常に時間がかかる poll()
ループがある場合は、以下のいずれかを実行することができます。
max.poll.interval.ms
を使用して、コンシューマーが他のレコードをフェッチする前にアイドル状態でいられる時間の上限を引き上げます。max.poll.records
構成パラメーターを使用して、バッチの最大サイズを減らします。
セッションのタイムアウト値を長くすると、コンシューマーの失敗を検出してリカバリするための時間が増えますが、クライアントが失敗するインシデントは、ネットワークの問題と比べてあまり発生しません。
タスク処理ステートのリストア¶
最後に、イベントストリーミングアプリケーションのインスタンス間でタスクを移動して負荷分散を再調整するときに、アプリケーションインスタンスが処理を回復する前のタスク処理ステートの復元にかかる時間を少なくすることができます。Kafka Streams では、対応する changelog トピックを再生してステートストアを再構成することで、ステートのリストア を実行できます。構成パラメーター num.standby.replicas
を設定すると、アプリケーションでローカルのステートストアを複製して、changelog に基づくリストアの時間を最小にすることができます。これにより、ストリームタスクを初期化するとき、またはアプリケーションインスタンスを再初期化するときに、ステートストアはそれに応じて最新のスナップショットに復元されます。
- ローカルのステートストアが存在しない場合は(
num.standby.replicas=0
)、最も古いオフセットから changelog が再生されます。 - ローカルのステートストアが存在する場合は(
num.standby.replicas
が 0 よりも大きい)、changelog は前回チェックポイントが設定されたオフセットから再生されます。このメソッドは、changelog の比較的小さな部分に適用されるため、かかる時間が少なくなります。