Amazon ElastiCache よくある質問

ElastiCache Serverless は、インフラストラクチャのプロビジョニングやキャパシティプランニングなしで 1 分以内にキャッシュの使用を開始できるサーバーレスオプションです。ElastiCache Serverless は、キャッシュのコンピューティング、メモリ、ネットワークの使用状況を継続的に監視することで、時間のかかるキャパシティプランニングの必要性を排除します。そのため、ダウンタイムやパフォーマンスの低下を招くことなく、需要に合わせて即座にスケーリングできます。ElastiCache Serverless は、複数のアベイラビリティーゾーン (AZ) にわたってデータを自動的に複製し、キャッシュごとに 99.99% の可用性サービスレベル契約 (SLA) をお客様に提供します。ElastiCache サーバーレスでは、保存したデータと、アプリケーションが使用するコンピューティングリソースに対してのみお支払いいただきます。使用を開始するには、コンソール、ElastiCache Development Kit (SDK)、または AWS コマンドラインインターフェイス (AWS CLI) を使用してキャッシュ名を指定して、わずか数ステップで ElastiCache Serverless キャッシュを作成します。

Valkey、Memcached、または Redis OSS エンドポイントをアプリケーション内の新しい ElastiCache Serverless キャッシュエンドポイントに変更することで、既存の ElastiCache ワークロードを移動できます。バックアップファイルの Amazon Simple Storage Service (Amazon S3) の場所を指定することで、既存の ElastiCache データを ElastiCache サーバーレスに移行できます。ワークロードの移行について詳しくは、ElastiCache サーバーレスのドキュメントをご覧ください。

ElastiCache Serverless は Valkey 7.2、Memcached バージョン 1.6.21、Redis OSS バージョン 7.0 以降をサポートしています。

ElastiCache サーバーレスは、キャッシュのメモリ、コンピューティング、ネットワークの使用状況を継続的に監視して、即座にスケーリングできます。ElastiCache Serverless は、キャッシュのスケールアップとスケールアウトを並行して開始できるため、アプリケーションの要件をジャストインタイムで満たすため、ダウンタイムやアプリケーションのパフォーマンス低下なしにスケーリングできます。スケーリングの詳細については、ElastiCache サーバーレスのドキュメントをご覧ください。

ElastiCache Serverless は、データを自動的に複数の AZ にわたって冗長的に保存し、すべてのワークロードに 99.99% の可用性サービスレベルアグリーメント (SLA) を提供します。

ElastiCache サーバーレスでは、保存したデータと、アプリケーションが使用するコンピューティングに対してのみお支払いいただきます。詳細については、「ElastiCache の料金ページ」をご覧ください。

リザーブドノードまたはリザーブドインスタンス (RI) は、1 年または 3 年の利用期間をお約束いただくと、オンデマンド利用よりも大幅に割引されます。リザーブドノードを使用し、1 年または 3 年の期間での予約を一括先払いしていただくことで、自分のキャッシュを特定のリージョンで実行し、時間単位の利用料金の請求に対して大幅な割引を受けることができます。リザーブドノードタイプには、「全前払い」、「前払いなし」、「一部前払い」の 3 つがあり、前払いする金額と実効時間単価とのバランスを取ることができます。

リザーブドノードには、ElastiCache のオンデマンド使用に適用される割引があります。ElastiCache サーバーレスはリザーブドノードと互換性がありません。

リザーブドノードは最大 300 個まで購入できます。300 個を超えるノードの実行を希望される場合は、ElastiCache ノード申請フォームにご記入ください。

現在実行中で予約したいノードと同じリージョン内の同じノードクラスでノード予約を購入します。予約の購入が完了すると、ElastiCache では既存のノードに新しい時間単位の利用料金が自動的に適用されます。

支払い認証の処理中にお客様からのリクエストがあれば、リザーブドノードに関連する料金変更が有効になります。AWS アカウントアクティビティページまたは DescribeReservedCacheNodes API を使用して予約の状態を確認できます。次の請求期間に一括払いが承認されない場合は、割引料金が適用されません。

予約期間が過ぎると、リザーブドノードは、ノードクラスとリージョンに該当するオンデマンド時間料金に戻ります。

ノードの作成、変更、削除を行う ElastiCache API ではオンデマンドノードとリザーブドノードが区別されないため、両方をシームレスに使用できます。お客様への請求額の計算時に、予約購入状態に応じて、該当するすべてのノードにリザーブドキャッシュノードの低額の時間料金が自動的に適用されます。

各リザーブドノードは、特定のリージョンに関連付けられています。これはリザーブドノードの存続期間中固定されており、変更できません。ただし、それぞれの予約は、そのリージョン内のどのアベイラビリティーゾーンでも使用できます。

いいえ。ノードリザーブはキャンセルできず、一括払いは (該当する場合) 返金不可能です。使用したかどうかにかかわらず、リザーブドノードの期間が終了するまで、毎時間の料金をお支払いいただきます。

すべて前払いのオプションでリザーブドノードを購入する場合、リザーブドノードの全期間を 1 回の前払いで支払います。いっさい前払いなしにすることもでき、その場合は「前払いなし」を選択します。「前払いなし」のリザーブドノードの価額総額が期間内の各時間に分配され、お客様へのご請求は使用の有無にかかわらず、期間内の 1 時間ごとに発生することになります。「一部前払い」は、「全前払い」と「前払いなし」の間をとったお支払い方法です。最初に少額をお支払いいただき、使用の有無にかかわらず、期間内の 1 時間ごとに低い時間単価で計算した料金請求が発生します。

はい。ElastiCache リザーブドノードは、インスタンスファミリー (またはノードファミリー) と AWS リージョン内でサイズの柔軟性を提供します。同じノードファミリーのすべてのサイズの使用には、既存の割引されたリザーブドノード料金が自動的に適用されます。

ElastiCache では、AWS Key Management Service (AWS KMS) による保管中のデータの暗号化、Transport Layer Security (TLS) による転送中のデータの暗号化、AWS ID およびアクセス管理 (IAM) による認証、および Amazon Elastic Compute Cloud (Amazon EC2) セキュリティグループによるネットワークアクセス制御を設定できます。

Amazon Virtual Private Cloud (Amazon VPC) を使用していない場合、ElastiCache ではネットワークセキュリティグループを通じてキャッシュへのアクセスを制御できます。セキュリティグループは、キャッシュへのネットワークアクセスを制御するファイアウォールのように動作します。デフォルトでは、キャッシュへのネットワークアクセスは無効になっています。アプリケーションからキャッシュにアクセスできるようにするには、特定の Amazon EC2 セキュリティグループのホストからのアクセスを明示的に有効にする必要があります。

IAM 認証を使用して ElastiCache リソースへのアクセスを制御することもできます。詳細については、 IAM による認証のドキュメントを参照してください。

ElastiCache では、SOC 1、SOC 2、SOC 3、ISO、MTCS、C5、PCI DSS、HIPAA、FedRAMP などのコンプライアンスプログラムがサポートされています。サポートされているコンプライアンスプログラムの最新のリストについては、コンプライアンスプログラムによる AWS 対象範囲内のサービスを参照してください。

はい。AWS PCI コンプライアンスプログラムには、ElastiCache が PCI 準拠サービスとして含まれています。詳細については、以下のリソースをご覧ください。

• ElastiCache コンプライアンス
• AWS PCI コンプライアンスページ

ElastiCache が対象範囲に含まれるコンプライアンスプログラムの最新リストについては、コンプライアンスプログラムによる AWS 対象範囲内のサービスを参照してください。

ElastiCache は HIPAA 使用可能なサービスで、AWS Business Associate Addendum (BAA) でカバーされています。このため、ElastiCache を使用して、保護された医療情報 (PHI) の処理、管理、保存を行うことや、ヘルスケアアプリケーションを実行することができます。

いいえ。コンプライアンス機能を使用しても追加料金は発生しません。

