「クラウド」という言葉は、IT関連ではもはや日常的な単語です。クラウドサービスの数や種類も多くなりました。

 クラウドを一言でいうと、「高性能なコンピュータを手元に置かず、インターネット越しに使いつつ、手元にある以上に好きなように使える」ことです。使う側には便利な方式ですが、そのぶんサービスを提供する事業者に求められるサービスの提供力や責任も大きくなります。

 手元と同じように使えるということでシステムをクラウドに移したら、サーバーがダウンして業務が止まった、取引情報などの大事なデータが消えた――大型障害から小さな障害まで、クラウドサービスの事故は、残念ながらしばしば起こっています。そのため、使う側としても、数あるクラウドサービスの中から、信頼できるサービスかどうか設備や体制から見わけるべき時代になってきています。

 そこで、信頼できるクラウドサービスを見わけるチェックポイントを見てみましょう。

 

 


 ITインフラの設計の基本は「マーフィーの法則」、つまり「失敗する余地があるなら、失敗する」ということを念頭に置いて行う必要があります。

 サーバーはいつか故障する、記憶装置はいつか壊れてデータを失う、通信回線はいつか接続が切れる。地震などの天災だって起こるかもしれません。そうした事態が起きてもいいようにあらかじめ準備しておくのが、ITのインフラ設計の定石なのです。

 いちばんの基本は、同じ機器やシステムを複数用意して、1つが壊れても、ほかのものが代わりに動き続けるようにする方法です。これを冗長化といいます。

 サーバーは複数台用意して、1台が壊れても代わりがきくようにします。データも複数台の記憶装置に分散して、そのうちの1台(あるいはそれ以上)が故障してもデータが失われないようにします。建物(データセンター)レベルでは、電源や通信回線も別々の方面から入るようにして、1カ所で停電などがあっても止まらないようにします。

冗長化の一例。上記の例では、データをRAID 6で複数に分散し、10台中2台に故障が発生しても、自動的にホットスペア(稼働状態で接続された代替機)と置き換えることで、データの消失を防ぐ

 


 クラウドサービスでは、事業者はお客さまの大事なデータを預かるわけですから、ほぼ必ず冗長化をして、障害が起きてもシステムが動き続けられるようにしています。

 しかし、どれだけ余裕をとっているかはサービスごとに違いがあります。実際には、たとえば1台のサーバーが壊れたときに、同時にもう1台のサーバーが壊れてしまうことも、決して稀ではありません。こうした場合、2台のサーバーが同時に壊れてもシステムが動き続けるようになっていれば問題ありませんが、そうした対策が取られていなければ、システムが止まってしまいます。このように、どれだけ余裕を持って構成しているかが、信頼性を見きわめる1つのポイントになるのです。

 クラウドサービスの稼働率は高い方が望ましいのですが、機器を増やせば機器自体の価格や維持費も大きくなりますし、緊急時のために対応する人間が増えれば人件費も膨らみます。そのぶん、サービスの料金に反映されることが多いでしょう。データや業務の重要性に応じて、コストと稼働率のバランスを考えること、そして公称の稼働率にふさわしい設備や実績があるかどうかをチェックすることが重要です。

 また、取引情報などのデータを守ることは、システムよりも重要です。万一システムがダウンした場合でも、データが失われることは避けなければなりません。クラウド型のアプリケーションを利用する場合には、冗長化の度合い以外に、クラウドサービスがデータのバックアップをどのように取っているかも重要なポイントです。

 冗長化により機器がダウンする確率は減ります。しかし、たとえばソフトウェアの不具合や人間の操作ミスによって、データが消去されたり上書きされたりしてしまう事故は防げません。実際、そのような大規模事故がホスティング事業者で6月に起こったことが報道されました。そのほか、未知の原因により記憶装置やサーバーがすべてダウンしてしまう可能性も、ゼロではありません。

 そうしたトラブルに備えるためには、データのバックアップが重要になるわけです。動いている本番システムとは別系統のところに、定期的にデータをバックアップすることで、本番システムのデータに万一のことがあっても、バックアップをとったデータに戻せます。

