サービスの更新の管理

MemoryDB のサービスの更新は定期的にリリースされています。これらのサービスの更新の対象となるクラスターが 1 つ以上ある場合は、更新がリリースされたときに、E メール、SNS、Personal Health Dashboard (PHD)、および Amazon CloudWatch Events より通知が送信されます。更新は、MemoryDB コンソールの [サービスの更新] ページにも表示されます。このダッシュボードを使用すると、MemoryDB フリートに関するサービスの更新とそのステータスをすべて表示できます。

自動更新を開始する前に、更新を適用するタイミングを制御します。最新のセキュリティパッチで MemoryDB を常に最新の状態に維持できるように、できるだけ早く [セキュリティ更新] タイプの更新を適用することを強くお勧めします。

以下のセクションでは、これらのオプションについて詳しく説明します。

Amazon MemoryDB のマネージドメンテナンスとサービスの更新の概要

当社は、インスタンスにシームレスに適用されるパッチとアップグレードを使用して、頻繁に MemoryDB フリートのアップグレードを行います。これには以下の 2 つの方法があります。

このメンテナンスとサービスの更新は、セキュリティ、信頼性、運用パフォーマンスを強化するアップグレードを適用するために必要です。

継続的マネージドメンテナンスは、ユーザーのアクションを必要とせずに、メンテナンスウィンドウ内で随時、直接行われます。メンテナンスウィンドウはすべてのお客様に必須であり、オプトアウトはできないことに注意してください。この設定されたメンテナンスウィンドウ中にクリティカルな、または重要なアクティビティを行わないようにすることを強く推奨します。また、システムのセキュリティと最適なパフォーマンスを確保するために、重要な更新はスキップできないことにも注意してください。

サービスの更新では、更新を自分の判断で柔軟に適用できます。サービスの更新には期限があります。期限が切れると、更新がメンテナンスウィンドウに移動され、当社によって適用される場合があります。

更新は、できるだけ早く適用することによって適切に管理できます。また、ノードの交換によって管理することもできます。交換時に自動的に更新が適用されるからです。次回のメンテナンスウィンドウの前に更新がすべてのノードに適用されている場合、次回のメンテナンスウィンドウ中に更新アクティビティが行われることはありません。

サービスの更新

MemoryDB のサービスの更新では、特定のサービス更新を自分の判断で適用できます。これらの更新には、セキュリティパッチとマイナーなソフトウェア更新があります。これらの更新は、クラスターのセキュリティ、信頼性、運用パフォーマンスの強化に役立ちます。

これらのサービスの更新の価値は、更新を適用するタイミングを制御できることです (例えば、MemoryDB クラスターの 24 時間 365 日の可用性を必要とする重要なビジネスイベントがある場合には、サービス更新の適用を遅らせることができます)。

これらのサービスの更新の対象となるクラスターが 1 つ以上ある場合は、更新がリリースされたときに、E メール、Amazon SNS、AWS Health Dashboard、および Amazon CloudWatch Events より通知が送信されます。更新は、MemoryDB コンソールの [サービスの更新] ページにも表示されます。このダッシュボードを使用すると、MemoryDB フリートに関するサービスの更新とそのステータスをすべて表示できます。

自動更新を開始する前に、更新を適用するタイミングを制御します。最新のセキュリティパッチで MemoryDB を常に最新の状態に維持できるように、できるだけ早く [セキュリティ更新] タイプの更新を適用することを強くお勧めします。

クラスターは、複数の異なるサービス更新の対象である場合があります。ほとんどの更新では、更新を個別に適用する必要はありません。クラスターに 1 つの更新を適用すると、該当する他の更新も「完了」とマークされます。ステータスが自動的に「完了」に変わらない場合は、同じクラスターに複数の更新を個別に適用する必要が生じることがあります。

サービスの更新による影響とダウンタイム