AWS とビジネスアソシエイト契約 (BAA) を締結している場合は、ElastiCache を使用して HIPAA に基づいて HI を保存および処理するアプリケーションを構築できます。BAA を締結していない場合や、アプリケーションでの AWS の使用に関するご質問がある場合は、詳細についてお問い合わせください。 

AWS FedRAMP コンプライアンスプログラムには、ElastiCache が FedRAMP 認可サービスとして含まれています。米国政府のお客様とそのパートナーは、最新バージョンの ElastiCache を使用して、FedRAMP システム、データ、およびミッションクリティカルで影響の大きいワークロードを AWS GovCloud (米国東部) と AWS GovCloud (米国西部) リージョンで処理および保存できるようになりました。また、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (北カリフォルニア)、米国西部 (オレゴン) リージョンでは中程度の影響が及ぶリージョン。

詳細については、以下のリソースをご覧ください。

• ElastiCache コンプライアンス
• AWS FedRAMP コンプライアンス

ElastiCache が対象範囲に含まれるコンプライアンスプログラムの最新リストについては、コンプライアンスプログラムによる AWS 対象範囲内のサービスを参照してください。

ElastiCache は、I/O スレッドが強化されており、多重化やプレゼンテーションレイヤーのオフロードなどにより、大規模なスループットと待機時間を大幅に改善します。拡張された I/O スレッドは、I/O の処理に多くのコアを活用し、ワークロードを動的に調整することでパフォーマンスを向上させます。ElastiCache は、暗号化を同じ拡張された I/O スレッドにオフロードすることで、TLS 対応クラスターのスループットを向上させます。Valkey 用 Redis バージョン 7.2 では、拡張された I/O 多重化が導入されました。これにより、多数のクライアントリクエストが 1 つのチャネルにまとめられ、スレッドの効率が向上しました。

Valkey 用 ElastiCache バージョン 7.2 以降では、拡張 I/O スレッド機能が拡張され、プレゼンテーションレイヤーロジックも処理できるようになりました。拡張された I/O スレッドは、クライアント入力を読み取るだけでなく、その入力をバイナリコマンド形式に解析し、それをメインスレッドに転送して実行することで、パフォーマンスを向上させます。Valkey 用 ElastiCache バージョン 7.2 では、以前のバージョンと比較して、スループットが最大 100% 向上し、P99 レイテンシーが 50% 低下しています。r7g.4xlarge 以上では、1 ノードあたり 100 万回を超えるリクエスト/秒 (RPS) を達成できます。

ElastiCache には、キャッシュデプロイの選択に応じて、キャッシュの CPU 使用率を測定するための 2 つの異なるメトリクスセットが用意されています。ElastiCache サーバーレスを使用する場合、ElastiCache プロセッシングユニット (ECPU) メトリクスを使用して CPU 使用率をモニタリングできます。リクエストによって消費される ECPU の数は、かかる vCPU 時間と転送されるデータ量によって異なります。Valkey の GET コマンドと SET コマンド、または Memcached の get コマンドと set コマンドのように、読み取りと書き込みを行うたびに、転送されるデータの 1 キロバイト (KB) あたり 1 つの ECPU が必要です。メモリ内のデータ構造を操作する Valkey コマンドの中には、GET または SET コマンドよりも vCPU 時間を多く消費するものがあります。ElastiCache は、SET または GET コマンドでかかった vCPU 時間のベースラインと比較して、コマンドによって使用された vCPU 時間に基づいて消費された ECPU 数を計算します。コマンドに vCPU 時間が余分にかかり、1 ECPU のベースラインを超えるデータを転送する場合、ElastiCache は 2 つのディメンションのうち大きい方に基づいて必要な ECPU を計算します。

独自のクラスターを設計する場合、EngineCPUUtilization と CPUUtilization を監視できます。CPUUtilization メトリクスはインスタンス (ノード) の CPU 使用率を測定し、EngineCPUUtilization メトリクスはエンジンプロセスレベルの使用率を測定します。CPUUtilization メトリクスに加えて EngineCPUUtilization メトリクスも必要になるのは、メインのエンジンプロセスがシングルスレッドであり、インスタンスで利用できる複数 CPU コアのうち 1 CPU のみを使用するためです。このため、CPUUtilization メトリクスではプロセスレベルでの CPU 使用率を正確に把握することができません。CPUUtilization メトリクスと EngineCPUUtilization メトリクスの両方を使用して、Valkey クラスターの CPU 使用状況の詳細を把握することをお勧めいたします。

これらのメトリクスのセットはすべての AWS リージョンで使用でき、Amazon CloudWatch を使用するか、コンソールを通じてアクセスできます。さらに、パフォーマンスモニタリングに役立つメトリクスについては、このドキュメントを参照することをお勧めします。

リードレプリカは、次の 2 つの用途で使用されます。

• 障害処理
• 読み込みのスケーリング

リードレプリカを含むキャッシュを実行すると、「プライマリ」が書き込みと読み込みの両方を行います。レプリカは読み取りトラフィックのみを処理し、プライマリに障害が発生した場合のウォームスタンバイとしても使用できます。

ElastiCache サーバーレスでは、リードレプリカはサービスによって自動的に管理されます。独自のキャッシュを設計する場合、特定のプライマリノードに 1 つ以上のリードレプリカをデプロイすることが理にかなっている可能性があるさまざまなシナリオがあります。リードレプリカをデプロイする一般的な理由:

• 読み取り負荷の高いワークロードで、1 つのプライマリノードのコンピューティングまたは I/O キャパシティを超えるスケーリングを行う場合:この過剰な読み取りトラフィックは、1 つ以上のリードレプリカに送られます。
• プライマリが利用できない間、読み取りトラフィックに対応する: お客様のプライマリノードが入出力リクエストを取得できない場合 (バックアップまたは定期メンテナンスによる入出力一時停止のため)、読み込みトラフィックをリードレプリカに誘導することができます。このようなユースケースの場合、プライマリインスタンスを利用できないため、リードレプリカのデータは「古い」場合があるため注意が必要です。リードレプリカを使用して、障害が発生したプライマリのウォームアップを再起動することもできます。

データ保護のシナリオ: 予期せぬイベント、プライマリノードの障害、またはプライマリノードが属する AZ が使用できなくなった場合、別の AZ 内にあるリードレプリカを新しいプライマリに昇格させることができます。

リードレプリカには、プライマリキャッシュノードに接続するのと同じように接続できます。リードレプリカが複数ある場合、読み込みトランザクションがどのように誘導されるかはアプリケーションに依存します。こちらが詳細です:

• Valkey または Redis (クラスターモードが無効化されている) OSS クラスターの場合、読み取り操作には個々のノードエンドポイントを使用します。(API/CLI では、これらは読み取りエンドポイントと呼ばれます。)
• Valkey または Redis OSS (クラスターモードが有効化されている)クラスターは、クラスターの全操作で設定エンドポイントを使用します。個々のノードエンドポイントから引き続き読み取ることができます。(API と CLI では、これらは読み取りエンドポイントと呼ばれます。)

ElastiCache では、1 つのプライマリキャッシュノードに対して最大 5 個のリードレプリカを作成できます。

フェイルオーバーが発生し、関連付けられた利用可能なリードレプリカがある場合、フェイルオーバーが完了すると自動的にレプリケーションが再開されます (新しく昇格したリードレプリカから更新データが取得されます)。

プライマリキャッシュノードの更新は、あらゆる関連したリードレプリカに対して自動的にレプリケーションが実行されます。ただし、Valkey または Redis OSS の非同期レプリケーションテクノロジーを使うと、さまざまな理由によりリードレプリカがプライマリキャッシュノードより遅れることがあります。一般的な理由:

• プライマリキャッシュノードに対する書き込みの入出力量が、変更をリードレプリカに適用できる速度を超えている。
• ネットワークパーティション、またはプライマリキャッシュノードとリードレプリカ間にレイテンシーがある。

リードレプリカは、Valkey または Redis OSS レプリケーションの長所と短所の影響を受けます。リードレプリカを使う場合は、リードレプリカとそのプライマリキャッシュノードの間に遅延または「矛盾」が発生する可能性があることを理解しておく必要があります。 ElastiCache は、不整合を理解できるよう支援するメトリクスを発行します。