このように、最新のバックアップだけでなく、それ以前の複数世代のバックアップを取ることで、問題に気づくのが遅れた場合でも、問題が起きる前のデータに戻すことができる

 また、データの事故は、サーバーなど装置の事故に比べて気付くのが遅れることがあります。バックアップが1つだけだと、問題が起きたあとのデータでバックアップを取ったため、問題が起きる前のデータがない、という事態も起こりえます。それを防ぐには、最新のバックアップだけでなく、その1つ前のバックアップや、もう1つ前のバックアップ……といったように、複数世代のバックアップを取る必要があります。

 さらに、バックアップをとった記憶装置が障害を起こしてしまうと、いざというときに役に立ちません。ですから、バックアップシステムにも冗長化が必要です。

 このように、データのバックアップをちゃんと取っているか、どれぐらいの頻度でバックアップを取っているか、何世代のバックアップを取っているか、バックアップも冗長化しているか、ということをチェックしましょう。

 ただしバックアップの冗長化や世代管理も、何重にも備えているのが望ましいのですが、これもコストに直結しますし、したがってサービス料金のアップにもつながります。システムの冗長化と同じように、データの重要性とコストのバランスや、それを保証するだけの設備や実績をチェックすることが重要です。

 

 あまり愉快な話ではありませんが、1つの建物(データセンター)でデータやシステムを守っても、地震などの災害によってデータセンターや地域そのものが打撃を受けてしまうというのも、起こりうる事態です。そこまで深刻でなくても、停電などの影響で一時的に1つのデータセンター自体が止まってしまうこともありえます。そのような事態でも、重要なシステムは動き続ける必要はありますし、データが失われてはなりません。

 これに備えるには、十分に離れた複数箇所にデータセンターを用意し、複数のデータセンターでデータやシステムを冗長化します。こうした災害への備えをディザスタリカバリ(災害対策)と呼びます。

 たとえば、さきほど説明したバックアップの場合では、バックアップしたデータを複数のデータセンターに遠隔コピーして保管します。それにより、1つのデータセンターに万一天災などが起きても、データは守られます。

 国内のサービスでディザスタリカバリをする場合は、東日本と西日本にそれぞれデータセンターを用意することが多いようです。国際的なサービスでは、地球上をたとえばアメリカ・ヨーロッパ・アジアなどの地域に分け、さらにその中で離れたところに複数のデータセンターを設けるようなこともしています。

万一天災などが起きてもデータが守られるように、十分に離れたところで複数のデータセンターを設け、冗長化することも大切

 

 たとえば、Microsoftのクラウドサービスでは、米国・欧州・アジアの3つの地域にデータセンター群(リージョン)を設け、それぞれの中に複数のデータセンターを設置してサービスを提供しています。

 Amazon Web Services(AWS)のクラウドサービスでも、顧客企業が自分で選ぶ必要はありますが、世界で7つのリージョンと、その中の複数のデータセンター(アベイラビリティゾーン)を選べるようになっています。

 なお、AWSのクラウドサービスの上で動いているクラウド型のアプリケーションは多数ありますが、それらのサービスは、ディザスタリカバリのために複数のリージョンやアベイラビリティゾーンを使えるわけです。ただし、実際に使っているかどうかは、また別にチェックすべき点です。

 

 データが失われないことのほかに、漏れないことも重要です。特にクラウド型のアプリケーションでは、データの扱い方もクラウドサービス側に任せるため、サービス側でデータをどれだけきちんと扱って保護しているかも、チェックすべき項目になります。

 具体的には、クラウドサービスがセキュリティ上の弱点に関して最新情報を集めたり検査したりしてすばやく対策しているかどうか、ネットワーク上をデータが伝送されるときに暗号化などによって解読されないようにしているか、保管しているデータをいかに守っているか、などがポイントです。

 また、クラウド型のアプリケーションではしばしばアカウントの乗っ取り事件が起こります。その対策として、サービスでのアカウントの管理や、アクセス権の管理などがきちんとされているかどうかも重要です。

 ログイン方法でも、IDとパスワードだけでなく、専用のデバイスや、そのたびに発行される使い捨てのパスワード(ワンタイムパスワード)、アクセス元などを組み合わせることによって、より強固なセキュリティが保たれます。

 ややレアながら想定されるケースとして、法的なリスクもあります。米国では2001年に成立した「愛国者法(パトリオット法)」により、捜査機関が裁判所の令状なしにデータセンターのデータを調査できることになっています。この捜査権限は、米国の事業者がアジアやヨーロッパで運営しているデータセンターにも及ぶとされています。

 そのため、自社のデータを米国の捜査機関が令状なしに捜査できるほか、もしほかの顧客が捜査対象になった場合にサーバーが停止することもありえます。あくまでも可能性ですが、一つのリスクではあります。

 

 設備だけでなく、サービスを提供する事業者の体制や姿勢も、信頼に大きく関わります。そのチェックポイントもいくつか見てみましょう。

 

