翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon ElastiCache Well-Architected レンズの信頼性の柱
信頼性の柱は、ワークロードがその意図した機能を果たし、需要に応じて迅速に障害から回復する方法に焦点を当てています。主なトピックとして、分散システムの設計、復旧計画、および要件の変更への対応方法があります。
トピック
REL 1: 高可用性 (HA) アーキテクチャの導入をどのようにサポートしているか。
質問レベルの紹介: Amazon ElastiCache の高可用性アーキテクチャを理解することで、可用性イベントが発生しても回復力のある状態で運用できるようになります。
質問レベルのメリット: 障害に強い ElastiCache クラスターを構築することで、ElastiCache デプロイの可用性を高めることができます。
-
[必須] ElastiCache クラスターに必要な信頼性のレベルを決定します。完全に一時的なワークロードからミッションクリティカルなワークロードまで、ワークロードが異なれば回復力の基準も異なります。開発、テスト、本番環境など、運用する環境のタイプごとにニーズを定義します。
キャッシュエンジン: ElastiCache for Memcached と ElastiCache for Valkey and Redis OSS
-
ElastiCache for Memcached はレプリケーションメカニズムを提供しておらず、主にエフェメラルワークロードに使用されます。
-
Valkey および Redis OSS 用 ElastiCache は、以下で説明する HA 機能を提供します。
-
-
〔最良] HA を必要とするワークロードの場合、シャードを 1 つだけ必要とする小規模なスループット要件ワークロードでも、シャードごとに最低 2 つのレプリカを持つクラスターモードで ElastiCache を使用します。
-
クラスターモードを有効にすると、マルチ AZ が自動的に有効になります。
マルチ AZ は、計画的または計画外のメンテナンスが発生した場合に、プライマリノードからレプリカへの自動フェイルオーバーを実行することでダウンタイムを最小限に抑え、AZ の障害を軽減します。
-
シャーディングされたワークロードの場合、最低 3 つのシャードを使用するとフェイルオーバーイベント中の復旧が速くなります。これは、Valkey または Redis OSS クラスタープロトコルでは、クォーラムの達成にプライマリノードの過半数を利用可能にする必要があるためです。
-
アベイラビリティ全体で 2 つ以上のレプリカを設定します。
レプリカが 2 つあると、1 つのレプリカがメンテナンス中のとき、読み取りのスケーラビリティが向上し、シナリオでの読み取りの可用性も向上します。
-
Graviton2 ベースのノードタイプ (ほとんどのリージョンでのデフォルトノード) を使用します。
ElastiCache は、これらのノードに最適化されたパフォーマンスを追加しました。それにより、レプリケーションと同期のパフォーマンスが向上し、全体的な可用性が向上しています。
-
予想されるトラフィックのピークに対応するために、モニタリングと適切なサイズ設定を行います。負荷が高い場合、エンジンが応答しなくなる可能性があり、可用性に影響します。
BytesUsedForCache
とDatabaseMemoryUsagePercentage
はメモリ使用量の優れた指標ですが、ReplicationLag
は書き込みレートに基づくレプリケーションの状態の指標です。これらのメトリクスを使用してクラスタースケーリングをトリガーできます。 -
本番環境でフェイルオーバーイベントが発生する前にフェイルオーバー API
でテストすることで、クライアント側の耐障害性を確保します。
[リソース]:
-
REL 2: ElastiCache を使用して目標復旧時点 (RPO) をどのように達成しているか。
質問レベルの紹介: ワークロードの RPO を理解して、ElastiCache のバックアップとリカバリの戦略に関する意思決定に役立てます。
質問レベルのメリット: RPO 戦略を策定することで、ディザスタリカバリシナリオが発生した場合の事業継続性を向上させることができます。バックアップと復元のポリシーを設計すると、ElastiCache データの目標復旧時点 (RPO) の達成に役立ちます。ElastiCache には、Amazon S3 に保存されているスナップショット機能と、設定可能な保持ポリシーが用意されています。これらのスナップショットは、定義されたバックアップウィンドウ中に取得され、サービスによって自動的に処理されます。ワークロードにさらに細かいバックアップが必要な場合は、1 日あたり最大 20 の手動バックアップを作成できます。手動で作成されたバックアップにはサービス保持ポリシーがなく、無期限に保存できます。
-
[必須] ElastiCache デプロイの RPO を理解し、文書化します。
-
Memcached はバックアッププロセスを提供していないことに注意してください。
-
ElastiCache のバックアップと復元の機能を確認してください。
-
-
[最良] クラスターをバックアップするためのプロセスをしっかりと伝えておきます。
-
必要に応じて手動バックアップを開始します。
-
自動バックアップの保存ポリシーを確認します。
-
手動バックアップは無期限に保持されることに注意してください。
-
自動バックアップは使用率が低い時間帯にスケジュールします。
-
リードレプリカに対してバックアップオペレーションを実行して、クラスターのパフォーマンスへの影響を最小限に抑えます。
-
-
[良い] ElastiCache のスケジュールバックアップ機能を活用して、定義した時間帯に定期的にデータをバックアップします。
-
バックアップからの復元を定期的にテストします。
-
-
[リソース]:
REL 3: ディザスタリカバリ (DR) 要件をどのようにサポートしているか。
質問レベルの紹介: ディザスタリカバリは、あらゆるワークロードプランニングの重要な側面です。ElastiCache には、ワークロードの耐障害性要件に基づいてディザスタリカバリを実装するためのオプションがいくつか用意されています。Amazon ElastiCache Global Datastore を使用すると、1 つのリージョンのクラスターに書き込み、他の 2 つのクロスリージョンレプリカクラスターからデータを読み取ることができるため、リージョン間で低レイテンシーの読み取りとディザスタリカバリが可能になります。
質問レベルのメリット: さまざまな災害シナリオを理解して計画することで、事業継続性を確保できます。DR 戦略は、コスト、パフォーマンスへの影響、およびデータ損失の可能性とのバランスを取る必要があります。
-
[必須] ワークロード要件に基づいて、すべての ElastiCache コンポーネントの DR 戦略を策定し、文書化します。ElastiCache がユニークなのは、完全に一時的で DR 戦略を必要としないユースケースもあれば、逆に、きわめて強固な DR 戦略を必要とするユースケースもあるという点です。すべてのオプションは、コストの最適化に対して比較検討する必要があります。回復力を高めるには、より多くのインフラストラクチャが必要です。
リージョンレベルおよびマルチリージョンレベルで利用可能な DR オプションを理解します。
-
AZ 障害を防ぐために、マルチ AZ 配置が推奨されます。マルチ AZ アーキテクチャでは、必ずクラスターモードを有効にして、最低 3 つの AZ が利用可能な状態でデプロイします。
-
リージョンの障害を防ぐために、グローバルデータストアの使用が推奨されます。
-
-
[最良] リージョンレベルの耐障害性を必要とするワークロードには、グローバルデータストアを有効にします。
-
プライマリのパフォーマンスが低下した場合に備えて、セカンダリリージョンへのフェイルオーバーを計画します。
-
本番環境でフェイルオーバーする前に、マルチリージョンのフェイルオーバープロセスをテストします。
-
ReplicationLag
メトリクスをモニタリングして、フェイルオーバーイベント中のデータ損失の潜在的な影響を把握します。
-
-
[リソース]:
REL 4: フェイルオーバーを効果的に計画するにはどうすればよいか。
質問レベルの紹介: 自動フェイルオーバーでマルチ AZ を有効にすることは、ElastiCache のベストプラクティスです。場合によっては、ElastiCache for Valkey と Redis OSS がサービスオペレーションの一部としてプライマリノードを置き換えます。例えば、計画されたメンテナンスのイベントや、ノードの障害またはアベイラビリティゾーンの問題という万一の場合が含まれます。フェイルオーバーが成功するかどうかは、ElastiCache とクライアントライブラリの設定の両方に依存します。
質問レベルのメリット: 特定の ElastiCache クライアントライブラリと組み合わせて ElastiCache フェイルオーバーのベストプラクティスに従うと、フェイルオーバーイベント中の潜在的なダウンタイムを最小限に抑えることができます。
-
[必須] クラスターモードが無効になっている場合は、タイムアウトを使用して、クライアントが古いプライマリノードから切断して、更新されたプライマリエンドポイントの IP アドレスを使用して新しいプライマリノードに再接続する必要があるかどうかを検出できるようにします。クラスターモードが有効になっている場合、クライアントライブラリは基盤となるクラスタートポロジの変更を検出します。これは、ほとんどの場合、ElastiCache クライアントライブラリの設定によって実現されます。これにより、更新の頻度と方法を設定することもできます。各クライアントライブラリには独自の設定があり、詳細は対応するドキュメントに記載されています。
[リソース]:
-
ElastiCache クライアントライブラリのベストプラクティスを確認します。
-
[必須] フェイルオーバーが成功するかどうかは、プライマリノードとレプリカノード間のレプリケーション環境が正常であるかどうかによります。Valkey および Redis OSS レプリケーションの非同期性、およびプライマリノードとレプリカノード間のレプリケーションの遅延を報告するための CloudWatch メトリクスを確認して理解します。より高いデータの安全性が求められるユースケースでは、WAIT コマンドを活用して、接続されたクライアントに応答する前にレプリカが書き込みを確認するよう強制します。
[リソース]:
-
[最良] ElastiCache テストフェイルオーバー API を使用して、フェイルオーバー中のアプリケーションの応答性を定期的に検証します。
[リソース]:
REL 5: ElastiCache コンポーネントがスケーリングに対応するように設計されがいるか。
質問レベルの紹介: スケーリング機能と利用可能なデプロイトポロジを理解することで、ElastiCache コンポーネントは変化するワークロード要件に合わせて経時的に調整できます。ElastiCache には、イン/アウト (水平) とアップ/ダウン (垂直) の 4 通りのスケーリングがあります。
質問レベルのメリット: ElastiCache デプロイのベストプラクティスに従うと、スケーリングの柔軟性が最大化されるだけでなく、障害の影響を最小限に抑えるために水平方向にスケーリングするという Well Architected の原則も満たすことができます。
-
[必須] クラスターモード有効ポロジとクラスターモード無効トポロジの違いを理解します。ほとんどの場合、クラスターモードを有効にしてデプロイすることが推奨されます。これは、時間の経過とともにスケーラビリティが向上できるためです。クラスターモードが無効になっているコンポーネントでは、リードレプリカを追加することにより水平方向にスケーリングする機能に制限があります。
-
[必須] いつ、どのようにスケーリングすべきかを理解します。
-
READIOPS を増やすには、レプリカを追加します
-
WRITEOPS を増やすには、シャードを追加します (スケールアウト)
-
ネットワーク IO を増やすには — ネットワーク最適化インスタンス、スケールアップを使用します
-
-
[最良] ElastiCache コンポーネントをクラスターモードを有効にしてデプロイし、少ないノード数で大規模にするのではなく、小さなノードを数多くします。これにより、ノード障害時の影響範囲を効果的に制限できます。
-
[最良] クラスターにレプリカを含めると、スケーリングイベント中の応答性が向上します
-
[良い] クラスターモードが無効になっている場合は、リードレプリカを活用して全体的な読み取り容量を増加します。ElastiCache は、クラスターモードが無効な状態で最大 5 つのリードレプリカをサポートし、垂直スケーリングもサポートします。
-
[リソース]: