BCP/DRを目的としたクラウドでのデザインパターン

DRにクラウドを利用するメリット

地震・台風といった自然災害やテロなどの人的災害にあった際に、迅速に復旧できる体制を予め整えることをDRと呼びます。DRを実現する具体的な方法はさまざまですが、データセンター全体に影響するような大規模の災害も想定する必要があるため、メイン環境と同等の（あるいは代替となる）DR環境をメイン環境とは物理的に離れた場所に用意するのが一般的です。万が一の事態が発生した場合には、DR環境に切り替えてシステムの運用を継続します。

ビジネスの継続という観点から見ても、万が一に備えたDRは非常に重要です。しかし、いつ発生するかわからない、もしかしたら一度も発生しないかもしれない災害に備えて、普段は利用しない環境を用意しておくのは、平常時においては生産性や利益に直結しないコストとなってしまいます。こうしたコストは無駄と捉えられてしまうこともあり、可能な限り抑えたいと思うのが自然でしょう。

こうしたコストを可能な限り圧縮する手段として有効なのが、クラウドの活用です。クラウドはオンプレミスと比較して、低費用、かつ少ない運用工数で運用できるため、最小限のコストでDR環境を維持することができます。

ニフクラでのDR/バックアップのデザインパターン

ソフトウェア開発においては、しばしば「よくある問題」と、それに対する「解決のための典型的な設計」が登場します。こうしたよくある設計パターンを整理し、再利用しやすいように名前をつけたものを「デザインパターン」と呼んでいます。同様にクラウドにおけるシステム設計・構築においても、さまざまな「よくある問題」に直面します。こうした問題を解決するために考えられた典型的な設計パターンをソフトウェア開発におけるデザインパターンにならって「クラウドデザインパターン」と呼んでいます。

具体的な例を挙げると、「サーバーが止まらないようにしたい（サーバーの可用性を上げたい）」というのは典型的な「よくある問題」の代表例と言えるでしょう。サーバーの可用性を上げるには、複数のサーバーを並べて冗長化するのが基本ですが、これは非常に定番の構成のため、サーバー冗長化パターンとしてパターン化されています。例えば、クラウドの初心者であってもクラウドデザインパターンに沿ってシステムを構築すれば、先人の積み上げたノウハウを享受できるというわけです。

「災害に備える」というのもクラウドにおけるよくある問題の1つですから、DRのためのクラウドデザインパターンも数多く用意されています。ここでは、ニフクラで提供されている機能・サービスを利用したDRのためのクラウドデザインパターンをいくつか紹介します。パターンごとにそれぞれコストやRPO/RTOなどが異なりますので、対象システムの要件や許容できるコストとを天秤にかけ、どの方式が最適か検討するようにしてください。

複数リージョンでのDR（ホットスタンバイ）

ホットスタンバイとは、あらかじめメイン環境と同等のDR環境を用意しておく方式です。災害時には接続する環境を切り替えるだけで運用が継続できるように、DR環境は普段から稼動状態（ホット）で待機（スタンバイ）させておきます。

例えば、メイン環境が東日本リージョンで稼動しているのであれば、それとは別のリージョン（例：西日本リージョン）に同スペックのDR環境を稼動状態で待機させておきます。災害発生時にはDNSのレコードを変更して、アクセス先をDR環境へ切り替えることで運用を継続します。また、このときにアクセス先のサイトがダウンした際に正常なサイトへアクセスを振り分けられる「DNSフェイルオーバー」を利用することで、DR環境への切り替えすらも自動化することができます。