(1)情報が公開されているかどうか

 冗長化やバックアップのところでも説明したように、信頼性とコストを判断するには、実際に機器の構成やデータセンターの情報、運用実績データなどを知る必要があります。そうした情報が公開されているかどうか、そしてその内容は、大きな判断材料となります。

 ただし、クラウドサービス側の方針によっては、サービスの稼動率のレベルは高く、運用情報も公開しているものの、データセンターなどについての情報を公開していない場合もあります。こうした点での比較は、自社が利用した場合に、どこに信頼性の問題が生じうるかによって判断することになるでしょう。

 いずれの場合でも、障害発生時の情報公開体制や、障害などの運用実績など客観的に判断できる情報を提供しているかどうかは、重要なポイントです。


(2)事業者がどこまでの範囲で保証しているか

 クラウド型のアプリケーションでは、設備やデータセンターも自社で運用している場合と、データセンター事業者の上でサーバーなどは自社で運用している場合、AWSなどの設備提供型クラウドサービス(IaaS)の上でアプリケーションに注力して提供している場合など、運用形態は分かれます。

 どの形態が優れているかは一概にいえませんが、利用するアプリケーションがどの形態で提供されているかは把握しておく必要があります。それは、障害や性能低下などトラブルが起きたときに、事業者がどこまでを保証できるかにつながるためです。

 クラウド型のアプリケーションでは、AWSやMicrosoftのクラウドサービス上で提供されるものが多数あります。それらのアプリケーションが稼働実績を公開している場合でも、実はそれがAWSのクラウドサービス自体の数字で、アプリケーションについては別であることもあります。数字自体もそうですが、それ以上に、事業者がどこまでの範囲で保証しているかを把握しておくことが大切です。


(3)どこまでクラウドに力を入れているか

 冒頭でも書いたように、クラウドは「手元にある以上に好きなように使える」サービスです。そのため、サービスをできるかぎり自動化し、利用側がセルフサービスで利用できる必要があります。

 自動化がどこまでできているかは、クラウドサービスを見きわめる一つの基準です。自動化するには、サーバーを効率的に管理し、顧客ごとの環境を定型化された形でスピーディにセットアップし、さらに契約も含めてすばやく安全にとりおこなうだけの技術力とノウハウが必要になります。

 それはまた、クラウドサービスにどれだけ力を入れているかということにもつながります。契約がFAXで行なわれ、サーバーが手動でセットアップされ、利用するまでに1週間かかる、という場合には、利用側がクラウドサービスとして利用することを期待している人にはミスマッチでしょう。

 そうしたことも含め、事業者がどれだけクラウドサービスをクラウドサービスとして提供しているかは、ひとつの判断材料です。アウトソーシングやホスティングの一環としてのクラウドか、それとは別物として、あるいは専業でクラウドに取り組んでいるかどうか。クラウドサービスが終了してしまったりしないか、といった点なども含めて、サービス事業者がどこまで力を入れているか、利用側としては把握しておきたいところです。

 

サイボウズが2011年から正式スタートした自社クラウド基盤「cybozu.com」

 グループウェアは、クラウド型のアプリケーションとして企業で最もよく使われているものの一つです。

 サイボウズは2011年から自社クラウド基盤「cybozu.com」を正式スタートしました。cybozu.comのシステムは、サイボウズが一から自社開発したものです。この基盤の上で、主に中小企業向けグループウェア「サイボウズ Office」や大企業向けグループウェア「Garoon」などのクラウド型アプリケーションと、クラウド上でビジネスアプリケーションを簡単に作れる「kintone」を提供しています。

 cybozu.comでは、社内サーバーと同じようにセキュアに社内で情報共有できるサーバーをクラウドサービスで使える「プロテクテッド・クラウド」を名乗り、アクセス権などのセキュリティに配慮。専用サブドメインで利用し、IDとパスワードだけでなく、IPアドレスやクライアント証明書などと組み合わせて認証できるなどのセキュリティを提供しています。

 システムは東日本のデータセンターで運用。記憶装置を10台(+予備2台)で冗長化し、さらにそれを2系統に冗長化。そのデータを1日1回バックアップして7日分のバックアップまで保管、バックアップデータを西日本のデータセンターにも遠隔コピーして保管しています。

 設備面でさらに特長的なのは、こうした構成や実績などを、Webサイトで積極的に公開している点です。上に書いた特長も、すべてWebから確認できます。サービスの稼働率目標も99.9%(計画メンテナンスを除く)と宣言しつつ、月ごとの稼働率実績データを、サービスごとに数字で公表しています。

 グループウェアで定評のあるサイボウズですが、世界のクラウド型グループウェアではGoogle AppsやOffice 365なども大きなシェアがあります。その中で、グループウェアとしての実績とともに、クラウドサービスとしての設備面でも、cybozu.com上のサービスは実力を持ったサービスといえるでしょう。

 

関連情報
(高橋 正和)