はじめに p.405
この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧はこちら。
この記事ではAWSにおけるディザスタリカバリを超詳細解説しています。
具体的には以下流れで説明します。
- RPOとRTO
- AWSにおけるディザスタリカバリ
- ディザスタリカバリのベストプラクティス
AWSの区分でいう「Level 200：トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。
この記事を読んでほしい人
- AWSにおけるディザスタリカバリを説明できるようになりたい人
- AWS Certified DevOps Engineer Professionalを目指している人
RPO（Recovery Point Objective）と RTO（Recovery Time Objective）
1. RPO（Recovery Point Objective）
RPO は、ディザスタリカバリ計画において設定されるパラメータで、災害発生時に許容されるデータ損失の最大許容時間を示します。
具体的には、最後の正常なデータバックアップからどれだけの時間のデータ損失が許容されるかを定義します。
例えば、RPOが1時間の場合、ディザスタ発生前に1時間以内のデータ損失を許容するという意味です。
したがって、データのバックアップはRPOに基づいて行われ、災害発生時に最小限のデータ損失でシステムを復旧することが目標とされます。
2. RTO（Recovery Time Objective）
RTOは、ディザスタ発生後にサービスやシステムを正常な運用状態に戻すための目標時間を示します。
つまり、ディザスタが発生してからサービスが復旧するまでの合理的な時間枠を指定します。
RTOは事業継続性計画の中で非常に重要であり、ビジネス上の影響を最小限に抑えるために設定されます。
例えば、RTOが1時間の場合、ディザスタ発生後に1時間以内にサービスを完全に回復させる必要があります。
このため、バックアップの高速な復元、冗長性の確保、自動化されたプロセスがRTOの達成に寄与します。
3. RPOとRTOの関係
RPOとRTOは密接な関係にあります。
データ損失を最小限に抑えるためには頻繁なバックアップが必要ですが、同時にそれを迅速に復元し、サービスを運用可能な状態に戻すことが求められます。
ディザスタリカバリ計画では、RPOとRTOのバランスを取りながら、適切なテクノロジーや手法を選定し、事業継続性を確保します。
継続的なビジネスの要求やテクノロジーの進化に応じて、組織はRPOとRTOを定期的に見直し、最新の事業状況や技術トレンドに適応させることが重要です。
AWSにおけるディザスタリカバリ
AWSにおけるディザスタリカバリは、サービスの可用性を確保し、データ損失を最小限に抑え、ビジネス継続性を確保するための包括的な戦略を指します。
以下は、AWSが提供するディザスタリカバリの手法です。
前提として、ディザスタリカバリを計画する際にはマルチリージョンでの展開がベストプラクティスになります。
そのため、以下で説明する内容はマルチリージョンの環境をどのように準備するかをまとめたものとして読んでください。
ただし、オンプレのバックアップサイトとしてAWSを使えることも示したかったので、図ではマルチリージョンではなくハイブリッド構成を描いています。
1. バックアップとリストア
バックアップとリストアは定期的なバックアップを取得して起き、ディザスタ発生時にリストアしながらセカンダリリージョンを構築する手法です。
AWSでは、多くのサービスで自動バックアップ機能が提供されています。
例えば、Amazon RDSでは自動バックアップが利用可能で、指定した時間にデータベースのスナップショットが自動的に作成されます。
これにより、ディザスタ発生時には最新の状態にデータをリストアできます。
コストは最も安いですが、リストアをしながら別リージョンに環境を構築するためRTOは最も長くなります。
2. パイロットライト
パイロットライトは、本番環境の一部のトラフィックをセカンダリリージョンにルーティングする手法です。
Amazon Route 53の地理的ルーティングを使用して、ユーザートラフィックの一部をセカンダリリージョンに誘導し、サービスの運用状態を確認します。
本番トラフィックを移行する前に、セカンダリリージョンでの動作検証が可能です。
3. ウォームスタンバイ
ウォームスタンバイは、セカンダリリージョンにアプリケーションの冗長な環境を構築し、必要に応じてトラフィックを切り替える手法です。
Amazon EC2 Auto ScalingやAmazon RDSのクロスリージョンリードレプリカなどを活用して、冗長性を確保します。ウォームスタンバイでは、冗長な環境を保ちつつも、リソースのオーバーヘッドを最小限に抑えられます。
4. ホットサイト/マルチサイト
ホットサイトやマルチサイトは、本番環境と同等の冗長な環境を別のAWSリージョンに構築する手法です。
これにより、完全なディザスタリカバリが可能で、本番トラフィックを素早く切り替えることができます。
ただし、コストやリソースの管理が複雑化するので注意が必要です。
ディザスタリカバリのベストプラクティス
ディザスタリカバリ（DR）は、ビジネス継続性の重要な要素であり、AWSが提供するベストプラクティスを活用することで、迅速かつ信頼性の高い復旧が実現できます。
継続的なテストと訓練
ディザスタリカバリプランの有効性を確保するために、定期的で計画的なテストが必要です。
これには、フルスケールのシミュレーションやフェイルオーバーの実施、チームメンバーのトレーニングが含まれます。
これにより、プランの最適化と従業員の準備が維持されます。
Well-Archited Frameworkにも記載があるとおり、ディザスタリカバリはシステムだけでは成立しません。
運用できるように日々の訓練も非常に重要です。
自動化とオーケストレーション
ディザスタリカバリプロセスを自動化し、オーケストレーションツールを活用することで、復旧時間を短縮し、人為的なエラーを最小限に抑えることができます。
AWSでは、AWS Step FunctionsやAWS CloudFormationなどのサービスが自動化とオーケストレーションに役立ちます。
適切なリージョンの選定
ディザスタリカバリリージョンの選定は慎重に行います。地理的な距離、法的要件、データセンターの信頼性などを考慮し、本番リージョンとの適切なバランスを見つけます。
AWSは世界中に多くのリージョンを提供しており、これらを効果的に組み合わせることで高い可用性を確保できます。
監視と通知
ディザスタリカバリプランの監視と通知を確立し、異常なイベントが発生した場合に関係者に適切な通知が送信されるようにします。
AWS CloudWatchやAWS CloudTrailを活用して、リアルタイムの監視とログ管理を行います。
まとめ
この記事ではAWSにおけるディザスタリカバリを超詳細解説しました。
- RPOとRTO
- AWSにおけるディザスタリカバリ
- ディザスタリカバリのベストプラクティス
次回からはモニタリングとロギングについてまとめていきます。