リードレプリカの使用料金は、標準キャッシュノードと同じ料金で請求されます。標準のキャッシュノードと同様に、リードレプリカのキャッシュノード時間あたりの料金は、リードレプリカのキャッシュノードクラスによって決定さ れます。最新の価格については、ElastiCache の価格ページをご覧ください。プライマリキャッシュノードとリードレプリカ間のデータレプリケーションに発生したデータ転送に対しては請求されません。リードレプリカの請求は、そのレプリカを作成 (一覧のステータスが「アクティブ」になるなど) してから開始します。リードレプリカは、削除するコマンドを発行するまで標準 ElastiCache キャッシュノードの時間料金で請求されます。

開始されるフェイルオーバーは ElastiCache でサポートされているため、すばやくキャッシュ操作を再開できます。フェイルオーバーが行われると、ElastiCache はキャッシュノードの DNS レコードを反転させ、リードレプリカを示します。このリードレプリカが新しいプライマリに昇格します。ベストプラクティスに沿って、アプリケーションレイヤーでキャッシュノード接続を再試行することを推奨いたします。通常、開始から終了まで、以下のステップ 1 ～ 5 は 6 分以内に完了します。

これらは自動フェイルオーバーイベントであり、発生順に表示されています。

1. レプリケーショングループメッセージ: ノードグループ <node-group-id> に対して呼び出されたフェイルオーバー API のテスト
2. キャッシュクラスターメッセージ: プライマリノード <primary-node-id> からレプリカノード <node-id> へのフェイルオーバーが完了しました
3. レプリケーショングループメッセージ: プライマリノード <primary-node-id> からレプリカノード <node-id> へのフェイルオーバーが完了しました
4. キャッシュクラスターメッセージ: キャッシュノード <node-id> の復旧
5. キャッシュクラスターメッセージ: キャッシュノード <node-id> の復旧が終了しました

リードレプリカは、キャッシュノードプライマリと同じリージョンに属する、同じまたは別の AZ にのみプロビジョニングできます。 ただし、Global Datastore を使用すれば、AWS リージョン間で高速かつ信頼性が高く、安全重視のフルマネージド型のレプリケーションを操作できます。この機能を使用すると、ElastiCache のリージョン間リードレプリカクラスターを作成して、AWS リージョン全体で低レイテンシーのリードとディザスタリカバリを有効にできます。

はい。クラスター環境では、1 つまたは複数のシャードにわたってリードレプリカを追加または削除できます。クラスターがオンラインのままで、この操作の間 I/O 受信を行います。

マルチ AZ は、独自の ElastiCache キャッシュを設計する際に、より可用性の高い構成で実行できるようにする機能です。すべての ElastiCache サーバーレスキャッシュは、マルチ AZ 構成で自動的に実行されます。ElastiCache レプリケーショングループはプライマリレプリカと最大 5 つのリードレプリカで構成されます。マルチ AZ が有効になっている場合は、プライマリごとに少なくとも 1 つのレプリカが必要です。特定の種類の計画されたメンテナンス中、または ElastiCache ノード障害、AZ 障害などの予期しないイベントが発生している間、プライマリの障害検知、リードレプリカの選択、新しいプライマリへの昇格が ElastiCache によって自動的に実行されます。また、ElastiCache は昇格したリードレプリカの DNS の変更を伝達します。そのためアプリケーションがプライマリノードのエンドポイントへの書き込み中である場合、エンドポイントの変更は必要ではありません。

マルチ AZ モードで ElastiCache を実行する主な利点は、拡張された可用性と、管理の必要性が少なくなることにあります。マルチ AZ 構成で ElastiCache を実行している場合、キャッシュは 99.99% の可用性 SLA の対象となります。ElastiCache のプライマリノードに障害が発生した場合、自動フェイルオーバーが完了するまでの間のプライマリへの読み取り/書き込み能力への影響が限定されます。マルチ AZ が有効になっている場合、ElastiCache ノードフェイルオーバーは自動的に作動し、管理の必要がありません。

ElastiCache を利用する際、レプリケーショングループ内にプライマリノードと、1 つ以上のリードレプリカがある場合にマルチ AZ を使用できます。プライマリノードに障害が発生すると、ElastiCache は自動的に障害を検知し、利用可能なリードレプリカを 1 つ選択し、新しいプライマリに昇格させます。ElastiCache は昇格したレプリカの DNS の変更を伝達します。そのためアプリケーションはプライマリのエンドポイントに書き込み続けることが可能です。また、ElastiCache では、障害が発生したプライマリの AZ に、昇格したリードレプリカを置き換えるための新しいノードがスピンアップされます。プライマリの障害が、一時的な AZ の中断によって起きた場合、AZ の復旧後に新しいレプリカが起動します。

はい。同じ AZ にプライマリとレプリカの両方を配置する場合、AZ の中断に対する ElastiCache のレプリケーショングループの柔軟性が与えられないことに注意してください。

ElastiCache は、以下のイベントにおいてリードレプリカへのフェイルオーバーを行います。

• プライマリ AZ での可用性の喪失
• プライマリに対するネットワーク接続の喪失
• プライマリ上でのコンピュートユニット障害

リードレプリカが 2 つ以上ある場合、非同期レプリケーションのプライマリへの遅延が最も小さいものが昇格されます。

はい、ElastiCache は自動フェイルオーバーが発生したことをお知らせするイベントを作成します。DescribeEvents API を使用して、ElastiCache ノードに関連するイベントについての情報を返すことができます。または、ElastiCache マネジメントコンソールの [イベント] セクションを選択します。

AZ は、同じリージョン内の他の AZ に低レイテンシーのネットワーク接続を提供するように設計されています。1 つの AZ が中断した場合でもお客様のアプリケーションの柔軟性を保つため、アプリケーションや他の AWS リソースに複数の AZ による冗長性を持たせるようアーキテクチャーを設計することもできます。

マルチ AZ の詳細については、ElastiCache のドキュメントを参照してください。

バックアップと復元は、お客様が ElastiCache キャッシュのスナップショットを作成できるようにする機能です。ElastiCache はスナップショットを保存し、その後ユーザーがそのスナップショットを使用してキャッシュを復元できるようにします。これは現在、ElastiCache for Valkey、ElastiCache for Redis OSS、サーバーレスでサポートされています。

スナップショットを作成しておくと、ノード障害によってデータ損失が発生した場合や、万が一ハードウェア障害が発生した場合に役立ちます。バックアップを使用する別の一般的な理由はアーカイブを目的とするものです。スナップショットは Amazon S3 に保存されます。

ElastiCache スナップショットは、リージョン内にある認可された S3 バケットにクラスターとしてエクスポートできます。

はい。まず、スナップショットを同じリージョン内で選択した、認可された S3 バケットにコピーしてから、別のアカウントにクロスアカウントバケットアクセス許可を付与します。

Amazon ElastiCache では、アクティブな ElastiCache キャッシュごとに、1 つのスナップショットのストレージ領域を無料で利用できます。追加のストレージは、スナップショットで使用される容量に基づいて、毎月 0.085 USD/GB (すべてのリージョンで同じ料金) で課金されます。スナップショットを使用するためのデータ転送は無料です。

ElastiCache キャッシュを削除しても、手動スナップショットは保持されます。キャッシュが削除される前に最終スナップショットを作成するオプションもあります。自動キャッシュスナップショットは保持されません。

ElastiCache 内のエンジンは Valkey および Redis OSS と完全互換ですが、堅牢性と安定性を向上させるための強化が図られています。以下のような点が強化されています。

