AWS再入門2018 バックアップとディザスタリカバリ編
こんにちは。池田です。新しい年を迎え、この一年も気を引き締めつつ日々を楽しんでいこうと思います。どうぞよろしくお願いします。
はじめに
AWS 認定ソリューションアーキテクト – プロフェッショナル認定試験の勉強をはじめようと思い試験概要を確かめますと、以下のことが求められるとのことでした。
- AWS でのアプリケーションの動的なスケーラビリティ、高可用性、高耐障害性および信頼性の設計およびデプロイ
- 与えられた要件に基づいてアプリケーションを設計およびデプロイするための、適切な AWS サービスの選択
- AWS における複雑かつ多階層のアプリケーションの移行
- AWS におけるエンタープライズ全体のスケーラブルな運用の設計およびデプロイ
- コストコントロール戦略の導入
なかなか広範囲にわたる知識が求められる認定試験ですが、クラスメソッドAWS事業部の一員ならば挑戦しない訳にはいきません。そこでまずは、AWSの仕組みを活用した高可用性と高耐障害性について基本的なことからおさらいしておこうと思い、ホワイトペーパーやAmazon Web Services Japanのslideshareに目を通してみました。
今回、学習の題材として選んだスライドは「AWSで実現するバックアップとディザスタリカバリ」という2012年に公開されたものですが、可用性と耐障害性を高めるという視点において、AWS活用方法の基本的な考え方や仕組みを整理して理解する目的に適したわかりやすい内容だと判断しました。
また、この資料はバックアップや災害対策、事業継続の一環としてAWSサービスの活用を検討している方々にも、導入のメリットや注意点がわかりやすく整理された内容ですのでご一読されることをお勧めします。
もくじ
背景の整理
ディザスタリカバリ（DR）が重要視されるようになった背景
2011年以降世界各地で発生した大規模な自然災害による経済損失は2,200億円を上回り事業継続について関心が高まり、クラウドストレージをバックアップやDR目的で導入するケースが増えた。
従来型DRが持つ課題
- 巨額の投資を必要とする
- 導入後もランニングコストの負担が大きい
- 調達に数ヶ月以上要する
- 運用リソース
結果、コスト効果や柔軟性、アジリティの低さに疑問が生じた。
・ ディザスタリカバリ（DR）
（英語：disaster recovery）とは、事業継続マネジメントにおける概念のひとつで、災害などによる被害からの回復措置、あるいは被害を最小限に抑えるための予防措置のことである。 主にコンピュータシステムやネットワークなどIT関連で用いられることが多い。（ウィキペディアより）
・アジリティ
機敏さ、俊敏性、敏捷性、素早さ、などの意味を持つ英単語。“agile”(アジャイル：素早い、機敏な)の名詞形。 ビジネスの分野で、企業などが事業環境や状況の変化に対応する素早さ、柔軟さのことをアジリティということがある。変化する状況に適応する素早さ、状況に応じて即座に適切な手を打てる俊敏さを表し、物事を進める速さ(スピード)とは区別される。（IT用語辞典 e-Wordsより）
DRのゴールとコストについて
これまでのDRではコストとRTO/RPOのトレードオフにおいて限られた選択肢しかなかった。
可用性とDRレベルをより高いレベルで維持しようとすると当然コストも大きくなる。
また、平常時のバックアップから災害発生後の復旧への手順も多く、短時間での復旧を目指すには（人的リソースもシステムリソースも）それなりのコストが発生する。
- RTO（Recovery Time Objective: 目標復旧時間）
- 事象が発生してから復旧するまでの目標時間
- RPO（Recovery Point Objective: 目標復旧時点）
- データを失ってもよい時間幅
AWS（クラウド）の導入で何が起きるか
- 初期投資が不要：ほとんどのリソースはオンデマンドで利用が可能
- ランニングコストを大幅に圧縮：オンデマンド料金での支払いとなり、コールドスタンバイなどの活用でランニングコストを最低限に抑えられる
- グローバルなインフラが利用できる：国内で大規模災害が発生した場合でも、遠く離れた海外DCでのサービス再開が可能
- 高い汎用性：様々なOS、ミドルウェアや開発言語のサポート
- セキュアで堅牢性の高いストレージ：イレブンナイン（99.999999999%の耐久性）
アベイラビリティゾーン（AZ）におけるAWSのポリシーについて
- 物理的に隔離
- 洪水面を考慮
- 安定した地盤
- UPS、バックアップ電源、異なる電源供給元
- 冗長化されたネットワーク
AWS（クラウド）を利用することで、これら条件を満たしたDCにシステムを構築、維持するためのコスト問題が解消される。
バックアップとDRへのアプローチ
- オンプレミス環境と連携する場合
- 高可用性を維持するアーキテクチャを構築
- DR戦略の構築
- 災害発生時の迅速な切り替え
- 復旧時のリストア
- AWSのみを利用する場合
- 高可用性を維持するアーキテクチャを構築
- DR戦略の構築
- 複数のAWSゾーンを利用した迅速なリストアと復旧
- AWS同士の場合は切り替えずに継続的な運用が可能
活用できるAWSサービス
- S3：高耐久性を持つWebストレージ
- EC2：仮想サーバ
- EBS：仮想ストレージ
- Route 53：SLA100%のDNSサービス
- StorageGateway：オンプレミス環境とクラウド間でのデータ自動連携
AWSにおけるアーキテクチャパターン
クラウドバックアップ＆リストア
- 仕組み
- クラウドストレージをバックアップデータの格納先に
- データリストアはオンプレミス環境へ
- 利点
- シンプルな構成
- バックアップコストの削減が可能
- クラウドをデータの外部保存先に
- S3へのデータ同期をサポートした多くのサードパーティ製品群
- 製品の機能のみでリストアが可能
- 注意点
- 災害時のデータ復旧に時間を要する
- RPOはバックアップ取得時点となる
クラウドコールドスタンバイ
- 仕組み
- クラウドをデータの外部保存先に
- 災害発生時はクラウド上でシステムを起動、データ復旧を実施
- クラウド側へシステムイメージを事前に準備する必要がある
- 利点
- シンプルな構成
- 災害時のみクラウドリソースを利用することでコストの削減が行える
- S3へのデータ同期をサポートした多くのサードパーティ製品群
- 注意点
- コールドスタンバイシステムのメンテナンスが必要
- 定期的な切り替え試験を推奨（災害対応訓練の実施）
- オペレーションが複雑化する可能性がある
- RPOはバックアップ取得時点となる
クラウドウォームスタンバイ
- 仕組み
- 常時切り替えが可能となるよう、クラウド側システムの常時稼働、データ同期も常時実施
- クラウド側システムは最小限の構成で常時稼働、災害発生時に必要なサイズへ変更
- 利点
- 切り替え時間の短縮が可能
- 最低限の構成による常時稼働のためコストを抑えられる
- 切り替えオペレーションは製品に依存するが比較的容易
- RTO/RPOの向上が見込める
- 注意点
- DCとクラウド間での常時VPNまたは専用線接続が必要（セキュリティ確保の視点からも）
- クラウド側システムの常時運用も必要
- 全てのシステムで実現できる仕組みではない
クラウドマルチサイトホットスタンバイ
- 仕組み
- オンプレミスとクラウドを跨いだ冗長化構成。障害が発生したシステムを切り離して運用
- 利点
- システムの切り替えが瞬時に行える
- どのような状況下でも本番相当の負荷を処理
- 他の仕組みと比べてRTO/RPOが最も高い
- AWSのみでの実現も可能（マネージドサービスの活用により運用負荷の軽減も計れる）
- 注意点
- DCとクラウド間での常時VPNまたは専用線接続が必要（セキュリティ確保の視点からも）
- クラウド側システムの常時運用も必要
- 実現可能なシステムが限られる
AWSを活用したベストプラクティス
- シンプルスタートから徐々に高度な仕組みへ
- 継続的にRTO/RPOを改善
- SLAに沿った適切なパターンを適用
- データ転送に注意が必要
- 回線がボトルネックになる可能性
- VPNを利用する場合、AWS側にProxyが必要
- 利用する仕組みごとにライセンスの確認をしておく
AWSリソースを活用したDR構築のまとめ
- データバックアップからホットスタンバイまで、あらゆるレベルにおいて低コストでの構築が可能
- RTO/RPOとコストバランスの選択肢が多く、実装も容易である
- Amazon S3を活用することでデータ損失のリスクを回避
- 平常時のコスト抑制と災害時の負荷に対応できるシステムを実現できる
まとめ
知っていたつもりではありましたが、改めて資料に目を通しながら整理していくことで各アーキテクチャパターンの内容を正しく理解することができました。
今後は様々な背景、システムの組み合わせパターン、各ユースケースにおけるベストプラクティスや、AWSリソースにおける具体的な技術要素などについて読み解き、実際に各サービスを体験しながら理解を深めていきたいと思います。
