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

パッチ適用

MSK プロビジョニングされたクラスターへのパッチ適用

Amazon は、クラスター内のブローカーのソフトウェアを定期的にMSK更新します。メンテナンスには、計画的な更新または計画外の修復が含まれます。計画されたメンテナンスには、オペレーティングシステムの更新、セキュリティの更新、証明書の更新、およびクラスターのヘルス、セキュリティ、パフォーマンスを維持するために必要なその他のソフトウェアの更新が含まれます。計画外のメンテナンスを実行して、インフラストラクチャの突然の劣化を解決します。Standard ブローカーと Express ブローカーでメンテナンスを実行しますが、エクスペリエンスは異なります。

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

標準ブローカーの更新は、ベストプラクティスに従っていても、アプリケーションの書き込みと読み取りには影響しません。

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

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

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

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

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

Express ブローカーのメンテナンスウィンドウはありません。Amazon は、時間分散方式でクラスターを継続的にMSK更新します。つまり、1 か月間にブローカーが時折再起動されることが予想されます。これにより、クラスター全体の 1 回限りのメンテナンス期間に計画や対応を行う必要がなくなります。リーダーシップはリクエストを処理し続ける他のブローカーに変更されるため、ブローカーの再起動中もトラフィックは中断されません。

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

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

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