Amazon ElastiCache マネージドメンテナンスとサービス更新のヘルプページ

概要

Amazon ElastiCache フリートは頻繁にアップグレードされており、パッチやアップグレードがシームレスにインスタンスに適用されます。これは、次の 2 つの方法のいずれかで行います。

(a) 継続的な管理メンテナンスの更新、(b) サービス更新。これらのメンテナンスとサービスの更新は、セキュリティ、信頼性、運用パフォーマンスを強化するアップグレードを適用するために必要となります。

継続的な管理メンテナンスは、お客様からのアクションを必要とせずに、時々メンテナンス期間中に直接行われます。
サービス更新により、ご自身で適用できる柔軟性が得られます。時限があるため、メンテナンス期間に移動して、期日が過ぎた後に適用される場合があります。

予定されたメンテナンス期間に先駆けて、いつでもご自身で更新を管理することもできます。更新をご自身で管理する場合、インスタンスの OS 更新はノードの再作成時に行われ、予定されていたメンテナンス期間はキャンセルされます。

ページトピック

サービス更新
23
継続的な管理メンテナンスの更新
11

サービス更新

サービス更新は、Amazon ElastiCache の機能であり、特定のサービス更新をお客様の裁量で適用することを可能にします。これらの更新には、セキュリティパッチまたはマイナーソフトウェア更新タイプがあります。これらの更新によってクラスターのセキュリティ、信頼性、運用パフォーマンスが強化されます。

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

各サービス更新の詳細については、[更新の説明] 属性の値をご覧ください。

クラスターに適用可能なサービス更新が利用可能になると、Amazon ElastiCache コンソール、E メール、Amazon Simple Notification Service (SNS)、AWS Personal Health Dashboard、Amazon CloudWatch Events など、複数のチャネルを介して通知されます。

継続的な管理メンテナンスを介して利用可能な更新は、サービス更新によって提供される更新とは別のものです。継続的な管理メンテナンスを介して適用された更新は、メンテナンス期間に直接スケジュールされるため、ユーザー側からのアクションは必要ありません。サービス更新には時限があり、[推奨される日付による適用] によって適用するタイミングを制御できます。それでもまだ適用されない場合、ElastiCache はメンテナンス期間中にこれらの更新をスケジュールすることがあります。

ElastiCache クラスターが HIPAA、PCI、または FedRAMP コンプライアンスプログラムに参加している場合、コンプライアンスを維持するために、[推奨される日付による適用] までにサービス更新を適用する必要があります。詳細については、「Self-Service Security Updates for Compliance」をご覧ください。

他のクラスターについては、ビジネス頻度によってサービス更新を適用することをお勧めします。[推奨される日付による適用] までにサービス更新を適用できない場合でも、[更新の有効期限] までは適用できます。ただし、[更新の有効期限] は、新しい更新の可用性に応じていつでも変更できます。

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

  • クラスター設定に変更はありません。
  • CloudWatch メトリクスには遅れが発生しますが、遅れはすぐに取り戻します。

サービス更新は「継続的なマネージドメンテナンスの更新」と同じ方法で、ノードの置換を通じて適用されます。更新の適用方法や、アプリケーションへの影響を最小限に抑えるための準備の詳細については、このページの「継続的なマネージドメンテナンスの更新」セクションの次の質問をご覧ください。

  • Q: ノードの置換はアプリケーションにどのような影響を与えますか?
  • 置換を順調に実施し、データ損失を最小限に抑えるために、どのようなベストプラクティスに従えばよいですか?
  • メンテナンス中にアプリケーションの中断を最小化するためのクライアント設定のベストプラクティスは何ですか?

はい、ノードは新しい空のノードに置き換えられます。キャッシュの内容はもう存在せず、新たに始まります。

[有効期限以降に自動更新] 属性の値を確認することで、サービス更新をオプトアウトできるかどうかを判断できます。サービス更新の [有効期限以降に自動更新] 属性の値が [いいえ] である場合、このサービス更新はオプトアウトできます。ただし、サービス更新の [有効期限以降に自動更新] 属性の値が [はい] で、推奨される [日付による適用] を過ぎている場合、ElastiCache は今後のメンテナンスウィンドウ中に残りのクラスターに対するサービス更新を自動的にスケジュールします。この自動サービス更新は、[更新の有効期限] の前にスケジュールされ、更新の 1 週間前に予定時刻が記載された通知が届きます。オプトアウトできる場合でも、セキュリティアップデートを適用することを強くお勧めします。  メンテナンス期間より前に残りのクラスターにサービス更新を適用することを選択すると、ElastiCache はメンテナンス期間中にサービス更新を再適用しません。

