Amazon ElastiCache 管理メンテナンスとサービス更新のヘルプページ

Q: Amazon ElastiCache のサービス更新とは何ですか?

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

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

各サービス更新の詳細については、 「更新詳細」属性の数値を参照してください。 

Q: 利用可能な ElastiCache サービス更新の通知を受け取るにはどうすればよいですか?

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

Q: メンテナンス期間で適用される更新は、サービス更新とどのように異なりますか?

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

Q: 利用可能なサービス更新を適用する必要があるかどうかを判断するにはどうすればよいですか?

ElastiCache Redis クラスターが HIPAA、PCI、または FedRAMP コンプライアンスプログラムに参加している場合、コンプライアンスを維持するために、「日付ごとの推奨適用」までサービス更新を必ず適用する必要があります。詳細については、「コンプライアンスのためのセルフサービスセキュリティ更新」を参照してください。

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

Q: Redis クラスターの ElastiCache にサービス更新を適用すると、どのような影響がありますか? データまたはクラスター接続が失われますか?

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

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

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

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

Q: Memcached クラスターの ElastiCache に更新を適用する際に関連するダウンタイムはありますか?

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

Q: サービス更新をオプトアウトできますか?

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

Q: メンテナンス時間中に ElastiCache によってサービス更新を直接適用できないのはなぜですか?

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

Q: サービス更新を用いて Amazon ElastiCache サービスメンテナンスをオプトアウトし、利用できる更新を直接適用できますか?

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

Q: すべてのサービス更新属性リストはどこにありますか?

属性とその説明に関する全リストは、「セルフサービス更新の適用」で利用できます。

Q: すべてのサービス更新には同じタイムラインが適用されますか?

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

1. 重大: すぐに適用することを推奨 (14 日以内)
2. 重要: ビジネスフローが許容され次第、すぐに適用することを推奨 (30 日以内)
3. 普通: 60 日以内に適用することを推奨
4. 低: 90 日以内に適用することを推奨

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

Q: サービス更新はどれくらいの頻度でリリースされますか?

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

Q:「サービス更新 SLA Met」属性とは何ですか?

この属性は、クラスターが「日付ごとの推奨適用」までに更新されたかどうかを反映しています。「日付ごとの推奨適用」の後にサービス更新が適用された場合、属性「サービス更新 SLA 要件」は「いいえ」に設定されます。

この情報は、HIPAA、PCI、および FedRAMP コンプライアンスプログラムに参加している Amazon ElastiCache Redis クラスターに関連しています。詳細については、「コンプライアンスのためのセルフサービスセキュリティ更新」を参照してください。

Q: 1 つ以上のサービス更新を見逃した場合、後で適用できますか?

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

Q: サービス更新を ElastiCache クラスターの特定のノードに適用するように設定できますか?

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

Q: サービス更新を適用していない場合でも、ElastiCache クラスターの 1 つ以上のノードでの更新ステータスが「未適用」から「完了」に変更されたのはなぜですか?

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

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

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

Q: 期限切れのサービス更新を適用するノードがある場合はどうなりますか? 次のサービス更新を待つ必要がありますか?

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

Q: サービス更新はエンジン固有のものですか?

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

Q: メンテナンスの予定をより適切な時間に変更できますか? メンテナンスウィンドウを変更すると、予定されていた更新はどうなりますか?

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

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

Q: 同じクラスターに対して複数の更新通知が届きました。 すべて適用が必要ですか?

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

Q: 「日付ごとの推奨適用」以降、サービス更新はどのようにスケジュール、適用されますか?

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

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

Q: 1 つのメンテナンスウィンドウでクラスター全体にサービス更新が適用できない場合はどうなりますか?

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

Q: サービス更新を古いものに戻すことはできますか?

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

Q: 継続的な管理メンテナンスの更新とは何ですか?

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

Q: ノードの置換にはどれくらい時間がかかりますか?

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

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

Q: ノードの置換はアプリケーションにどのような影響を与えますか?

Redis ノードの場合、置換プロセスは Redis レプリケーションが正常に実行されることを条件に、既存のデータをベストエフォート方式で保持するように設計されています。シングルノードの Redis クラスターでは、ElastiCache によってレプリカが動的に作成され、データレプリケーションの後にレプリカへとフェイルオーバーします。レプリケーショングループが複数のノードで構成されている場合、ElastiCache によって既存のレプリカが置換され、データがプライマリから新しいレプリカに同期されます。マルチ AZ 自動フェイルオーバーが有効になっている場合、プライマリの置換によってリードレプリカへのフェイルオーバーがトリガーされます。Redis クラスタークライアントの使用を設定されている Redis クラスター設定で、自動フェイルオーバーが有効な非クラスター設定の場合は、クラスターが書き込みリクエストの受信を処理するとともに、予定されたノード置換が完了します。マルチ AZ が無効になっている場合、ElastiCache によってプライマリが置換され、リードレプリカからデータが同期されます。この間プライマリノードが利用不可能になり、書き込み中断が長引きます。

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

Q: 置換を順調に実施し、データ損失を最小限に抑えるために、どのようなベストプラクティスに従えばよいですか?

Redis ノードの場合、置換プロセスは Redis レプリケーションが正常に実行されることを条件に、既存のデータをベストエフォート方式で保持するように設計されています。クラスターを安定した状態に保つために、同一のクラスターで一度に交換するノードの数が調整されます。プライマリおよびリードレプリカは異なるアベイラビリティーゾーンにプロビジョニングできます。この場合、ノードの置換を行うと、データは別のアベイラビリティーゾーンのピアノードから同期されます。また、Redis エンジンのバージョンを 5.0.6 以上にアップグレードすることをお勧めします。これらのエンジンバージョンは安定性が向上しており、自動フェイルオーバーが有効になっているクラスターでは、パッチ適用中に受信した書き込みリクエストに継続して対応できるようになります。最後に、シャードごとにプライマリとシングルレプリカが1つずつしかない設定の場合は、パッチの前にレプリカを追加することをお勧めします。これにより、パッチ中の可用性の低下やリスクを防ぐことができます。こちらで説明しているように、シングルノードの Redis クラスターでは、Redis システムが使用するための十分なメモリを確保しておくことを推奨します。Redis レプリケーショングループに複数のノードがある場合は、置換のスケジュールを書き込みの受信トラフィックが少ない時間帯に設定することもお勧めします。

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

Q: メンテナンス中にアプリケーションの中断を最小化するためのクライアント設定のベストプラクティスは何ですか?

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

Q: 自分でノードの置換を管理するにはどうしたらよいですか?

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

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

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

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

• Redis クラスター構成でクラスターモードが有効な場合

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

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

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

Q: 今後の置換スケジュールはどのようにしてわかりますか?

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

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

Q: メンテナンスの予定をより適切な時間に変更できますか?

はい。クラスターのメンテナンス時間は変更可能です。メンテナンス時間をより都合のよい時間に変更する場合は、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 時に置き換えられます。

Q: なぜ AWS 側でノードの置換を行うのですか?

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

Q: これらの置換は複数のアベイラビリティーゾーンに配置しているノードに対して同時に影響が生じますか?

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

Q: 異なるリージョンで、複数のクラスターにあるノードを同時に置換できますか?

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