フェイルオーバー中に ElastiCache のダウンタイムを最小限に抑える方法を教えてください。

所要時間1分

Amazon ElastiCache for Redis OSS および Amazon ElastiCache for Valkey において、フェイルオーバー中のダウンタイムを最小化するためのベストプラクティスを実施したいです。

簡単な説明

次の原因で、ElastiCache でフェイルオーバーが発生し、アプリケーションのパフォーマンスと信頼性に影響する可能性があります。

メモリ、CPU、ネットワーク帯域幅などのリソースを使い果たすと、ノードでフェイルオーバーが発生する可能性があります。
AWS が更新のメンテナンスイベントをスケジュールすると、ノードでフェイルオーバーが発生する可能性があります。
ノードをホストするインフラストラクチャの物理ハードウェアが故障したり問題が発生したりすると、ノードでフェイルオーバーが発生する可能性があります。
キャッシュと通信するアプリケーションやサービスに構成ミスがある場合、その構成によりダウンタイムが長くなる可能性があります。

解決策

マルチ AZ を有効にする

AWS リージョン内の複数のアベイラビリティーゾーン (AZ) にわたってプライマリノードとレプリカノードを作成および管理するには、ElastiCache のマルチ AZ 機能を使用します。プライマリノードに障害が発生した場合、レプリカノードがプライマリノードとしての役割を引き継ぎます。この際、最小限のダウンタイムのみが発生します。

リードレプリカを追加する

Redis のデプロイにリードレプリカを追加すると、フェイルオーバータスクでのダウンタイムとデータ損失を大幅に軽減できます。リードレプリカが読み取りリクエストを管理する際、プライマリノードが書き込み操作を処理するように設定します。この構成には次の利点があります。

読み取りスループットの向上
遅延の削減
フォールトトレランスの実現
クラスターのダウンタイムの原因となるメンテナンスタスクの簡素化

アベイラビリティーゾーンへのノード分散

ノードを複数のアベイラビリティーゾーンに分散させると、別々の AZ にあるレプリカが高可用性と継続的な読み取り操作を実現します。この構成により、システムの耐障害性が向上し、ノードでフェイルオーバーが発生した場合のダウンタイムを短縮できます。クラスターを初めて構成したり、既存のクラスターに新しいノードを追加したりするときに、ノードを複数の AZ に分散できます。詳細については、「ElastiCache のリージョンとアベイラビリティーゾーンを選択する」を参照してください。

Valkey または Redis OSS の最新バージョンを使用する

クラスターとノードタイプに応じて、最新の機能をサポートする、最新バージョンの Valkey または Redis OSS を使用してください。たとえば、クラスターモードが無効になっているクラスターでは、ノード交換機能の計画を使用するには、Valkey バージョン 7.2 または Redis OSS バージョン 5.0.6 以降が必要です。詳細については、「サポートされるノードの種類」を参照してください。

クラスターイベントを監視する

フェイルオーバーを特定して対処するために、ElastiCache クラスターイベントをレビューします。フェイルオーバーを早期に検出するには、Amazon Simple Notiﬁcation Service (Amazon SNS) を使用して ElastiCache が重要なクラスターイベントに関する通知を送信するように設定します。

正しいエンドポイントを使用する

フェイルオーバー中のダウンタイムを最小限に抑えるには、クラスター設定に応じて ElastiCache for Redis OSS クラスターの正しいエンドポイントを使用する必要があります。クラスターモードが無効なクラスターの全レプリカに読み取りワークロードを分散するには、書き込み操作にはプライマリエンドポイントを使用し、読み取り操作にはリーダーエンドポイントを使用します。クラスターモードが有効なクラスターでは、すべての操作に設定エンドポイントを使用すると、正しいノードへの接続を自動的に管理できます。クラスターモードに適したエンドポイントを選択すると、パフォーマンスが最適化され、フェイルオーバープロセスがスムーズになります。詳細については、「ElastiCache の接続エンドポイントを特定する」を参照してください。

注: 個々のノードエンドポイントを直接使用することはおすすめしません。代わりに、接続タイプに適したエンドポイントを使用してください。フェイルオーバーイベント中にノードの役割が変わる可能性があるため、個々のノードエンドポイントを使用すると、アプリケーションの問題が増えます。

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

Redis のデプロイにおける信頼性を維持するために、自動フェイルオーバーを定期的にテストすることをおすすめします。自動フェイルオーバーをテストするには、プライマリノードの障害をシミュレートして、レプリカがプライマリステータスに昇格していることを確認する必要があります。これらのテストを実施すると、構成内の問題を特定し、クラスターに影響が及ぶ前に問題に対処できます。フェイルオーバーテストでは、アプリケーションのパフォーマンスおよび、アーキテクチャと復旧手順を最適化する方法に関する洞察も得られます。

Redis クライアントのベストプラクティスに従う

Redis クライアントでは、次のベストプラクティスに従ってください。

アプリケーションのパフォーマンスとスケーラビリティを高めるには、接続プーリングを使用して再利用可能な確立済みの接続を管理します。詳細については、Redis のウェブサイトで「接続プールと多重化」を参照してください。
Redis クラスターでのアプリケーションの効率性を維持するために、例外とタイムアウト処理を実装します。ログにタイムアウトがないかを確認しても、問題を特定し、設定を調整できます。詳細については、Redis のウェブサイトで「クライアントのタイムアウト」を参照してください。
アプリケーションの耐障害性を維持するには、エクスポネンシャルバックオフ戦略を使用する再試行メカニズムを実装します。メカニズムが再試行が必要な一時的なエラーと、再試行が必要ない永続的なエラーを区別するように設定します。詳細については、「クラスターのクライアント検出とエクスポネンシャルバックオフ (Valkey および Redis OSS)」を参照してください。
ログを有効にして主要なメトリクスとエラーをキャプチャし、クラスターのパフォーマンスにベースラインを確立します。詳細については、Redis のウェブサイトで「イベントを記録する」を参照してください。
クライアントがクラスタートポロジーの変更を動的に処理し、ノードやロールの変更にも適応するように設計します。クラスターノードへの接続を維持し、クラスターを最適化するために、スマート接続プーリングを実装します。詳細については、Redis のウェブサイトで「Redis クラスターとクライアントライブラリ」を参照してください。