Jayendra’s Blog
この記事は自己学習用に「AWS Disaster Recovery – Whitepaper (Jayendra’s Blogより)」を日本語に訳した記事です。
AWSディザスタリカバリホワイトペーパー
AWSディザスタリカバリホワイトペーパーは、Associate&Professional AWS認定試験のための非常に重要なホワイトペーパーの1つです
災害復旧の概要
- AWSディザスタリカバリホワイトペーパーでは、災害復旧(DR)プロセスに活用できるAWSサービスと機能を紹介し、データ、システム、および全体的なビジネスオペレーションへの影響を大幅に最小限に抑えます。
- 最小限の投資からフルスケールの可用性と耐障害性まで、DRプロセスを改善するためのベストプラクティスを概説し、DRイベント中にAWSサービスを使用してコストを削減し、ビジネスの継続性を確保する方法について説明します。
- 災害復旧(DR)は、災害の準備と復旧に関することです。 企業の事業継続または財務にマイナスの影響を与えるイベントは、災害と呼ばれることがあります。 AWSのベストプラクティスの1つは、常にシステムの障害を設計することです。
障害復旧キーAWSサービス
- リージョン
- AWSサービスは世界中の複数のリージョンで利用でき、DRサイトの場所はプライマリサイトの場所に加えて適切に選択できます。
- ストレージ
- Amazon S3
- ミッションクリティカルでプライマリなデータストレージ用に設計された耐久性の高い(99.999999999%)ストレージインフラストラクチャを提供します。
- リージョン内の複数の施設にまたがって複数のデバイスに重複してオブジェクトを格納します。
- Amazon Glacier
- データのアーカイブとバックアップに非常に低コストのストレージを提供します。
- オブジェクトは頻繁にアクセスされないように最適化されており、検索時間は数(3-5)時間で十分です。
- Amazon EBS
- データボリュームのポイントインタイムスナップショットを作成する機能を提供します。
- スナップショットを使用してボリュームを作成し、実行中のインスタンスにアタッチすることができます。
- Amazon ストレージゲートウェイ
- オンプレミスのIT環境とAWSのストレージインフラストラクチャとのシームレスで安全性の高い統合を実現するサービスです。
- AWS Import/Export
- インターネットを迂回するポータブルストレージデバイスを使用して大量のデータをAWSとの間で移動させることを加速します。
- Amazonの高速内部ネットワークを使用して、ストレージデバイスに直接データを転送します。
- Amazon S3
- Compute
- Amazon EC2
- クラウドにサイズ変更可能な計算能力を提供し、容易に作成および拡張することができます。
- 事前設定されたAMIを使用したEC2インスタンスの作成。
- EC2インスタンスは、他のAZの障害から隔離されるように設計された複数のAZで起動できます。
- Amazon EC2
- ネットワーキング
- Route53
- 高可用性と拡張性を備えたDNS Webサービスです。
- たとえば、DNSエンドポイントの健全性チェックや複数のエンドポイント間のフェールオーバー機能などのDRシナリオを処理する場合に効果的な、多数のグローバルなロードバランシング機能が含まれています。
- Elastic IP
- アドレスは、プログラムで再マッピングすることによってインスタンスまたは可用性ゾーンの障害をマスクすることができます。
- アドレスは、動的クラウドコンピューティング用に設計された静的IPアドレスです。
- ELB
- ヘルスチェックを実行し、着信アプリケーショントラフィックを複数のEC2インスタンスに自動的に配信する。
- Amazon VPC
- 定義された仮想ネットワーク内でリソースを起動できる、AWSクラウドの非公開の独立したセクションをプロビジョニングできます。
- Amazon ダイレクトコネクト
- オンプレミス環境からAWSへの専用ネットワーク接続を簡単にセットアップできます。
- Route53
- データベース
- RDS、DynamoDb、Redshiftは、完全に管理されたRDBMS、NoSQLおよびデータウェアハウスソリューションとして提供され、容易に拡張できます。
- DynamoDBはクロスリージョンレプリケーションを提供します。
- RDSはマルチAZおよびリードレプリカを提供し、あるリージョンから別のリージョンにデータをスナップショットする機能も備えています。
- デプロイメント・オーケストレーション
- CloudFront
- 開発者やシステム管理者は関連するAWSリソースのコレクションを簡単に作成し、秩序ある予測可能な方法で提供することができます。
- Elastic Beanstalk
- Webアプリケーションとサービスの展開とスケーリングのための使いやすいサービスです。
- OpsWork
- すべてのタイプとサイズのアプリケーションの配備と操作を容易にするアプリケーション管理サービスです。
- 環境は一連のレイヤーとして定義でき、各レイヤーはアプリケーションの層として構成できます。
- 自動的にホストが置換されるため、インスタンスに障害が発生した場合に自動的に置換されます。
- 環境をテンプレート化する準備段階で使用し、回復段階でAWS CloudFormationと組み合わせることができます。
- 定義されたRTOをサポートするために、格納された構成からスタックを迅速にプロビジョニングできます。
- CloudFront
災害計画の主要因
Recovery Time Objective (RTO) – たとえば、RTOが1時間で午後12時(正午)に災害が発生した場合の業務レベル契約(OLA)で定義されているように、ビジネスプロセスをそのサービスレベルに復元するために中断した後、DR プロセスは1時間以内にシステムを許容可能なサービスレベルに復元する必要があります。
Recovery Point Objective (RPO) – 災害発生前に測定されたデータ損失の許容量。 たとえば、午後12:00(正午)に災害が発生し、RPOが1時間である場合、システム内のすべてのデータを午前11:00以降のデータに回復する必要があります。
災害復旧のシナリオ
- 災害復旧のシナリオは、AWSと連携してデータセンターで実行されているプライマリインフラストラクチャで実装できます。
- プライマリサイトがAWSマルチリージョン機能を使用してAWSで実行されている場合、災害復旧シナリオは引き続き適用されます。
- 以下の組み合わせとバリエーションは常に可能です。
障害回復シナリオのオプション
- バックアップと復元(データのバックアップと復元)
- パイロットライト(最小臨界機能のみ)
- ウォームスタンバイ(完全機能縮小版)
- マルチサイト(アクティブ – アクティブ)
DRシナリオオプションの場合、バックアップ&リストアオプション(左)からマルチサイトオプション(右)に移動すると、RTOとRPOはコストの増加とともに減少します。
バックアップ&リストア
AWSを使用すると、費用対効果の高い、耐久性のある安全な方法でデータをバックアップし、データを迅速かつ確実にリカバリすることができます。
バックアップフェーズ
従来のほとんどの環境では、データはテープにバックアップされ、障害や災害が発生した場合にシステムを復元するために定期的にオフサイトに送信されます。
- Amazon S3を使用してデータをバックアップし、迅速なリストアを実行できます。また、任意の場所からも利用できます。
- AWSインポート/エクスポートを使用すると、ストレージデバイスをインターネット経由でAWSに直接出荷することで、大きなデータセットを転送できます。
- Amazon Glacierは、数時間の検索時間が適切で受け入れやすい、データのアーカイブに使用できます。
- AWS Storage Gatewayを使用すると、オンプレミスデータボリュームのスナップショット(作成されたEBSボリュームに使用)をバックアップ用にS3に透過的にコピーできます。 バックアップソリューション(ゲートウェイ格納ボリューム)またはプライマリデータストア(ゲートウェイキャッシュボリューム)として使用できます。
- AWS Direct Connectを使用すると、On-PremiseからAmazonまで、一貫して高速でデータを直接転送できます。
- Amazon EBSボリューム、Amazon RDSデータベース、Amazon RedshiftデータウェアハウスのスナップショットをAmazon S3に保存できます。
リストアフェーズ
バックアップしたデータを使用して、ComputeおよびDatabaseインスタンスを迅速にリストアして作成できます。
バックアップと復元の主な手順
1. 適切なツールまたは方法を選択して、データをAWSにバックアップします。
2. このデータの適切な保持ポリシーを確認します。
3. 暗号化やアクセスポリシーなど、このデータに適切なセキュリティ対策が施されていることを確認します。
4. このデータの復旧とシステムの復旧を定期的にテストします。
パイロット・ライト
パイロットライトディザスタリカバリのシナリオオプションでは、環境の最小限のバージョンがクラウド内で常に実行されています。クラウドは基本的にデータベースなどのアプリケーションの重要な機能をホストします。
- このアプローチでは
- AWSでシステムの最も重要なコア要素を設定して実行し、パイロットライトを維持します。 データを複製して更新する必要があるデータベース。
- リカバリの間、本格的な生産環境、例えば、 アプリケーションおよびWebサーバーは、クリティカルコアの周りに迅速にプロビジョニングできます(事前構成済みのAMIおよびEBSボリュームスナップショットを使用)。
- ネットワークの場合、トラフィックを複数のインスタンスに配布し、DNSがロードバランサを指し示すか、インスタンスが関連付けられた事前割り当てのElastic IPアドレスを使用するELBを使用できます。
- 準備段階
- Amazon EC2インスタンスまたはRDSインスタンスを設定して、データの重要なデータを複製またはミラーリングします。
- サポートしているすべてのカスタムソフトウェアパッケージがAWSで使用できることを確認します。
- 迅速な復旧が必要な主要サーバーのAMIを作成して維持する。
- これらのサーバーを定期的に実行してテストし、ソフトウェアの更新と構成の変更を適用します。
- AWSリソースのプロビジョニングを自動化することを検討してください。
- リカバリーフェーズ
- 独自のAMIからアプリケーションEC2インスタンスを起動します。
- 既存のデータベース/データストアインスタンスのサイズを変更して、トラフィックの増加を処理します。たとえば、RDSを使用する場合、EC2インスタンスを水平方向に容易に拡大縮小することができます。
- 追加のデータベース/データストアインスタンスを追加して、DRサイトの復元力をデータ層に与えます。たとえば、Multi-AZ for RDSをオンにして復元力を向上させます。
- Amazon EC2サーバーを指すようにDNSを変更します。
- 理想的には自動化された方法で、非AMIベースのシステムをインストールして構成します。
ウォームスタンバイ
- ウォームスタンバイ DR シナリオでは、ビジネスクリティカルシステムと完全に同一に機能する環境のスケールダウンバージョンが常にクラウドで実行されます。
- この設定は、テスト、品質保証、または内部使用のために使用できます。
- 災害が発生した場合は、システムを簡単にスケールアップまたはアウトして、生産負荷を処理することができます。
- 準備段階:
- amazon ec2 インスタンスを設定して、データをレプリケートまたはミラーリングします。
- より迅速なプロビジョニングのために ami を作成および管理します。
- ec2 インスタンスまたは aws インフラストラクチャの最小限のフットプリントを使用してアプリケーションを実行します。
- ライブ環境に合わせて、ソフトウェアと構成ファイルを修正して更新します。
- リカバリー手順:
- サービス内の amazon ec2 フリートのサイズをロードバランサーに増やします。(水平スケーリング)
- 必要に応じて、より大きな amazon ec2 インスタンスタイプでアプリケーションを起動します。 (垂直スケーリング)
- 手動で dns レコードを変更するか、ルート53の自動ヘルスチェックを使用して、すべてのトラフィックを aws 環境にルーティングします。
- 自動スケーリングを使用してフリートを正しいサイズにするか、増加した負荷に対応することを検討してください。
- 回復力を追加するか、データベースをスケールアップして、DR がダウンするのを防ぐ。
マルチサイト
- マルチサイトはアクティブ-アクティブな構成の DR アプローチであり、同一のソリューションでは、オンサイトインフラストラクチャとして aws 上で実行されます。
- トラフィックは、DNS 重み付けルーティングを使用して、必要に応じて両方のインフラストラクチャに均等に分散できます。
- 災害が発生した場合、DNS はすべてのトラフィックを AWS 環境に送信するように調整でき、AWS インフラストラクチャはそれに応じてスケーリングされます。
- 準備段階:
- 運用環境を複製するように AWS 環境を設定します。
- DNS の重み付け、または同様のトラフィックルーティングテクノロジを設定して、着信要求を両方のサイトに配布します。
- 自動フェールオーバーを構成して、影響を受けるサイトからトラフィックを再ルーティングします。たとえば、AWS DB にリダイレクトしない場合にプライマリ DB が使用可能かどうかを確認するアプリケーション
- リカバリー手順:
- 手動または DNS フェールオーバーを使用して、すべての要求が AWS サイトに送信されるように DNS の重み付けを変更します。
- すべてのクエリに対してローカル AWS データベースサーバーを使用するために、フェイルオーバー用のアプリケーションロジックを持っている。
- 自動スケーリングを使用して AWS フリートを自動的に適切なサイズにすることを検討してください。
AWS認定試験の練習問題
- 質問はインターネットから収集され、答えは自分の知識と理解に基づいてマークされます(これはあなたと異なる場合があります)。
- AWSサービスは毎日更新され、回答と質問はすぐに時代遅れになる可能性がありますので、それに応じて調査してください。
- AWSのアップデートのペースを追うためにAWS試験の質問は更新されないため、基礎となる機能が変更されても質問が更新されないことがあります。
- さらなるフィードバック、ディスカッション、修正を可能にします。
- これらの災害復旧オプションで、どのコストが一番少ないか?
- パイロットライト (ほとんどのシステムはダウンしており、災害後にのみ)。
- 完全に働く低容量のウォームスタンバイ
- マルチサイトアクティブ-アクティブ
- 現在、社内のデータセンターで2層の WEB アプリケーションが実行されています。過去2か月でいくつかのインフラストラクチャの障害が発生したため、重大な財務損失が発生します。お客様の CIO は、アプリケーションを AWS に移動することに強く同意します。他の企業幹部からのバイインの実現に取り組んでいる一方で、短期的にはビジネス継続性を向上させるための災害復旧計画の策定を求めている。目標復旧時間 (RTO) を4時間とし、1時間以下の RPO (目標復旧時点) を指定します。彼はまた、2週間以内にソリューションを実装するように求められます。データベースのサイズは200GB であり、20Mbps インターネット接続を使用しています。コストを最小限に抑えながら、どのようにしたらいいでしょうか。
- 新規インストールまたはアプリケーションを含む EBS バックアップ、プライベート AMI を作成します。データセンターのスクリプトをセットアップして、ローカルデータベースを1時間ごとにバックアップし、結果のファイルをマルチパートアップロードを使用して s3 バケットに暗号化およびコピーします。(AMI はコストを抑えるための正しいアプローチですが、S3 へのアップロードは非常に遅くなります)。
- アプリケーションの平均的な負荷をサポートできるコンピューティング最適化された EC2 インスタンスにアプリケーションをインストールします。セキュリティで保護されたダイレクトコネクトを介して、オンプレミスデータベースから AWS のデータベースインスタンスに同期的にトランザクションをレプリケートします。(EC2 は最適化された計算で実行し、ダイレクトコネクトも開始するにはコストがかかる。ダイレクトコネクトは2週間では実装できません)。
- 複数のアベイラビリティーゾーンにまたがる自動スケーリンググループ内の EC2 インスタンスにアプリケーションをデプロイするセキュリティで保護された VPN 接続を介して、オンプレミスデータベースから AWS のデータベースインスタンスに非同期的にトランザクションをレプリケートします。(VPN を使用して迅速に非同期レプリケーションが動作することができますが、DR のインスタンスを実行しているため高価です。)
- アプリケーションの新規インストールを含む EBS バックアップ、プライベート AMI を作成します。AMI と必要な EC2 を含むテンプレートを作成します。複数のアベイラビリティーゾーンにまたがるアプリケーションの展開をサポートするために、リソースの自動スケーリングと ELB を行います。セキュリティで保護された VPN 接続を介して、オンプレミスデータベースから AWS のデータベースインスタンスにトランザクションを非同期にレプリケートします。(AMI および自動スケーリング設定を構成している間は、DB のみを実行してレプリケートするパイロットライトアプローチ)。
- あなたは、エンドユーザーに最小限のダウンタイムで非常に迅速に災害から回復することができるアーキテクチャを設計しています。次のどちらの方法が最適ですか。
- ルート53のヘルスチェックを利用して、プライマリサイトが到達不能になったときに自動的にバックアップサイトにフェールオーバーします。
- プライマリサイトが到達不能になった場合にトラフィックをシームレスに処理できるように、パイロットライト DR アーキテクチャを実装します。
- プライマリサイトが到達不能になっても、エンドユーザーが遅延を発生させないように、完全に動作する低容量スタンバイまたはマルチサイト・アクティブ-アクティブ・アーキテクチャのいずれかを実装します。
- 高可用性を確保するために、マルチリージョンアーキテクチャを実装します。
- お客様は、複数の WEB サーバー、複数のアプリケーションサーバー、および小規模 (50 GB) の Oracle データベースから成る AWS にエンタープライズアプリケーションを導入することを希望しています。情報は、データベースとさまざまなサーバーのファイルシステムの両方に格納されます。バックアップシステムでは、データベースの回復、サーバー全体、およびディスク全体の復元をサポートする必要があり、復旧時間が2時間を超えて個別のファイルが復元されます。彼らは、データベースとして RAS Oracle を使用するように選択しました。これらの要件を満たすバックアップアーキテクチャはどれですか。
- 自動日次 DB バックアップを使用して RDS をバックアップします。AMI を使用して EC2 インスタンスをバックアップし、ファイルレベルの復元を提供するために、従来のエンタープライズバックアップソフトウェアを使用することで、S3 へのバックアップを追加します。(迅速なフェイルオーバーのためのマルチ AZ 展開を好むでしょう)
- マルチ AZ 展開を使用したバックアップ RDS は、AMI を使用して EC2 インスタンスをバックアップし、ファイルシステムデータを S3 にコピーしてファイルレベルの復元を提供します。
- 自動日次 DB バックアップを使用して RDS をバックアップします。EBS スナップショットを使用して EC2 インスタンスをバックアップし、ファイルレベルの復元を提供するために、従来のエンタープライズバックアップソフトウェアを使用して Amazon Glacierにファイルレベルのバックアップを追加します。(Glacierは2時間の RTO とのオプションではありません)
- Oracle RMAN を使用して S3 にバックアップ RDS データベース。AMI を使用して EC2 インスタンスをバックアップし、個々のボリュームリストアのために EBS スナップショットを補足します。(データベースが EC2 でホストされていて、RDS を使用していない場合にのみ RMAN を使用します)
- パイロットライトの障害復旧アーキテクチャパターンについては、どのステートメントが当てはまりますか。
- パイロットライトはホットスタンバイ (コールドスタンバイ)
- AWS へのすべての重要なデータのレプリケーションを有効にします
- 非常に費用対効果の高い DR パターン
- 現在の生産負荷を処理するために必要に応じてシステムを拡張可能
- ERP アプリケーションは、単一のリージョン内の複数のAZにまたがってデプロイされます。障害が発生した場合、目標復旧時間 (RTO) は3時間未満で、RPO (目標復旧時点) は15分にする必要があります。顧客は、データの破損が約1.5 時間前に発生したことを実現します。このような障害が発生した場合に、この RTO と RPO を達成するためにどのような DR 戦略を使用できますか。
- S3 に毎時 DB バックアップを実行し、トランザクションログは5分ごとに S3 に格納されます。
- 2つのアベイラビリティーゾーン間で同期データベースマスタスレーブレプリケーションを使用します。(レプリケーションはバックトラックに役立つことはありませんし、常に同期される)
- 5分ごとに S3 に格納されたトランザクションログを使用して、EC2 インスタンスストアボリュームに毎時 DB バックアップを実行します。(インスタンスストアは優先ストレージではありません)
- 5分ごとに S3 に格納されたトランザクションログを使用して、Glacier に保存された15分間の DB バックアップを実行します。(Glacierは RTO を満たしていません)
- 社内のコンテンツ管理システムには、次のアーキテクチャがあります。
–アプリケーション層– JBOSS アプリケーションサーバ上の Java コード
―データベース層― Oracle のデータベースを定期的に Amazon のシンプルなストレージサービス (S3) は、Oracle RMAN のバックアップユーティリティを使用してバックアップ
―静的なコンテンツ– 512GB ゲートウェイに格納されているストレージゲートウェイのボリュームは、iSCSI interfaceWhich AWS ベースの災害復旧戦略を介してアプリケーションサーバに接続され、最高の RTO を提供しますか?- Oracle データベースと JBOSS アプリケーションサーバーを EC2 にデプロイします。Amazon S3 から RMAN Oracle バックアップをリストアします。ストレージゲートウェイからの静的コンテンツの EBS ボリュームを生成し、JBOSS EC2 サーバーに接続します。
- RDS に Oracle データベースを展開します。JBOSS アプリケーションサーバーを EC2 にデプロイします。Amazon Glacierから RMAN Oracle バックアップを復元します。ストレージゲートウェイからの静的コンテンツの EBS ボリュームを生成し、JBOSS EC2 サーバーに接続します。(Glacierは最高の RTO を与えるのに役立ちます)
- Oralce データベースと JBOSS アプリケーションサーバーを EC2 にデプロイします。Amazon S3 から RMAN Oracle バックアップをリストアします。Amazon EC2 上で実行されている AWS ストレージゲートウェイを、iSCSI ボリュームとして JBOSS EC2 サーバーに接続して、静的コンテンツを復元します。(iscsi ボリュームとしてストレージ・ゲートウェイを接続する必要はないので、EBS ボリュームを作成するだけでかまいません)
- Oracle データベースと JBOSS アプリケーションサーバーを EC2 にデプロイします。Amazon S3 から RMAN Oracle バックアップをリストアします。Amazon EC2 で実行されている AWS ストレージゲートウェイ VTL から静的コンテンツを復元します。(VTL は仮想テープ・ライブラリであり、RTO には適合しません)
リファレンス
- ホワイトペーパー:「障害復旧を目的とした Amazon Web Services の使用」
コメントを残す