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