• メモリの可用性の強化: 同期やスナップショットの間にスワップ使用率が増加するというリスクなしに、アプリケーションにより多くのメモリを安全に割り当てられるようになりました。
• 同期の向上: 高負荷状態やネットワーク切断からの回復時の同期の堅牢性が向上しました。さらに、このオペレーションにディスクが使用されなくなったため、プライマリとレプリカの両方について同期速度が向上しました。
• より円滑なフェイルオーバー: フェイルオーバーの発生時に、プライマリとの完全再同期を実行するためのレプリカデータのフラッシュが行われなくなったため、シャードの回復速度が向上しました。
• TLS オフロードと IO 多重化:ElastiCache は、特定のネットワーク関連プロセスを専用スレッドで処理することで、利用可能な CPU リソースをより有効に活用するように設計されています。

強化されたエンジンは Valkey または Redis OSS と完全互換であるため、アプリケーションのコードにはまったく手を加えずに、向上した堅牢性と安定性を利用できます。

強化されたエンジンは追加料金なしで使用できます。

転送中の暗号化、保存時の暗号化、Valkey AUTH、ロールベースアクセス制御 (RBAC) は、ElastiCache キャッシュの作成時に選択できる機能です。転送中の暗号化を有効にした場合は、セキュリティとアクセスコントロールを強化するために AUTH または RBAC を使用することを選択できます。

保管時の暗号化は、データへの不正アクセスを防ぐためのメカニズムを提供します。有効にすると、次の項目が暗号化されます。

• 同期、バックアップ、およびスワップ操作中のディスク
• Amazon S3 に保存されているバックアップ

ElastiCache は保管時の (サービス管理) 暗号化をデフォルトで提供します。さらに、独自の対称カスタマープライマリキーを AWS (KMS) の AWS KMS キーで使用する機能も提供します。詳細については、保存時の暗号化をご覧ください。

転送時の暗号化機能は、クライアントと ElastiCache 間、およびサーバー (プライマリとリードレプリカ) 間の通信の暗号化を容易にします。ElastiCache の転送中暗号化の詳細については、こちらをご覧ください。

いいえ。証明書の有効期限と更新は、ElastiCache によってユーザーから見えない形で管理されます。実行中の証明書の管理に必要なユーザーの操作はありません。

いいえ、暗号化の使用に追加のコストはかかりません。

グローバルデータストアは、ElastiCache の機能の 1 つです。高速で、信頼性が高く、安全重視のフルマネージド型クロスリージョンレプリケーションを実現できます。グローバルデータストアを使用すると、1 つのリージョンでキャッシュに書き込みながら、他の 2 つのクロスリージョンレプリカクラスターでのデータ読み取りも実現できます。これにより、リージョンをまたいだ低レイテンシーの読み取りおよびディザスタリカバリが可能となります。

グローバルデータストアは、グローバルなフットプリントを持つリアルタイム・アプリケーション向けに設計されており、通常 1 秒以内にリージョン間でデータをレプリケートするので、エンドユーザーに近い場所でジオローカルな読み取りを行うことができ、アプリケーションの応答性が向上します。まれにリージョンの劣化が発生した場合、健全なクロスリージョンレプリカキャッシュの 1 つを、完全な読み取り/書き込み機能を持つプライマリに昇格させることができます。昇格は通常、開始後 1 分以内に完了し、このためアプリケーションは中断することなく利用可能です。

最大で、グローバルデータストアに含まれる 2 つのセカンダリリージョンにレプリケートすることができます。セカンダリリージョンのキャッシュを、低レイテンシーのローカル読み取り用として、および万一リージョンにサービス品質の低下が発生した場合のディザスタリカバリとして使用できます。

グローバルデータストアは、Valkey 用 ElastiCache バージョン 7.2 と Redis OSS 用 ElastiCache バージョン 5.0.6 以降でサポートされています。

グローバルデータストアをセットアップするには、既存のキャッシュを使用するか、プライマリとして使用する新しいキャッシュを作成します。ElastiCache マネジメントコンソールでは数回のクリックでグローバルデータストアを作成できます。または、最新の AWS SDK または CLI をダウンロードして作成できます。AWS CloudFormation ではグローバルデータストアをサポートしています。

いいえ。ElastiCache では、プライマリクラスター (リージョン) に品質低下が発生したときに、セカンダリクラスターを自動的に昇格させることはありません。セカンダリクラスターをプライマリに昇格して手動でフェイルオーバーを開始することは可能です。フェイルオーバーとセカンダリクラスターの昇格は、通常 1 分未満で完了します。

ElastiCache では、Global Datastore の利用に対する追加料金は発生しません。グローバルデータストア内のプライマリクラスターとセカンダリクラスターの料金、およびリージョン間のデータ転送トラフィックの料金が発生します。

ElastiCache では、RPO と RTO について SLA を提供していません。RPO はリージョン間のレプリケーションの遅延によって異なり、リージョン間のネットワークレイテンシーとクロスリージョンネットワークトラフィックの混雑状態の影響も受けます。グローバルデータストアの RPO は通常 1 秒未満です。そのため、プライマリリージョンに書き込まれたデータは、1 秒以内にセカンダリリージョンでも利用可能になります。Global Datastore の RTO は通常 1 分未満です。セカンダリクラスターへのフェイルオーバーが始まると、ElastiCache では通常 1 分未満でセカンダリを昇格し、読み書き機能を全面的に回復させます。

この質問に対する決まった答えはありませんが、ElastiCache ではノードの追加や削除が後から簡単に行えるため、ノード数が最適かどうか心配する必要はありません。また、ElastiCache サーバーレスを使用して、可用性の高い Memcached キャッシュを簡単に実行することもできます。初期設定を選択するときには、相互に関連した以下の 2 つの側面を考慮できます。

• 目標のキャッシュヒット率を達成するために、データに必要なメモリ合計。
• ノードの障害発生時に、データベースバックエンドに過負荷をかけることなく、許容できるアプリケーションパフォーマンスを維持するために必要なノード数。

必要なメモリの量は、データセットのサイズおよびアプリケーションのアクセスパターンにより異なります。耐障害性を強化させるため、必要なメモリの合計が大まかにわかったら、1～2 個のノードが損失してもアプリケーションが動作を続けられる数のノードにそのメモリを分割します。例えば、メモリ要件が 13 GB の場合、cache.m4.xlarge ノード 1 つではなく、cache.m4.large ノード 2 つを使用する方がよいかもしれません。1 つ以上のノードの障害復旧中にキャッシュヒット率が一時的に下がった場合でも、データベースなどの他のシステムが過負荷にならないようにすることが重要です。詳細については、「Amazon ElastiCache ユーザーガイド」をご覧ください。

はい。クラスターを作成するとき、または既存のクラスターにノードを追加するとき、新しいノードの AZ を選択できます。各 AZ でリクエストされるノード数を指定することも、「ゾーン全体にノードを分散」するように選択することもできます。クラスターが Amazon VPC にある場合、ノードは選択されたキャッシュサブネットグループの一部である AZ にしか配置できません。詳細については、「ElastiCache VPC ドキュメント」をご覧ください。

リージョン 1 つあたり最大 300 のノードを実行できます。さらにノードが必要な場合は、ElastiCache 制限緩和申請フォームにご記入ください。

このサービスではノードの障害が検出され、自動的に以下のような手順で対応します。

• ElastiCache のノード修復では、新しいサービスのリソースが取得された後、ノードの既存の DNS 名がそのリソースに向けてリダイレクトされます。Amazon VPC インストールの場合、ノードが障害から復帰すると、ElastiCache はノードの DNS 名と IP アドレスの両方が同じままになるようにします。非 Amazon VPC インストールの場合、ElastiCache でノードの DNS 名が変わることはありませんが、基となるノードの IP アドレスは変わる場合があります。
• クラスターに SNS トピックを関連付けている場合、新しいノードが設定され使用準備が完了した時点で、ElastiCache により SNS 通知が送信され、そのノードの復旧が発生したことを知らせます。これにより、オプションとして、Memcached クライアントライブラリに修復されたノードへの再接続試行を強制させるよう、アプリケーションを調整できます。一部の Memcached ライブラリでは、サーバーとの通信エラーまたはタイムアウトの発生時に、そのサーバー (ノード) の使用が無期限停止されるため、このことが重要になります。

