マネージドDNSで実現するDR（ディザスタリカバリ）対策
2022.10.03
マルチCDNサービス
NS1
普段、我々はPCやスマートフォンを介して様々なサービスを利用しています。利用者・提供者にとって、サービスが利用できなくなることはデメリットでしかありません。
そこで今回は、Webサービスを継続するためのDR（ディザスタリカバリ）を弊社が提供するマネージドDNSサービス「NS1」でどのように実現できるか紹介します。
1. DR（ディザスタリカバリ）とは
DR（ディザスタリカバリについては、アマゾン ウェブ サービス (AWS)のWebページでの記述が参考になります。
ディザスタリカバリは、組織がテクノロジー関連の災害を予測して対処するプロセスです。どの企業の IT システムも、停電、自然災害、セキュリティに関する問題などの予測できない状況が原因となって予期せずダウンする可能性があります。ディザスタリカバリには、そのようなイベントから迅速に復旧するための企業の手順とポリシーが含まれます。
DR自体はITシステムに対して復旧までを検討します。これはBCP（事業継続計画）にも役立ちます。
目標復旧時点（RPO）と目標復旧時間（RTO）
DRを考える上では、目標復旧時点（Recovery Point Objective。以下RPO）と目標復旧時間（Recovery Time Objective。以下RTO）を検討します。
目標復旧時点（RPO）
RPOは障害が発生した際に、“過去のどの時点までのデータを復旧させるか”を定めた目標値です。
RPOを短くすればデータ喪失が少なくなりますが、高頻度にバックアップを取得する必要があります。
例えばRPOが1分の目標値とした場合、バックアップも1分毎に取得する必要があり、バックアップに対するコストも増大することになります。
RPOを長くすればデータ損失は大きいですが、バックアップは低頻度となりコストも低くなります。
目標復旧時間（RTO）
RTOは、“システムの復旧までにかかる時間”を定めた目標値です。
RTOを短く設定する場合は、短時間でシステムを復旧させる必要があります。
短時間で復旧させるためには、事前にシステムを物理的に離れている拠点に複製しバックアップを作成し、障害発生時にはバックアップ側のシステムを利用する等の方法が考えられます。
これは、バックアップ用の拠点の準備やシステムの複製によりコストが増大します。
ＲＴＯが長い場合は、障害発生後にバックアップデータを利用して別拠点にシステムを再構築する等が考えられます。復旧に時間はかかりますがコストは低くなります。
RPO、RTOは提供するサービスによって考え方が違いますので、利用状況等を加味して検討する必要があります。
2. DRの種類
RPO、RTOを設定したのちDRをどのように実装するかを検討します。
DRには、「遠隔バックアップ」「データベースのレプリケーション」「マルチサイト（システムの複製）」といった種類があります。
共通して言えることはバックアップデータを遠隔地に置くことがベースとなります。
遠隔バックアップ
遠隔地にバックアップデータのみを保存する方式です。
例えば、オンプレミスのバックアップデータをクラウドサービスのストレージを利用して海外に設置する、等で実現します。
この方式はRPO/RTOともに長くても問題ないサービスに利用できる方法で、低コストで実現できます。
データベースのレプリケーション
遠隔地にスレーブのデータベースのみを作成しマスターのデータベースとレプリケーションを組むことで、データのバックアップを行います。
レプリケーションを行うことでDBを常に同じ状態にできるのでRPOが短い計画に利用できます。
マルチサイト（システムの複製）
前述のレプリケーションに加え、システムを複製し遠隔地にバックアップとして準備しておく方法です。遠隔地にもデータベースだけでなくWEB/APPサーバーを準備するので必要なコストは増大しますが、バックアップ側をアクティブに運用するかパッシブに運用するかである程度調整できます。この手法はPRO/PTOを短くするべきサービスに適しています。
3. DNSレコードによるマルチサイトの切り替え
マルチサイトによる構成は、DR対策としてサービス影響が一番少なく済む方法です。マルチサイトの切り替えにはGlobal Server Load Balancing（GSLB）の導入など、各拠点のFQDNまたはIPアドレスを切り替える何かしらの方法が必要になってきます。
本記事では、弊社が提供しているサービス、「NS1」を利用しDNSレコードを切り替える方法を紹介します。
4. マネージドDNSとしての「NS1」
弊社で“マルチCDNサービス”として取り扱っているNS1ですが、マネージドDNSをベースとしたサービスとなっています。NS1には通常のマネージドDNSサービスにはない機能があります。
Filter Chain機能
NS1にはFilter Chainという機能があり、1つのレコードに対して複数の値を設定し出しわけることが可能です。
例えば、NS1はCNAMEレコードに、下記のように2つ値を設定可能です。
ホスト：www.stream.co.jp
Value1：test1.stream.co.jp
Value2：test2.stream.co.jp
CNAMEレコードは通常、1つの値しか設定できませんが、NS1のFilter Chainを利用することで複数の回答から回答を一つ選択することが可能です。値を絞る方法は複数ありますが、単純なもので割合やプライオリティを設定することで出しわけることも可能ですし、後述するMonitoaring機能を利用してUP/DOWNを判定して出しわけることが可能です。
上記設定の場合、
- Up：UP/DOWNを判定。DOWNであればその値はこの時点で削除。
- Weighted Shuffle：割合の数値による値の並び替え。
- Select First N：並び変えられた順番のN番目の値を取得。デフォルトは“1”。
と動作します。
Filter Chain機能は他に、クライアントのアクセス元情報で判定するものもありますので詳細は下記ＵＲＬをご覧ください。
Monitoring機能
NS1には監視を行う機能があり、結果をUP/DOWNで判定します。
監視ルールとしては以下が作成できます。
- DNS
- HTTP/HTTPS
- PING（ICMP）
- TCP
例えば、HTTP/HTTPSの場合、あるURLにアクセスして、ステータスコードが200であった場合、UPとする、というような設定が可能です。
この監視結果をFilter Chainに利用できますので、DOWNしたサイトを除外することが可能です。
NS1をマルチサイトの切り替えに活用する
「Filter Chain機能」部分で記載したようにNS1機能でレコードの出し分けが可能です。
DR対策でマルチサイトを選択した場合、下記のようなシナリオで切替えが実現できます。
前提：アクティブ/アクティブでマルチサイトを構築。それぞれをAサイト・Bサイトとする。
- Aサイトで障害が発生。ＮＳ１のMonitoaring機能によりDOWNの判定がされる。
- Filter ChainでDOWNとなったAサイトの値は除外される。
- TTLが切れたタイミングからBサイトのみの値が回答される。
- Aサイトが普及し、NS1のMonitoaring機能がUPと判定される。
- Filter ChainはUPに戻ったAサイトの値を回答に含める。
- TTLが切れたタイミングでAサイト・Bサイトの値が回答される。
自動的に切り替わりますので短いRTOを実現したい場合に最適なソリューションとなります。
以上、Webサービスを継続するためのDR（ディザスタリカバリ）を弊社が提供するマネージドDNSサービス「NS1」でどのように実現できるか紹介しました。
NS1はマルチCDNサービスとして展開しておりますが、元となるマネージドDNSの機能が優秀ですので、DR対策以外でも簡易的なGSLBとしての利用にもご活用いただけると思います。
是非ご検討いただければと思います。
サービス詳細
Ｊストリームの
ソリューションに
興味をお持ちの方は
お気軽に
お問い合わせください。
電話でのお問い合わせ
【受付時間】9：30～18：30（土日祝日を除く）
