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

サービスの更新の管理

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 ダッシュボード、Amazon CloudWatch Events イベントを通じて通知を受け取ります。更新は、MemoryDB コンソールの [サービスの更新] ページにも表示されます。このダッシュボードを使用すると、MemoryDB フリートに関するサービスの更新とそのステータスをすべて表示できます。

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

クラスターは、異なるサービス更新の一部である可能性があります。ほとんどの更新では、個別に適用する必要はありません。クラスターに 1 つの更新を適用すると、他の更新は必要に応じて完了としてマークされます。ステータスが自動的に「完了」に変わらない場合は、同じクラスターに複数の更新を個別に適用する必要がある場合があります。

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

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

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

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

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

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

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

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

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

メンテナンスウィンドウ中に MemoryDB がサービスの更新を直接適用できないのはなぜですか？ - サービスの更新の目的は、いつ適用するかを柔軟にすることです。MemoryDB がサポートするコンプライアンスプログラムに参加していないクラスターは、これらの更新を適用しないか、1 年を通じて低い頻度で適用するかを選択できます。ただし、規制に準拠し続けるために更新を適用することをお勧めします。これは、サービス更新の「自動更新開始日」属性の値が存在しない場合にのみ当てはまります。詳細については、「MemoryDB のコンプライアンス検証」を参照してください。

メンテナンスウィンドウの更新は、サービスの更新とどのように異なりますか？ - 継続的マネージドメンテナンスによって適用された更新は、ユーザー側のアクションなしで、メンテナンスウィンドウに直接スケジュールされます。サービスの更新は時間指定され、「自動更新の開始日」までにいつ適用するかを制御できます。それでも適用されない場合、MemoryDB はメンテナンスウィンドウでこれらの更新をスケジュールすることがあります。

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

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

継続的なメンテナンスの影響とダウンタイム

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

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

ノード交換を自分で管理するにはどうすればよいですか？ - これらの置換は、スケジュールされたノード置換ウィンドウの前にいつでも自分で管理できます。置き換えを自分で管理することを選択した場合は、ユースケースに応じてさまざまなアクションを実行できます。

予定されている交換について調べるにはどうすればよいですか？ - ヘルスダッシュボードで AWS ヘルス通知を受け取る必要があります。また、DescribeServiceUpdates API を使用して、さまざまなサービスアップグレードのステータスを確認することもできます。予測可能な代替品について事前にお客様に通知するよう努めています。ただし、予測不可能な障害などの例外的なケースでは、予告なく置き換えられる可能性があります。

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

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

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