今こそディザスタリカバリについて考えよう！#Mirantis #セキュリティ

本記事はMirantisブログ「Disaster recovery concepts: fault tolerance, high availability, backups, and more」の翻訳です。

現代社会では、誰もが犯罪や国家関与による攻撃の標的（または過失の犠牲者）になり得ます。ですからディザスタリカバリ（DR）計画を持つことは絶対に重要です。本稿では、DR計画を策定する際に理解しておくべき基本的な考え方について、NASA、AWS、化学薬品製造業者などの事例を交えて解説していきます。

本稿は、Mirantisウェビナー「Now's not the time to ignore Disaster Recovery. Learn what you need to know.（今こそディザスタリカバリをないがしろにしてはいけない）」を元に作成しています。Mirantisウェビナー（英語）は、オンデマンドで視聴可能です。

目次：

• ディザスタリカバリ（DR）すべき災害とは
• 事業継続（BC）とは
• フォールトトレランスとは
• 高可用性（HA）とは
• バックアップとは
• フェイルオーバーサイトとは
• アクティブ／アクティブとは
• アクティブ／パッシブとは
• 目標復旧時間（RTO）とは
• 目標復旧ポイント（RPO）とは
• シェアードナッシング・インフラストラクチャとは

進行：Ben Dorman（グローバルクラウド アーキテクト）
解説：Nick Chase（テクニカルマーケティング ディレクター ）

ディザスタリカバリ（DR）すべき災害とは

Ben Dorman: まず、災害（ディザスタ）にはどんなものがあるか、起こり得る問題とはどのようなものかについて話したいと思います。

災害のシナリオのうち非常に分かりやすい例として、例えば爆弾が落ちてきたり火災が発生したりして、データセンターが物理的に破壊される場合が挙げられます。この場合、災害が起きている事実と、あなたがこれに対処しなければいけないということは明確です。

一方で、より一般的に起こり得る災害とは、事業を継続するうえで何らかの障害が起こることであり、それは長期間にわたる場合もあります。

要因として、ネットワーク障害、ハードウェア障害、ソフトウェア障害などが考えられます。他にあまり知られていませんが、さまざまな類のデータ損失も災害の一例として考えられます。データベースを失ったあとで、何らかの理由により復元が不可能であることに気づくケースもあるでしょう。失ったデータが顧客データの大半ではなく、ごく一部だったとしてもこれは災害です。

その他の災害の要因として、これは報道などでもよく見受けられますが、ランサムウェアをはじめサイバー攻撃によるものがあります。ランサムウェアとは、何者かが侵入しあなたがデータにアクセスできないようにして身代金を要求し、ビジネスを停止させるというものです。もちろん、これ以外のサイバー攻撃による災害が発生する可能性もあります。この後、これらの災害に対して、対処する必要があるか否かを判断する方法、また対処する場合の具体的なディザスタリカバリ方法についてお話しします。

特に、ディザスタリカバリには政治的な側面があるということや、ディザスタリカバリを実施するかどうかの判断も重要であることを理解しておく必要があります。そして、伝統的なプラットフォームであるか、クラウドネイティブなプラットフォームであるかによっても異なる点が出てきますので、これらについても考える必要があります。

事業継続（BC）とは

Nick Chase:　まず最初に、事業継続（business continuity; BC）とは何でしょうか。究極的に言えばディザスタリカバリは事業継続そのものに含まれます。

このウェビナーでは、主にディザスタリカバリの技術的な側面についてお話しします。しかし災害の例として、例えば重要な人物が会社を去る場合にも当てはまります。組織の事業の全プロセスを熟知している人物が、競合他社に転職してしまうというような事態は、紛れもなく災害だと言えるでしょう。そのような場合への備えも必要となります。

事業継続計画を作る際には、ありとあらゆる事態を想定しておく必要があります。今回焦点を当てるのは技術的な問題に対するディザスタリカバリですが、本来の事業継続計画においては、ありとあらゆる側面に配慮すべきことをよく覚えておいてください。

Ben Dorman:　ニックに補足すると、災害には技術的な側面と、人に関わる側面があります。つまりアプリケーションをリカバリさせるだけでなく、どのような順序で、企業としてどのように行うか、ということも重要になります。

Nick Chase:　その通りです。では早速タブーに触れましょう。バックアップについてです。よく耳にすることですが「バックアップがあるからディザスタリカバリの心配はいらない」と思っている人もいるかもしれません。ベン、これについてはどうでしょう？

Ben Dorman:　バックアップはディザスタリカバリの一要素ではありますが、もちろんそれがすべてではありません。環境が失われてしまった場合、環境を復旧させる必要があり、そのためにバックアップが必要なのは言うまでもありません。しかしバックアップがあるというだけではディザスタリカバリとは言えません。もう１つ、ディザスタリカバリという言葉の定義です。「これから挙げる戦略が実際に全て失敗した場合にどうするか」が「ディザスタリカバリ」なのです。「高可用性」、「フォールトトレランス」、「バックアップ」など聞いたことがあると思いますが、これらの定義もこのあと説明していきます。すべて有効かつ重要な戦略です。しかしディザスタリカバリとは、これらのいずれもがビジネスの破綻からあなたを救うことができなかったときに実行するものだということを覚えておいてください。