キャッシュクラスターの [ノード] タブにある [ノードを追加] オプションを使用するか、ModifyCacheCluster API を呼び出すことによって、既存の Memcached クラスターにノードを追加できます。

ElastiCache では、長期的なデータの耐久性を提供しながら、高性能アプリケーションでの非常に短いレイテンシーを実現し、要求ボリュームの負荷の一部を軽減できるため、Amazon RDS や DynamoDB といった AWS のフロントエンドとして理想的です。このサービスは、Amazon EC2 や Amazon EMR と組み合わせて、アプリケーションのパフォーマンスを向上させるために使用することもできます。

Memcached クライアントライブラリは、すべてではないものの多くの一般的なプログラミング言語でご利用いただけます。ElastiCache を使用している際に、特定の Memcached クライアントで何らかの問題が発生した場合は、ElastiCache コミュニティフォーラム経由で、当社までお知らせください。

ElastiCache は特定のクライアントライブラリを必要とせず、再コンパイルやアプリケーションの再リンクを行わずに既存の Memcached クライアントライブラリと連携します (Memcached 1.4.5 以降)。例としては、libMemcached (C) やそれをベースにしたライブラリ (PHP、Perl、Python など)、spyMemcached (Java)、ファウナ (Ruby) などがあります。

自動検出とは、開発に必要な時間と労力を削減すると同時に、開発されるアプリケーションの複雑さを緩和する機能です。自動検出を使用すると、ElastiCache クラスターのキャッシュノードが追加または削除されたことを、クライアントが自動的に検出します。以前は、クラスターメンバーシップの変更を処理するために、開発者はキャッシュノードのエンドポイントのリストを手動で更新する必要がありました。クライアントアプリケーションのアーキテクチャーによっては、クライアント初期化が必要になり、このときにアプリケーションがシャットダウンされて再起動されるので、ダウンタイムが発生しました。自動検出により、ElastiCache はこの複雑さを解消します。ElastiCache は、Memcached プロトコルとの下位互換性に加えて、自動検出により、クライアントにキャッシュクラスターのメンバーシップ情報を与えます。この追加情報の処理能力があるクライアントは、クライアント自体を再設定すれば、初期化しなくても ElastiCache クラスターの最新のノードを使用できるようになります。

ElastiCache クラスターを作成したときに指定したノードのアドレスは、名前付きエンドポイントを介して指定できます。自動検出によって、ElastiCache クラスターには一意の「設定エンドポイント」も付与されます。これは 1 つの DNS レコードであり、クラスターの存続期間が終了するまで有効です。この DNS レコードには、クラスターに属するノードの DNS 名が記録されています。ElastiCache では、設定エンドポイントにこのような「ターゲット」ノードが常に 1 つ以上指定されます。ターゲットノードへのクエリを実行すると、該当するクラスターのすべてのノードに対応するエンドポイントが返されます。この後は、これまでと同様の方法でクラスターノードに接続して、Memcached プロトコルのコマンド (get、set、incr、decr など) を実行できます。詳細については、「ドキュメント」を参照してください。自動検出機能を使用するには、自動検出対応クライアントが必要です。.Net、Java と PHP の自動検出クライアントは、ElastiCache コンソールからダウンロードできます。初期化時に、このクライアントは設定エンドポイントを使用して ElastiCache クラスターの最新のメンバーを自動的に特定します。キャッシュクラスターのノードが追加または削除されたときや、特定のノードに障害が発生して交換されたときも、自動検出クライアントは自動的にその変更を特定するので、クライアントを手動で初期化する必要はありません。

使用を開始するには、ElastiCache コンソールの [ElastiCache クラスタークライアントをダウンロード] をクリックして Amazon ElastiCache クラスタークライアントをダウンロードします。ダウンロードするには、ElastiCache アカウントが必要です。まだお持ちでない場合は、ElastiCache 詳細ページからサインアップしてください。クライアントをダウンロードしたら、ElastiCache クラスターのセットアップとアクティブ化を開始します。開始するには、ElastiCache コンソールにアクセスします。詳細については、「ドキュメント」をご参照ください。

はい。自動検出の使用はいつでも停止できます。自動検出を無効にするには、ElastiCache クラスタークライアントの初期化時に動作モードを指定します。また、ElastiCache では引き続き Memcached が完全にサポートされるため、任意の Memcached プロトコル準拠クライアントを以前と同様に使用できます。

自動検出を利用するには、自動検出対応クライアントを使用して ElastiCache クラスターに接続する必要があります。ElastiCache では現在、.Net、Java と PHP の自動検出対応クライアントをサポートしています。これらは、ElastiCache コンソールからダウンロードできます。他の言語でクライアントを作成するには、一般的に使用されている Memcached クライアントで構築してください。

任意の Memcached クライアントライブラリを利用して、自動検出のサポートを追加できます。独自のクライアントを追加または削除して自動検出を有効にする方法については、自動検出コマンドセットのドキュメントをご覧ください。

はい、ElastiCache は引き続き Memcached プロトコル準拠であるため、開発したクライアントの変更は不要です。ただし、自動検出機能を利用するために、Memcached クライアント機能を強化しました。ElastiCache クラスタークライアントを使用しない場合は、独自開発したクライアントを引き続き使用することも、独自のクライアントライブラリが自動検出コマンドセットを解釈できるように修正することもできます。
 

はい。同じ ElastiCache クラスターに、自動検出対応クライアントと従来の Memcached クライアントから同時に接続できます。ElastiCache は引き続き Memcached に完全に準拠しています。

はい。自動検出の使用はいつでも停止できます。自動検出を無効にするには、ElastiCache クラスタークライアントの初期化時に動作モードを指定します。また、ElastiCache では引き続き Memcached が完全にサポートされるため、任意の Memcached プロトコル準拠クライアントを以前と同様に使用できます。

ElastiCache では、クラスターを実行している Memcached のプロトコル準拠ソフトウェアを ElastiCache でサポートされている新しいバージョンにアップグレードするかどうかや、アップグレードするタイミングをコントロールできます。したがって、お客様は特定の Memcached バージョンとの互換性を維持することや、新しいバージョンをアプリケーションでテストしてから本稼働にデプロイすることや、独自の条件とタイムラインでバージョンのアップグレードを実行することが自由にできます。バージョンのアップグレードには互換性のリスクが伴うため、自動的には行われません。お客様ご自身の責任で実施してください。ソフトウェアへのパッチ適用では、バージョンアップグレードの決定権がお客様にあると同時に、ElastiCache へのパッチ適用作業の負荷が軽減されています。バージョン管理の詳細については、このよくある質問を引き続きご覧ください。または、「ElastiCache ユーザーガイド」をご覧ください。エンジンバージョン管理機能では、パッチ適用を可能な限りお客様側で管理できるようになっていますが、システムやキャッシュソフトウェアに重大なセキュリティの脆弱性があると当社が判断した場合には、お客様に代わって当社がクラスターにパッチを適用する可能性があります。

新しいクラスターを作成する際に、現在サポートされているどのバージョンでも (マイナーやメジャー) でも指定できます。サポートされているエンジンバージョンリリースにアップグレードする場合、クラスターで [変更] オプションを選択します。[キャッシュエンジンバージョン] フィールドで、アップグレード先のバージョンを指定します。アップグレードは、[即時に実行] オプションがチェックされている場合は即時に実行されます。または、次に予定されているクラスターのメンテナンスウィンドウに実行されます。

はい。これを実行するには、新しいエンジンバージョンを指定して新しいクラスターを作成します。開発/ステージングアプリケーションをこのクラスターに指定し、テストしてから、元のクラスターをアップグレードするかどうか決めることができます。

今後、当社では ElastiCache に対してさらに多くの Memcached バージョンを、メジャーとマイナーの両方ともサポートする予定です。毎年サポートされる新しいバージョンリリースの数は、Memcached バージョンリリースの頻度とコンテンツ、AWS のエンジニアリングチームによるリリースの徹底的な診断結果により異なります。

