シンガポールの2つのアベイラビリティーゾーンでAWSロードバランシングと複数のウェブサーバーを使用しています。
現在、両方のアベイラビリティーゾーンにelasticacheノードをデプロイすることを検討しており、異なるアベイラビリティーゾーンのelasticacheノードにアクセスするWebサーバーによって引き起こされる遅延の問題があるかどうかを知りたいですか？
更新-実際、さらに調査した結果、elasticacheクラスターは1つのアベイラビリティーゾーンにのみ存在できるようです。したがって、アベイラビリティーゾーンの停止に対処するための最良のソリューションは何ですか？
確かに、ElasticCacheではマルチアベイラビリティーゾーン機能はまだサポートされていません。ただし、通常、AZ間の遅延が1msと短いため、大きな問題にはなりません。
キャッシュの目的は、メモリから提供される長くて頻繁なSQLクエリを作成することです。これは、300ミリ秒のSQLクエリの代わりに、単一のメモリルックアップで提供できます。その1msのネットワーク遅延と比較すると、問題にはならないはずです。
ElasticCacheとしてのキャッシュの2番目のプロパティは、データベースからのライブデータを使用してキャッシュをウォームアップおよびウォームアップすることです。バックグラウンドのデータは常に変化しているため、キャッシュ全体が最新であるとは決して期待しないでください。システムは新しく作成されたキャッシュノードをかなり迅速にウォームアップする必要があるため、クラスター内のキャッシュノードが失われることが予想されます（大規模システムの他の障害と同様）。ElasticCacheは障害が発生したノードを置き換えますが、キャッシュデータで再度埋める必要があります。
アベイラビリティーゾーン間の冗長性については、AWSの説明を確認できます。
異なるアベイラビリティーゾーンでの冗長キャッシュクラスターのセットアップ
Amazon ElastiCacheは、キャッシュノードの状態を監視し、ネットワークパーティショニング、ホストハードウェア、またはソフトウェアの障害が発生した場合にキャッシュノードを置き換えます。ただし、キャッシュの一時的な性質を考えると、キャッシュノードの置換は空で始まり（「コールド」とも呼ばれます）、ワークロードパターンによっては、データが再入力されるまでに時間がかかる場合があります（「ウォーミングアップ」とも呼ばれます）。さらに、Amazon ElastiCacheが提供する自動交換機能は、単一のアベイラビリティーゾーンに制限されています。アプリケーションがキャッシュノードの障害回復または「ウォームアップ」時間に敏感である場合、またはアベイラビリティーゾーンレベルの障害に対するフォールトトレランスを強化したい場合は、異なるアベイラビリティーゾーンに冗長ElastiCacheクラスターをデプロイすることをお勧めします。
データの冗長性を管理する方法の1つは、アプリケーションにすべてのキャッシュ書き込みをこれらのアベイラビリティーゾーン全体のキャッシュノードに適用させることです。プライマリアベイラビリティーゾーンの1つ以上のキャッシュノードに障害が発生した場合、Amazon ElastiCacheがプライマリアベイラビリティーゾーンのキャッシュノードを復元している間に、セカンダリアベイラビリティーゾーンの対応するキャッシュノードに直接読み取りを行うことができます。
アベイラビリティーゾーン間の遅延は通常約2ミリ秒であるため、通常は問題ありません。
質問の2番目の部分に対処できるように、それをどのように使用しているかについてもっと知る必要があります。これは単なるキャッシングレイヤーであるため、AWSが問題を修正するか、手動で介入するまで、アプリケーションは劣化モードで実行されることがよくあります。または、アプリケーションを設計して、別のアベイラビリティーゾーンにある2番目のクラスターに自動的にフェイルオーバーすることもできます。その場合、キャッシュは永続データストアから再構築する必要があります。キャッシュミスを発生させるか、アプリケーションがキャッシュの使用を開始する前にキャッシュミスを準備することができます。