STAY KOBE

[SolutionArchitect Pro] ホワイトペーパー：災害からの復旧

Atsushi Marumo

Jayendra’s Blog

この記事は自己学習用に「AWS Disaster Recovery – Whitepaper （Jayendra’s Blogより）」を日本語に訳した記事です。

AWSディザスタリカバリホワイトペーパー

AWSディザスタリカバリホワイトペーパーは、Associate＆Professional AWS認定試験のための非常に重要なホワイトペーパーの1つです

災害復旧の概要

障害復旧キーAWSサービス

  1. リージョン
    • AWSサービスは世界中の複数のリージョンで利用でき、DRサイトの場所はプライマリサイトの場所に加えて適切に選択できます。
  2. ストレージ
    • Amazon S3
      • ミッションクリティカルでプライマリなデータストレージ用に設計された耐久性の高い（99.999999999％）ストレージインフラストラクチャを提供します。
      • リージョン内の複数の施設にまたがって複数のデバイスに重複してオブジェクトを格納します。
    • Amazon Glacier
      • データのアーカイブとバックアップに非常に低コストのストレージを提供します。
      • オブジェクトは頻繁にアクセスされないように最適化されており、検索時間は数(3-5)時間で十分です。
    • Amazon EBS
      • データボリュームのポイントインタイムスナップショットを作成する機能を提供します。
      • スナップショットを使用してボリュームを作成し、実行中のインスタンスにアタッチすることができます。
    • Amazon ストレージゲートウェイ
      • オンプレミスのIT環境とAWSのストレージインフラストラクチャとのシームレスで安全性の高い統合を実現するサービスです。
    • AWS Import/Export
      • インターネットを迂回するポータブルストレージデバイスを使用して大量のデータをAWSとの間で移動させることを加速します。
      • Amazonの高速内部ネットワークを使用して、ストレージデバイスに直接データを転送します。
  3. Compute
    • Amazon EC2
      • クラウドにサイズ変更可能な計算能力を提供し、容易に作成および拡張することができます。
      • 事前設定されたAMIを使用したEC2インスタンスの作成。
      • EC2インスタンスは、他のAZの障害から隔離されるように設計された複数のAZで起動できます。
  4. ネットワーキング
    • Route53
      • 高可用性と拡張性を備えたDNS Webサービスです。
      • たとえば、DNSエンドポイントの健全性チェックや複数のエンドポイント間のフェールオーバー機能などのDRシナリオを処理する場合に効果的な、多数のグローバルなロードバランシング機能が含まれています。
    • Elastic IP
      • アドレスは、プログラムで再マッピングすることによってインスタンスまたは可用性ゾーンの障害をマスクすることができます。
      • アドレスは、動的クラウドコンピューティング用に設計された静的IPアドレスです。
    • ELB
      • ヘルスチェックを実行し、着信アプリケーショントラフィックを複数のEC2インスタンスに自動的に配信する。
    • Amazon VPC
      • 定義された仮想ネットワーク内でリソースを起動できる、AWSクラウドの非公開の独立したセクションをプロビジョニングできます。
    • Amazon ダイレクトコネクト
      • オンプレミス環境からAWSへの専用ネットワーク接続を簡単にセットアップできます。
  5. データベース
    • RDS、DynamoDb、Redshiftは、完全に管理されたRDBMS、NoSQLおよびデータウェアハウスソリューションとして提供され、容易に拡張できます。
    • DynamoDBはクロスリージョンレプリケーションを提供します。
    • RDSはマルチAZおよびリードレプリカを提供し、あるリージョンから別のリージョンにデータをスナップショットする機能も備えています。
  6. デプロイメント・オーケストレーション
    • CloudFront
      • 開発者やシステム管理者は関連するAWSリソースのコレクションを簡単に作成し、秩序ある予測可能な方法で提供することができます。
    • Elastic Beanstalk
      • Webアプリケーションとサービスの展開とスケーリングのための使いやすいサービスです。
    • OpsWork
      • すべてのタイプとサイズのアプリケーションの配備と操作を容易にするアプリケーション管理サービスです。
      • 環境は一連のレイヤーとして定義でき、各レイヤーはアプリケーションの層として構成できます。
      • 自動的にホストが置換されるため、インスタンスに障害が発生した場合に自動的に置換されます。
      • 環境をテンプレート化する準備段階で使用し、回復段階でAWS CloudFormationと組み合わせることができます。
      • 定義されたRTOをサポートするために、格納された構成からスタックを迅速にプロビジョニングできます。

