表1の中で、OSイメージの少なさが目に付く。しかしこれは平易に追加可能な部分でもあるので、今後、充実されていくことを期待したい。個別のインストールの要望にも対応しているようだ。

　vCPUは2GHz相当と、やや見劣り感がある。ただ、筆者が少し触ってみた際には「2GHzにしては速いな」という印象を持った。スペックの公称値を安全サイドに（控えめに）採っているのかもしれない。非公式ながら、実測値を発表しつつ、他社サービスと「互角」としている個人ブログもあるようだ。

　次にインスタンス性能のバリエーションが狭いことが見て取れる。これは恐らく物理層で採用しているサーバのリソースの制約によるものだろう。コア数／メモリ容量ともに（ニフティクラウドと比べて）小さめの物理筐体を利用しているものと想像される。この“小さめの物理筐体”という特性を逆手にとったユニークなサービスがあるので、後ほど紹介したい。

　その前に価格を比較しておこう。中核サービスであるインスタンスについて、想定クロック数に差があることを承知で、vCPU数とメモリ、OSをそろえて比較してみる。Linuxの最小リソースモデルと、Windowsの最大リソースモデルを月額固定費用で比較すると次の通りだ。

　価格面ではBIGLOBEクラウドに軍配が上がった。CPUの公称想定性能差（ニフティクラウドが1.5倍）を考慮しても、まだ割安感があるように感じられる。

　さて、小さめの物理筐体を生かしたユニークなサービスの件だが、下記の2つがある。

クロック保証

　「CPUリソース保証」という有料オプションがあり、2GHz限定ではあるが、vCPUの稼働速度を確保できる。パブリック型のIaaSでは、同一の物理筐体に複数のユーザーのインスタンスが相乗りすることが予見されるが、このとき、vCPUのリソース（速度）の取り合いになることがある。速度を安定させたい場合には、このオプションが有益だろう。同一筐体を共有するユーザー数が少ない場合に提供可能なオプションといえる。他社のサービスでは、物理筐体ごと確保するオプションもあるが、割高である。このようなオプションを気軽に使える点は、ユーザーにとってメリットがあるだろう。

Oracle対応サーバモデル

　多くの企業ユーザーが、既にOracleのライセンスを保有している。これをクラウド環境上に持ち込もうとする際、「ライセンス」の問題が悩ましいことは有名だ。Oracleのライセンスポリシーとして、インストール先が仮想サーバであっても、その下にある物理サーバのプロセッサ数をカバーするだけのライセンスを要求している。例えば、vCPUを1つしか使わない仮想サーバにOracleをインストールする場合、これを支える物理層が16プロセッサであれば、16プロセッサ分のライセンスが必要といわれている。AWSはOracleとの交渉によってこの問題を解消しているが、多くのIaaSベンダーがこの問題を解決しきれずにいる。

　BIGLOBEクラウドは、「Oracle用」とされるインスタンスを用意している。このインスタンスを支える物理層には次のような特徴がある。（1）プロセッサ数が少ない、（2）物理的に分離したクラスタ（ゾーン）を選べる。これによって、持ち込むべきOracleのライセンスは、最小2～最大6プロセッサ分でよいことが保証されている。また、物理的に異なる筐体を使って冗長構成を組むことが可能になる。さらに、他の（通常の）インスタンスと同様に、ユーザーが管理コンソールでオンデマンドに調達できる点も特徴だ。

　以上、面白いサービスだと思うので紹介させていただいた。

　ところで、小さめの物理筐体のハンディは大きいのだろうか？　表1に戻ると、ニフティクラウドでは6vCPUのインスタンスが使えるが、BIGLOBEクラウドでは4vCPU止まりだ。重大な差のように見えてしまうが、この違いが重要になることはあまりないのではないか。よく考えればいずれのクラウドでも8vCPU以上は利用できない。「8vCPUは要らないが、6vCPUが必要」という状況は考えにくいと思われてならない。ある程度ハイスペックなサーバが必要であれば、自前で用意し、ハイブリッド化を検討することは避けられない。BIGLOBEクラウドは、この点で非常に充実したオプションを用意している。冒頭で触れた2012年8月31日に発表された新サービス「クラウドアクセスサービス」がこれだ。

