翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Valkey と Redis でマルチ AZ ElastiCache を使用して のダウンタイムを最小限に抑える OSS
Valkey と Redis ElastiCache では、プライマリノードを置き換えるOSS必要があるインスタンスが多数あります。これには、特定のタイプの計画的なメンテナンスや、プライマリノードまたはアベイラビリティーゾーンの障害が発生する可能性の低いイベントが含まれます。
この置き換えにより、クラスターのダウンタイムが発生しますが、マルチ AZ が有効になっている場合、ダウンタイムは最小限に抑えられます。プライマリノードのロールは、いずれかのリードレプリカに自動的にフェイルオーバーされます。 ElastiCache はこれを透過的に処理するため、新しいプライマリノードを作成してプロビジョニングする必要はありません。このフェイルオーバーとレプリカの昇格により、昇格が完了したらすぐに新しいプライマリへの書き込みを再開できます。
ElastiCache は、昇格されたレプリカのドメインネームサービス (DNS) 名も伝達します。これを行うのは、アプリケーションがプライマリエンドポイントに書き込みを行う場合、アプリケーションでエンドポイントの変更が必要なくなるためです。個別のエンドポイントから読み取りを行う場合は、プライマリに昇格されたレプリカの読み取りエンドポイントを新しいレプリカのエンドポイントに変更してください。
メンテナンス更新やセルフサービス更新に伴って開始された計画的なノード置換の場合:
ElastiCache Valkey クラスターと Redis OSSクラスターの場合、クラスターが受信書き込みリクエストを処理する間に、計画されたノード置換が完了します。
5.0.6 以降のエンジンで実行されるマルチ AZ が有効になっている Valkey および Redis OSSクラスターモードが無効になっているクラスターの場合、クラスターが受信書き込みリクエストを処理する間、計画されたノード交換は完了します。
4.0.10 以前のエンジンで実行されるマルチ AZ が有効になっている Valkey および Redis OSSクラスターモードが無効になっているクラスターでは、DNS更新に関連する短時間の書き込み中断が発生することがあります。この中断は数秒続く場合があります。このプロセスは、新しいプライマリを再作成してプロビジョニングする (マルチ AZ を有効にしない場合に発生すること) よりもはるかに高速です。
マルチ AZ を有効にするには、 ElastiCache マネジメントコンソール、 AWS CLI、または を使用します ElastiCache API。
Valkey または Redis OSSクラスター ( APIおよび 、レプリケーショングループ) で ElastiCache マルチ AZ を有効にするとCLI、耐障害性が向上します。これは特に、クラスターの読み取り/書き込みプライマリクラスタノードが到達できなくなった場合、または何らかの理由で障害が発生した場合に当てはまります。マルチ AZ は、各シャードに複数のノードを持つ Valkey クラスターと Redis OSSクラスターでのみサポートされています。
マルチ AZ の有効化
マルチ AZ は、 ElastiCache コンソール、または を使用してクラスター (API または CLI、レプリケーショングループ) を作成 AWS CLIまたは ElastiCache変更するときに有効にできますAPI。
マルチ AZ は、使用可能なリードレプリカが 1 つ以上ある Valkey または Redis OSS (クラスターモードが無効) クラスターでのみ有効にできます。リードレプリカのないクラスターでは、高可用性や耐障害性は提供されません。レプリケーションが有効なクラスターの作成については、「Valkey または Redis OSSレプリケーショングループの作成」を参照してください。レプリケーションが有効なクラスターへのリードレプリカの追加については、「Valkey または Redis のリードレプリカの追加 OSS (クラスターモードが無効)」を参照してください。
マルチ AZ の有効化 (コンソール)
ElastiCache コンソールを使用してマルチ AZ を有効にするには、新しい Valkey または Redis OSSクラスターを作成するとき、またはレプリケーションを使用して既存のクラスターを変更します。
マルチ AZ は、Valkey または Redis OSS (クラスターモードが有効) クラスターでデフォルトで有効になっています。
重要
ElastiCache は、クラスターにすべてのシャードのプライマリとは異なるアベイラビリティーゾーンに少なくとも 1 つのレプリカが含まれている場合にのみ、マルチ AZ を自動的に有効にします。
ElastiCache コンソールを使用してクラスターを作成するときにマルチ AZ を有効にする
このプロセスの詳細については、「Valkey (クラスターモードが無効) クラスターの作成 (コンソール)」を参照してください。必ず 1 つ以上のレプリカを用意して、マルチ AZ を有効にしてください。
既存のクラスターでのマルチ AZ の有効化 (コンソール)
このプロセスの詳細については、「の使用 ElastiCache 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 コマンドリファレンスの以下のトピックを参照してください。
-
modify-replication-group 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 は以下を実行します。
失敗したプライマリノードがオフラインになります。
レプリケーションの遅延が最短のリードレプリカがプライマリに昇格されます。
書き込みは、昇格プロセスが完了するとすぐに (通常は数秒) 再開できます。アプリケーションがプライマリエンドポイントに書き込む場合、書き込みまたは読み取りのエンドポイントを変更する必要はありません。 ElastiCache は昇格されたレプリカDNSの名前を伝達します。
置き換えられたリードレプリカが起動し、プロビジョニングされます。
ノードのディストリビューションが維持されるように、障害が発生したプライマリノードがあったアベイラビリティーゾーンで置き換えリードレプリカが起動されます。
レプリカが新しいプライマリノードと同期されます。
新しいレプリカが使用可能になった後は、次の影響に注意してください。
-
プライマリエンドポイント – 新しいプライマリノードDNSの名前はプライマリエンドポイントに伝達されるため、アプリケーションに変更を加える必要はありません。
-
[読み取りエンドポイント] – 読み取りエンドポイントは、新しいレプリカノードを指すように自動的に更新されます。
クラスターのエンドポイントの検索については、以下のトピックを参照してください。
プライマリノードと複数のリードレプリカが失敗した場合の障害シナリオ
プライマリおよび少なくとも 1 つのリードレプリカで障害が発生した場合、利用可能でレプリケーションの遅延が最も少ないレプリカが、プライマリクラスターに昇格されます。また、障害が発生したノードおよびプライマリに昇格されたレプリカと同じアベイラビリティーゾーンで、新しいリードレプリカが作成およびプロビジョニングされます。
プライマリノードと一部のリードレプリカが失敗すると、 ElastiCache マルチ AZ は以下を実行します。
障害が発生したプライマリノードとリードレプリカがオフラインになります。
レプリケーションの遅延が最短の使用可能なレプリカがプライマリノードに昇格されます。
書き込みは、昇格プロセスが完了するとすぐに (通常は数秒) 再開できます。アプリケーションがプライマリエンドポイントに書き込む場合、writes. ElastiCache propagates で昇格されたレプリカDNSの名前のエンドポイントを変更する必要はありません。
複数の置き換えレプリカを作成してプロビジョニングします。
ノードのディストリビューションが維持されるように、障害が発生したノードのアベイラビリティーゾーンで置き換えレプリカが作成されます。
すべてのクラスターが新しいプライマリノードと同期されます。
新しいノードが使用可能になったら、アプリケーションに以下の変更を行います。
-
[プライマリエンドポイント] – アプリケーションは変更しないでください。新しいプライマリノードDNSの名前は、プライマリエンドポイントに伝達されます。
-
[読み取りエンドポイント] – 読み取りエンドポイントは、新しいレプリカノードを指すように自動的に更新されます。
レプリケーショングループのエンドポイントの検索については、次のトピックを参照してください:
クラスター全体が失敗した場合の障害シナリオ
すべてに障害が発生した場合、すべてのノードは、元のノードと同じアベイラビリティーゾーンで再作成され、プロビジョニングされます。
このシナリオでは、クラスター内のすべてのデータがクラスター内のすべてのノードの障害のために失われます。これはまれにしか発生しません。
クラスター全体が失敗すると、 ElastiCache マルチ AZ は以下を実行します。
障害が発生したプライマリノードとリードレプリカがオフラインになります。
置き換えプライマリノードが作成され、プロビジョニングされます。
複数の置き換えレプリカを作成してプロビジョニングします。
ノードのディストリビューションが維持されるように、障害が発生したノードのアベイラビリティーゾーンで置き換えレプリカが作成されます。
クラスター全体に障害が発生したため、データが失われ、すべての新しいノードがコールド起動されます。
置換先の各ノードと置換元のノードはエンドポイントが同じであるため、アプリケーションでエンドポイントを変更する必要はありません。
レプリケーショングループのエンドポイントの検索については、次のトピックを参照してください:
耐障害性レベルを上げるために、プライマリノードとリードレプリカは別々のアベイラビリティーゾーンに作成することをお勧めします。
自動フェイルオーバーのテスト
自動フェイルオーバーを有効にする AWS CLIと、 ElastiCache コンソール、、および を使用してテストできます ElastiCache API。
テストを行う場合、以下の点に注意してください。
-
このオペレーションを使用して、任意のローリング 24 時間で最大 15 個のシャード ( および でノードグループと呼ばれます AWS CLI) の自動フェイルオーバーを ElastiCache APIテストできます。
-
異なるクラスター ( APIおよび ではレプリケーショングループと呼ばれますCLI) のシャードに対してこのオペレーションを呼び出すと、同時に呼び出しを行うことができます。
-
場合によっては、同じ Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループの異なるシャードでこのオペレーションを複数回呼び出すことがあります。このような場合、後続の呼び出しを行う前に、最初のノードの置換が完了する必要があります。
-
ノードの交換が完了したかどうかを判断するには、Amazon ElastiCache コンソール、、 AWS CLIまたは を使用してイベントを確認します ElastiCache API。自動フェイルオーバーに関連する次のイベントを検索します。ここでは、発生すると思われる順番にイベントを示します。
-
レプリケーショングループメッセージ:
Test Failover API called for node group <node-group-id>
-
キャッシュクラスターメッセージ:
Failover from primary node <primary-node-id> to replica node <node-id> completed
-
レプリケーショングループメッセージ:
Failover from primary node <primary-node-id> to replica node <node-id> completed
-
キャッシュクラスターメッセージ:
Recovering cache nodes <node-id>
-
キャッシュクラスターメッセージ:
Finished recovery for cache nodes <node-id>
詳細については、次を参照してください。
-
「ElastiCache ユーザーガイド」の「 ElastiCache イベントの表示」
-
DescribeEvents ElastiCache APIリファレンスの
-
AWS CLI コマンドリファレンスの describe-events。
-
これはAPI、 ElastiCache フェイルオーバー時のアプリケーションの動作をテストするように設計されています。クラスターの問題に対処するためにフェイルオーバーを開始するための運用ツールとしては設計されていません。さらに、大規模な運用イベントなどの特定の条件下では、この をブロック AWS することがありますAPI。
トピック
を使用した自動フェイルオーバーのテスト AWS Management Console
コンソールで自動フェイルオーバーをテストするには、次の手順に従います。
自動フェイルオーバーをテストするには
-
にサインイン AWS Management Console し、 https://console.aws.amazon.com/elasticache/
で ElastiCache コンソールを開きます。 -
ナビゲーションペインで、Valkey または Redis OSSを選択します。
-
クラスターのリストから、テストするクラスターの左側にあるボックスを選択します。このクラスターには、少なくとも 1 つのリードレプリカノードが必要です。
-
Details エリアで、このクラスターでマルチ AZ が有効になっていることを確認します。クラスターでマルチ AZ が有効になっていない場合は、別のクラスターを選択するか、このクラスターを変更してマルチ AZ を有効にします。詳細については、「の使用 ElastiCache AWS Management Console」を参照してください。
Valkey または Redis OSS (クラスターモードが無効) の場合は、クラスターの名前を選択します。
Valkey または Redis OSS (クラスターモードが有効) の場合は、以下を実行します。
-
クラスターの名前を選択します。
-
シャードページで、フェイルオーバーをテストするシャード ( APIと でノードグループと呼ばれますCLI) に対して、シャードの名前を選択します。
-
-
[Nodes] ページで [Failover Primary] を選択します。
-
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 、 を使用して、Valkey または Redis OSS (クラスターモードが有効) クラスター redis00-0003
のノードグループで自動フェイルオーバーをテストしますredis00
。
例 自動フェイルオーバーをテストする
Linux、macOS、Unix の場合:
aws elasticache test-failover \ --replication-group-id
redis00
\ --node-group-idredis00-0003
Windows の場合:
aws elasticache test-failover ^ --replication-group-id
redis00
^ --node-group-idredis00-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
オペレーションを使用します。
詳細については、次を参照してください。
-
AWS CLI コマンドリファレンスの test-failover。
-
AWS CLI コマンドリファレンスの describe-events。
を使用した自動フェイルオーバーのテスト ElastiCache API
オペレーション を使用して、マルチ AZ で有効なクラスターで自動フェイルオーバーを ElastiCache APIテストできます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>
フェイルオーバーの進行状況を追跡するには、 ElastiCache DescribeEvents
APIオペレーションを使用します。
詳細については、次を参照してください。
-
TestFailover ElastiCache APIリファレンスの
-
DescribeEvents ElastiCache APIリファレンスの
マルチ AZ の制限事項
マルチ AZ では、以下の制限に注意してください。
-
マルチ AZ は Valkey および Redis OSSバージョン 2.8.6 以降でサポートされています。
-
マルチ AZ は T1 ノードタイプではサポートされていません。
-
Valkey レプリケーションと Redis OSSレプリケーションは非同期です。そのため、プライマリノードがレプリカにフェイルオーバーすると、レプリケーションの遅延のために少量のデータが失われる可能性があります。
プライマリに昇格するレプリカを選択する場合、レプリケーションの遅延が最も少ないレプリカ ElastiCache を選択します。言い換えると、最新のレプリカを選択します。これにより、失われるデータ量が最小限に抑えられます。レプリケーションの遅延が最短のレプリカは、障害が発生したプライマリノードと同じ、または異なるアベイラビリティーゾーンに存在できます。
-
クラスターモードが無効になっている Valkey クラスターまたは Redis OSSクラスターでリードレプリカをプライマリに手動で昇格させる場合、マルチ AZ および自動フェイルオーバーが無効になっている場合にのみ行うことができます。リードレプリカをプライマリに昇格させるには、以下のステップを実行します。
-
クラスターでマルチ AZ を無効にします。
-
クラスターで自動フェイルオーバーを無効にします。これは、レプリケーショングループの自動フェイルオーバーチェックボックスをオフにすることでコンソールから行うことができます。これは、
ModifyReplicationGroup
オペレーションを呼び出すfalse
ときにAutomaticFailoverEnabled
プロパティを に設定 AWS CLI することでも実行できます。 -
リードレプリカをプライマリに昇格させます。
-
マルチ AZ を再度有効にします。
-
-
ElastiCache (Redis OSS) マルチ AZ と追加専用ファイル (AOF) は相互に排他的です。一方を有効にすると、他方を有効にすることはできません。
-
アベイラビリティーゾーン全体の障害というまれなイベントにより、ノードの障害が発生することがあります。この場合、障害の発生したプライマリを置き換えるレプリカは、アベイラビリティーゾーンがバックアップされているときのみ作成されます。たとえば、AZ-a のプライマリおよび AZ-b および AZ-c のレプリカを持つレプリケーショングループを考えてみます。プライマリに障害が発生した場合、レプリケーションの遅延が最も小さい利用可能なレプリカをプライマリクラスターに昇格します。次に、 は、AZ-a がバックアップされ、使用可能である場合にのみ、AZ-a に新しいレプリカ ElastiCache を作成します (失敗したプライマリが配置されている)。
-
プライマリの再起動をお客様が開始した場合、自動フェイルオーバーはトリガーされません。他の再起動と障害は、自動フェイルオーバーをトリガーします。
-
プライマリが再起動すると、オンラインに戻ったときにデータがクリアされます。リードレプリカがクリアされたプライマリクラスターを検出すると、データのコピーがクリアされるため、データ損失が発生します。
-
リードレプリカが昇格されると、他のレプリカは新しいプライマリと同期されます。最初の同期後に、レプリカのコンテンツは削除され、新しいプライマリからデータが同期されます。この同期プロセスに伴って一時的に中断が発生し、その間はレプリカにアクセスできなくなります。また、この同期プロセスに伴ってレプリカとの同期中にプライマリで一時的にロードが増えます。この動作は Valkey と Redis にネイティブOSSであり、マルチ AZ に ElastiCache固有ではありません。この動作の詳細については、Valkey ウェブサイトの「レプリケーション
」を参照してください。
重要
Valkey 7.2.6 以降または Redis OSSバージョン 2.8.22 以降では、外部レプリカを作成することはできません。
2.8.22 より前の Redis OSSバージョンでは、マルチ AZ が有効になっている ElastiCache クラスターに外部レプリカを接続しないことをお勧めします。このサポートされていない設定は、フェイルオーバーと復旧を適切に実行 ElastiCache できない問題を引き起こす可能性があります。外部レプリカを ElastiCacheクラスターに接続するには、接続を行う前にマルチ AZ が有効になっていないことを確認してください。