災害計画の主要因


Recovery Time Objective (RTO) – たとえば、RTOが1時間で午後12時（正午）に災害が発生した場合の業務レベル契約（OLA）で定義されているように、ビジネスプロセスをそのサービスレベルに復元するために中断した後、DR プロセスは1時間以内にシステムを許容可能なサービスレベルに復元する必要があります。
Recovery Point Objective (RPO) – 災害発生前に測定されたデータ損失の許容量。 たとえば、午後12:00（正午）に災害が発生し、RPOが1時間である場合、システム内のすべてのデータを午前11:00以降のデータに回復する必要があります。

災害復旧のシナリオ

障害回復シナリオのオプション

  1. バックアップと復元（データのバックアップと復元）
  2. パイロットライト（最小臨界機能のみ）
  3. ウォームスタンバイ（完全機能縮小版）
  4. マルチサイト（アクティブ – アクティブ）

    DRシナリオオプションの場合、バックアップ＆リストアオプション（左）からマルチサイトオプション（右）に移動すると、RTOとRPOはコストの増加とともに減少します。

バックアップ＆リストア

AWSを使用すると、費用対効果の高い、耐久性のある安全な方法でデータをバックアップし、データを迅速かつ確実にリカバリすることができます。

バックアップフェーズ

従来のほとんどの環境では、データはテープにバックアップされ、障害や災害が発生した場合にシステムを復元するために定期的にオフサイトに送信されます。

  1. Amazon S3を使用してデータをバックアップし、迅速なリストアを実行できます。また、任意の場所からも利用できます。
  2. AWSインポート/エクスポートを使用すると、ストレージデバイスをインターネット経由でAWSに直接出荷することで、大きなデータセットを転送できます。
  3. Amazon Glacierは、数時間の検索時間が適切で受け入れやすい、データのアーカイブに使用できます。
  4. AWS Storage Gatewayを使用すると、オンプレミスデータボリュームのスナップショット（作成されたEBSボリュームに使用）をバックアップ用にS3に透過的にコピーできます。 バックアップソリューション（ゲートウェイ格納ボリューム）またはプライマリデータストア（ゲートウェイキャッシュボリューム）として使用できます。
  5. AWS Direct Connectを使用すると、On-PremiseからAmazonまで、一貫して高速でデータを直接転送できます。
  6. Amazon EBSボリューム、Amazon RDSデータベース、Amazon RedshiftデータウェアハウスのスナップショットをAmazon S3に保存できます。

リストアフェーズ

バックアップしたデータを使用して、ComputeおよびDatabaseインスタンスを迅速にリストアして作成できます。

バックアップと復元の主な手順
1. 適切なツールまたは方法を選択して、データをAWSにバックアップします。
2. このデータの適切な保持ポリシーを確認します。
3. 暗号化やアクセスポリシーなど、このデータに適切なセキュリティ対策が施されていることを確認します。
4. このデータの復旧とシステムの復旧を定期的にテストします。

パイロット・ライト

パイロットライトディザスタリカバリのシナリオオプションでは、環境の最小限のバージョンがクラウド内で常に実行されています。クラウドは基本的にデータベースなどのアプリケーションの重要な機能をホストします。

ウォームスタンバイ

マルチサイト

