クラウド&データセンター完全ガイド:特集

今だからこそ考える企業のDR/BCP対策(Part 1)

DR/BCPの基礎知識

弊社刊「クラウド&データセンター完全ガイド 2020年秋号」から記事を抜粋してお届けします。「クラウド&データセンター完全ガイド」は、国内唯一のクラウド/データセンター専門誌です。クラウドサービスやデータセンターの選定・利用に携わる読者に向けて、有用な情報をタイムリーに発信しています。
発売:2020年9月29日
定価:本体2000円+税

新型コロナウイルス感染症の流行により、多くの企業がテレワーク対応などを迫られることになった。しかし、地震や水害といった自然災害、ネットワークやサービスのトラブルによる停止など、企業が考えるべき対策は他にも多くある。IT システムのバックアップなどの対策をどのように行うかは、起こりうるトラブルと企業の事業内容との組み合わせにより変わってくる。企業のDR(災害対策)/ BCP(事業継続)対策について、オンプレミスとクラウドをどのように組み合わせるのがいいか、その考え方を紹介する。 text:渡邉利和

 DR/BCPについて考える際には、どれほど幅広い“災害”を想定できるか、という想像力が求められることになるが、一方で“対応可能な範囲”についても考えておく必要がある。「人類滅亡後、廃墟となった都市の店舗でロボットだけが今も来客を待ち続けている」というのはSFの一場面としては印象的かもしれないが、現実の企業のDR / BCPでは、社会全体が機能停止するような状況でも自社だけはビジネス継続できるようにする、というのはさすがに過剰だ。

 これは極端な例としても、現実的なDR/BCPを考える上ではやはり「ビジネス停止によって想定される損失」をできるだけ正確に見積もる必要がある。その損失を回避するための投資額が想定損失額の数倍に及ぶようでは、むしろ何もせずにビジネス停止を受け入れる方が安上がり、ということになりかねない。

 逆に、公共サービスなどでは単純な経済原理だけでは判断出来ない場合もあるのはもちろんだが、通常は「現実に起こりうる災害などをできるだけ幅広く予測し、それらに対して現実的に取りうる対策をきちんと準備しつつ、どうしようもない状況に関してはすっぱり諦める」という態度が必要になるだろう。

図1:事業継続計画(BCP)の概念(出典:内閣府「事業継続ガイドライン 第三版」)

災害の想定

 日本は世界でも有数の自然災害大国であり、ありとあらゆる自然災害が起こりうる環境だと言える。都市が壊滅的な打撃を受ける規模の地震の発生も予測されているほか、津波/洪水もどれほど広範な被害をもたらしうるか、広く周知されているといってよいだろう。このほか、最近の気候変動の影響と言って良いのかどうかは分からないが、この数年は台風や活発化した雨雲の停滞などを原因とした集中豪雨が大規模な水害や河川の氾濫、土砂災害を引き起こす例も繰り返し発生している。

 このほか、災害というよりは事故の範疇だとは思われるが、最近のニュースで印象的だった例としては、都市部でのガス爆発の発生で近隣の建物が大きな被害を受けた例もあった。もちろん、被害に遭う可能性があるのは小規模な建物だけとは限らない。2019年秋の台風では地下の電気設備が内水氾濫で水没した結果、近代的かつ大規模なタワーマンションが停電し、復旧まで長期間を要したという事例もあった。これまでのところ大規模な被災には至っていない首都圏の高層オフィスビルに関しても、完全に機能停止に陥るような状況が絶対にあり得ないとは言い切れないだろう。

 こうした災害に関しては、最悪の被害状況として「オフィスが、内部にあるモノ全て含めて完全に失われる」ことを想定しておく必要がある。オフィス内部にマシンルームがあるような状況では、すべての機器とそこに格納されているデータも丸ごと完全に失われる可能性があるということだ。仮に大規模な災害ではなかったとしても、火災などでも同様の被害が生じる可能性が考えられる。

 この場合の備えとして基本となるのは、データのバックアップだ。これはもちろん、「失われたら取り返しの付かないものは予備を作っておく」という発想だ。機器やパッケージソフトウェアなどは買い直すことができるが、自社のデータは自社にしかないため、自社で確実に保全する必要がある、ということである。