クラウドアクセスサービス

　オンプレミス環境とクラウド環境をWAN接続する場合、インターネットVPNや、IP-VPNなどの選択肢がある。これに加えてBIGLOBEクラウドでは、顧客指定キャリアによる専用線の引き込みを可能としている。これによってオンプレミスのサーバとクラウド上のインスタンスを任意の帯域で接続できるようになる。AWS Direct Connectによく似たサービスだが、キャリアと帯域を自由に選べる点が特徴といえそうだ。あと、もう1点、次のような裏技が使える（AWSの関連記事：AWSが2010～2012年に増強したエンタープライズ向け機能を一挙紹介）。

クラウドと一体化したデータセンター

　専用線の物理的引き込みはユーザー側が行う。この際、データセンターが指定され、その中にラックを借り、ルータなどの機器を置くことになる。このスペースは見えないところでクラウドと直結される仕組みになっている。もちろん、普通のデータセンターであり、これまで通りの活用ができる。従ってユーザーは、このスペースにハイブリッド用のオンプレミスのサーバを置くことが可能だ。これはなかなか得難いサービスではないだろうか。うまく使えば専用線の帯域を落とし、コストを下げることが可能になるだろう。

　ビッグローブによれば、BIGLOBEクラウドの成り立ちから考えれば、これは自然な流れなのだそうである。企業向けのハウジング／ホスティングサービスから、仮想サーバのレンタル、そしてパブリッククラウドへと拡張してきており、いずれのサービスも相互連携しながら成長してきている。パブリッククラウドのすぐ横に直結できるデータセンターがあり、ハイブリッド構成が自然に組めるよう全体最適化が図られている、これがBIGLOBEクラウドの最大の特徴といえるだろう。

保険が適用できる唯一のクラウド

　もう1つの特徴は、少々変わり種である。BIGLOBEクラウドは「保険を掛けられる唯一のクラウド」なのだそうだ。三井住友海上火災保険が提供するクラウドプロテクター（クラウド特約付きコンピュータ総合保険）という保険があり、BIGLOBEクラウドは、この保険の適用が可能な唯一のクラウドサービスだそうである。ユーザーがこれに加入していれば、クラウドが停止したりデータが消失した場合の休業補償や緊急対応費用、データやプログラムなどの再作成費用の一部が補償される。障害の原因としては、自然災害はもとより、クラウド事業者側の瑕疵によるケースでもOKだ。そんな掛け金があれば、その分だけ冗長構成やデータ保護のエンジニアリングに傾注した方がよいという意見もあるだろうが、技術だけでは「想定外」の事態は超えられないのもまた事実である。保険という最後の手段でヘッジをしておくのも1つの考え方だろう。

　最後に、BIGLOBEクラウドの課題について見ていこう。

データセンターは1カ所しかない

　パブリッククラウドを使う場合、データセンターレベルで冗長化を図ることが一般化しつつある中で、データセンターは1カ所しかない構成は少々心もとない。DR構成などを考えると複数のデータセンターは必須だ。拡張を期待したいところだ。

クラウドストレージサービスがない

　Amazon S3相当のサービスが見当たらない。ニフティクラウドを含む他のクラウドにおいて標準となりつつあるサービスであり、ユーザーはこのようなストレージの存在を前提とした構成を検討しがちである。こちらも拡張を期待したい。

　以上、BIGLOBEクラウドについて概観した。読者各位においてクラウド利用の選択肢が広がれば幸いである。なお、取材や資料調査には最大限の注意を払っているが、本稿の内容に事実と異なる点があれば筆者の責によるものであることをあらかじめお断りしておく。

加藤 章（かとう あきら）

電通国際情報サービス　ビジネス統括本部　クラウドビジネス開発部　ストラテジスト

システム開発のPMやビジネスコンサルタントなどを経て、現在は自社内のビジネス企画に従事。クラウドに軸足を置いて調査、企画、情報発信、営業支援および社外とのアライアンスを担当する。