AWS認定試験の練習問題

  1. これらの災害復旧オプションで、どのコストが一番少ないか?
    1. パイロットライト (ほとんどのシステムはダウンしており、災害後にのみ)。
    2. 完全に働く低容量のウォームスタンバイ
    3. マルチサイトアクティブ-アクティブ
  2. 現在、社内のデータセンターで2層の WEB アプリケーションが実行されています。過去2か月でいくつかのインフラストラクチャの障害が発生したため、重大な財務損失が発生します。お客様の CIO は、アプリケーションを AWS に移動することに強く同意します。他の企業幹部からのバイインの実現に取り組んでいる一方で、短期的にはビジネス継続性を向上させるための災害復旧計画の策定を求めている。目標復旧時間 (RTO) を4時間とし、1時間以下の RPO (目標復旧時点) を指定します。彼はまた、2週間以内にソリューションを実装するように求められます。データベースのサイズは200GB であり、20Mbps インターネット接続を使用しています。コストを最小限に抑えながら、どのようにしたらいいでしょうか。
    1. 新規インストールまたはアプリケーションを含む EBS バックアップ、プライベート AMI を作成します。データセンターのスクリプトをセットアップして、ローカルデータベースを1時間ごとにバックアップし、結果のファイルをマルチパートアップロードを使用して s3 バケットに暗号化およびコピーします。(AMI はコストを抑えるための正しいアプローチですが、S3 へのアップロードは非常に遅くなります)。
    2. アプリケーションの平均的な負荷をサポートできるコンピューティング最適化された EC2 インスタンスにアプリケーションをインストールします。セキュリティで保護されたダイレクトコネクトを介して、オンプレミスデータベースから AWS のデータベースインスタンスに同期的にトランザクションをレプリケートします。(EC2 は最適化された計算で実行し、ダイレクトコネクトも開始するにはコストがかかる。ダイレクトコネクトは2週間では実装できません)。
    3. 複数のアベイラビリティーゾーンにまたがる自動スケーリンググループ内の EC2 インスタンスにアプリケーションをデプロイするセキュリティで保護された VPN 接続を介して、オンプレミスデータベースから AWS のデータベースインスタンスに非同期的にトランザクションをレプリケートします。(VPN を使用して迅速に非同期レプリケーションが動作することができますが、DR のインスタンスを実行しているため高価です。）
    4. アプリケーションの新規インストールを含む EBS バックアップ、プライベート AMI を作成します。AMI と必要な EC2 を含むテンプレートを作成します。複数のアベイラビリティーゾーンにまたがるアプリケーションの展開をサポートするために、リソースの自動スケーリングと ELB を行います。セキュリティで保護された VPN 接続を介して、オンプレミスデータベースから AWS のデータベースインスタンスにトランザクションを非同期にレプリケートします。(AMI および自動スケーリング設定を構成している間は、DB のみを実行してレプリケートするパイロットライトアプローチ)。
  3. あなたは、エンドユーザーに最小限のダウンタイムで非常に迅速に災害から回復することができるアーキテクチャを設計しています。次のどちらの方法が最適ですか。
    1. ルート53のヘルスチェックを利用して、プライマリサイトが到達不能になったときに自動的にバックアップサイトにフェールオーバーします。
    2. プライマリサイトが到達不能になった場合にトラフィックをシームレスに処理できるように、パイロットライト DR アーキテクチャを実装します。
    3. プライマリサイトが到達不能になっても、エンドユーザーが遅延を発生させないように、完全に動作する低容量スタンバイまたはマルチサイト・アクティブ-アクティブ・アーキテクチャのいずれかを実装します。
    4. 高可用性を確保するために、マルチリージョンアーキテクチャを実装します。
  4. お客様は、複数の WEB サーバー、複数のアプリケーションサーバー、および小規模 (50 GB) の Oracle データベースから成る AWS にエンタープライズアプリケーションを導入することを希望しています。情報は、データベースとさまざまなサーバーのファイルシステムの両方に格納されます。バックアップシステムでは、データベースの回復、サーバー全体、およびディスク全体の復元をサポートする必要があり、復旧時間が2時間を超えて個別のファイルが復元されます。彼らは、データベースとして RAS Oracle を使用するように選択しました。これらの要件を満たすバックアップアーキテクチャはどれですか。
    1. 自動日次 DB バックアップを使用して RDS をバックアップします。AMI を使用して EC2 インスタンスをバックアップし、ファイルレベルの復元を提供するために、従来のエンタープライズバックアップソフトウェアを使用することで、S3 へのバックアップを追加します。(迅速なフェイルオーバーのためのマルチ AZ 展開を好むでしょう)
    2. マルチ AZ 展開を使用したバックアップ RDS は、AMI を使用して EC2 インスタンスをバックアップし、ファイルシステムデータを S3 にコピーしてファイルレベルの復元を提供します。
    3. 自動日次 DB バックアップを使用して RDS をバックアップします。EBS スナップショットを使用して EC2 インスタンスをバックアップし、ファイルレベルの復元を提供するために、従来のエンタープライズバックアップソフトウェアを使用して Amazon Glacierにファイルレベルのバックアップを追加します。(Glacierは2時間の RTO とのオプションではありません)
    4. Oracle RMAN を使用して S3 にバックアップ RDS データベース。AMI を使用して EC2 インスタンスをバックアップし、個々のボリュームリストアのために EBS スナップショットを補足します。(データベースが EC2 でホストされていて、RDS を使用していない場合にのみ RMAN を使用します)
  5. パイロットライトの障害復旧アーキテクチャパターンについては、どのステートメントが当てはまりますか。
    1. パイロットライトはホットスタンバイ (コールドスタンバイ)
    2. AWS へのすべての重要なデータのレプリケーションを有効にします
    3. 非常に費用対効果の高い DR パターン
    4. 現在の生産負荷を処理するために必要に応じてシステムを拡張可能
  6. ERP アプリケーションは、単一のリージョン内の複数のAZにまたがってデプロイされます。障害が発生した場合、目標復旧時間 (RTO) は3時間未満で、RPO (目標復旧時点) は15分にする必要があります。顧客は、データの破損が約1.5 時間前に発生したことを実現します。このような障害が発生した場合に、この RTO と RPO を達成するためにどのような DR 戦略を使用できますか。
    1. S3 に毎時 DB バックアップを実行し、トランザクションログは5分ごとに S3 に格納されます。
    2. 2つのアベイラビリティーゾーン間で同期データベースマスタスレーブレプリケーションを使用します。(レプリケーションはバックトラックに役立つことはありませんし、常に同期される)
    3. 5分ごとに S3 に格納されたトランザクションログを使用して、EC2 インスタンスストアボリュームに毎時 DB バックアップを実行します。(インスタンスストアは優先ストレージではありません)
    4. 5分ごとに S3 に格納されたトランザクションログを使用して、Glacier に保存された15分間の DB バックアップを実行します。(Glacierは RTO を満たしていません)
  7. 社内のコンテンツ管理システムには、次のアーキテクチャがあります。
    –アプリケーション層– JBOSS アプリケーションサーバ上の Java コード
    ―データベース層― Oracle のデータベースを定期的に Amazon のシンプルなストレージサービス (S3) は、Oracle RMAN のバックアップユーティリティを使用してバックアップ
    ―静的なコンテンツ– 512GB ゲートウェイに格納されているストレージゲートウェイのボリュームは、iSCSI interfaceWhich AWS ベースの災害復旧戦略を介してアプリケーションサーバに接続され、最高の RTO を提供しますか?
    1. Oracle データベースと JBOSS アプリケーションサーバーを EC2 にデプロイします。Amazon S3 から RMAN Oracle バックアップをリストアします。ストレージゲートウェイからの静的コンテンツの EBS ボリュームを生成し、JBOSS EC2 サーバーに接続します。
    2. RDS に Oracle データベースを展開します。JBOSS アプリケーションサーバーを EC2 にデプロイします。Amazon Glacierから RMAN Oracle バックアップを復元します。ストレージゲートウェイからの静的コンテンツの EBS ボリュームを生成し、JBOSS EC2 サーバーに接続します。(Glacierは最高の RTO を与えるのに役立ちます)
    3. Oralce データベースと JBOSS アプリケーションサーバーを EC2 にデプロイします。Amazon S3 から RMAN Oracle バックアップをリストアします。Amazon EC2 上で実行されている AWS ストレージゲートウェイを、iSCSI ボリュームとして JBOSS EC2 サーバーに接続して、静的コンテンツを復元します。(iscsi ボリュームとしてストレージ・ゲートウェイを接続する必要はないので、EBS ボリュームを作成するだけでかまいません)
    4. Oracle データベースと JBOSS アプリケーションサーバーを EC2 にデプロイします。Amazon S3 から RMAN Oracle バックアップをリストアします。Amazon EC2 で実行されている AWS ストレージゲートウェイ VTL から静的コンテンツを復元します。(VTL は仮想テープ・ライブラリであり、RTO には適合しません)

リファレンス