変更プロセスによって、既存の Memcached クラスターをアップグレードできます。古いバージョンの Memcached から Memcached バージョン 1.4.33 以降にアップグレードする際には、既存のパラメータ max_chunk_size の値が slab_chunk_max パラメータに必要な条件を満たしていることを確認してください。アップグレードの前提条件をご確認ください。

ElastiCache は、I/O スレッドが強化されており、多重化やプレゼンテーションレイヤーのオフロードなどにより、大規模なスループットと待機時間を大幅に改善します。拡張された I/O スレッドは、I/O の処理に多くのコアを活用し、ワークロードを動的に調整することでパフォーマンスを向上させます。ElastiCache は、暗号化を同じ拡張された I/O スレッドにオフロードすることで、TLS 対応クラスターのスループットを向上させます。ElastiCache (Redis OSS) バージョン 7.0 では、拡張された I/O 多重化が導入されました。これにより、多数のクライアントリクエストが 1 つのチャネルにまとめられ、スレッドの効率が向上しました。

Redis OSS 用 ElastiCache バージョン 7.1 以降では、拡張 I/O スレッド機能が拡張され、プレゼンテーションレイヤーロジックも処理できるようになりました。拡張された I/O スレッドは、クライアント入力を読み取るだけでなく、その入力をバイナリコマンド形式に解析し、それをメインスレッドに転送して実行することで、パフォーマンスを向上させます。Redis OSS 用 ElastiCache バージョン 7.1 では、以前のバージョンと比較して、スループットが最大 100% 向上し、P99 レイテンシーが 50% 低下しています。r7g.4xlarge 以上では、1 ノードあたり 100 万回を超えるリクエスト/秒 (RPS) を達成できます。

ElastiCache には、キャッシュデプロイの選択に応じて、キャッシュの CPU 使用率を測定するための 2 つの異なるメトリクスセットが用意されています。ElastiCache サーバーレスを使用する場合、ElastiCache プロセッシングユニット (ECPU) メトリクスを使用して CPU 使用率をモニタリングできます。リクエストによって消費される ECPU の数は、かかる vCPU 時間と転送されるデータ量によって異なります。Redis OSS の GET コマンドと SET コマンド、または Memcached の get コマンドと set コマンドのように、読み取りと書き込みを行うたびに、転送されるデータの 1 キロバイト (KB) あたり 1 つの ECPU が必要です。インメモリデータ構造を操作する Redis OSS コマンドの中には、GET または SET コマンドよりも vCPU 時間を多く消費する可能性のあるものがあります。ElastiCache は、SET または GET コマンドでかかった vCPU 時間のベースラインと比較して、コマンドによって使用された vCPU 時間に基づいて消費された ECPU 数を計算します。コマンドに vCPU 時間が余分にかかり、1 ECPU のベースラインを超えるデータを転送する場合、ElastiCache は 2 つのディメンションのうち大きい方に基づいて必要な ECPU を計算します。

独自のクラスターを設計する場合、EngineCPUUtilization と CPUUtilization を監視できます。CPUUtilization メトリクスはインスタンス (ノード) の CPU 使用率を測定し、EngineCPUUtilization メトリクスはエンジンプロセスレベルの使用率を測定します。CPUUtilization メトリクスに加えて EngineCPUUtilization メトリクスも必要になるのは、メインの Redis OSS プロセスがシングルスレッドであり、インスタンスで利用できる複数 CPU コアのうち 1 CPU のみを使用するためです。このため、CPUUtilization メトリクスではエンジンプロセスレベルでの CPU 使用率を正確に把握することができません。CPUUtilization メトリクスと EngineCPUUtilization メトリクスの両方を使用して、Redis OSS クラスターの CPU 使用状況の詳細を把握することをお勧めいたします。

これらのメトリクスのセットはすべての AWS リージョンで使用でき、Amazon CloudWatch を使用するか、コンソールを通じてアクセスできます。さらに、パフォーマンスモニタリングに役立つメトリクスについては、このドキュメントを参照することをお勧めします。

リードレプリカは Redis OSS 内で以下の 2 つの用途で使用されます。

• 障害処理
• 読み込みのスケーリング

リードレプリカを含むキャッシュを実行すると、「プライマリ」が書き込みと読み込みの両方を行います。レプリカは読み取りトラフィックのみを処理し、プライマリに障害が発生した場合のウォームスタンバイとしても使用できます。

ElastiCache サーバーレスでは、リードレプリカはサービスによって自動的に管理されます。独自のキャッシュを設計する場合、特定のプライマリノードに 1 つ以上のリードレプリカをデプロイすることが理にかなっている可能性があるさまざまなシナリオがあります。リードレプリカをデプロイする一般的な理由:

• 読み取り負荷の高いワークロードで、1 つのプライマリノードのコンピューティングまたは I/O キャパシティを超えるスケーリングを行う場合:この過剰な読み取りトラフィックは、1 つ以上のリードレプリカに送られます。
• プライマリが利用できない間、読み取りトラフィックに対応する: お客様のプライマリノードが入出力リクエストを取得できない場合 (バックアップまたは定期メンテナンスによる入出力一時停止のため)、読み込みトラフィックをリードレプリカに誘導することができます。このようなユースケースの場合、プライマリインスタンスを利用できないため、リードレプリカのデータは「古い」場合があるため注意が必要です。リードレプリカを使用して、障害が発生したプライマリのウォームアップを再起動することもできます。
• データ保護のシナリオ: 予期せぬイベント、プライマリノードの障害、またはプライマリノードが属する AZ が使用できなくなった場合、別の AZ 内にあるリードレプリカを新しいプライマリに昇格させることができます。 

リードレプリカには、プライマリキャッシュノードに接続するのと同じように接続できます。リードレプリカが複数ある場合、読み込みトランザクションがどのように誘導されるかはアプリケーションに依存します。こちらが詳細です:

• Redis (クラスターモードが無効) OSS クラスターの場合、読み取り操作には個々のノードエンドポイントを使用します。(API/CLI では、これらは読み取りエンドポイントと呼ばれます。)
• Redis OSS (クラスターモードが有効化されている)クラスターは、クラスターの全操作で設定エンドポイントを使用します。個々のノードエンドポイントから引き続き読み取ることができます。(API と CLI では、これらは読み取りエンドポイントと呼ばれます。)

ElastiCache では、1 つのプライマリキャッシュノードに対して最大 5 個のリードレプリカを作成できます。

フェイルオーバーが発生し、関連付けられた利用可能なリードレプリカがある場合、フェイルオーバーが完了すると自動的にレプリケーションが再開されます (新しく昇格したリードレプリカから更新データが取得されます)。

プライマリキャッシュノードの更新は、あらゆる関連したリードレプリカに対して自動的にレプリケーションが実行されます。ただし、Redis OSS の非同期レプリケーションテクノロジーを使うと、さまざまな理由によりリードレプリカがプライマリキャッシュノードより遅れることがあります。一般的な理由:

• プライマリキャッシュノードに対する書き込みの入出力量が、変更をリードレプリカに適用できる速度を超えている。
• ネットワークパーティション、またはプライマリキャッシュノードとリードレプリカ間にレイテンシーがある。

リードレプリカは、Redis OSS レプリケーションの長所と短所の影響を受けます。リードレプリカを使う場合は、リードレプリカとそのプライマリキャッシュノードの間に遅延または「矛盾」が発生する可能性があることを理解しておく必要があります。 ElastiCache は、不整合を理解できるよう支援するメトリクスを発行します。

リードレプリカの使用料金は、標準キャッシュノードと同じ料金で請求されます。標準のキャッシュノードと同様に、リードレプリカのキャッシュノード時間あたりの料金は、リードレプリカのキャッシュノードクラスによって決定さ れます。最新の価格については、ElastiCache の価格ページをご覧ください。プライマリキャッシュノードとリードレプリカ間のデータレプリケーションに発生したデータ転送に対しては請求されません。リードレプリカの請求は、そのレプリカを作成 (一覧のステータスが「アクティブ」になるなど) してから開始します。リードレプリカは、削除するコマンドを発行するまで標準 ElastiCache キャッシュノードの時間料金で請求されます。