サービス更新の目的は、適用するタイミングを柔軟に決めることです。ElastiCache がサポートするコンプライアンスプログラムに参加していないクラスターは、これらの更新を適用しないか、一年を通して頻度を減らして適用するかを選択できます。これは、サービス更新の [有効期限以降に自動更新] 属性の値が [いいえ] の場合にのみ当てはまります。詳細については、[サービス更新をオプトアウトできますか?] を参照してください。

いいえ、サービス更新は、クラスターのメンテナンス期間中に Amazon ElastiCache によって直接適用される継続的な管理メンテナンス更新に対して相互排他的です。

属性の詳細なリストとその説明は、「セルフサービス更新の適用」でご覧いただけます。

利用可能なサービス更新を適用するまでの時間を決めるのに役立つように、次の値を持つ [重要度] サービス更新属性を参照できます (優先度順):

1. 重大: すぐに適用することを推奨 (14 日以内)
2. 重要: ビジネスフローで可能となり次第すぐに適用することを推奨 (30 日以内)
3. 中: 60 日以内に適用することを推奨
4. 低: 90 日以内に適用することを推奨

詳細については、公開ドキュメント「更新の適用」をご覧ください。

リリーススケジュールは、サービス更新の重要性によって異なります。

この属性は、クラスターが [推奨される日付による適用] までに更新されたかどうかを反映しています。[推奨される日付による適用] の後にサービス更新が適用された場合、[SLA 基準を満たすサービスの更新] 属性は [いいえ] に設定されます。

この情報は、HIPAA、PCI、および FedRAMP コンプライアンスプログラムに参加している Amazon ElastiCache クラスターに関連しています。詳細については、「Self-Service Security Updates for Compliance」をご覧ください。

はい。サービス更新の [説明] 属性で別途明記されていない限り、サービス更新は常に累積されます。[更新の有効期限] までに適用しなかった場合、適用しなかった更新は次のサービス更新に含まれます。[セキュリティ] タイプのサービス更新は、この累積カテゴリに分類されます。

いいえ、サービス更新はクラスターレベルで適用されます。進行中の更新をキャンセルすると、クラスターのノードが一部だけ更新され、残りのノードが更新されない可能性があります。この場合、サービス更新を適用するために、クラスターは引き続きクラスターリストに表示されます。クラスターは正常に動作し続けます。

この状態が発生する可能性のあるケースには、次の 2 通りがあります。

(a) オプションのサービス更新の適用を逃し、更新が「期限切れ」状態になった場合。したがって、コンプライアンスプログラムに参加しているクラスターは、すべてのサービス更新を常に適用する必要があります。
(b) 計画されたメンテナンスイベントやノードフェイルオーバーなど、他の理由でノードが交換された場合、Amazon ElastiCache は最新のサービス更新を含む新しいノードをプロビジョニングします。

どちらの場合も、クラスターは正常に動作し続けます。

新しいノードには、該当するすべてのサービス更新が含まれているため、更新されていない既存のノードを手動で置き換えて、最新の更新を入手できます。

はい。サービス更新は、Redis OSS のみ、Memcached のみ、または Redis OSS と Memcached の両方に適用できます。[エンジン] および [エンジンバージョン] のサービス更新の属性を検索して、各更新の範囲を決定できます。

はい、メンテナンスウィンドウを変更してサービス更新を延期することができます。スケジュールされた更新は、予定された日付がクラスターのメンテナンスウィンドウと一致した場合に限り、クラスターに適用されます。メンテナンスウィンドウを変更し、予定されていた日付が過ぎると、翌週以降に改めて指定されたウィンドウに合わせてサービス更新が再度スケジュールされます。新しい日付の 1 週間前に通知が届きます。

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

クラスターが、異なるサービス更新の一部を構成している場合があります。ほとんどの場合、更新を別々に適用する必要はありません。クラスターの更新を 1 つ適用すると、可能な限りその他の更新も完了と表示されます。ただし、ステータスが自動的に「完了」に変更されない場合は、同じクラスターについて複数の更新を適用する必要があります。

[有効期限以降に自動更新] の属性の値が [はい] の場合、[推奨される日付による適用] が経過すると、ElastiCache は残りのクラスターでサービス更新をスケジュールします。 更新はクラスターのメンテナンスウィンドウ内でスケジュールされ、更新の適用が予定された日付の 1 週間前に新しい通知が届きます。

スケジュールされたサービス更新は、「継続的なマネージドメンテナンスの更新」と同じ方法でクラスターに適用されます。 更新の適用方法や更新スケジュールの変更方法、アプリケーションへの影響を最小限に抑えるための準備の詳細については、以下のセクションを参照してください。

クラスターの安定性を維持するために、ElastiCache はシャードごとに 1 回あたり 1 つのノードに更新を適用します。1 回のメンテナンスウィンドウでクラスター全体にサービス更新を適用できない場合、更新は以降のウィンドウでスケジュールされます。次回のスケジュールについては改めて通知が届きますので、それに従って用意を進めてください。

