知っておきたいクラウドのリスクとセキュリティ 第3回

IT環境をクラウド化し、データーセンターを使うメリットとは？

自社設備でOK？企業がクラウドを使う上でのリスク管理

ロケーションリスクと考慮点

　前節で触れたように、金融機関等一部の企業を除けば自社設備を用いるよりもクラウドサービスを利用するほうが災害や攻撃といった各種リスクに対しては強いといえる。しかしながら、実際そのリスクが顕在化する際、またはそのリスクへの対応を考える際、地理的な位置すなわちロケーションは重要な要素となる。IaaS、PaaS、SaaSのそれぞれによってロケーションリスクは異なるため、その点について触れていく。

　まず、IaaSは一般にはサーバーリソース、OSレベルまでのサービスを提供するため、提供する場所（エリア／リージョン）は明確にしている。たとえば、HaaS/IaaSからSaaSまでをサポートするIIJのクラウドサービス「IIJ GIO」は、関西（大阪）に第一弾の設備を用意している。さらに、すでに発表している松江のモジュール型エコデータセンター（コンテナ型DC）など、データーセンターの場所を明確にしている。

IIJの「松江データセンターパーク」の完成予想図と独自のデータセンターモジュール「IZmo（イズモ）」

　これによって、クラウドサービスの物理位置がわかるため、そのサービスを利用する際のロケーションリスクがはっきりする。どのようなバックアップ対策をとればよいのかといった、設計上の指針が明確になるという利点もある。

　PaaSやSaaSについては、サービスによっては国レベルの設置位置は公にしているもの、具体的な場所に関しては公開していないものがある。一方で、PaaS/SaaSでも、どのIaaS基盤のうえにサービスを構築しているのかを明確にしているものもある。たとえば、メジャーなグループウェアの1つであるサイボウズの「サイボウズ ガルーン SaaS」はIIJ GIOの上で提供しているSaaSであり、現時点のユーザーには関西の設備でサービスを提供していることを明確にしている。

　また、外国にあるサービスを利用する際にさらに2点気を付けなければならない点がある。1つ目は海外における法律、2つ目は遅延（レイテンシ）である。

　1つ目の海外における法律は、米国のパトリオット法により有事の際に自社のデータが米国政府に閲覧されるおそれあること、EUの個人情報保護指令によりEUで収集した個人情報を日本に持ってくることができない、といった問題が具体的に挙げられる。海外のサービスを用いると、ユーザーのビジネスに影響を与えるリスクがあることを、注意しなければならない。

　2つ目は、遅延時間である。光の速度を超える技術が世の中にない以上、光ファイバを通じて伝送されるデータは距離の影響を直接的に受ける。日本の東京～大阪のような距離では、大した影響はないだろう。しかし、太平洋の先にある米国や南米のデーターセンターを使うと、クライアントとサーバーの間でのトランザクションの中で何往復もデータをやり取りするような場合に、大きな遅延を感じてしまうことがある。アプリケーションによっては、タイムアウトしてしまう場合がある。

　これは「クラウドスルース（CloudSleuth）」のようなサイトを見ると一目瞭然である。このサイトでは、世界の主要IaaS/PaaSベンダーのレスポンスタイムを全世界から測定している。レスポンスタイムの測定方法は、ECサイトの一連のトランザクションをシミュレーションしており、

1. 40枚のサムネイルを表示
2. 1つの商品を選択
3. その商品の大きな画像を表示する

という流れとなっている。

CloudSleuthの調査結果。東京では「IIJ GIO」のレスポンスタイムが1.07secであり、2位のAmazon EC2（シンガポール）の5.89secに圧倒的な差を付けている

　基本的にはユーザーの近くにシステム（特にデータストア）があることがクラウドの利用上は重要な要素であることは明らかである。

災害リスクと考慮点

　災害対策を考えた場合、クラウドサービスを利用することは有用である可能性が高い。たとえば、インターネットゲートウェイ（メールゲートウェイ、Webゲートウェイ）、電子メール、ファイルサーバー、公開Webサーバーといったシステムは自社で持つよりもクラウドサービスを組み合わせたほうがコスト面で明確に有利である。

　一方でオンプレミスでユーザー独自で構築しているシステムに関しても、クラウドサービスは自前でディザスタリカバリ対策を行なうよりも有利な点がある。たとえば、本番サービスが20台のサーバーで動いている場合、自前でディザスタリカバリ対策を行なう際には、災害時のクラスタ構成や性能の縮退を許容しても通常半分の10台のサーバーで構成するような設計が一般的となる。サーバーコストは約半額になるが、それでも普段使わないシステムに対して本番の半額のコストをかける体力がある会社はほとんどないだろう。さらに、リスク対策が原価高の要因となって事業の競争力を下げるのであれば、リスク対策そのものが事業継続上のリスクとなり本末転倒である。

　またストレージに関しては、ユーザーデータ保護領域は本番サイトとディザスタリカバリサイトでは同じものを持つ必要があり、コスト面でさらに厳しい。これに対してクラウドサービスを用いると、本番サイトを20台の仮想マシン（VM）で構成した場合、ディザスタリカバリサイトは1台のVMで済む。

　この1台のVMに対して本番データのレプリケーションを行なえば、ユーザーデータは救える。本番サイトが利用できない場合は、ディザスタリカバリサイトのVMをオンデマンドで増設すればよい。1台5分程度で増設可能なため、数十台でも半日かからない。従来この増設を求められるRTO（目標復旧時間）内に実現しようとすると、どうしても自前で設備を持つ必要があった。しかも、縮退システムにしかならなかったのだ。これに対し、クラウドサービスを利用すれば、コストと可用性の問題を一気に解決できることになる。

図1　クラウドを利用したディザスタリカバリ

■関連サイト

• CloudSleuth

（次ページ、「自社設備にこだわるべきではない」に続く）