Amazon ElastiCache Redis クラスターのために災害復旧または耐障害性を実装するにはどうすればよいですか?

最終更新日: 2020 年 9 月 15 日

Amazon ElastiCache Redis クラスターデータのために災害復旧または耐障害性を実装する必要があります。どのようなオプションを利用できますか?

解決方法

利用可能な耐障害性ソリューションには、それぞれにデータ耐久性、パフォーマンスへの影響、およびコスト間における独自のバランスがあります。ユースケースに最適なソリューションを選択してください。

マルチ AZ

マルチ AZ は、データ保持、最小限のダウンタイム、およびアプリケーションのパフォーマンスが最優先事項である場合に最適なオプションです。

  • データ損失の可能性 – 低。マルチ AZ は、ハードウェア関連の問題を含めたあらゆるシナリオに対して耐障害性を提供します。
  • パフォーマンスへの影響 – 低。プロセス実装後に実行する手動の手順がないことから、マルチ AZ は利用可能なオプションの中でも最も短い復旧時間を実現します。
  • コスト – 低~高。マルチ AZ はコストが最も低いオプションです。マルチ AZ は、ハードウェアの故障のためにデータを損失するリスクを負うことができない、または機能停止への対応において他のオプションで必要となるダウンタイムを許容できない場合に使用してください。

マルチ AZ の詳細については、「マルチ AZ でのRedis 用 ElastiCache のダウンタイムの最小化」を参照してください。

日次自動バックアップ

クラスターのリソース使用率が低くなることが予想されるときには、日次自動バックアップをスケジュールすることができます。ElastiCache は、クラスターのバックアップを作成してから、キャッシュからの全データを Redis RDB ファイルに書き込みます。バージョン 2.8.22 以降の Radis は、パフォーマンスを向上させることができる分岐なしのバックアップを実装します。

注意: Redis のバックアップと復元は、クラスターモードが無効化されたクラスター向けの cache.t1.micro ノードではサポートされません。

  • データ損失の可能性 – 高 (最大 1 日分)。日次自動バックアップは、最大 35 日間保持されます。
  • パフォーマンスへの影響 – 中~高。複数のファイルバックアップを一日中実行することは、パフォーマンスに影響を及ぼします。パフォーマンスを向上させるには、指定された永続性のみのセカンダリノードで RDB スナップショットを有効化することを検討してください。その後、プライマリノードとその他すべてのセカンダリノードで RDB スナップショットと Redis 追加専用ファイル (AOF) の両方を無効化します。
  • コスト – 低~中。ストレージコストは、バックアップの数とデータ保持期間とともに増加します。

バックアップと復元を実装する前に、「バックアップの制約」による制約事項について検討してください。Redis を実行する ElastiCache クラスターのためのバックアップの実装に関する包括的な情報については、「Redis 用 ElastiCache のバックアップと復元」を参照してください。詳細については、「手動バックアップの作成」を参照してください。

Redis 追加専用ファイル (AOF) を使用した手動バックアップ

AOF を使用した手動バックアップは恒久的に保持され、テストおよびアーカイブ用に役立ちます。手動バックアップは、任意の 24 時間の期間内に最大 20 回実行されるようにスケジュールできます。

Redis クラスター向けに AOF を有効化するには、appendonly パラメータを yes に設定してパラメータグループを作成してください。次に、そのパラメータグループをクラスターに割り当てます

AOF を使用するときは、以下の点に留意してください。

  • パフォーマンスを向上させるには、指定された永続性のみのセカンダリノードで RDB スナップショットを有効化することを検討してください。その後、プライマリノードとその他すべてのセカンダリノードで RDB スナップショットと AOF の両方を無効化します。
  • パフォーマンスを向上させるには、appendfsync パラメータの値を everysec または no に設定して、毎秒、または必要に応じてディスクに書き込みます。
  • AOF は、バージョン 2.8.21 以前の Redis での使用でのみサポートされています。
  • AOF は、「障害の軽減: Redis 追加専用ファイル (AOF)」で説明されている制約の対象になります。
  • AOF は、cache.t1.micro および cache.t2.* の各ノード、または マルチ AZ レプリケーショングループではサポートされていません。これらのタイプのノードでは、appendonly パラメータの値が無視されます。

AOF を使用する手動バックアップは、バージョン 2.8.21 以前の Redis にネイティブの機能を使用することによって、比較的低いコストで高レベルのデータ永続性を維持するために最適なオプションです。

  • データ損失の可能性 – 低~中。AOF はある程度の耐障害性を提供しますが、ハードウェア関連のキャッシュノード障害からデータを保護することはできないため、データ損失のリスクが存在します。
  • パフォーマンスへの影響 – 低~高。AOF のパフォーマンスへの影響は、関連する appendfsync パラメータの値 (これによって AOF の出力バッファがディスクに書き込まれる頻度が制御されます) に大きく関係しています。出力バッファがディスクに書き込まれる頻度が高いほど、パフォーマンスへの影響も大きくなります。このパラメータに always オプションを選択すると、キャッシュデータが変更されるたびにバッファがフラッシュされることになるため、このオプションは推奨されません。AOF ファイルは急速に成長する場合があるため、ディスク容量要件を確認することがベストプラクティスです。AOF に関するもう 1 つのパフォーマンス上の考慮事項は、AOF ファイルを再現するために必要な時間です。Redis ノードにキャッシュデータを投入するには、数分必要になる場合があります。この時間中、アプリケーションは、データベースに直接クエリすることによるキャッシュされていないデータへのクエリにしか対応できません。
  • コスト – 低~中。AOF のコストは、AOF ファイルを再現する必要がある場合には必ず付随する時間要件とパフォーマンス上の考慮事項に最も強く関連しています。ディスク容量要件は、先ほど説明したスナップショットオプションの容量を超えます。

詳細については、「Redis 用 ElastiCache 追加専用ファイル (AOF)」を参照してください。