こんにちは。「クロジカサーバー管理」コンサルティングチームの西原です。
日本では毎年のように、台風、豪雨、地震などの自然災害が起きています。さらに近年では気候の変動により、豪雨災害や台風被害などの予測も難しくなっています。2011年の東日本大震災では、多くの病院や企業が被災して、サービスの継続ができなくなりました。BCP対策の必要性が注目を集め、クラウドが災害に強いのではないかという認識も広まりました。今後も大きな地震が起こる可能性は残されており、大規模テロやコロナなどの感染症も心配されます。継続性の高いサービスにするためにも、障害に強くなるBCP対策が必要な時代です。
目次
「災害からの復旧」ディザスタリカバリとは？
ディザスタリカバリ（Disaster Recovery）とは、「災害からの復旧」という意味で、略してDRとも言われます。この概念は、東日本大震災以降に企業が取り組むべき課題の一つとして認識されるようになりました。ディザスタリカバリは、自然災害やテロ、犯罪などでシステムが大規模な損傷を受けた際に復旧や修繕を行うこと、または早期に再開できるシステムや体制のことを指します。
災害の影響を受けてもデータが失われることがないように、クラウドサービスの活用や遠隔地へのバックアップデータの分散、データセンターへの移設などが行われます。しかし、災害対策であるディザスタリカバリには、コスト負担が生じるため、コストを考慮しながらどこまで有効な対策がとれるかが問われることになります。
AWSの活用がBCP対策になる理由
災害発生時に事業を継続させるためにとるべき対策を、「BCP対策（Business Continuity Planning）」と呼びます。BCP対策として現在注目されているのが、クラウドサービスであるAWSの活用です。AWSは、BCP対策の課題である「低コスト」で、「高いセキュリティ環境」や「別リージョンへリスク分散」を実現できるためです。
低コスト
BCP対策を企業内で行う場合、膨大な初期投資が必要になります。サーバーなどの固定資産の調達・維持には、コストがかかるためです。しかし、AWSはクラウド上にサーバーがあるため、初期の設備投資が必要なく、低コストでBCP対策を始めることができます。さらにAWSは、運用費用も低コストです。AWSは使った分だけ課金される料金体制であるため、コストのスリム化ができます。
高いセキュリティ環境
AWSは情報・ID・アプリケーション・デバイスを、高いセキュリティ環境で保護しています。 「防止策によるデータの保護」「セキュリティ状況の可視化による問題の検出」「自動化したセキュリティ対応と復旧による原因の分析対応」「環境のリアルタイムな修復と保護」などを、戦略的に行っています。
別リージョンへリスク分散
AWSではリスクを分散するために、同じリージョン内にある複数のデータセンターを利用することができます。データセンター間は数キロ以上離れているため、一部地域の浸水や停電などであればリスクを減らすことができます。さらに大規模な災害を想定したBCP対策では、別の地域にあるリージョンと組み合わせることで、災害に強いシステムを構築することが可能になります。
重要になるリカバリー方法とは？
災害が起きることを想定したリカバリー方法は、コストと有効性とのバランスを取りながら、どのようなものにするのかを決めていきます。リカバリー方法を事前によく検証しておくことが、災害時の復旧時間の短縮や被害を最小限にとどめることにつながります。例として、AWSの主な4パターンのリカバリー方法について触れていきます。
バックアップ
バックアップはコストもあまりかからない、基本的なリカバリー方法です。定期的にバックアップを取ることで、バックアップを取得した時点に復旧できるようにします。AWSでは、バックアップデータを保存したリージョンとは別のリージョンのS3（ストレージサービス）に複製して保管しておきます。
ただし、バックアップには、注意しなければならない問題点があります。バックアップは毎月・毎日など、決まった期間で定期的に保存します。リアルタイムなデータではなく、保存した時点のデータしかありません。あくまでも最後に保存した時点のデータにしか戻すことができないことに注意します。また、復旧までに時間がかかることも注意点です。
パイロットライト
データをできるだけ最新データに戻したい場合には、パイロットライトが有効です。パイロットライトでは、DR用として別のリージョンに低スペックのDBを用意します。データは適時、別リージョンのDBに同期するために、常に最新データが保管されます。障害が発生した時には、DR用の別リージョンでアプリケーションを立ち上げて、DBのスケールアップを行います。難点としては、復旧までの時間がやや長めであることです。
ホットスタンバイ
障害発生時に回復までの時間を最短にしたい場合には、ホットスタンバイが最適です。ホットスタンバイでは、スペックおよび構成が同じシステムを、別リージョンに用意しておきます。2つの同じシステムが常に同時稼働しているため、障害が発生した場合にもDNSを切り替えるだけで、サービスを継続させることが可能になります。データも最新の状態を保ち、最も早く復旧が可能な方法です。しかし、同じシステムを複数用意する必要があるため、最もコストが高くなります。
ウォームスタンバイ
ホットスタンバイほどではなくても、比較的スピーディに最新の状態に復旧できるのが、 ウォームスタンバイです。ウォームスタンバイでは、低スペックではあるけれど同じ構成のシステムを、別リージョンに常時稼働させておきます。障害が発生した場合には、DBとアプリケーションのスケールアップとDNSの切り替えを行います。復旧までの時間は比較的短時間で、データは最新の状態に戻せます。しかし、低スペックながら同じ構成のシステムを用意するため、比較的コストが高くなります。ホットスタンバイとパイロットライトの中間的な方法です。
さいごに
コストを考えなければ、ホットスタンバイが最適な方法です。しかし、BCP対策は収益が出るわけではないため、現実的にはコストも考えなければいけません。災害やトラブルにも強い、継続性の高いWebサイトやサービスにするため、自社にはどの方法が最適であるのか、バランスを考えながら判断することをお勧めします。
コーポレートサイトをクラウドでセキュアに
無料ではじめるサーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカサーバー管理の主な機能
- 導入事例
- 導入までの流れ