Nick Chase:　その通り。他がすべて失敗したときです。

では、さっそく言葉の定義から始めましょう。ディザスタリカバリとは、どのようなものでしょうか。先ほども言ったように、他のすべてが失敗したときに実行するものである、という以外に、ディザスタリカバリとは具体的に何を指すのでしょう。

フォールトトレランスとは

Ben Dorman:　さて、これらの概念について手短に話します。まずはフォールトトレランスから。フォールトトレラントシステムとは、プライマリシステムに障害が発生したけれどもサービス上では顕著な中断が見られないときに、セカンダリシステムが引継ぐ仕組みを指します。例えばハートビートシステムでは、数ミリ秒以内にプライマリシステムが停止していることを認識または検知して、それを引き継ぎます。フォールトトレランスには通常、プライマリからセカンダリへシステムが切り替わる際に、元のプロセスの状態やステータスが維持されるため、ユーザーは障害に気づかない（「フォールトトレランス」：「耐障害性」）という概念なのです。

高可用性（HA）とは

高可用性は前述のフォールトトレランスとは若干異なります。セカンダリシステムは短時間で起動できるように準備されていますが、実行中のプロセスデータは失われる可能性があり、サービスには短時間だけれども顕著な中断が生じる可能性がある場合です。例えば、Veritasのクラスタリングシステムを覚えている人もいると思います。私はかつてシステムウェアに携わっていました。プライマリシステムがダウンすると、セカンダリシステム側にディスクがマウントされ、1～2分で復旧します。つまり高可用性システムでした。両サイドにセカンドサーバがあるので、作業中にダウンしたのでなければ、サービスが中断されることはあまりありませんでした。これがフォールトトレランスとは異なる、高可用性システムです。

バックアップとは

バックアップとは言うまでもなく、故障したデータベースを復旧させたり、最近のInfrastructure-as-codeでは、すべてのアプリケーションを元通りに復旧させたりするためのシステムのことです。通常、バックアップには時間もかかり多少の中断もありますが、障害が発生したシステムを復旧させ、代替手段を確保するため絶対的に必要なものです。

Nick Chase：わかりました。ここまでは基本的なことですね。では、より専門的な話に移りましょう。

フェイルオーバーサイトとは

Ben Dorman:　まず、ディザスタリカバリのための最も一般的でほぼ普遍的と言える方法は、フェイルオーバーサイトを持つことです。しかし戦略はそれだけではありません。NASAのスペースシャトル打ち上げの様子を思い出してみてください。彼らは、複数のコンピュータで同じ計算をするシステムを持っていました。そのうちの1つが他のコンピュータと食い違った場合は無視される仕組みになっています。これは投票システムのようなものですが、とてつもなく高価なものです。数十億ドルの費用と人命がかかっているのであれば、このような方法をとるべきでしょう。しかしほとんどの企業はそのような状況にはないので、できるだけ早くビジネスを再開させるために、何らかの判断やインフラの修正を行った後にすばやくインフラを切り替えるフェイルオーバーサイトを保有しているのです。

アクティブ／アクティブとは

アクティブ／アクティブシステムとは、いわゆるセカンダリシステムが常時アクティブになっているシステムのことです。常時アクティブなのでディザスタリカバリではないように思われるかもしれませんが、事実、ディザスタリカバリとしてはいくつかのトレードオフがあります。なぜなら実際には、セカンダリシステムはプライマリシステムよりも費用をかけていなかったり、プライマリシステムほどの能力がなかったり、プライマリデータではなかったりするからです。そのため、プライマリとセカンダリが完全に同格なシステムでない限り、一般的には完全にシームレスな切り替えは実現できません。すなわち、セカンダリシステムへの切り替え後にシステムの調整が必要なため、追加費用が発生することになります。

アクティブ／パッシブとは

アクティブ／パッシブシステムとは、セカンダリシステムが実際にはオフラインでありながら、時には数秒という非常に短い時間で立ち上げることができるシステムです。また、データにアクセスできるシステムが1つのみ許されるプロセスの場合には、アクティブ／アクティブ構成にできないため、アクティブ／パッシブシステムが利用されます。

また、コールドスタンバイ／ウォームスタンバイというものもあります。コールドスタンバイとは、セカンダリシステムの電源を切った状態で必要な時に起動させる状態のことです。ウォームスタンバイとは、トラフィックが送信されてきたら即座に起動させられる状態でセカンダリシステムを待機させていることを指します。

目標復旧時間（RTO）とは