サービス更新を古いものに戻すことはできません。サービス更新の適用後に問題が発生した場合は、AWS サポートチームにお問い合わせください。

継続的な管理メンテナンスの更新

これらの更新は必須であり、メンテナンス期間に直接適用されます。お客様側からのアクションは必要ありません。これらの更新は、サービス更新によって提供される更新とは別のものです。

置換は通常、数秒で完了します。特定のインスタンス設定やトラフィックパターンでは、置換に時間がかかることがあります。例えば、Redis OSS のプライマリノードの空きメモリが不足していて、かつ、書き込みトラフィックが多くなっている可能性がある場合です。空のレプリカがこのプライマリから同期する場合、レプリカの同期に加えて、着信書き込みに対処しようとするため、プライマリノードがメモリ不足を起こす可能性があります。そのため、マスターは一旦レプリカを切断してから同期プロセスを再開します。レプリカの同期が正常に完了するまで、この動作が複数回行われることがあります。書き込みの受信トラフィックが多い状態が続く場合、レプリカの同期が成功しない可能性もあります。

Memcached ノードは同期を必要としないため、ノードサイズに関係なく、ノードの置換がより速く完了します。

Redis OSS ノードの場合、置換プロセスは既存のデータを最大限に保持するように設計されており、レプリケーションの成功を要求します。シングルノードのクラスターでは、ElastiCache はレプリカを動的にスピンアップし、データをレプリケートして、それにフェイルオーバーします。レプリケーショングループが複数のノードで構成されている場合、ElastiCache は既存のレプリカを置換し、データをプライマリから新しいレプリカに同期します。マルチ AZ 自動フェイルオーバーが有効になっている場合、プライマリの置換によってリードレプリカへのフェイルオーバーがトリガーされます。クラスタークライアントを使用するよう設定されているクラスター設定、および自動フェイルオーバーが有効になっている非クラスター設定では、クラスターが着信書き込みリクエストを処理する間に、計画されたノード置換が完了します。マルチ AZ が無効になっている場合、ElastiCache によってプライマリが置換され、リードレプリカからデータが同期されます。この間プライマリノードが利用不可能になり、書き込み中断が長引きます。

Memcached ノードの場合、置換プロセスによって空の新規ノードが立ち上げられ、現在のノードは削除されます。切り替え中の短い時間、新規ノードは使用できません。切り替えが完了し、新規ノードにキャッシュデータを移行する間、アプリケーションのパフォーマンスが低下する場合があります。

Redis OSS ノードの場合、置換プロセスは既存のデータを最大限に保持するように設計されており、レプリケーションの成功を要求します。クラスターの安定性を維持するために、一度に同一のクラスターから十分な数のノードだけを置き換えるよう努めています。プライマリおよびリードレプリカは異なるアベイラビリティーゾーンにプロビジョニングできます。この場合、ノードの置換を行うと、データは別のアベイラビリティーゾーンのピアノードから同期されます。また、Redis OSS のバージョンを 5.0.6 以降にアップグレードすることをお勧めします。これらのエンジンバージョンは安定性が向上しており、自動フェイルオーバーが有効になっているクラスターでは、パッチ適用中、着信書き込みリクエストを継続して処理できます。最後に、シャードごとにプライマリとシングルレプリカが 1 つずつしか含まれていない設定の場合は、パッチ適用の前にレプリカをさらに追加することをお勧めします。これにより、パッチ適用プロセス中の可用性の低下やリスクを防ぐことができます。こちらに記載されているように、シングルノードのクラスターでは、Redis OSS システムが使用できる十分なメモリを確保しておくことを推奨します。レプリケーショングループに複数のノードがある場合は、着信書き込みトラフィックが少ない時間帯に置換をスケジュールすることもお勧めします。

Memcached ノードでは、着信書き込みトラフィックが少ない時間帯にメンテナンスウィンドウをスケジュールし、アプリケーションのフェイルオーバーをテストして、ElastiCache が提供する「よりスマートな」クライアントを使用します。Memcached ではメモリ内にのみデータを保持するため、データ損失を避けることはできません。