コロナ禍での変化

 というわけで、従来のDR/BCP対策としては「バックアップ」を軸に、具体的にどのような形でバックアップを残すのが良いのか、という点を考えるという形だったのだが、現在は全世界的な新型コロナウイルスの大流行を受け、これまでの“日常”がまるで違ったものになってしまうほどの変化を経験している最中だ。当然、DR/BCPに関する考え方も変化せざるを得ない面がある。

 従来は、自然災害という場合は暗黙のうちに「オフィスやシステムが物理的に破壊される」可能性について考えていたわけだが、今回のコロナ禍によって、システムではなく人が被害を受ける“疫病”についても考える必要が出てきたと言えるだろう。もちろん、ITシステムの工夫でウイルス感染を防ぐという話ではないが、DR/BCPのそもそもの目的は「デジタルデータの保護」ではなく「事業継続」であり、デジタルデータの保護は事業継続のための手段であると考える必要がある。当然のことではあるのだが、ついITのことだけ考えてしまう“視野狭窄”的な状況に陥ってしまうこともあるのではないだろうか。

 改めて、俯瞰的な視点から現在のコロナ禍におけるDR / BCPを考えるなら、従来の「データのバックアップ」に加え、新たに「リモートワーク/テレワークのための支援環境」も用意しておくべきだということになるだろう。現在のビジネス環境では、ITがないとビジネスそのものが成り立たないという例が増えてきている。これは必ずしも「オンラインビジネス」と言われるような業種業態に限った話ではなく、あらゆるビジネスで共通する中核リソースである「ヒト、モノ、カネ」の管理をITが一手に引き受けている例が少なくないためだ。そのせいもあって、一般的なDR/BCPの文脈では「ITシステムとデータを守る」ことに注目するわけだが、コロナ禍によって「ITを活用して事業継続を可能にする」という側面にも改めて注目が集まっているのではないだろうか。

 コロナ禍では、特に首都圏を中心に多くの企業が急遽リモートワーク/在宅勤務を実施する必要に迫られた。これには、もともと2020年夏に開催が予定されていた東京オリンピックで海外から多数の観客が集まり、競技場間を移動することが想定されたため、いつもどおりの「通勤ラッシュ」状態では混乱が避けられないという意味もあって、オリンピック開催期間中は都内企業はテレワーク/在宅勤務を実施し、「通勤人数を大幅に削減する」ことが求められていたという事情もある。

 コロナ禍が深刻化し、緊急事態宣言が発令された4月の段階では、オリンピックに向けたリモートワーク/在宅勤務態勢の構築がまだ完了していないという企業も多かったが、部分的ではあるにせよ、準備が行われていた企業があったことから、新型コロナウイルスの感染拡大防止策の一環としてリモートワーク/在宅勤務に切り替えるという方針も比較的受け入れやすかった面があるだろう。一方で、緊急事態宣言下では都心部のほぼすべての企業が全面的な在宅勤務に移行することになったため、オリンピック対策として想定していた規模を遥かに超える接続が生じた例もあったようだ。

 その結果、オンプレミスでVPN接続機器を運用していた企業の中には、急遽接続容量を増強するために機器の追加/更新を計画したが、コロナ禍の影響によるサプライチェーンの混乱もあって機器の入手ができなかったところもあったと聞く。コロナ禍以前にこうした状況を想定して備えておくことができていた企業/組織はほとんどないと思われるが、この経験を踏まえて各社のDR / BCP対策がより一層充実することになるだろう。逆に言えば、「想定外の事態」を経験するたびに備えるべきことが膨れあがっていくことになるので、自社の体力/ビジネス規模に照らして「どこまで備えることが現実的か」という判断も適切に行う必要があるだろう。

