翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

MSK プロビジョンド クラスターへのパッチ適用

Amazon MSK は、定期的に クラスター 内のブローカーのソフトウェアを更新します。メンテナンスには、計画的な更新または計画外の修復が含まれます。計画メンテナンスには、クラスター の健全性、セキュリティ、およびパフォーマンスを維持するために必要なオペレーティングシステムの更新、セキュリティ更新、その他のソフトウェア更新が含まれます。予期せぬインフラの劣化を解決するため、計画外のメンテナンスを実施します。標準 ブローカーと Express ブローカーでメンテナンスを実行しますが、その体験は異なります。

標準ブローカーへのパッチ適用

ベストプラクティス に従っている場合、標準ブローカーの更新はアプリケーションの書き込みおよび読み取り操作に影響を与えません。

Amazon MSK では、ソフトウェアのローリング更新を使用してクラスターの高可用性を維持します。このプロセス中、ブローカーは一度に 1 つずつ再起動され、Kafka により自動的にリーダーシップが別のオンラインブローカーに移行されます。Kafka クライアントには、パーティションのリーダーシップの変更を自動的に検出し、MSK クラスターへのデータの書き込みと読み取りを継続するメカニズムが組み込まれています。パッチ適用中を含め、クラスターを常に円滑に動作させるにはApache Kafka クライアントのためのベストプラクティスに従ってください。

ブローカーがオフラインになった後、クライアントで一時的な切断エラーが表示されるのは正常です。また、短い期間 (最大 2 分、通常これより短い) で p99 の読み取りおよび書き込みレイテンシー (通常高いミリ秒、最大約 2 秒) の急増が見られます。これらの急増は予想され、クライアントが新しいリーダーブローカーに再接続することによって引き起こされます。また、生成や消費には影響せず、再接続後に解決されます。詳細については、「ブローカーのオフラインおよびクライアントフェイルオーバー」を参照してください。

また、シャットダウンされたブローカーのパーティションがデータを複製しなくなったため、メトリクス UnderReplicatedPartitions の増加も見られます。これは、他のブローカーでホストされているこれらのパーティションのレプリカとしてのアプリケーションの書き込みと読み取りには影響しません。これらのブローカーは現在、リクエストを提供しています。

ソフトウェアの更新後、ブローカーがオンラインに戻ったら、オフライン中に生成されたメッセージを「キャッチアップ」する必要があります。キャッチアップ中に、ボリュームスループットと CPU の使用率の増加も見られる場合もあります。ブローカーに十分な CPU、メモリ、ネットワーク、ボリュームリソースがある場合、これらはクラスターへの書き込みと読み取りには影響しません。

Express ブローカーのパッチ適用

Express ブローカーにメンテナンスウィンドウはありません。Amazon MSK は、継続的に時間配分されたタイミングでクラスターを自動的に更新します、これにより、月内に単発のブローカー再起動が時折発生することが予想されます。これにより、クラスタ全体の定期メンテナンス期間に合わせて計画や調整を行う必要がなくなります。同様に、リクエストを処理する他のブローカーにリーダーシップが変わるため、ブローカーの再起動中もトラフィックは中断されません。ブローカーの再起動中も、リーダーシップが他のブローカーに移行し、リクエスト処理を継続するため、トラフィックは、常に中断することはありません。

Express ブローカーは、ベストプラクティスの設定と ガードレール が事前に設定されており、メンテナンス中に発生する可能性のある負荷変化に対して クラスター の耐性を高めます。Amazon MSK は、ブローカーの再起動時に問題を引き起こす可能性のある クラスター の過負荷の影響を軽減するため、Express ブローカーの スループット クォータを設定します。これらの改善により、Express ブローカーを使用する際の事前通知、計画、およびメンテナンスウィンドウが不要になります。

Express ブローカーは常にデータを 3 重に複製するため、クライアントは再起動時に自動的にフェイルオーバーします。レプリケーション係数が 1 または 2 に設定されていても、トピックが使用できなくなるような心配はありません。また、再起動後の Express ブローカーは、標準ブローカーに比べてキャッチアップが高速です。Express ブローカーにおける高速パッチ適用により、 クラスター にスケジュールした コントロールプレーン アクティビティの計画的な中断を最小限に抑えることができます。

すべての Apache Kafka アプリケーションと同様に、Express ブローカーに接続するクライアントには、依然として共有クライアント-サーバー契約が存在します。ブローカー間のリーダーシップフェイルオーバーを処理できるようクライアントを設定することは、依然として極めて重要です。クラスターを常にApache Kafka クライアントのためのベストプラクティス円滑に操作するため、パッチ適用時を含め、以下の手順に従ってください。ブローカーの再起動後、クライアント側で一時的な切断エラーが発生するのは正常な動作です。これにより、フォロワーブローカーがパーティションのリーダーシップを引き継ぐため、生産と消費には影響しません。Apache Kafka クライアントは自動的にフェイルオーバーし、新しいリーダーブローカーへのリクエストの送信を開始します。