Redis OSS の場合、クラスターモード設定はマネージドまたはアンマネージドオペレーション中が可用性が最も高くなり、クラスター検出エンドポイントに接続するクラスターモードをサポートするクライアントを常に使用することが推奨されています。クラスターモードが無効になっている場合、すべての書き込みオペレーションのために、常にプライマリエンドポイントを使用することが推奨されています。レプリカの個々のノードエンドポイントは、すべての書き込みオペレーションに対し使用することが可能です。クラスターで自動フェイルオーバーが有効化されている場合、プライマリノードは変更される可能性があります。そのため、アプリケーションはノードロールを確定し、マスター上で大規模なロードを起こしていないかを確認するため、すべての読み取られたエンドポイントを更新します。自動フェイルオーバーが無効化されているとノードのロールは変更されませんが、自動フェイルオーバーが有効化されたクラスターに比べ、マネージド型またはアンマネージド型のダウンタイムが発生する可能性が高くなります。リードリクエストにリードレプリカのみを指示しないでください。レプリカのみを読み込むよう、クライアントに読み込みリクエストのダイレクトを設定する場合、ダウンタイム中の読み込み中断を防ぐため、少なくとも 2 つの読み取りレプリカがあるようにしてください。

予定されたメンテナンス期間中、ノードの置換を ElastiCache で管理できるようにしておくことをお勧めします。ElastiCache クラスターを作成するときに、週単位のメンテナンス期間を使用して、置換を行う時間を指定できます。ModifyCacheCluster API を使用するか、ElastiCache マネジメントコンソールで [Modify] をクリックして、メンテナンス時間を将来のもっと都合のよい時間に変更できます。

置換の管理を自分で行う場合、ユースケースやクラスター構成によって以下のようなさまざまな操作を行うことができます。

• メンテナンスウィンドウを変更する。
• バックアップと復元プロセスを使用してインスタンスを再起動する。
• クラスター設定でクラスターモードが無効な場合

o リードレプリカの置換 (クラスターモードが無効) – レプリケーショングループのリードレプリカを手動で置換する手順。
o プライマリノードの置換 (クラスターモードが無効) – レプリケーショングループのプライマリノードを手動で置換する手順。
o スタンドアロンノードの置換 (クラスターモードが無効) – スタンドアロンノードを置き換えるための 2 つの異なる手順。

• クラスター設定でクラスターモードが有効な場合

o 1 つ以上のシャードがあるクラスター内のノードの置換 – バックアップと復元を使用するか、またはスケールアウトとそれに続くスケールインを使用して、ノードを置換できます。

これらすべてのオプションの詳細については、「ノードが置き換え対象となった場合に実行可能なアクション」のページをご覧ください。

Memcached では、クラスターを削除して再度作成することで置換できます。置換の後、置換に関連付けられたスケジュールイベントはインスタンスからなくなります。

通知を受けとるには、予定されているリプレースイベントなど重要イベント向けの Amazon SNS 通知をセットアップします。今後の ElastiCache:NodeReplacementScheduled イベントをチェックするには、[イベント] セクションの下の ElastiCache マネジメントコンソールを使用するか、describe-events API を使用します。

SNS 通知のセットアップ方法の詳細については、こちらの情報をご覧ください。

はい。クラスターのメンテナンス時間は変更可能です。メンテナンス時間をより都合のよい時間に変更する場合は、API (ModifyCacheCluster または ModifyReplicationGroup) を使用するか、ElastiCache マネジメントコンソールで [Modify] をクリックします。

メンテナンス時間が変更されると、ElastiCache サービスでは、新しく指定された時間の範囲内でノードのメンテナンスをスケジューリングします。どのような方法で変更が有効になるかについては、下記の例を確認してください。

例:

現在 11 月 9 日、木曜日の 15 時で、次のメンテナンス時間が 11 月 10 日、金曜日の 17 時と仮定します。3 つのシナリオとその結果は以下のとおりです。

• メンテナンス時間を金曜日の 16 時に変更すると (現在の日時より後、スケジュールされている次のメンテナンスウィンドウより前)、ノードは 11 月 10 日、金曜日の 16 時に置き換えられます。
• メンテナンス時間を土曜日の 16 時に変更すると (現在の日時およびスケジュールされている次のメンテナンスウィンドウより後)、ノードは 11 月 11 日、土曜日の 16 時に置き換えられます。
• メンテナンス時間を水曜日の 16 時に変更すると (同じ週の、現在の日時より前)、ノードは次の水曜日、11 月 15 日 16 時に置き換えられます。

このような置換は、基盤となるホストにソフトウェアの必須アップデートを適用するために必要です。更新によってセキュリティ、信頼性、運用パフォーマンスが強化されます。

クラスターの設定によっては、クラスターの安定性を確保しながら、同一のクラスターの複数のノードを置換する場合があります。シャードされたクラスターでは、一度に同一のシャード内で複数のノードの置換を行わないよう努めています。また、すべてのシャードにわたり、クラスターの大部分のマスターノードを置換する操作も行わないようにしています。
シャードされていないクラスターでは、クラスターの安定性を継続的に確保するため、メンテナンス期間中にできる限り時間差を設けてノード置換を行います。

はい。メンテナンス期間が同じになるようにこれらのクラスターが構成されている場合、ノードを同時に置換できます。