簡単な説明

Amazon Managed Streaming for Apache Kafka (Amazon MSK) では、ローリングアップデートを使用して高可用性を維持し、パッチ適用中のクラスター I/O をサポートします。このプロセス中、ブローカーは 1 つずつ再起動され、現在再起動しているブローカーのパーティションが完全に追いつく (同期中) まで、次のブローカーは再起動されません。この更新プロセス中に、クライアントで一時的な接続解除エラーが表示されるのは正常です。

セキュリティパッチの適用中にクライアントのダウンタイムが発生するのを防ぐには、次のベストプラクティスを使用してクラスターの可用性を高めてください。

解決方法

3 つの AZ クラスターをセットアップする

アベイラビリティーゾーンに障害が発生した場合、Three-AZ クラスターはダウンタイムを防ぎます。

Amazon MSK は、broker.rack ブローカープロパティを設定して、アベイラビリティーゾーンレベルでの耐障害性を実現するラック対応レプリケーション割り当てを実現します。つまり、レプリケーション係数 (RF) が 3 の 3 つの AZ クラスターを使用する場合、3 つのパーティションレプリカはそれぞれ別のアベイラビリティーゾーンにあります。

**注記:**RF-3 の Two-AZ クラスターでは、3 つのパーティションレプリカをそれぞれ別のアベイラビリティーゾーンに配置することはできません。Amazon MSK では、1 つのアベイラビリティーゾーンにクラスターを作成することはできません。

レプリケーション係数がアベイラビリティーゾーンの数であることを確認してください

セキュリティパッチ適用中にブローカーを再起動すると、リーダーが使用できなくなります。その結果、クラスタがクライアントにサービスを提供し続けることができるように、フォロワーレプリカの 1 つが新しいリーダーとして選出されます。

RF-1 では、クラスターに新しいリーダーとして昇格するレプリカがないため、ローリング更新中にパーティションが使用できなくなる可能性があります。最小同期レプリカ (miniSR) が 1 つの RF-2 では、プロデューサー確認応答 (acks) が「all」に設定されている場合でも、データが失われる可能性があります。 書き込みが成功するためには、minISR が 1 であれば、リーダーが書き込みを承認することが唯一必要とされています。リーダーレプリカのブローカーが確認後すぐにダウンし、後続レプリカが追いつく前にダウンすると、データが失われます。min.insync.replicas の詳細については、Apache Kafka ドキュメントを参照してください。

最小 minISR を最大 RF-1 に設定する

MiniSR を RF の値に設定すると、ローリングアップデートが原因で 1 つのブローカーがサービスを停止しているときに、プロデューサに障害が発生する可能性があります。レプリカからプロデューサーへの書き込み確認が送信されない場合、プロデューサーは例外を発生させます。たとえば、AZ が 3 で RF が 3 の場合、プロデューサは 3 つのパーティションレプリカすべて (リーダーを含む) がメッセージを承認するまで待ちます。ブローカーの 1 つが停止すると、3 つのパーティションのうち 2 つだけが確認応答を返すため、プロデューサー例外が発生します。

このシナリオでは、プロデューサー acks が「all」に設定されていることを前提としています。 プロデューサー acks を「all」に設定すると、少なくとも 1 つの同期レプリカが存続している限り、レコードは失われません。プロデューサーパックの詳細については、Apache Kafka ドキュメントを参照してください。

クライアント接続文字列には、各 AZ の少なくとも 1 つのブローカーを含めてください。

クライアントは、単一のブローカーのエンドポイントを使用してクラスターへの接続をブートストラップします。最初のクライアント接続中に、ブローカーはクライアントがアクセスする必要があるブローカーに関する情報を含むメタデータを送信します。

ブローカーが使用できなくなると、接続は失敗します。たとえば、クライアントの接続文字列にはブローカーが 1 つしかありません。パッチ適用中、ブローカーを再起動すると、クライアントはクラスターとの初期接続を確立できません。

または、クライアント接続文字列に複数のブローカーがあります。この場合、クライアントの接続文字列により、接続の確立に使用されたブローカーがオフラインになったときにフェイルオーバーが可能になります。複数のブローカーで接続文字列を設定する方法の詳細については、Amazon MSKクラスターのブートストラップブローカーの取得を参照してください。

再試行を許可する

ブローカーを再起動すると、そのブローカーのリーダーパーティションは使用できなくなります。その結果、Apache Kafka は別のブローカーのレプリカパーティションを新しいリーダーとして昇格させています。クライアントは、新しいリーダーパーティションを見つけるためにメタデータの更新を要求するようになりました。この変更中は、クライアントで一時的なエラーが発生するのが普通です。

デフォルトでは、クライアントにはこのような一時的なエラーを処理するための再試行が組み込まれています。クライアントがリトライ用に設定されていることを確認します。リトライの設定の詳細については、Apache Kafka ドキュメントを参照してください。