クラウド&データセンター完全ガイド：特集
今だからこそ考える企業のDR/BCP対策（Part 3）
ネットワーク／サービスのトラブルを想定した対策
2020年10月7日 06:00
弊社刊「クラウド＆データセンター完全ガイド 2020年秋号」から記事を抜粋してお届けします。「クラウド＆データセンター完全ガイド」は、国内唯一のクラウド／データセンター専門誌です。クラウドサービスやデータセンターの選定・利用に携わる読者に向けて、有用な情報をタイムリーに発信しています。
発売：2020年9月29日
定価：本体2000円＋税
現在のIT インフラは、自社だけで完結する例はむしろまれで、クラウドやSaaSなどの外部サービスに依存して運用されている例が大半だ。さらに言えば、IT機器の運用に必須の電力に関しては基本的に外部サービス依存だと言って良いだろう。こうした外部サービスが停止することも想定しておく必要があるが、当然ながらユーザーサイドでできうる対処には限界がある。 text：渡邉利和
停電に備える
ITシステム運用のために必須の外部リソースと言えば、真っ先に想定されるのが電力だろう。電力供給が停止した場合に備えて自家発電可能な発電設備を準備しておく、という対応は、データセンターであれば一般的に行われているが、ユーザー企業が独自にできる範囲は超えているものと思われる。そのため、電力会社からの電力供給が停止した際にもシステムの運用を継続する、ということであれば、まずはシステムをデータセンターで運用することがもっとも現実的な対応策となるだろう。
データセンターでは、ガスタービンやディーゼルエンジンなどの動力源を含む発電設備と、それを一定期間運転し続けるための燃料の備蓄を行っているが、当然ながら施設内に備蓄できる燃料の量には制限があるため、外部からの支援なしで運用を継続できるのは数日～1週間程度、おおむね5日くらいというレベルである。
近年の被災例としては、2年前の2018年9月6日に起きた北海道胆振東部地震が北海道では初めてとなる震度7を観測、発電所に大きな被害をもたらした結果、北海道全域で大規模な停電「ブラックアウト」が発生した事例となった。この停電は数日にわたって継続し、一般家庭やオフィスなどが多大な影響を受けたが、データセンターも例外ではなかった。域内には大規模なクラウド型の高効率データセンターなどもあったが、当時ブログなどで発信された情報では、自家発電設備に切り替えて運用を継続したものの、燃料の調達が滞り、運用停止しなくてはならないかもしれない、といった緊迫した様子が伝えられた。結果的には燃料の流通が間に合い、運用停止に追い込まれることはなかったのだが、大規模災害のリスクについて再認識するきっかけになったと言えるだろう。
データセンタークラスであれば数日程度の停電には耐えられるわけだが、オフィス内に設置した機器などでは、せいぜい数時間程度の停電に備える位が限界であろう。こうした目的で利用される非常用電源設備としてはUPSがあるが、昔ながらの鉛蓄電池に加え、最近ではリチウムイオン電池などを採用したより高性能な電源製品も出回り始めている。UPSの代替という形ではなく、まずはスマートフォンのバッテリ切れに備えるための予備電源として商品化が始まったこれらの製品は、リチウムイオン電池の性能向上に伴って大型化し始め、現在では家庭用の電気製品を野外で利用できる「ポータブル電源」として一大ジャンルを形成しつつある。現在主流の製品仕様は、元々の用途だったスマートフォンなどのデジタルデバイスの充電用にUSBポート（DC 5V）を複数備えるのはもちろん、車載用の電気製品や、場合によっては自動車のバッテリー上がりに対応できるようなシガーライターソケット（DC 12V）、さらに家庭用電気製品に対応できるAC 100Vソケットまで備え、1000Wh以上という大容量製品も市販されるようになってきている。こうした電源を上手く活用すれば、小型のサーバーなどを数時間稼働させるくらいのことはできそうだ。もちろん、永年にわたって制御を洗煉させてきたUPSとは製品のコンセプトが全く異なるため、商用電源に常時接続しておき、IT機器側に流れる電流波形を乱すことなく切り替える、といった高度な制御は到底期待できる段階ではないが、今後の電源技術の発展に期待がかかる。
データセンター向けに利用可能な製品としては、米国のEVメーカーであるTESLAが産業用にリチウムイオン蓄電池を販売しており、2019年秋にはIIJが千葉県白井市に開設した「白井データセンターキャンパス」に導入したことが発表されている。鉛蓄電池と比較して寿命が長いことで交換回数を減らすことができるほか、高度な電源制御技術を活用し、電気代の安い時間帯に充電しておき、ピーク時間帯には商用電源と合成して使う形で使用量の平準化を可能とするなどのメリットがあるとされている。
停電対策としてユーザー企業レベルで実施できることはさほど多くはないが、リチウムイオン電池の性能向上によって新たなソリューションが生まれつつあるので、そうした動向にも注意を払っておくとよいだろう。
ネットワークの冗長化
現在の企業ITシステムでは、何らかの形でクラウドサービスが活用されている例が大半だろう。さらに、外部のインターネットと接続するためにはネットワークサービス事業者のサービスに依存していることになる。大規模な自然災害でこうしたインフラに支障が出る可能性ももちろんあるが、現実的な視点では、災害対策というよりも、利用中のサービスプロバイダーのサービス停止が起こる可能性に備えることを考えるべきかもしれない。これまでにも、機器故障や設定ミスなどによってクラウドサービスが数時間程度停止してしまう事態が起こっている。現実問題として、大規模な自然災害で通信網やクラウドサービスまでが丸ごとダウンするような状況であれば、自社のビジネスがその期間止まったところで仕方ないという面はある。逆に、自社のシステムが正常稼働を続けていたとしても、顧客側が動けない状況になっていれば結局ビジネスは動かないことに変わりは無い。そのため、「壊滅的な被害」を想定するなら、回復段階に至ったところでいかに少ない被害で迅速に回復するか、という点を主眼に置くべきであり、どのような状況であってもビジネスを止めない、というのは目標としては崇高かもしれないが、現実には膨大なコストを要する可能性が高い。
一方、特定のサービスプロバイダーのシステムがダウンする、という可能性の方が発生確率は高い上、この場合はそのサービスプロバイダーに依存していないユーザーは全く被害を受けない可能性が高い。そのため、「周りは正常に稼働しているのに自社のビジネスだけが止まる」という状況に陥る可能性があるが、これは何とか避けたいと思う企業が大半であろう。通信網やクラウドサービスなどに関しては自社で予備を用意するというよりも、代替を確保しておき、冗長化するというのが唯一の対策となるだろう。
この点でもデータセンターの対策が最高レベルのものとして参考になる。一般的なデータセンターでは、商用電源の契約に関しても「複数の異なる変電所から並列に引き込み、完全な電源断が起こる可能性を引き下げる」という対策を採った上でさらに非常用発電設備なども準備するという体制を取っている。通信に関しても考え方は同様で、通常は複数の通信事業者とそれぞれ専用の回線を敷設して接続しており、すべての接続が失われるという状況が発生しないように備えている。
ユーザー企業側で同様の対策を講じるとすると、通信回線に関してはSD-WANと呼ばれる仮想化技術を活用し、複数回線をシームレスに切り替えることができるように備えておくことが考えられる。SD-WANの利用状況は、海外と日本とでは大きく異なっていると言われる。日本では、企業のWAN回線としてはキャリアなどが提供する専用線接続（海外ではこれをプロトコル名で代表させる形でMPLSと呼ぶことが多い）を利用する例が大半だろう。そして、国内の通信網の品質は極めて高く、通信断絶などが起こることは基本的に想定されていないレベルだ。
一方、海外ではMPLSサービスの評判は芳しくなく、ユーザー企業としても品質に信頼を置いてはいない様子が窺える。そこで、専用線接続（MPLS）を運用すると同時に公衆回線網を使ったブロードバンド接続も併用し、適宜両者を切り替えながら運用するためにSD-WANを活用するのが一般的だという。日本国内では、そもそも専用接続に対して代替回線を用意するという発想があまりないことから、中核的なユースケースを封じられた形になったSD-WANベンダーが苦戦する状況にもなっているが、DR／BCP対策の一環として代替回線を確保しておくことには一定の意味があるだろう。今後、5Gネットワークの整備に伴って企業側で選択可能な通信回線のバリエーションが増えることになる。さまざまな通信網を用途に応じて適宜使い分ける形がより一般化することになると思われる。
クラウドサービスの複線化
DR／BCPを考える場合、基本的な考え方はSPOF（単一障害点：Single Point of Failure）をなくしていくことだ。その点、事業者／サービスプロバイダーごとの差異があまり大きくはない電力や通信網に関しては、冗長化という手法が採りやすいが、クラウドサービスに関しては少々考慮すべき点がある。
現在のクラウドサービスは、ハイパースケールと称されるグローバル市場での主要プレイヤーが提供するパブリッククラウドを中心とした市場が形成されている。これら事業者間でも競争が働いており、主要パブリッククラウドプロバイダー各社は自社のサービスがユーザーにとってより魅力的なものとなるよう日々改良／革新を積み重ねている状況だ。
ユーザー視点で、シンプルな仮想サーバーの実行プラットフォームとして見た場合、別の言い方をするなら、IaaSとしてクラウドを活用するだけなら、どのクラウドを選んでもそれほど大きな違いはない。仮想化基盤として何を使っているかとか、運用管理インターフェイスの使いやすさとか料金体系とか、細かい違いはもちろん存在するが、緊急時に予備として利用することが困難になるほどの違いではないと言ってよいレベルだ。
当然そうした事情はクラウドサービスプロバイダー側もよく理解しているため、昨今盛んに繰り広げられている差別化競争は、このレイヤではなくより上位のレイヤで行われている。高機能なデータサービスや、AIやIoTなどの特定のワークロードを支援するための機能などだ。各クラウドサービスプロバイダーが独自に用意する、洗煉された最新機能群は、API連携などの形でユーザーのワークロードと連携し、あるいはユーザーが独自開発を行わなくてもクラウド側が用意した機能を組み込んで活用する、といった形で開発負担を大幅に軽減するのに役立つ。
同時に、こうした機能は各クラウドサービスプロバイダーごとに独自に用意されたものであることがあり、そうした機能を活用してアプリケーションを開発した場合、そのアプリケーションを他のクラウド環境に移行することは困難になる。こうした機能提供は各クラウドサービスプロバイダーが自社の環境を競合他社の環境よりも魅力的なものにしようとする努力の産物であり、結果として顧客を囲い込むための武器として機能する。ユーザー側では、「特定の環境に囲い込まれることを避けるために、特定のクラウドでのみ提供されている機能を利用することは避ける」か「環境移行がしにくくなるリスクは飲み込んだ上で、アプリケーション開発を迅速に行えるメリットを選ぶ」か、自社の方針に合わせて選択する必要がある。
現在のクラウド活用は、オンプレミス／プライベートクラウドはもちろん、複数のパブリッククラウドを組み合わせて適材適所で活用する「ハイブリッド・マルチクラウド」が主流となりつつある。複数のパブリッククラウドを併用するのは、まさに各パブリッククラウドが独自に開発／提供している機能に違いがあり、それぞれに強みを持つ分野が異なっているためだ。
そこでユーザー側としてはそれぞれの良い点を組み合わせて活用する「良いとこ取り」を狙うわけだが、この場合はあくまでも全体で1つのシステムを構成している形であり、冗長性が確保されているわけではない。どこか1つのクラウドサービスプロバイダーがサービス停止すると、処理の内容にもよるがアプリケーションサービス全般に影響が及ぶ可能性がある。
IaaSベースのシンプルなサービス利用であれば、異なるクラウドサービスプロバイダー間でワークロードを移行し、冗長環境として運用することは可能だ。また、クラウドストレージを活用するバックアップ／アーカイブでは、複数のクラウド・ストレージを並列的に利用して冗長性を確保することは普通に行われているので、クラウドを冗長構成で利用できるかどうかは、クラウドをどのように利用しているのかに依存するということになる。
クラウド環境で独自に提供されている機能／サービスを活用している場合、クラウドサービスが停止した際には影響を避けることは難しくなるが、対策がないわけではない。まず、現在国内でサービスを提供している主要ハイパースケールクラウド事業者は、国内拠点の冗長化を進めている。典型的な例としては、東京リージョンに加えて大阪リージョンを開設し、ユーザーが適宜使い分けられるようにしている。あくまでも同一事業者のサービスなので同時にダウンしてしまう可能性はゼロではないが、地理的に離れた複数のリージョンを併用することで安全性が大幅に高まることは間違いない。
さらに最近では、主要クラウドサービスプロバイダーが提供する機能／サービスを丸ごとユーザー企業のオンプレミス環境で利用できるようにパッケージ化して提供する動きが進んできている。具体的には、Amazon Web Servicesの「AWS Outposts」、Microsoft Azureの「Azure Stack」、Google Cloud Platform（GCP) の「Cloud Services Platform（CSP）」などが挙げられる。これらの取り組みは、オンプレミスとクラウドで同じアーキテクチャに基づくアプリケーションを実行可能とし、両環境をシームレスに接続したいというニーズに対応して提供されるもので、DR／BCPという文脈で、「何らかの理由でパブリッククラウドが利用できなくなった際にも自社のオンプレミス環境だけで処理を継続できる」ことを目指したものではないのだが、使い方によってはクラウドサービスやネットワークサービスの不意のダウンに対する対策としても活用できる可能性があることは間違いないだろう。
なお、企業ITのワークロードに関しても、現在仮想サーバーベースからコンテナベースへと急速な世代交代が進行しつつある状況だ。コンテナベースとなることでワークロードのポータビリティが向上し、異なるプラットフォーム間でのワークロード移行がやりやすくなるというメリットもある。
DR／BCPを考える場合、基本的にはバックアップ／レプリケーションの環境整備であり、さまざまなインフラの冗長化を考えていくことになるわけだが、一方でアプリケーションアーキテクチャのモダナイズによってポータビリティを高め、展開速度を速めることで環境移行を迅速に行えるようにしておけば、ある環境が利用できなくなった際にも新たな環境を構築して素早く立ち上げ直すといった対応もできるようになっていく。
オンプレミスではハードウェアがないとどうにもならないという状況になるが、インフラとしてクラウドを利用可能な現在では、ワークロードのポータビリティが確保されていれば何とかやりようもあるという状況を作っておくことは不可能ではない。いわゆるDXという考え方にも通じる部分ではあるが、最新のテクノロジーを活用して企業活動のデジタル化を進め、柔軟性／俊敏性を確保しておくことも、災害発生時の事業継続性を高める、という目的に照らして極めて有効な取り組みと言えるだろう。