目標復旧時間（Recovery Time Objective；RTO）とは、定義上、災害発生と宣言された後、復旧するまでにどれくらいの時間を要するかという目標値を指します。ディザスタリカバリシステムを構築する際に、例えば「3時間から4時間で復旧できるように、このディザスタリカバリシステムを設計します」という基準を設けます。最近私が聞いた話では、ある化学薬品製造工場の目標復旧時間は「3秒」だったそうです。

Nick Chase:　それはまた、すごいですね。

Ben Dorman:そうなんです。その企業は化学薬品の製造を行っていて、もし何か厄介な事態に陥った場合には化学薬品がその製造工場を焼き尽くしてしまう可能性もありますから、本当にすばやい復旧が必須なのです。

Nick Chase:　そのような場合には費用をかけて、スタンバイに必要なものをすべて揃えるのですね。

Ben Dorman:　はい。この極端な例を出したのは、可能な限りフォールトトレランスに近い状態でないと、本当に冗談では済まない事態に陥ってしまうケースがあるからです。通常のフォールトトレランスシステムが機能しないような災害が発生した場合でも、問題の性質上、非常に迅速に復旧する義務があるケースです。

目標復旧ポイント（RPO）とは

次に目標復旧ポイント（Recovery Point Objective；RPO）です。どの組織もデータに基づいて運営されているわけですが、そのデータを失わないようにするために、何らかの形式で複製を行っています。複製には基本的に、同期型と非同期型の2種類があります。同期型レプリケーションでは、セカンダリデータは常に更新されています。つまりトランザクションの一部として、セカンダリデータが更新されるのです。実際、セカンダリデータが保存されるまでプライマリシステムは続行されません。もちろんそこにはトレードオフされるデメリットもあります。次に述べますが、レイテンシが発生するからです。しかしそれでも、データの損失を防ぐためには同期型レプリケーションが非常に重要です。そしてもちろん、ネットワークやハードウェアのコスト面においては、この同期型レプリケーションが最も高くつきます。

また、非同期型レプリケーションでは、プライマリシステムとセカンダリシステム間でレプリケーションを定期的に実行しますが、その頻度は目標復旧ポイント、つまり災害発生時にどの程度のデータ損失が許容されるかによって決まります。どの企業に聞いても初めは、「いや、許容できるデータの損失量などまったくない」という答えが返ってくるでしょう。しかし実際には「では、データを失わないシステムのためにいくら支払えますか？」と質問すると、支払える金額と受け入れられるデータの損失量との妥協点を探る、という企業が一般的です。

Nick Chase: 例えば、6時間分のデータを失っても構わないという目標復旧ポイントであれば、少なくとも6時間ごとにバックアップを取る必要があります。

Ben Dorman：その通りです。

シェアードナッシング・インフラストラクチャとは

シェアードナッシング・インフラストラクチャは、実に分かりやすい概念です。プライマリデータセンタが破壊された場合、セカンダリデータセンタがプライマリデータセンタと何か1つでも共有していれば、セカンダリデータセンタも破壊されるのは目に見えています。シェアードナッシングとは、フェイルオーバーサイトがプライマリサイトの機能に一切依存しないことを意味します。フェイルオーバーサイトはプライマリサイトと同じデータセンタの別のラックにあっても、同じ電源やネットワーク、あるいはその両方を共有している場合は十分とは言えません。一般的にシェアードナッシングとは、物理的に何マイル、あるいは何キロメートルも離れているデータセンターのことを指します。

しかしもちろん、ネットワークレイテンシという制約もあります。今話したように、2つのデータセンター間でデータの複製やシームレスなネットワーク接続を行うためには、シェアードナッシングとは言え、あまり遠すぎない距離であることも求められます。同じ都市にある2つの地区で、電力網やネットワークプロバイダーが異なるなど、プライマリデータセンタの障害に対してフェイルオーバーサイトを堅牢にするために、さまざまな方法が考えられます。

Nick Chase：覚えている人もいると思いますが、AWSの障害が発生し多くのサービスがダウンしたことがあります。フェイルオーバーサイトを他の地域に置いてあるので安全だと考えていた人たちも、どうやらAWSの、1つのコンポーネントが共有されていたことをこの件で気づいたようです。DNSか何かだったようです。この問題が修正されるまでのしばらくの間、すべてがダウンしてしまっていたので、本当に注意が必要です。

Ben Dorman：Amazonのドキュメントでは、それほど注意深く読まずとも「データセンターには監視員を配備し、電源の同期を行うなど、物理的なインフラは私たちが責任を持って管理します。ただし、ソフトウェアに起因する停止はお客様の責任となります」などと書かれている箇所を見つけることができます。しかし、実際にはAmazonがあのような障害を起こしたとしても、それはあなたの責任になるのです。

Nick Chase:そうですね。

Ben Dorman:　被害を受けるのは、やはり皆さんのビジネスなのです。

最後まで読んでくださってありがとうございました！