マルチ AZ による ElastiCache (Redis OSS) のダウンタイムの最小化 - Amazon ElastiCache (Redis OSS）
マルチ AZ の有効化 障害シナリオとマルチ AZ のレスポンス自動フェイルオーバーのテストマルチ AZ に関する注意事項

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

マルチ AZ による ElastiCache (Redis OSS) のダウンタイムの最小化

ElastiCache (Redis OSS) がプライマリノードを置き換える必要があるインスタンスは多数あります。これには、特定のタイプの計画的なメンテナンスや、プライマリノードまたはアベイラビリティーゾーンの障害が発生する可能性が低いことが含まれます。

この置き換えにより、クラスターのダウンタイムが発生しますが、マルチ AZ が有効になっている場合、ダウンタイムは最小限に抑えられます。プライマリノードのロールは、いずれかのリードレプリカに自動的にフェイルオーバーされます。はこれを透過的に ElastiCache 処理するため、新しいプライマリノードを作成してプロビジョニングする必要はありません。このフェイルオーバーとレプリカの昇格により、昇格が完了したらすぐに新しいプライマリへの書き込みを再開できます。

ElastiCache は、昇格されたレプリカのドメインネームサービス (DNS) 名も伝播します。これを行うのは、アプリケーションがプライマリエンドポイントに書き込みを行う場合、アプリケーションでエンドポイントの変更が必要なくなるためです。個別のエンドポイントから読み取りを行う場合は、プライマリに昇格されたレプリカの読み取りエンドポイントを新しいレプリカのエンドポイントに変更してください。

メンテナンス更新やセルフサービス更新に伴って開始された計画的なノード置換の場合:

  • ElastiCache (Redis OSS) クラスターの場合、クラスターが受信書き込みリクエストを処理する間に、計画されたノード交換が完了します。

  • 5.0.6 以降のエンジンで実行されているマルチ AZ が有効になっている Redis OSS クラスターモードが無効になっているクラスターの場合、クラスターが受信書き込みリクエストを処理する間に、計画されたノードの置き換えが完了します。

  • 4.0.10 以前のエンジンで実行されているマルチ AZ が有効になっている Redis OSS クラスターモードが無効になっているクラスターでは、DNS 更新に関連する短い書き込み中断が発生することがあります。この中断は数秒続く場合があります。このプロセスは、新しいプライマリを再作成してプロビジョニングする (マルチ AZ を有効にしない場合に発生すること) よりもはるかに高速です。

マルチ AZ は、 ElastiCache マネジメントコンソール、 AWS CLI、または ElastiCache API を使用して有効にできます。

Redis OSS クラスター (API および CLI、レプリケーショングループ) で ElastiCache マルチ AZ を有効にすると、耐障害性が向上します。これは特に、クラスターの読み取り/書き込みプライマリクラスタノードが到達できなくなった場合、または何らかの理由で障害が発生した場合に当てはまります。マルチ AZ は、各シャードに複数のノードがある Redis OSS クラスターでのみサポートされます。

マルチ AZ の有効化

ElastiCache コンソール、または API を使用してクラスター (API または CLI、レプリケーショングループ) を作成または ElastiCache変更するときに AWS CLI、マルチ AZ を有効にできます。

マルチ AZ は、使用可能なリードレプリカが少なくとも 1 つある Redis OSS (クラスターモードが無効) クラスターでのみ有効にできます。リードレプリカのないクラスターでは、高可用性や耐障害性は提供されません。レプリケーションが有効なクラスターの作成については、「Redis OSS レプリケーショングループの作成」を参照してください。レプリケーションが有効なクラスターへのリードレプリカの追加については、「Redis OSS (クラスターモードが無効) レプリケーショングループ用のリードレプリカの追加」を参照してください。

マルチ AZ の有効化 (コンソール)

コンソールを使用してマルチ AZ を有効にするには、新しい Redis OSS クラスターを作成する ElastiCache とき、またはレプリケーションを使用して既存の Redis OSS クラスターを変更します。

マルチ AZ は、Redis OSS (クラスターモードが有効) クラスターでデフォルトで有効になっています。

重要

ElastiCache は、クラスターにすべてのシャードのプライマリとは異なるアベイラビリティーゾーンに少なくとも 1 つのレプリカが含まれている場合にのみ、マルチ AZ を自動的に有効にします。

ElastiCache コンソールを使用してクラスターを作成するときにマルチ AZ を有効にする

このプロセスの詳細については、「Redis OSS (クラスターモードが無効) クラスターの作成 (コンソール）」を参照してください。必ず 1 つ以上のレプリカを用意して、マルチ AZ を有効にしてください。

既存のクラスターでのマルチ AZ の有効化 (コンソール)

このプロセスの詳細については、「の使用 AWS Management Console」でクラスターの変更に関する説明を参照してください。

マルチ AZ の有効化 (AWS CLI)

次のコード例では、 を使用して AWS CLI レプリケーショングループ のマルチ AZ を有効にしますredis12。

重要

レプリケーショングループ redis12 が既に存在しており、少なくとも 1 個の利用可能なリードレプリカが必要となります。

Linux、macOS、Unix の場合:

aws elasticache modify-replication-group \
    --replication-group-id redis12 \
    --automatic-failover-enabled \
    --multi-az-enabled \
    --apply-immediately

Windows の場合:

aws elasticache modify-replication-group ^
    --replication-group-id redis12 ^
    --automatic-failover-enabled ^
    --multi-az-enabled ^
    --apply-immediately

このコマンドの JSON 出力は次のようになります。

{
    "ReplicationGroup": {
        "Status": "modifying", 
        "Description": "One shard, two nodes", 
        "NodeGroups": [
            {
                "Status": "modifying", 
                "NodeGroupMembers": [
                    {
                        "CurrentRole": "primary", 
                        "PreferredAvailabilityZone": "us-west-2b", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis12-001.v5r9dc.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis12-001"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2a", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis12-002.v5r9dc.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis12-002"
                    }
                ], 
                "NodeGroupId": "0001", 
                "PrimaryEndpoint": {
                    "Port": 6379, 
                    "Address": "redis12.v5r9dc.ng.0001.usw2.cache.amazonaws.com"
                }
            }
        ], 
        "ReplicationGroupId": "redis12", 
        "SnapshotRetentionLimit": 1, 
        "AutomaticFailover": "enabling", 
        "MultiAZ": "enabled", 
        "SnapshotWindow": "07:00-08:00", 
        "SnapshottingClusterId": "redis12-002", 
        "MemberClusters": [
            "redis12-001", 
            "redis12-002"
        ], 
        "PendingModifiedValues": {}
    }
}

詳細については、AWS CLI コマンドリファレンスの以下のトピックを参照してください。

マルチ AZ の有効化 (ElastiCache API)

次のコード例では、 ElastiCache API を使用してレプリケーショングループ のマルチ AZ を有効にしますredis12。

注記

この例を使用するには、レプリケーショングループ redis12 が既に存在していて、少なくとも 1 個の利用可能なリードレプリカがある必要があります。

https://elasticache.us-west-2.amazonaws.com/
    ?Action=ModifyReplicationGroup
    &ApplyImmediately=true
    &AutoFailover=true
    &MultiAZEnabled=true
    &ReplicationGroupId=redis12
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20140401T192317Z
    &X-Amz-Credential=<credential>

詳細については、 ElastiCache API リファレンスの以下のトピックを参照してください。

障害シナリオとマルチ AZ のレスポンス

マルチ AZ の導入前に、 は、障害が発生したノードを再作成して再プロビジョニングすることで、クラスターの障害が発生したノード ElastiCache を検出して置き換えました。マルチ AZ を有効にすると、失敗したプライマリノードはレプリケーションの遅延が最も小さいレプリカにフェイルオーバーされます。選択されたレプリカは自動的にプライマリに昇格されます。このプロセスは、新しいプライマリノードを作成して再プロビジョニングするよりも大幅に高速です。通常は数秒で、クラスターへの書き込みが再び可能になります。

マルチ AZ が有効になっている場合は、プライマリノードの状態 ElastiCache を継続的にモニタリングします。プライマリノードが失敗すると、失敗のタイプに応じて次のいずれかのアクションが実行されます。

プライマリノードのみが失敗した場合の障害シナリオ

プライマリノードのみが失敗した場合、レプリケーションの遅延が最も小さいリードレプリカがプライマリに昇格されます。次に、失敗したプライマリと同じアベイラビリティーゾーンに置換リードレプリカが作成されてプロビジョニングされます。

プライマリノードのみが失敗した場合、 ElastiCache マルチ AZ は以下を実行します。

  1. 失敗したプライマリノードがオフラインになります。

  2. レプリケーションの遅延が最短のリードレプリカがプライマリに昇格されます。

    書き込みは、昇格プロセスが完了するとすぐに (通常は数秒) 再開できます。アプリケーションがプライマリエンドポイントに書き込む場合、書き込みまたは読み取りのエンドポイントを変更する必要はありません。 ElastiCache は昇格されたレプリカの DNS 名を伝播します。

  3. 置き換えられたリードレプリカが起動し、プロビジョニングされます。

    ノードのディストリビューションが維持されるように、障害が発生したプライマリノードがあったアベイラビリティーゾーンで置き換えリードレプリカが起動されます。

  4. レプリカが新しいプライマリノードと同期されます。

新しいレプリカが使用可能になった後は、次の影響に注意してください。

  • [プライマリエンドポイント] – 新しいプライマリノードの DNS 名がプライマリエンドポイントに伝達されるため、アプリケーションに変更は加えません。

  • [読み取りエンドポイント] – 読み取りエンドポイントは、新しいレプリカノードを指すように自動的に更新されます。

クラスターのエンドポイントの検索については、以下のトピックを参照してください。

 

プライマリノードと複数のリードレプリカが失敗した場合の障害シナリオ

プライマリおよび少なくとも 1 つのリードレプリカで障害が発生した場合、利用可能でレプリケーションの遅延が最も少ないレプリカが、プライマリクラスターに昇格されます。また、障害が発生したノードおよびプライマリに昇格されたレプリカと同じアベイラビリティーゾーンで、新しいリードレプリカが作成およびプロビジョニングされます。

プライマリノードと一部のリードレプリカが失敗すると、 ElastiCache マルチ AZ は以下を実行します。

  1. 障害が発生したプライマリノードとリードレプリカがオフラインになります。

  2. レプリケーションの遅延が最短の使用可能なレプリカがプライマリノードに昇格されます。

    書き込みは、昇格プロセスが完了するとすぐに (通常は数秒) 再開できます。アプリケーションがプライマリエンドポイントに書き込む場合、書き込みのエンドポイントを変更する必要はありません。 は昇格されたレプリカの DNS 名を ElastiCache 伝播します。

  3. 複数の置き換えレプリカを作成してプロビジョニングします。

    ノードのディストリビューションが維持されるように、障害が発生したノードのアベイラビリティーゾーンで置き換えレプリカが作成されます。

  4. すべてのクラスターが新しいプライマリノードと同期されます。

新しいノードが使用可能になったら、アプリケーションに以下の変更を行います。

  • [プライマリエンドポイント] – アプリケーションは変更しないでください。新しいプライマリノードの DNS 名がプライマリエンドポイントに伝達されます。

  • [読み取りエンドポイント] – 読み取りエンドポイントは、新しいレプリカノードを指すように自動的に更新されます。

レプリケーショングループのエンドポイントの検索については、次のトピックを参照してください:

 

クラスター全体が失敗した場合の障害シナリオ

すべてに障害が発生した場合、すべてのノードは、元のノードと同じアベイラビリティーゾーンで再作成され、プロビジョニングされます。

このシナリオでは、クラスター内のすべてのデータがクラスター内のすべてのノードの障害のために失われます。これはまれにしか発生しません。

クラスター全体が失敗すると、 ElastiCache マルチ AZ は以下を実行します。

  1. 障害が発生したプライマリノードとリードレプリカがオフラインになります。

  2. 置き換えプライマリノードが作成され、プロビジョニングされます。

  3. 複数の置き換えレプリカを作成してプロビジョニングします。

    ノードのディストリビューションが維持されるように、障害が発生したノードのアベイラビリティーゾーンで置き換えレプリカが作成されます。

    クラスター全体に障害が発生したため、データが失われ、すべての新しいノードがコールド起動されます。

置換先の各ノードと置換元のノードはエンドポイントが同じであるため、アプリケーションでエンドポイントを変更する必要はありません。

レプリケーショングループのエンドポイントの検索については、次のトピックを参照してください:

耐障害性レベルを上げるために、プライマリノードとリードレプリカは別々のアベイラビリティーゾーンに作成することをお勧めします。

自動フェイルオーバーのテスト

自動フェイルオーバーを有効にする AWS CLIと、 ElastiCache コンソール、、および ElastiCache API を使用してテストできます。

テストを行う場合、以下の点に注意してください。

  • このオペレーションを使用して、任意のローリング 24 時間で最大 15 個のシャード ( ElastiCache API および ではノードグループと呼ばれます AWS CLI) で自動フェイルオーバーをテストできます。

  • 別のクラスターのシャード (API および CLI ではレプリケーショングループと呼ばれます) でこのオペレーションを呼び出す場合、同時に呼び出しを行うことができます。

  • 場合によっては、同じ Redis OSS (クラスターモードが有効) レプリケーショングループの異なるシャードでこのオペレーションを複数回呼び出すことがあります。このような場合、後続の呼び出しを行う前に、最初のノードの置換が完了する必要があります。

  • ノードの交換が完了したかどうかを判断するには、Amazon ElastiCache コンソール、、 AWS CLIまたは ElastiCache API を使用してイベントを確認します。自動フェイルオーバーに関連する次のイベントを検索します。ここでは、発生すると思われる順番にイベントを示します。

    1. レプリケーショングループメッセージ: Test Failover API called for node group <node-group-id>

    2. キャッシュクラスターメッセージ: Failover from primary node <primary-node-id> to replica node <node-id> completed

    3. レプリケーショングループメッセージ: Failover from primary node <primary-node-id> to replica node <node-id> completed

    4. キャッシュクラスターメッセージ: Recovering cache nodes <node-id>

    5. キャッシュクラスターメッセージ: Finished recovery for cache nodes <node-id>

    詳細については、次を参照してください。

  • この API は、 ElastiCache フェイルオーバー時にアプリケーションの動作をテストするように設計されています。クラスターの問題に対処するためにフェイルオーバーを開始するための運用ツールとしては設計されていません。さらに、大規模な運用イベントなどの特定の条件下で AWS は、この API がブロックされる可能性があります。

を使用した自動フェイルオーバーのテスト AWS Management Console

コンソールで自動フェイルオーバーをテストするには、次の手順に従います。

自動フェイルオーバーをテストするには

  1. にサインイン AWS Management Console し、https://console.aws.amazon.com/elasticache/ で ElastiCache コンソールを開きます。

  2. ナビゲーションペインで、Redis OSS を選択します。

  3. Redis OSS クラスターのリストから、テストするクラスターの左側にあるボックスを選択します。このクラスターには、少なくとも 1 つのリードレプリカノードが必要です。

  4. Details エリアで、このクラスターでマルチ AZ が有効になっていることを確認します。クラスターでマルチ AZ が有効になっていない場合は、別のクラスターを選択するか、このクラスターを変更してマルチ AZ を有効にします。詳細については、「の使用 AWS Management Console」を参照してください。

    イメージ: マルチ AZ 対応 Redis OSS クラスターの詳細領域

  5. Redis OSS (クラスターモードが無効) では、クラスターの名前を選択します。

    Redis OSS (クラスターモードが有効) の場合は、次の操作を行います。

    1. クラスターの名前を選択します。

    2. [Shards] ページで、フェイルオーバーをテストするシャード (API および CLI ではノードグループと呼ばれます) のシャード名を選択します。

  6. [Nodes] ページで [Failover Primary] を選択します。

  7. Continue を選択してプライマリをフェイルオーバーするか、Cancel を選択してプライマリノードへのフェイルオーバーをキャンセルします。

    フェイルオーバープロセス中は、コンソールでノードのステータスが 使用可能 と継続して表示されます。フェイルオーバーテストの進捗状況を追跡するには、コンソールのナビゲーションペインから Events を選択します。Events タブで、フェイルオーバーの開始Test Failover API calledと完了Recovery completedを示すイベントを監視します。

 

を使用した自動フェイルオーバーのテスト AWS CLI

AWS CLI オペレーション を使用して、マルチ AZ 対応クラスターで自動フェイルオーバーをテストできますtest-failover。

パラメータ

  • --replication-group-id – 必須。テストするレプリケーショングループ (コンソールではクラスター)。

  • --node-group-id – 必須。自動フェイルオーバーをテストするノードグループの名前。24 時間周期で最大 15 個のノードグループをテストできます。

次の例では、 を使用して AWS CLI 、Redis OSS (クラスターモードが有効) クラスター redis00-0003のノードグループ で自動フェイルオーバーをテストしますredis00。

例 自動フェイルオーバーをテストする

Linux、macOS、Unix の場合:

aws elasticache test-failover \
   --replication-group-id redis00 \
   --node-group-id redis00-0003

Windows の場合:

aws elasticache test-failover ^
   --replication-group-id redis00 ^
   --node-group-id redis00-0003

上のコマンドによる出力は次のようになります。

{
    "ReplicationGroup": {
        "Status": "available", 
        "Description": "1 shard, 3 nodes (1 + 2 replicas)", 
        "NodeGroups": [
            {
                "Status": "available", 
                "NodeGroupMembers": [
                    {
                        "CurrentRole": "primary", 
                        "PreferredAvailabilityZone": "us-west-2c", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-001.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-001"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2a", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-002.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-002"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2b", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-003.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-003"
                    }
                ], 
                "NodeGroupId": "0001", 
                "PrimaryEndpoint": {
                    "Port": 6379, 
                    "Address": "redis1x3.7ekv3t.ng.0001.usw2.cache.amazonaws.com"
                }
            }
        ], 
        "ClusterEnabled": false, 
        "ReplicationGroupId": "redis1x3", 
        "SnapshotRetentionLimit": 1, 
        "AutomaticFailover": "enabled", 
        "MultiAZ": "enabled",
        "SnapshotWindow": "11:30-12:30", 
        "SnapshottingClusterId": "redis1x3-002", 
        "MemberClusters": [
            "redis1x3-001", 
            "redis1x3-002", 
            "redis1x3-003"
        ], 
        "CacheNodeType": "cache.m3.medium", 
        "DataTiering": "disabled",
        "PendingModifiedValues": {}
    }
}

フェイルオーバーの進行状況を追跡するには、 AWS CLI describe-eventsオペレーションを使用します。

詳細については、次を参照してください。

 

ElastiCache API を使用した自動フェイルオーバーのテスト

ElastiCache API オペレーション を使用して、マルチ AZ が有効になっているクラスターで自動フェイルオーバーをテストできますTestFailover。

パラメータ

  • ReplicationGroupId – 必須。テスト対象のレプリケーショングループ (コンソールではクラスター)。

  • NodeGroupId – 必須。自動フェイルオーバーをテストする対象のノードグループの名前。24 時間周期で最大 15 個のノードグループをテストできます。

次の例では、レプリケーショングループ (コンソールではクラスター) redis00 のノードグループ redis00-0003 で、自動フェイルオーバーをテストします。

例 自動フェイルオーバーのテスト
https://elasticache.us-west-2.amazonaws.com/
    ?Action=TestFailover
    &NodeGroupId=redis00-0003
    &ReplicationGroupId=redis00
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20140401T192317Z
    &X-Amz-Credential=<credential>

フェイルオーバーの進行状況を追跡するには、 API ElastiCache DescribeEventsオペレーションを使用します。

詳細については、次を参照してください。

 

Redis OSS マルチ AZ の制限事項

Redis OSS マルチ AZ では、次の制限に注意してください。

  • マルチ AZ は Redis OSS バージョン 2.8.6 以降でサポートされています。

  • Redis OSS マルチ AZ は T1 ノードタイプではサポートされていません。

  • Redis OSS レプリケーションは非同期です。そのため、プライマリノードがレプリカにフェイルオーバーすると、レプリケーションの遅延のために少量のデータが失われる可能性があります。

    プライマリに昇格するレプリカを選択すると、 ElastiCache (Redis OSS) はレプリケーションラグが最も少ないレプリカを選択します。言い換えると、最新のレプリカを選択します。これにより、失われるデータ量が最小限に抑えられます。レプリケーションの遅延が最短のレプリカは、障害が発生したプライマリノードと同じ、または異なるアベイラビリティーゾーンに存在できます。

  • リードレプリカを Redis OSS のプライマリに手動で昇格させる場合 (クラスターモードが無効）、マルチ AZ と自動フェイルオーバーが無効になっている場合にのみ昇格できます。リードレプリカをプライマリに昇格させるには、以下のステップを実行します。

    1. クラスターでマルチ AZ を無効にします。

    2. クラスターで自動フェイルオーバーを無効にします。これは、Redis OSS コンソールを使用して、レプリケーショングループの自動フェイルオーバーチェックボックスをオフにすることで実行できます。これを行うには、 ModifyReplicationGroupオペレーションを呼び出すfalseときに AutomaticFailoverEnabledプロパティを AWS CLI に設定します。

    3. リードレプリカをプライマリに昇格させます。

    4. マルチ AZ を再度有効にします。

  • ElastiCache (Redis OSS) マルチ AZ と追加専用ファイル (AOF) は相互に排他的です。一方を有効にすると、他方を有効にすることはできません。

  • アベイラビリティーゾーン全体の障害というまれなイベントにより、ノードの障害が発生することがあります。この場合、障害の発生したプライマリを置き換えるレプリカは、アベイラビリティーゾーンがバックアップされているときのみ作成されます。たとえば、AZ-a のプライマリおよび AZ-b および AZ-c のレプリカを持つレプリケーショングループを考えてみます。プライマリに障害が発生した場合、レプリケーションの遅延が最も小さい利用可能なレプリカをプライマリクラスターに昇格します。次に、 は、AZ-a がバックアップされ、使用可能である場合にのみ、AZ-a (障害が発生したプライマリが配置されている) に新しいレプリカ ElastiCache を作成します。

  • プライマリの再起動をお客様が開始した場合、自動フェイルオーバーはトリガーされません。他の再起動と障害は、自動フェイルオーバーをトリガーします。

  • プライマリが再起動すると、オンラインに戻ったときにデータがクリアされます。リードレプリカがクリアされたプライマリクラスターを検出すると、データのコピーがクリアされるため、データ損失が発生します。

  • リードレプリカが昇格されると、他のレプリカは新しいプライマリと同期されます。最初の同期後に、レプリカのコンテンツは削除され、新しいプライマリからデータが同期されます。この同期プロセスに伴って一時的に中断が発生し、その間はレプリカにアクセスできなくなります。また、この同期プロセスに伴ってレプリカとの同期中にプライマリで一時的にロードが増えます。この動作は Redis OSS にネイティブであり、マルチ AZ に ElastiCache固有ではありません。この Redis OSS の動作の詳細については、Redis OSS ウェブサイトの「レプリケーション」を参照してください。

重要

Redis OSS バージョン 2.8.22 以降では、外部レプリカを作成することはできません。

2.8.22 より前の Redis OSS バージョンでは、外部 Redis OSS レプリカをマルチ AZ が有効になっている ElastiCache (Redis OSS) クラスターに接続しないことをお勧めします。サポートされていない設定では、 がフェイルオーバーとリカバリを適切に実行 ElastiCache できない問題が発生する可能性があります。外部 Redis OSS レプリカを ElastiCache クラスターに接続するには、接続する前にマルチ AZ が有効になっていないことを確認してください。