バックアップの考え方

 ITシステムの保護に関して、基本となるのは昔ながらのバックアップだ。ただし、現在のDR / BCPを前提としたバックアップの考え方は、昔のバックアップとはいろいろと異なっている点もある。

 バックアップに関しては、バックアップを保存するためのメディアの制約があり、制約条件と現実の摺り合わせの結果、複雑なソリューションが作られてきた面がある。典型的な例が、インクリメンタル(増分)バックアップなどの複雑なスケジュールに基づいて実行されるバックアップだ。これは、バックアップメディアの消費を最小限に留めるため、「前回のバックアップ以降に変化したデータだけを追加で保存する」という発想に基づいている。これはもちろん、必要なデータだけを保存し、無駄な重複データは保存しないため合理的な手法ではあるが、昔ながらの方式で実行した場合には、リストアに時間を要するという課題がある。

 典型的なバックアップ手法では、ある時点で全データを一括でバックアップしてベースとし、以後はこのベースに対する変更箇所だけを適宜追加でバックアップしていくというやり方になる。変更箇所だけのバックアップは短時間で完了し、バックアップデータの量も最小限で済むため、合理的な手法として長く採用されてきたのだが、リストアの際の手順は複雑になり、時間も掛かってしまう点が難点だ。

 増分のリストアは順番どおりに正確に行わないと、新しいデータを古いデータを上書きしてしまうようなことが起こり、データの整合性が失われることになる。増分の数が増えるほど、リストアの際の負担は大きくなるため、極端な例として、年初に一度フルバックアップを取り、その後毎日増分を取っていって年末近くになったところでリストアの必要が生じた、という場合にはフルバックアップからのリストアを行った後、300回以上の増分リストアの作業を行うことになる。これではさすがにバランスが悪いということで、一般的にはフルバックアップを毎週行うなどのスケジュールが実行されてきたわけだが、フルバックアップには時間を要するため、フルバックアップの頻度を高めるとバックアップ作業の負担が増加する、というトレードオフになる。

 こうした事情を踏まえ、最新のバックアップソリューションでは、取得済みのフルバックアップに対して追加で取得した増分バックアップデータをサーバー側であらかじめ適用しておき、最新状態のフルバックアップデータを作成しておくという機能を持つものが増えてきている。「合成バックアップ」や「シンセティックバックアップ」などと呼ばれる機能だが、この機能を活用すれば、最新の状態に復元する場合はフルリストアを一回行えばよいため、迅速に復旧でき、かつ手順も最小限で済むため、運用管理上の負担も軽減される。

図2:合成バックアップの仕組み(出典:Arcserve Japan)

 さらに、リストアに際しては常に最新の状態に戻すことが最善とは限らない。マルウェア感染などの場合は、感染前のデータを復元したいというニーズもある。こうした場合に備えて過去の特定の時点のデータをリストアするためには、手動で差分バックアップを必要なだけ組み合わせていくほか、前述の様な合成機能をもったバックアップソリューションでは、システム側で特定の時点のバックアップデータを簡単な操作でリストアできるようになっているものもあるため、こうした製品を活用することで合理的な対応が可能になる。

 このように、従来型のバックアップの手法の見直しが進んできた背景には、やはり「事業継続」という観点から、何らかの要因でシステムダウンが起こった後、どのくらいの時間でシステムを復旧できるか、が重要な指標として評価されるようになってきたことがある。

 実のところ、以前のバックアップシステムに関しては、「念のため取ってはおくものの、実際にリストアが必要になるような事態はまず起こることはない」という暗黙の想定があった。システムの信頼性の向上や、多少のトラブルではデータ喪失までは至らないようなシステム側での保護機能(ストレージにおけるRAIDなど)などもあり、リストアを行わなくてはならないような「大事故」の発生確率は実際に低かったと思われる。

 しかし、最近では残念ながらデータ喪失に繋がるような状況の発生頻度は従来よりも高まってしまっているような印象がある。頻発する自然災害の印象も大きいが、別の要因としては、ソフトウェア的なデータ破壊の要因となるランサムウェアの流行も大きいだろう。データを保存しているストレージが物理的に破壊される可能性は現在でもそれほど高いわけではないが、ランサムウェアの被害を受けてデータにアクセスできなくなる可能性は自然災害の発生確率に比べると大幅に高いことは間違いない。ランサムウェア対策としてバックアップを位置付けるのであれば、ランサムウェアによってバックアップまで破壊されてしまわないような配慮も必要になるが、いずれにしても基本となるバックアップがきちんと取られていることが出発点となる。