ユーザーまたは Amazon MemoryDB が 1 つ以上の MemoryDB クラスターにサービスの更新を適用した場合、更新は、選択したすべてのクラスターが更新されるまで、各シャード内で一度に 1 つのノードにのみ適用されます。更新中のノードでは数秒のダウンタイムが発生しますが、残りのクラスターはトラフィックを処理し続けます。

ノード交換はアプリケーションにどのように影響するか? – MemoryDB ノードの場合、交換プロセスは耐久性と可用性を保証するように設計されています。単一ノードの MemoryDB クラスターの場合、MemoryDB はレプリカを動的にスピンアップし、耐久性コンポーネントからデータを復元してから、そのレプリカにフェイルオーバーします。複数のノードで構成されるレプリケーショングループの場合、MemoryDB は既存のレプリカを交換し、耐久性コンポーネントから新しいレプリカにデータを同期します。MemoryDB は複数のノードがある場合にのみマルチ AZ であるため、このシナリオでは、プライマリを交換すると、リードレプリカへのフェイルオーバーがトリガーされます。計画されたノード交換は、クラスターが受信した書き込みリクエストを処理する間に完了します。ノードが 1 つしかない場合、MemoryDB はプライマリを交換し、耐久性コンポーネントからデータを同期します。この間、プライマリノードは使用できなくなるため、書き込みの中断が長くなります。

交換をスムーズに行い、データ損失を最小限に抑えるには、どのようなベストプラクティスに従う必要があるか? – MemoryDB では、データの耐久性が高いため、単一ノードの実装でさえもデータ損失は予期されません。ただし、万一障害が発生した場合の損失の可能性を最小限に抑えるため、マルチ AZ およびバックアップ戦略を実施することを推奨します。当社は、交換をスムーズに行えるようクラスターを安定した状態に維持するために、同じクラスターの必要最小限のノードの交換を試みます。マルチ AZ を有効にすると、プライマリとリードレプリカを異なるアベイラビリティーゾーンにプロビジョニングできます。この場合、ノードが交換されると、プライマリロールはシャード内のレプリカにフェイルオーバーします。このシャードはトラフィックを処理し、データはその耐久性コンポーネントから復元されます。シャードごとにプライマリとレプリカがそれぞれ 1 つしか含まれていない構成の場合は、パッチ適用の前にレプリカを追加することを推奨します。これにより、パッチ適用プロセス中の可用性の低下が防止されます。交換は受信書き込みトラフィックが少ない期間中にスケジュールすることを推奨します。

メンテナンス中のアプリケーションの中断を最小限に抑えるには、どのようなクライアント設定のベストプラクティスに従う必要があるか? – MemoryDB では、クラスターモード設定は常に有効になっています。これにより、マネージド型またはアンマネージド型のオペレーション中に最高の可用性が提供されます。レプリカノードの個々のノードエンドポイントは、あらゆる読み取り操作に使用できます。MemoryDB では、クラスターで常に自動フェイルオーバーが有効になっています。つまり、プライマリノードが変更される可能性があります。したがって、アプリケーションでノードのロールを確認し、すべての読み取りエンドポイントを更新することで、プライマリに大きな負荷がかからないようにする必要があります。同様に、メンテナンスウィンドウ中にレプリカが読み取りリクエストで過負荷状態になるのを回避します。これを実現する方法の 1 つは、メンテナンス中の読み取りの中断を避けるために、少なくとも 2 つのリードレプリカを用意することです。

クライアントアプリケーションをテストし、アプリケーションが Redis/Valkey クラスタープロトコルに準拠していること、およびリクエストをノード間で適切にリダイレクトできることを確認することが重要です。メンテナンスおよび交換作業中に MemoryDB ノードが過負荷状態になるのを回避するために、バックオフおよび再試行戦略を実施することを推奨します。

再スケジュール – メンテナンスウィンドウを変更することで、サービスの更新を延期できます。スケジュールされた更新は、スケジュールされた日付がクラスターのメンテナンスウィンドウに一致する場合にのみクラスターに適用されます。メンテナンスウィンドウを変更し、スケジュールされた日付を過ぎると、サービスの更新は、今後の週に新しく指定したウィンドウに再スケジュールされます。新しい日付の 1 週間前に新しい通知が届きます。