開始されるフェイルオーバーは ElastiCache でサポートされているため、すばやくキャッシュ操作を再開できます。フェイルオーバーが行われると、ElastiCache はキャッシュノードの DNS レコードを反転させ、リードレプリカを示します。このリードレプリカが新しいプライマリに昇格します。ベストプラクティスに沿って、アプリケーションレイヤーでキャッシュノード接続を再試行することを推奨いたします。通常、開始から終了まで、以下のステップ 1 ～ 5 は 6 分以内に完了します。

これらは自動フェイルオーバーイベントであり、発生順に表示されています。

1. レプリケーショングループメッセージ: ノードグループ <node-group-id> に対して呼び出されたフェイルオーバー API のテスト
2. キャッシュクラスターメッセージ: プライマリノード <primary-node-id> からレプリカノード <node-id> へのフェイルオーバーが完了しました
3. レプリケーショングループメッセージ: プライマリノード <primary-node-id> からレプリカノード <node-id> へのフェイルオーバーが完了しました
4. キャッシュクラスターメッセージ: キャッシュノード <node-id> の復旧
5. キャッシュクラスターメッセージ: キャッシュノード <node-id> の復旧が終了しました

リードレプリカは、キャッシュノードプライマリと同じリージョンに属する、同じまたは別の AZ にのみプロビジョニングできます。 ただし、Global Datastore を使用すれば、AWS リージョン間で高速かつ信頼性が高く、安全重視のフルマネージド型のレプリケーションを操作できます。この機能を使用すると、ElastiCache のリージョン間リードレプリカクラスターを作成して、AWS リージョン全体で低レイテンシーのリードとディザスタリカバリを有効にできます。

はい。コンソールまたは DescribeCacheClusters API を使用して、現在のプライマリロケーションを確認できます。

はい。クラスター環境では、1 つまたは複数のシャードにわたってリードレプリカを追加または削除できます。クラスターがオンラインのままで、この操作の間 I/O 受信を行います。

マルチ AZ は、独自の ElastiCache キャッシュを設計する際に、より可用性の高い構成で実行できるようにする機能です。すべての ElastiCache サーバーレスキャッシュは、マルチ AZ 構成で自動的に実行されます。ElastiCache レプリケーショングループはプライマリレプリカと最大 5 つのリードレプリカで構成されます。マルチ AZ が有効になっている場合は、プライマリごとに少なくとも 1 つのレプリカが必要です。特定の種類の計画されたメンテナンス中、または ElastiCache ノード障害、AZ 障害などの予期しないイベントが発生している間、プライマリの障害検知、リードレプリカの選択、新しいプライマリへの昇格が ElastiCache によって自動的に実行されます。また、ElastiCache は昇格したリードレプリカの DNS の変更を伝達します。そのためアプリケーションがプライマリノードのエンドポイントへの書き込み中である場合、エンドポイントの変更は必要ではありません。

マルチ AZ モードで ElastiCache を実行する主な利点は、拡張された可用性と、管理の必要性が少なくなることにあります。マルチ AZ 構成で ElastiCache を実行している場合、キャッシュは 99.99% の可用性 SLA の対象となります。ElastiCache のプライマリノードに障害が発生した場合、自動フェイルオーバーが完了するまでの間のプライマリへの読み取り/書き込み能力への影響が限定されます。マルチ AZ が有効になっている場合、ElastiCache ノードフェイルオーバーは自動的に作動し、管理の必要がありません。 

ElastiCache を利用する際、レプリケーショングループ内にプライマリノードと、1 つ以上のリードレプリカがある場合にマルチ AZ を使用できます。プライマリノードに障害が発生すると、ElastiCache は自動的に障害を検知し、利用可能なリードレプリカを 1 つ選択し、新しいプライマリに昇格させます。ElastiCache は昇格したレプリカの DNS の変更を伝達します。そのためアプリケーションはプライマリのエンドポイントに書き込み続けることが可能です。また、ElastiCache では、障害が発生したプライマリの AZ に、昇格したリードレプリカを置き換えるための新しいノードがスピンアップされます。プライマリの障害が、一時的な AZ の中断によって起きた場合、AZ の復旧後に新しいレプリカが起動します。

はい。同じ AZ にプライマリとレプリカの両方を配置する場合、AZ の中断に対する ElastiCache のレプリケーショングループの柔軟性が与えられないことに注意してください。また、マルチ AZ がオンになっている場合は、プライマリと同じ AZ にレプリカを置くことはできません。

ElastiCache は、以下のイベントにおいてリードレプリカへのフェイルオーバーを行います。

• プライマリ AZ での可用性の喪失
• プライマリに対するネットワーク接続の喪失
• プライマリ上でのコンピュートユニット障害

リードレプリカが 2 つ以上ある場合、非同期レプリケーションのプライマリへの遅延が最も小さいものが昇格されます。

はい、ElastiCache は自動フェイルオーバーが発生したことをお知らせするイベントを作成します。DescribeEvents API を使用して、ElastiCache ノードに関連するイベントについての情報を返すことができます。または、ElastiCache マネジメントコンソールの [イベント] セクションを選択します。

AZ は、同じリージョン内の他の AZ に低レイテンシーのネットワーク接続を提供するように設計されています。1 つの AZ が中断した場合でもお客様のアプリケーションの柔軟性を保つため、アプリケーションや他の AWS リソースに複数の AZ による冗長性を持たせるようアーキテクチャーを設計することもできます。

マルチ AZ の詳細については、ElastiCache のドキュメントを参照してください。

バックアップと復元は、お客様が ElastiCache キャッシュのスナップショットを作成できるようにする機能です。ElastiCache はスナップショットを保存し、その後ユーザーがそのスナップショットを使用してキャッシュを復元できるようにします。これは現在、ElastiCache for Valkey、ElastiCache for Redis OSS、サーバーレスでサポートされています。 

スナップショットを作成しておくと、ノード障害によってデータ損失が発生した場合や、万が一ハードウェア障害が発生した場合に役立ちます。バックアップを使用する別の一般的な理由はアーカイブを目的とするものです。スナップショットは Amazon S3 に保存されます。

バックアップが開始されると、ElastiCache は指定されたキャッシュのスナップショットを作成します。このスナップショットは、後で復旧またはアーカイブに使用できます。バックアップはユーザーが選択する任意のタイミングで開始することも、保持期間が最長 35 日のバックアップが毎日作成されるように設定することもできます。復元するスナップショットを選択すると、新しい ElastiCache キャッシュが作成され、スナップショットのデータが入力されます。ElastiCache スナップショットは Redis OSS RDB ファイル形式と互換性があります。

バックアップと復元機能は、コンソール、ElastiCache API、および AWS CLI を通じて使用できます。この機能はいつでも無効化または再度アクティブ化することが可能です。

バックアップと復元機能では、キャッシュごとにスナップショットが作成されます。ユーザーは、コンソール、AWS CLI、または ElastiCache API を使用して、どの ElastiCache キャッシュをバックアップするかを指定できます。プライマリへの影響を最小限に抑えるため、キャッシュのリードレプリカの 1 つでバックアップを有効にすることをお勧めします。ElastiCache サーバーレスを使用すると、バックアップはリードレプリカに対して自動的に実行されます。

ElastiCache スナップショットは、リージョン内にある認可された S3 バケットにクラスターとしてエクスポートできます。

はい。まず、スナップショットを同じリージョン内で選択した、認可された S3 バケットにコピーしてから、別のアカウントにクロスアカウントバケットアクセス許可を付与します。

Amazon ElastiCache では、アクティブな ElastiCache キャッシュごとに、1 つのスナップショットのストレージ領域を無料で利用できます。追加のストレージは、スナップショットで使用される容量に基づいて、毎月 0.085 USD/GB (すべてのリージョンで同じ料金) で課金されます。スナップショットを使用するためのデータ転送は無料です。

