翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# MemoryDB のサービスの更新
MemoryDB は、サービスの更新が利用可能になったときに適用されるように、クラスターとノードのフリートを自動的にモニタリングします。通常、MemoryDB がこれらの更新を適用できるように、事前定義されたメンテナンスウィンドウを設定します。ただし、場合によっては、このアプローチが厳格すぎて、ビジネスフローが制限される可能性もあります。
[MemoryDB のサービスの更新](#service-updates)では、更新を適用するタイミングと内容を制御できます。選択した MemoryDB クラスターに対するこれらの更新の進行状況をリアルタイムでモニタリングすることもできます。
# サービスの更新の管理
MemoryDB のサービスの更新は定期的にリリースされています。これらのサービスの更新の対象となるクラスターが 1 つ以上ある場合は、更新がリリースされたときに、E メール、SNS、Personal Health Dashboard (PHD)、および Amazon CloudWatch Events より通知が送信されます。更新は、MemoryDB コンソールの **[サービスの更新]** ページにも表示されます。このダッシュボードを使用すると、MemoryDB フリートに関するサービスの更新とそのステータスをすべて表示できます。
自動更新を開始する前に、更新を適用するタイミングを制御します。最新のセキュリティパッチで MemoryDB を常に最新の状態に維持できるように、できるだけ早く **[セキュリティ更新]** タイプの更新を適用することを強くお勧めします。
以下のセクションでは、これらのオプションについて詳しく説明します。
**Topics**
+ [Amazon MemoryDB のマネージドメンテナンスとサービスの更新の概要](#managing-updates-maintenance)
## Amazon MemoryDB のマネージドメンテナンスとサービスの更新の概要
当社は、インスタンスにシームレスに適用されるパッチとアップグレードを使用して、頻繁に MemoryDB フリートのアップグレードを行います。これには以下の 2 つの方法があります。
1. 継続的マネージドメンテナンス。
1. サービスの更新。
このメンテナンスとサービスの更新は、セキュリティ、信頼性、運用パフォーマンスを強化するアップグレードを適用するために必要です。
継続的マネージドメンテナンスは、ユーザーのアクションを必要とせずに、メンテナンスウィンドウ内で随時、直接行われます。メンテナンスウィンドウはすべてのお客様に必須であり、オプトアウトはできないことに注意してください。この設定されたメンテナンスウィンドウ中にクリティカルな、または重要なアクティビティを行わないようにすることを強く推奨します。また、システムのセキュリティと最適なパフォーマンスを確保するために、重要な更新はスキップできないことにも注意してください。
サービスの更新では、更新を自分の判断で柔軟に適用できます。サービスの更新には期限があります。期限が切れると、更新がメンテナンスウィンドウに移動され、当社によって適用される場合があります。
更新は、できるだけ早く適用することによって適切に管理できます。また、ノードの交換によって管理することもできます。交換時に自動的に更新が適用されるからです。次回のメンテナンスウィンドウの前に更新がすべてのノードに適用されている場合、次回のメンテナンスウィンドウ中に更新アクティビティが行われることはありません。
### サービスの更新
[MemoryDB のサービスの更新](service-updates.md)では、特定のサービス更新を自分の判断で適用できます。これらの更新には、セキュリティパッチとマイナーなソフトウェア更新があります。これらの更新は、クラスターのセキュリティ、信頼性、運用パフォーマンスの強化に役立ちます。
これらのサービスの更新の価値は、更新を適用するタイミングを制御できることです (例えば、MemoryDB クラスターの 24 時間 365 日の可用性を必要とする重要なビジネスイベントがある場合には、サービス更新の適用を遅らせることができます)。
これらのサービスの更新の対象となるクラスターが 1 つ以上ある場合は、更新がリリースされたときに、E メール、[Amazon SNS](mdbevents.sns.md)、[AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)、および [Amazon CloudWatch Events](monitoring-cloudwatch.md) より通知が送信されます。更新は、MemoryDB コンソールの **[サービスの更新]** ページにも表示されます。このダッシュボードを使用すると、MemoryDB フリートに関するサービスの更新とそのステータスをすべて表示できます。
自動更新を開始する前に、更新を適用するタイミングを制御します。最新のセキュリティパッチで MemoryDB を常に最新の状態に維持できるように、できるだけ早く [セキュリティ更新] タイプの更新を適用することを強くお勧めします。
クラスターは、複数の異なるサービス更新の対象である場合があります。ほとんどの更新では、更新を個別に適用する必要はありません。クラスターに 1 つの更新を適用すると、該当する他の更新も「完了」とマークされます。ステータスが自動的に「完了」に変わらない場合は、同じクラスターに複数の更新を個別に適用する必要が生じることがあります。
#### サービスの更新による影響とダウンタイム
ユーザーまたは Amazon MemoryDB が 1 つ以上の MemoryDB クラスターにサービスの更新を適用した場合、更新は、選択したすべてのクラスターが更新されるまで、各シャード内で一度に 1 つのノードにのみ適用されます。更新中のノードでは数秒のダウンタイムが発生しますが、残りのクラスターはトラフィックを処理し続けます。
+ クラスター設定は変更されません。
+ CloudWatch メトリクスに遅延が生じますが、メトリクスは可能な限り早く追いつきます。
**ノード交換はアプリケーションにどのように影響するか?** – MemoryDB ノードの場合、交換プロセスは耐久性と可用性を保証するように設計されています。単一ノードの MemoryDB クラスターの場合、MemoryDB はレプリカを動的にスピンアップし、耐久性コンポーネントからデータを復元してから、そのレプリカにフェイルオーバーします。複数のノードで構成されるレプリケーショングループの場合、MemoryDB は既存のレプリカを交換し、耐久性コンポーネントから新しいレプリカにデータを同期します。MemoryDB は複数のノードがある場合にのみマルチ AZ であるため、このシナリオでは、プライマリを交換すると、リードレプリカへのフェイルオーバーがトリガーされます。計画されたノード交換は、クラスターが受信した書き込みリクエストを処理する間に完了します。ノードが 1 つしかない場合、MemoryDB はプライマリを交換し、耐久性コンポーネントからデータを同期します。この間、プライマリノードは使用できなくなるため、書き込みの中断が長くなります。
**交換をスムーズに行い、データ損失を最小限に抑えるには、どのようなベストプラクティスに従う必要があるか?** – MemoryDB では、データの耐久性が高いため、単一ノードの実装でさえもデータ損失は予期されません。ただし、万一障害が発生した場合の損失の可能性を最小限に抑えるため、マルチ AZ およびバックアップ戦略を実施することを推奨します。当社は、交換をスムーズに行えるようクラスターを安定した状態に維持するために、同じクラスターの必要最小限のノードの交換を試みます。マルチ AZ を有効にすると、プライマリとリードレプリカを異なるアベイラビリティーゾーンにプロビジョニングできます。この場合、ノードが交換されると、プライマリロールはシャード内のレプリカにフェイルオーバーします。このシャードはトラフィックを処理し、データはその耐久性コンポーネントから復元されます。シャードごとにプライマリとレプリカがそれぞれ 1 つしか含まれていない構成の場合は、パッチ適用の前にレプリカを追加することを推奨します。これにより、パッチ適用プロセス中の可用性の低下が防止されます。交換は受信書き込みトラフィックが少ない期間中にスケジュールすることを推奨します。
**メンテナンス中のアプリケーションの中断を最小限に抑えるには、どのようなクライアント設定のベストプラクティスに従う必要があるか?** – MemoryDB では、クラスターモード設定は常に有効になっています。これにより、マネージド型またはアンマネージド型のオペレーション中に最高の可用性が提供されます。レプリカノードの個々のノードエンドポイントは、あらゆる読み取り操作に使用できます。MemoryDB では、クラスターで常に自動フェイルオーバーが有効になっています。つまり、プライマリノードが変更される可能性があります。したがって、アプリケーションでノードのロールを確認し、すべての読み取りエンドポイントを更新することで、プライマリに大きな負荷がかからないようにする必要があります。同様に、メンテナンスウィンドウ中にレプリカが読み取りリクエストで過負荷状態になるのを回避します。これを実現する方法の 1 つは、メンテナンス中の読み取りの中断を避けるために、少なくとも 2 つのリードレプリカを用意することです。
クライアントアプリケーションをテストし、アプリケーションが Redis/Valkey クラスタープロトコルに準拠していること、およびリクエストをノード間で適切にリダイレクトできることを確認することが重要です。メンテナンスおよび交換作業中に MemoryDB ノードが過負荷状態になるのを回避するために、バックオフおよび再試行戦略を実施することを推奨します。
**再スケジュール** – [メンテナンスウィンドウ](maintenance-window.md)を変更することで、サービスの更新を延期できます。スケジュールされた更新は、スケジュールされた日付がクラスターのメンテナンスウィンドウに一致する場合にのみクラスターに適用されます。メンテナンスウィンドウを変更し、スケジュールされた日付を過ぎると、サービスの更新は、今後の週に新しく指定したウィンドウに再スケジュールされます。新しい日付の 1 週間前に新しい通知が届きます。
のセキュリティ AWS は共有責任です。更新をできるだけ早く適用することを強く推奨します。
**サービスの更新のオプトアウト **– サービスの更新をオプトアウトできるかどうかを判断するには、[自動更新開始日] 属性の値を確認します。サービスの更新の [自動更新開始日] 属性の値が設定されている場合、MemoryDB は残りのクラスターへのサービスの更新を今後のメンテナンスウィンドウにスケジュールします。これをオプトアウトすることはできません。ただし、メンテナンスウィンドウの前に残りのクラスターにサービスの更新を適用した場合、MemoryDB はメンテナンスウィンドウ中にサービスの更新を再適用しません。詳細については、「[サービスの更新の適用](applying-updates.md)」を参照してください。
**メンテナンスウィンドウ中に MemoryDB がサービスの更新を直接適用できないのはなぜか?** – サービスの更新の目的は、更新を適用するタイミングをユーザーが柔軟に決定できるようにすることです。MemoryDB がサポートする[コンプライアンス](memorydb-compliance.md)プログラムに参加していないクラスターは、これらの更新を適用しないか、年間を通じて低い頻度で適用するかを選択できます。ただし、規制への準拠を維持する更新を適用することを推奨します。これは、サービスの更新の [自動更新開始日] 属性の値が存在しない場合にのみ当てはまります。詳細については、「[MemoryDB のコンプライアンス検証](memorydb-compliance.md)」を参照してください。
**メンテナンスウィンドウで適用される更新は、サービスの更新とどのように異なるか?** – 継続的マネージドメンテナンスを介して適用された更新は、メンテナンスウィンドウに直接スケジュールされます。ユーザー側のアクションは必要ありません。サービスの更新には期限があり、ユーザーは [自動更新開始日] までに適用するタイミングを制御できます。それまでに適用されない場合、MemoryDB はメンテナンスウィンドウでこれらの更新をスケジュールすることがあります。
### 継続的マネージドメンテナンスの更新
これらの更新は必須であり、メンテナンスウィンドウに直接適用されます。ユーザー側のアクションは必要ありません。これらの更新は、サービスの更新で提供される更新とは異なります。
#### 継続的メンテナンスによる影響とダウンタイム
**ノードの交換にはどのくらいの時間がかかるか?** – 交換は通常は 30 分以内に完了します。特定のインスタンス設定やトラフィックパターンでは、交換にそれ以上の時間がかかる場合があります。
**ノード交換はアプリケーションにどのように影響するか?** – 継続的マネージドメンテナンスの更新は、ノード交換を通じて「サービスの更新」と同じ方法で適用されます。詳細については、上記の「サービスの更新による影響とダウンタイム」セクションを参照してください。
**ノード交換を自分で管理するにはどうすればよいか?** – このような交換を、スケジュールされたノード交換ウィンドウより前に、任意のタイミングで独自に管理することもできます。交換を自分で管理することを選択した場合は、ユースケースに応じてさまざまなアクションを実行できます。
+ [クラスター内のノードを 1 つ以上のシャードに交換する](nodes.nodereplacement.md): [バックアップと復元](snapshots-restoring.md)またはスケールアウト後のスケールインを使用して[ノードを交換](cluster-resharding-online.md)できます。
+ [メンテナンスウィンドウを変更する](maintenance-window.md): クラスターのメンテナンスウィンドウを変更することもできます。後でメンテナンスウィンドウをより便利な時間に変更するには、[UpdateCluster API](clusters.modify.md)、[update-cluster CLI](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) を使用するか、MemoryDB マネジメントコンソールで [[変更]](clusters.modify.md) をクリックします。メンテナンスウィンドウを変更すると、MemoryDB は新しく指定されたウィンドウ中にノードのメンテナンスをスケジュールします。
これが実際にどのように機能するか見てみましょう。今が 11/09、木曜日の 1500 とします。次のメンテナンスウィンドウは 11/10、金曜日の 1700 です。次の 3 つのシナリオがあります。
+ メンテナンスウィンドウを金曜日の 1600 に変更します (現在の日時より後で、次の予定メンテナンスウィンドウより前)。ノードは 11/10、金曜日の 1600 に置き換えられます。
+ メンテナンスウィンドウを土曜日の 1600 に変更します (現在の日時より後で、次の予定メンテナンスウィンドウより後)。ノードは 11/11、土曜日の 1600 に置き換えられます。
+ メンテナンスウィンドウを水曜日の 1600 に変更します (週の中で、現在の日時より前)。ノードは 11/15、次の水曜日の 1600 に置き換えられます。
詳細については、「[メンテナンスの管理](maintenance-window.md)」を参照してください。
さまざまなリージョンのさまざまなクラスターのノードを同時に交換できます。ただし、対象となるクラスターのメンテナンスウィンドウが同じになるように設定されていることが条件です。
**今後予定されている交換について確認するにはどうすればよいか?** - ヘルスダッシュボードで AWS ヘルス通知を受け取る必要があります。DescribeServiceUpdates API を使用して、さまざまなサービスアップグレードのステータスを確認することもできます。当社では、予測可能な交換について事前にお客様に通知するよう努めています。ただし、予測不可能な障害などの例外的なケースでは、予告なしに交換を行う可能性があります。
**スケジュールされたメンテナンスをより適切なタイミングに変更できるか?** – はい。[メンテナンスウィンドウ](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeServiceUpdates.html)を変更することで、スケジュールされたメンテナンスをより適切な時間に延期できます。
**これらのノード交換を行うのはなぜか?** – これらの交換は、基盤となるホストに必須のソフトウェア更新を適用するために必要です。これらの更新は、セキュリティ、信頼性、運用パフォーマンスの強化に役立ちます。
**これらの交換は複数アベイラビリティーゾーンのノードと異なるリージョンのクラスターに同時に影響するか?** – 交換は、クラスターのメンテナンスウィンドウに応じて、複数のアベイラビリティーゾーンまたはリージョンで並行して実行できます。
# サービスの更新の適用
フリートに対するサービスの更新の適用は、更新が **使用可能** ステータスになってから開始することができます。サービスの更新は累積的です。つまり、未適用の更新も最新の更新に含まれます。
サービスの更新で自動更新が有効になっている場合、使用可能になったときにアクションを実行しないよう選択できます。MemoryDB は、**[自動更新開始日]** 以降、クラスターのメンテナンス期間中に更新を適用するようにスケジュールします。更新のステージごとに、関連する通知を受け取ります。
**注記**
ステータスが **使用可能**または **スケジュール済み** であるサービスの更新だけを適用できます。
該当する MemoryDB クラスターへのサービス固有の更新の確認および適用の詳細については、「[コンソールを使用したサービスの更新の適用](#applying-updates-console-APIReferenceconsole)」を参照してください。
1 つ以上の MemoryDB クラスターで新しいサービス更新が利用可能になったら、MemoryDB コンソール、API、または AWS CLI を使用して更新を適用できます。次のセクションでは、更新の適用に使用できるオプションについて説明します。
## コンソールを使用したサービスの更新の適用
使用可能なサービスの更新のリストと他の情報を確認するには、コンソールの **サービスの更新** (サービスの更新) ページに移動します。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB コンソールを開きます。
1. ナビゲーションペインで、**サービスの更新**を選択します。
**[サービスの更新の詳細]** では、次の項目を表示できます。
+ **サービスの更新名**: サービスの更新の一意の名前
+ **サービスの更新名**: サービスの更新に関する詳細情報
+ **自動更新開始日**:この属性が設定されている場合、MemoryDB は、この日付以降に適切なメンテナンスウィンドウでクラスターを自動更新するようにスケジューリングを始めます。正確なスケジュールされたメンテナンスウィンドウに事前に通知が届きますが、**[自動更新開始日]** の直後のメンテナンスウィンドウではない場合があります。ただし、クラスターにはいつでもアップデートを適用できます。属性が設定されていない場合、サービスの更新は自動更新が有効になっておらず、MemoryDB はクラスターを自動的に更新しません。
**クラスターの更新ステータス**セクションでは、サービスの更新が適用されていない、または最近適用されたばかりのクラスターのリストを表示できます。クラスターごとに、以下を表示できます。
+ **クラスター名**: クラスターの名前
+ **ノードを更新しました**: 特定のクラスター内で更新された、または特定のサービスの更新に対して利用可能な状態の個々のノードの比率。
+ **更新タイプ**: サービスの更新のタイプ (**セキュリティ更新** または **エンジン更新**のいずれか)
+ **ステータス**: クラスター上のサービス更新のステータス。以下のいずれかです。
+ *使用可能*: 必要なクラスターでこの更新が利用可能です。
+ *進行中*: このクラスターに更新を適用しています。
+ *スケジュール済み*: 更新日がスケジュールされています。
+ *完了*: 更新が正常に適用されました。完了ステータスのクラスターは、完了後 7 日間表示されます。
ステータスが **使用可能**または **スケジュール済み** (スケジュール済み) であるクラスターのいずれかまたはすべてを選択してから、**今すぐ適用**を選択した場合、更新がそれらのクラスターに適用され始めます。
## を使用したサービス更新の適用 AWS CLI
サービスの更新が利用可能であるという通知を受け取ったら、 AWS CLIを使用してそれらの更新を確認し、適用することができます。
+ 利用可能なサービスの更新の説明を取得するには、次のコマンドを実行します。
`aws memorydb describe-service-updates --status available`
詳細については、「[describe-service-updates](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-service-updates.html)」を参照してください。
+ クラスターのリストにサービスの更新を適用するには、次のコマンドを実行します。
`aws memorydb batch-update-cluster --service-update ServiceUpdateNameToApply=sample-service-update --cluster-names cluster-1 cluster2`
詳細については、「[batch-update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/batch-update-cluster.html)」を参照してください。