AWS のセキュリティは責任共有です。更新をできるだけ早く適用することを強く推奨します。

サービスの更新のオプトアウト – サービスの更新をオプトアウトできるかどうかを判断するには、[自動更新開始日] 属性の値を確認します。サービスの更新の [自動更新開始日] 属性の値が設定されている場合、MemoryDB は残りのクラスターへのサービスの更新を今後のメンテナンスウィンドウにスケジュールします。これをオプトアウトすることはできません。ただし、メンテナンスウィンドウの前に残りのクラスターにサービスの更新を適用した場合、MemoryDB はメンテナンスウィンドウ中にサービスの更新を再適用しません。詳細については、「サービスの更新の適用」を参照してください。

メンテナンスウィンドウ中に MemoryDB がサービスの更新を直接適用できないのはなぜか? – サービスの更新の目的は、更新を適用するタイミングをユーザーが柔軟に決定できるようにすることです。MemoryDB がサポートするコンプライアンスプログラムに参加していないクラスターは、これらの更新を適用しないか、年間を通じて低い頻度で適用するかを選択できます。ただし、規制への準拠を維持する更新を適用することを推奨します。これは、サービスの更新の [自動更新開始日] 属性の値が存在しない場合にのみ当てはまります。詳細については、「MemoryDB のコンプライアンス検証」を参照してください。

メンテナンスウィンドウで適用される更新は、サービスの更新とどのように異なるか? – 継続的マネージドメンテナンスを介して適用された更新は、メンテナンスウィンドウに直接スケジュールされます。ユーザー側のアクションは必要ありません。サービスの更新には期限があり、ユーザーは [自動更新開始日] を期限として適用するタイミングを制御できます。期限までに適用されない場合、MemoryDB はメンテナンスウィンドウでこれらの更新をスケジュールすることがあります。

継続的マネージドメンテナンスの更新

これらの更新は必須であり、メンテナンスウィンドウに直接適用されます。ユーザー側のアクションは必要ありません。これらの更新は、サービスの更新で提供される更新とは異なります。

継続的メンテナンスによる影響とダウンタイム

ノードの交換にはどのくらいの時間がかかるか? – 交換は通常は 30 分以内に完了します。特定のインスタンス設定やトラフィックパターンでは、交換にそれ以上の時間がかかる場合があります。

ノード交換はアプリケーションにどのように影響するか? – 継続的マネージドメンテナンスの更新は、ノード交換を通じて「サービスの更新」と同じ方法で適用されます。詳細については、上記の「サービスの更新による影響とダウンタイム」セクションを参照してください。

ノード交換を自分で管理するにはどうすればよいか? – このような交換を、スケジュールされたノード交換ウィンドウより前に、任意のタイミングで独自に管理することもできます。交換を自分で管理することを選択した場合は、ユースケースに応じてさまざまなアクションを実行できます。

今後予定されている交換について確認するにはどうすればよいか? – AWS Health Dashboard でヘルス通知を受け取る必要があります。DescribeServiceUpdates API を使用して、さまざまなサービスアップグレードのステータスを確認することもできます。当社では、予測可能な交換について事前にお客様に通知するよう努めています。ただし、予測不可能な障害などの例外的なケースでは、予告なしに交換を行う可能性があります。

スケジュールされたメンテナンスをより適切なタイミングに変更できるか? – はい。メンテナンスウィンドウを変更することで、スケジュールされたメンテナンスをより適切な時間に延期できます。

これらのノード交換を行うのはなぜか? – これらの交換は、基盤となるホストに必須のソフトウェア更新を適用するために必要です。これらの更新は、セキュリティ、信頼性、運用パフォーマンスの強化に役立ちます。

これらの交換は複数アベイラビリティーゾーンのノードと異なるリージョンのクラスターに同時に影響するか? – 交換は、クラスターのメンテナンスウィンドウに応じて、複数のアベイラビリティーゾーンまたはリージョンで並行して実行できます。