ElastiCache キャッシュを削除しても、手動スナップショットは保持されます。キャッシュが削除される前に最終スナップショットを作成するオプションもあります。自動キャッシュスナップショットは保持されません。

ElastiCache 内のエンジンは Redis OSS と完全互換ですが、堅牢性と安定性を向上させるための強化が図られています。以下のような点が強化されています。

• メモリの可用性の強化: 同期やスナップショットの間にスワップ使用率が増加するというリスクなしに、アプリケーションにより多くのメモリを安全に割り当てられるようになりました。
• 同期の向上: 高負荷状態やネットワーク切断からの回復時の同期の堅牢性が向上しました。さらに、このオペレーションにディスクが使用されなくなったため、プライマリとレプリカの両方について同期速度が向上しました。
• より円滑なフェイルオーバー: フェイルオーバーの発生時に、プライマリとの完全再同期を実行するためのレプリカデータのフラッシュが行われなくなったため、シャードの回復速度が向上しました。
• TLS オフロードと IO 多重化:ElastiCache は、特定のネットワーク関連プロセスを専用スレッドで処理することで、利用可能な CPU リソースをより有効に活用するように設計されています。

いいえ、強化されたエンジンは Redis OSS と完全互換であるため、アプリケーションのコードにはまったく手を加えずに、向上した堅牢性と安定性を利用できます。

強化されたエンジンは追加料金なしで使用できます。

保管時の暗号化は、データへの不正アクセスを防ぐためのメカニズムを提供します。有効にすると、次の項目が暗号化されます。

• 同期、バックアップ、およびスワップ操作中のディスク
• Amazon S3 に保存されているバックアップ

ElastiCache は保管時の (サービス管理) 暗号化をデフォルトで提供します。さらに、独自の対称カスタマープライマリキーを AWS (KMS) の AWS KMS キーで使用する機能も提供します。詳細については、保存時の暗号化をご覧ください。

転送時の暗号化機能は、クライアントと ElastiCache 間、およびサーバー (プライマリとリードレプリカ) 間の通信の暗号化を容易にします。ElastiCache の転送中暗号化の詳細については、こちらをご覧ください。

転送中の暗号化、保存時の暗号化、Redis OSS AUTH、およびロールベースアクセス制御 (RBAC) は、ElastiCache キャッシュの作成時に選択できる機能です。転送中の暗号化を有効にした場合は、セキュリティとアクセスコントロールを強化するために Redis OSS AUTH または RBAC を使用することを選択できます。

いいえ。証明書の有効期限と更新は、ElastiCache によってユーザーから見えない形で管理されます。実行中の証明書の管理に必要なユーザーの操作はありません。

いいえ、暗号化の使用に追加のコストはかかりません。

グローバルデータストアは、ElastiCache の機能の 1 つです。高速で、信頼性が高く、安全重視のフルマネージド型クロスリージョンレプリケーションを実現できます。グローバルデータストアを使用すると、1 つのリージョンでキャッシュに書き込みながら、他の 2 つのクロスリージョンレプリカクラスターでのデータ読み取りも実現できます。これにより、リージョンをまたいだ低レイテンシーの読み取りおよびディザスタリカバリが可能となります。

グローバルデータストアは、グローバルなフットプリントを持つリアルタイム・アプリケーション向けに設計されており、通常 1 秒以内にリージョン間でデータをレプリケートするので、エンドユーザーに近い場所でジオローカルな読み取りを行うことができ、アプリケーションの応答性が向上します。まれにリージョンの劣化が発生した場合、健全なクロスリージョンレプリカキャッシュの 1 つを、完全な読み取り/書き込み機能を持つプライマリに昇格させることができます。昇格は通常、開始後 1 分以内に完了し、このためアプリケーションは中断することなく利用可能です。

最大で、グローバルデータストアに含まれる 2 つのセカンダリリージョンにレプリケートすることができます。セカンダリリージョンのキャッシュを、低レイテンシーのローカル読み取り用として、および万一リージョンにサービス品質の低下が発生した場合のディザスタリカバリとして使用できます。

グローバルデータストアは、ElastiCache for Redis 5.0.6 以降でサポートされています。

いいえ。ElastiCache では、プライマリクラスター (リージョン) に品質低下が発生したときに、セカンダリクラスターを自動的に昇格させることはありません。セカンダリクラスターをプライマリに昇格して手動でフェイルオーバーを開始することは可能です。フェイルオーバーとセカンダリクラスターの昇格は、通常 1 分未満で完了します。

グローバルデータストアは、クロスリージョントラフィックに対して転送中の暗号化を使用して、データを安全に保ちます。さらに、プライマリとセカンダリのキャッシュを暗号化し、データをより安全に保護することもできます。プライマリキャッシュとセカンダリキャッシュにはそれぞれ、保存時の暗号化用に顧客管理の AWS KMS キーを個別に設定できます。

ElastiCache では、RPO と RTO について SLA を提供していません。RPO はリージョン間のレプリケーションの遅延によって異なり、リージョン間のネットワークレイテンシーとクロスリージョンネットワークトラフィックの混雑状態の影響も受けます。グローバルデータストアの RPO は通常 1 秒未満です。そのため、プライマリリージョンに書き込まれたデータは、1 秒以内にセカンダリリージョンでも利用可能になります。Global Datastore の RTO は通常 1 分未満です。セカンダリクラスターへのフェイルオーバーが始まると、ElastiCache では通常 1 分未満でセカンダリを昇格し、読み書き機能を全面的に回復させます。

ElastiCache では、RPO と RTO について SLA を提供していません。RPO はリージョン間のレプリケーションの遅延によって異なり、リージョン間のネットワークレイテンシーとクロスリージョンネットワークトラフィックの混雑状態の影響も受けます。グローバルデータストアの RPO は通常 1 秒未満です。そのため、プライマリリージョンに書き込まれたデータは、1 秒以内にセカンダリリージョンでも利用可能になります。Global Datastore の RTO は通常 1 分未満です。セカンダリクラスターへのフェイルオーバーが始まると、ElastiCache では通常 1 分未満でセカンダリを昇格し、読み書き機能を全面的に回復させます。

データ階層化はデータをメモリに保存するだけでなく、各クラスターノードに搭載された低コストのソリッドステートドライブ (SSD) を利用することで、新たな料金パフォーマンスの選択肢を提供します。データセット全体の最大 20％ に定期的にアクセスするワークロードや、SSD 上のデータにアクセスする際に追加のレイテンシーを許容できるアプリケーションに最適です。メモリと SSD を搭載した ElastiCache R6gd ノードは、メモリのみを搭載した ElastiCache R6g ノードと比較して、総ストレージ容量が約 5 倍となり、最大使用時の価格を 60% 以上削減することができます。

データ階層化は、利用可能なメモリ容量が完全に消費されると、自動的かつ透過的に、最後の使用から最も長時間が経過した項目をメモリからローカルに接続された NVMe SSD に移動させることで機能します。SSD に移動した項目がその後アクセスされると、ElastiCache はリクエストに応える前に非同期でメモリに戻します。

データ階層化は、アプリケーションのパフォーマンスへの影響を最小限に抑えるように設計されています。500 バイトの文字列値を想定した場合、SSD に保存されたデータへのリクエストは、メモリ上のデータへのリクエストと比較して、平均で 300 マイクロ秒の追加レイテンシーが予想されます。

ElastiCache は、ElastiCache for Redis OSS のバージョン 6.2 以降のデータ階層化をサポートしています。

ElastiCache は、R6gd ノードを使用してクラスターのデータ階層化をサポートしています。

データ階層化を使用する場合、すべての Valkey または Redis OSS コマンドとほとんどの ElastiCache 機能がサポートされます。データ階層化を使用しているクラスターでサポートされていない機能のリストは、ドキュメントを参照してください。

データ階層化を使用しても、ノードの時間当たりのコスト以外に追加のコストはかかりません。データ階層化を搭載したノードは、オンデマンドの料金で、リザーブドノードとして利用できます。料金については、ElastiCache の料金ページをご覧ください。