🌋
AWS 災害対策
はじめに
本記事は、AWS内で利用可能なRTO（復旧目標時間）およびRPO（復旧点目標）の要件に基づく災害対策戦略オプションと、それに関連するAWSのサービスについてのまとめです
RPOと RTO
- RTO（Recovery Time Objective、目標復旧時間）：災害発生からシステムが完全復旧するまでに要する時間
- RPO（Recovery Point Objective、目標復旧時点）：バックアップから復旧したデータはいつの時点まで戻っても良いかの指標
災害対策オプション
AWS 内で利用できる災害対策戦略は、コストが低くて複雑さが少ないバックアップ作成から、複数のアクティブなリージョンを使用したより複雑な戦略まで、4 つのアプローチに大別できる
バックアップと復元
- データの損失や破損を軽減するために適したアプローチ
- 他の AWS リージョンにデータをレプリケートしてリージョンの災害を軽減
- 1 つのアベイラビリティーゾーンにデプロイしたワークロードの冗長性の欠如を軽減
- データに加えて、インフラストラクチャ、設定、アプリケーションコードを復旧先のリージョンに再デプロイする必要がある
- 常に AWS CloudFormation や AWS CDK などInfrastructure as Code (IaC) を使用してデプロイする
- WEB層：
AMIやEBSスナップショットを作成 - DB層：
RDSのスナップショットを作成
-
クロスリージョンコピー
- 復元先のリージョンへ定期的に実行
- 他のリージョンで復元するために必要
- AMIとEBSスナップショット
- 対象範囲：リージョン
- DLM(Data Lifecycle Manager)で自動取得し、クロスリージョンコピーをスケーリングできる
- RDSスナップショット
- 対象範囲：リージョン
- データベースエンジンによって、組み込みの自動スナップショット機能でクロスリージョンコピーもオプジョンで指定できる
パイロットライト
- あるリージョンから別のリージョンにデータをレプリケートし、コアワークロードインフラストラクチャのコピーをプロビジョニング
- データのレプリケーションとバックアップをサポートするために必要なリソース(データベース、S3など)は常に稼働
- 他の要素(アプリケーションサーバーなど)は、アプリケーションコードや設定とともにロードされるが、オフに切り替えられ、災害対策フェイルオーバーの起動時にのみ使用される
ウォームスタンバイ(最小構成のスタンバイ)
- 本番環境のスケールダウンしたバージョンではあるが、完全な機能を備えたコピーを別のリージョンに確保
- パイロットライトの拡張
- 別のリージョンでワークロードが常に稼動しているため、復旧までの時間が短縮される
マルチサイトアクティブ/アクティブ
- ワークロードを複数のリージョンで同時に実行
- デプロイ先のすべてのリージョンからのトラフィックを処理（ユーザーはデプロイ先のすべてのリージョンでワークロードにアクセスできる）
- 災害対策として最も複雑でコストのかかるアプローチ
- ほとんどの災害で復旧時間をほぼゼロにまで短縮（ただし、データが破損した場合は、バックアップに依存する必要があり、通常は復旧時点がゼロ以外）
災害対策に関連するAWSのサービス
AWS Storage Gateway
オンプレミスから主にS3などAWSのストレージサービスをシームレス(透過的)に使用できる
オンプレミスのアプリケーションデータのバックアップ先としてもAWSを使用できる
ゲートウェイ
Amazon S3 ファイルゲートウェイ
- SMB(Server Message Block)/NFS(Network File System)プロトコルでマウントしてデータを保存するケースで利用
- マウントした仮想イメージに保存したデータは自動的にS3バケットに保存される
- ファイル共有設定時に、保存したオブジェクトのストレージクラスを選択
- S3 標準
- S3 Intelligent-Tiering
- S3 標準 IA
- S3 1ゾーンIA
- ライフサイクルポリシー、クロスリージョンレプリケーション、バージョニングを使用してS3のデータを管理できる
- コスト最適化：保管後にS3のライフサイクルポリシーを使用して、S3 Glacierに移行
Amazon FSx ファイルゲートウェイ
- FSx for Windowsへのオンプレミスからのファイル共有で使用
ボリュームゲートウェイ
-
iSCSIブロックストレージボリュームを必要とする場合に使用
-
保存したデータはStorage Gatewayのボリュームに保存される
-
保管型
- 保存したデータがオンプレミスとAWS両方に非同期で保存
-
キャッシュ型
- すべてのデータはAWSに保存
- オンプレミスには頻繁にアクセスするデータだけがキャッシュとして保管
テープゲートウェイ
- 保存先：テープ装置からAWSの仮想テープライブラリ(VTL)に変更可能（オンプレミスで使用しているバックアップソフトウェアはそのまま使用可能）
- テープアーカイブの保存先：Glacierプール or Archiveプール
- テープ保持ロック機能
- コンプライアンスモード：指定した保持期間のテーブ削除はルートユーザーにもできない
- ガバナンスモード：IAMポリシーで許可されたユーザーのみが削除できる
仮想イメージ
ゲートウェイ作成時に選択して、AWSよりダウンロードできる
- VMware ESXi
- Microsoft Hyper-V 2012R2/2016
- Linux KVM
AWS Backup
システム全体のストレージ、データベースサービスのバックアップを一元管理して自動化
対象サービス
- EC2インスタンス
- EBSボリューム
- RDS (+ Aurora)
- DynamoDBテーブル
- Volume Gateway
- EFS
- FSx (for Lustre、for Window File Server)
構成要素
- バックアップボールト
- バックアップを管理する抽象的な入れ物
- バックアップされたリソースは、ボールトの回復ポイントから復元
- アプリケーション単位
- ボールトを作成して管理
- ボールト単位
- KMSキーによる暗号化設定
- ボールトのリソースベースのポリシーが設定できる
- バックアッププラン
- ルールとリソースを指定
- ルール
- バックアップスケジュール、保存世代、対象のボールトを指定
- 他のリージョンへのバックアップコピーをさらに指定可能
- リソース
- 同じリージョンの対象リソースタイプ(EBS、RDSなど)を全て指定、または特定のタグキーと値で指定
AWS Elastic Disaster Recovery
システムのダウンタイム時間を最小に抑えながら、オンプレミスのサーバーをAWSへ復旧
- オンプレミスサーバーにはエージェントをインストール
- 設定により、継続的にレプリケートされる
- 障害発生時
- ポイントインタイムで特定のタイミングを指定可能
- 最新のタイミングから復元可能
- 復元先：起動テンプレートにより起動されたEC2インスタンス
AWS Global Accelerator
- 災害対策フェイルオーバー時間をさらに短縮できる
- ヘルスチェックによりアクティブなエンドポイントが正常でないと判断すると、使用可能な別のエンドポイントへのトラフィック転送を即時開始
-
固定化されたエニーキャストIPアドレスを使用
- DNSキャッシュの影響を受けない
AWS Fault Injection Simulator
用意されたシナリオによる障害をAWSリソースに注入することで、災害をシミュレーションできる
Discussion