ITによる事業継続

 歴史の教科書を見れば、地震や津波/水害、火災などと並んで「疫病の流行」も社会基盤を揺るがす大災害として認識されていたことが分かるが、現代社会において「疫病の流行」が全世界規模での経済麻痺を引き起こすとは想像していなかった人が多いのではないだろうか。人から人への感染が懸念されることからいわゆる「三密回避」が求められるようになり、首都圏での通勤電車の混雑や、全社員がオフィスに出勤して「集まって働く」というスタイルそのものがリスク要因と見なされるようになった。

 今回の新型コロナウイルスの世界的流行は、ITシステムの保護という観点から見れば特に被害をもたらしたわけではないと言って良いだろう。実際に、IT部門が想定する従来のDR/BCPの枠内にはこうした状況は含まれていなかったのではないだろうか。しかしながら、「社員がオフィスに出勤できない」という状況でどう事業継続を実現していくかという点を考えると、ITが力を発揮できる場面は多々あるはずだ。逆に言えば、そのレベルまでIT活用を進めていた企業は対応できたが、従来型のリアル/対面でのビジネスの体制のみを整えていた企業では対応が困難だったと言って良いだろう。

 もちろん、業種業態の違いによって対応できる幅の差はあるが、ITシステムが被害を受けるような状況に対してどう備えるか、という従来からのDR/BCPの観点に加え、ITシステムを活用して事業継続に寄与する、という視点での準備も進めていく必要があることが明らかになった形だ。

 とはいえ、バックアップのような決まった対策があるわけではなく、日常業務の地道な改革が必要になることでもあるので、さっとプランを立てて即座に実行、というわけにもいかないだろう。まず着手すべきだろうと思われるのは、業務環境の仮想化だろうか。

 現在のITインフラはサーバー、ストレージ、ネットワークといった主要要素が一通り仮想化技術の恩恵を受ける形で進化を遂げている。さらに、個々のユーザーが直接利用する作業環境/業務環境が仮想化されていれば、今回のコロナ禍のような「突然オフィスが使えなくなる」といった状況に対しても柔軟に対応できるだろう。主なソリューションとしては、VDIとリモートアクセス環境の組み合わせという形で既に実用化されているものだが、導入状況は企業によってまちまちだろうと思われる。

 今回のコロナ禍では、三密回避という観点から都心部のオフィスの利用を避けるという形にはなったものの、オフィスやデータセンターの機能が失われたわけではないので、とりあえずはリモートアクセスができるだけでも対応は可能な例が多く、VDIは必ずしも必須ではなかったと思われる。

 しかしながら、実際に急遽多数の社員をリモートワーク/在宅勤務に移行させるために必要な台数のノートPCを確保できなかったという声もある。こうした場合に、安全が確認された会社支給の端末でなくても、個人所有のPCなどを活用する、いわゆる“BYOD(Bring Your Own Devices)”という対応が考えられるが、この場合は「個人利用していたPCがウイルス感染済みだった」という可能性も考慮する必要があり、こうした事態に対応するためにはVDIなどを活用して「ハードウェアは個人所有のPCであっても、その上で稼働するソフトウェア的な作業環境は会社であらかじめ安全を確保した環境」という形にすることが解決策として有効だと考えられる。

 VDIの導入は、緊急対策として実施するのは少々無理がある比較的大規模なプロジェクトなので、まだ導入していない企業では、今回のコロナ禍に対する直接的な対策としてではなく、今後同様の状況が生じることを想定した長期的な対策として導入を検討するのが良いのではないだろうか。