ホットスタンバイで注意しなければならない点は、両環境間でのデータを同一に保つことです。異なる環境に切り替えても、正常に運用を継続するためには、普段から両環境のデータを同期しておく必要があります。この際に役立つのが、リージョンをまたいでプライベートLAN同士を[L2」で接続することができる「プライベートブリッジ」機能です。両環境をプライベートブリッジで接続し、データベースのレプリケーションなどを行うとよいでしょう。

詳細については、「クラウドデザインパターン（複数リージョンでのDRパターン（ホットスタンバイ））」を参照してください。

複数リージョンでのDR（ウォームスタンバイ/コールドスタンバイ）

ウォームスタンバイとは、ホットスタンバイと同様にあらかじめメイン環境とは別のDR環境を用意しておく方式です。ホットスタンバイとウォームスタンバイの違いは、待機中のDR環境のスペックです。ホットスタンバイがアクセス先を切り替えるだけで運用を継続できるようにメイン環境と同等のDR環境を用意するのに対して、ウォームスタンバイは最小台数かつ最小スペックのDR環境を用意します。

ウォームスタンバイのDR環境は最小限のスペックで構成されているため、そのままでは使用できません。災害時にはスケールアップ/スケールアウトを行い、メイン環境と同等の状態に拡張してから切り替えを行うことになります。まずスケールさせるという作業が発生するため、DNSフェイルオーバーを用いた自動切り替えもできません。

ウォームスタンバイは、平常時は最小構成で待機するため、待機時にかかるコストをホットスタンバイよりも小さく抑えることができます。しかし、切り替え時には、スケール作業と手動での切り替えが必要となるため、切り替え完了までのダウンタイムは長くなってしまいます。なお、普段からプライベートブリッジを経由したデータの同期が必要な点は、ホットスタンバイと同様です。詳細については、「クラウドデザインパターン（複数リージョンでのDRパターン（ウォームスタンバイ））」を参照してください。

ウォームスタンバイと似たパターンに、コールドスタンバイがあります。コールドスタンバイとは、ウォームスタンバイと同様にメイン環境とは別のDR環境を最小構成で構築しておく方式です。ウォームスタンバイとの違いは、DR環境を稼動状態ではなく、停止状態（コールド）で待機（スタンバイ）させておく点です。

災害時には、スケール作業だけでなく、サーバーの起動から行わなければなりません。また、平常時はサーバーが停止しているため、データの自動同期も行えません。そのため、サーバーを起動した後は、データのリストア作業も必要となります。待機時のコストはウォームスタンバイよりもさらに小さく抑えることができますが、切り替え時に必要な作業も多くなるため、切り替え完了までにかかる時間はより長くなってしまうのが、コールドスタンバイの特長です。詳細については、「クラウドデザインパターン（複数リージョンでのDRパターン（コールドスタンバイ））」を参照してください。

どの方式でDR環境を待機させるかは、RTOやDRにかけられるコストによって選択するとよいでしょう。

オンプレミスからクラウドへのDR（コールドスタンバイ）

バックアップしたデータの転送とリストアさえできるのであれば、環境を跨いでDRを行うことも可能です。例えば、オンプレミスで運用しているメイン環境に対する、DR環境をニフクラ上に構築することもできます。

具体的な手順は、複数リージョンでのDRと同様です。あらかじめオンプレミスのメイン環境にて、市販のバックアップソフトなどを利用してバックアップを取得し、DR環境のNASに保存しておきます。災害時にはDR環境にサーバーを新規作成し、NASのバックアップからデータをリストアします。

詳細については、「クラウドデザインパターン（オンプレミスからクラウドへのDRパターン（コールドスタンバイ））」を参照してください。

バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）(バックアップ&リストア)

ここまでに紹介した方式は、規模の差はあれ事前にDR環境を構築しておく方式でした。これに対してバックアップ&リストアとは、平常時はメイン環境のデータのみをバックアップしておき、災害発生後にDR環境を構築し、バックアップからデータをリストアして運用を継続する方式です。

バックアップ&リストア方式では、メイン環境と同じ状態をリストアできるのであれば、バックアップの具体的な手法は何でも構いません。そこで、クラウドベンダーが用意しているクラウドならではのバックアップサービスを利用するのもお勧めです。

ニフクラでは、バックアップ/セキュリティサービスであるバックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を提供しています。これはニフクラパートナーであるアクロニス・ジャパン株式会社が提供するクラウド型のバックアップサービスで、アクロニス社のサーバーを経由することで、柔軟なバックアップとリストアを実現します。

具体的な手順は、オンプレミスからクラウドへのDRと同様です。詳細については、「クラウドデザインパターン（バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）でのDRパターン）」を参照してください。

サーバー単位でのバックアップ&リストア

ニフクラには、複数のバックアップ手段が用意されています。サーバー単位でバックアップ&リストアを行うのであれば、前述の「バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）」ではなく、ニフクラのサーバーが持つ「バックアップ機能」を利用する方法もあります。

具体的な手順は、利用するバックアップ機能が異なるだけで、基本的には前述のバックアップ&リストア方式と同様です。あらかじめニフクラのバックアップ機能を利用して、サーバーのバックアップを取得しておきます。災害時には取得したバックアップから、同一ゾーン内に別サーバーを新規作成し、サーバーをリストアします。詳細については、「クラウドデザインパターン（サーバー単位でのバックアップ&リストア）」を参照してください。

デザインパターンや可用性を解説したeBookを提供中

ニフクラでは、上記以外にもさまざまなクラウドデザインパターンをまとめた「ニフクラ クラウドデザインパターン」をWebで公開しています。クラウドでの典型的な課題とその解決策を解説していますので、ニフクラを利用したシステムアーキテクチャ設計を行う際はもちろんこれからニフクラを利用検討される場合にも参考にしてください。

また、DRと深く関連する可用性を解説したeBook「ニフクラユーザーのための可用性向上のポイント」も無料で提供していますので、あわせてご利用ください。