まずは、今となっては少々古い資料だがGuy Rosen氏が運営していたWebサイト「Jack of all Clouds」を見てみよう。Guy Rosen氏が新たなベンチャー事業を開始して多忙になったことでWebサイト更新を停止してしまったため、2011年1月が最終更新となってしまったのが残念だ（筆者個人としてはこのデータが更新されなくなったのは非常に残念だが同氏の事業成功を祈りたい）。

　記事中最初のグラフ「Top 500k Sites by Cloud Provider - Jan 2011」の更新データを見ると、2011年1月時点で、Amazon Web Services（AWS）とRackSpaceが拮抗する勢力となっていることが分かる。

　また、記事中2番目の時系列データを見ると、この傾向は少なくとも2009年8月の計測開始時点から続いていたことと、シェア比が安定していることが読み取れる。気になる調査方法についてだが、このデータはquantcastを利用してアクセス数トップ50万サイトのリストを作成し、リストされたサイトの内で、調査対象の6社（RackSpace、AWS、Joyent、GoGrid、OpSource、Linode）にホストされているサイトを抽出する方法で作成されている（参考：Top Sites on Amazon EC2 - July 2009）。Jack of All Cloudsは調査対象ごとの計測方法も丁寧に解説されており、筆者は信頼性の高い情報源と評価している。

　一方、Deep Field Networksが先日公開した調査結果によるとAWSの全米トラフィックシェアが1％と算出されていた。米Cisco Systemsの「Visual Network Index」によると2011年の北米トラフィックシェアは35.5％なのでAWSの各地域シェアが北米シェアと同等であるなら、AWSの世界トラフィックシェアは0.35％と推測できる。

世界のIaaS資源量はインターネット接続された資源の数％

　先のJack of all Cloudsのデータによると調査対象6社でのAWSシェアは41.4％なので、6社の世界トラフィックシェアは、各社の全世界でのシェアが北米並であるなら0.86％となる。これで6社のトラフィックシェアは大ざっぱに推定できたが、これほどのビッグネームを並べてもIaaSのトラフィックシェアは1％に満たない。トラフィックの発生量と計算量は比例するので、これら6社の世界におけるインターネット接続された計算資源シェアは1％未満だと分かる。筆者は、以前にも紹介したCloud Sleuthに収録されている39社などの保有資源を含めて考えても全世界の計算資源の数％が現時点でIaaSが提供できる最大資源量と推測している。もちろん米Gartnerの2010年6月の予測に基づくと、世界のクラウド市場は2014年まで年率20％超の成長を続けるとされているので事業者は設備増強を続けるだろう。大多数の利用者から見れば設備量は無限に存在するかのように見え続けるはずだ。

池の中の鯨は気を付けないといけないことが多い

　しかし、先に紹介したDeep Field NetworksではAWSの全米トラフィックシェアは1％であり、その中でもtruste.comが最大で20％を占めるとも報告している。言い換えるとtruste.comの世界トラフィックシェアは、「35.5％（米国シェア）1％（全米AWSシェア）20％（AWS内シェア）」で0.07％だと特定できる。クレジットカード番号を登録して10分ほどで利用開始できるのがIaaSの利点とはいえ、truste.com規模の利用者になると簡単には乗換先を探すことができなくなる。truste.comは池の中の鯨なのだ。

　通常、国を跨ぐほどの規模の実装を想定したIaaSはラックやライン、フロア、データセンター（DC）、BGPトランジットなどの管理粒度ごとに障害を封じ込める設計を行って、ある部分で発生した障害が全体に波及することを防ぐように設計し、一定の障害粒度まではマイグレーションによって利用者を保護している。しかしマイグレーション不能な規模の障害が起こった際、単一事業者とだけ契約していたならば利用者は事業継続不能となってしまう。この問題を回避するために複数事業者に跨るハイブリッドクラウドの構築・利用は有効だ、と筆者もこれまで説明してきた（関連記事：クラウド事業者がサービスを中止する5つのケース）。

　池の中のメダカに当たる利用者にとっては自信を持って複数事業者に跨るハイブリッドクラウドの構築・利用は有効だといえるが、上述したような鯨に当たる利用者の場合は少々工夫が必要となる。池の中の鯨にとって自分自身が丸ごと引っ越すことのできる新しい池、つまり移転先IaaSがあるかどうかがまず問題になる。次にこの規模の利用者の場合、データ資産などの移設は瞬時には完了しない。あらかじめレプリケーションしておかなくては事業継続不能だ。そもそも自分自身を丸ごと収容できる新たな池が見つからない場合もある。その場合は自分自身の生存は諦めて子を新しい池に送り込むことになる。つまりレジリエンスな設計を行って生残性を確保する優先順位を決定し、継続を諦める部分を割り出しておくのだ（関連記事：エンドユーザーによるクラウド設備実査要求は百害あって一利なし）。ここで視点を変えるとディペンダブルであることを法規や社会からの要請されるシステムの場合、オンプレミスなシステムを維持することに合理性が見いだせるのだがそれはまた別の話だ。

鯨もメダカも共通して気を付けないといけない点もある

伝送遅延を考慮する

　そこまで身を削る思いをして生き延びる仕組みを用意してもまだ関門がある。最初に立ちはだかるのは伝送遅延の壁だ。移転先IaaSと従来利用していたIaaSとの論理的距離があまりに遠く、利用者が運用していたシステムが遅延に敏感なサービスを取り扱っていた場合、この問題は無視できない重みを持つ。双方向音声通信やオンラインゲームなどが該当する。証券取引システムなどは特に遅延に敏感だ。

　伝送遅延は経路上通過するノードごとの処理時間と伝送距離の合計だ。利用者は事業者にもよるがSLAやメトリクスを利用することでシステムをホストするIaaSから任意の接続要求先までの伝送遅延を知ることができる。

　双方向音声通信を取り扱うIP電話の場合、電気通信番号規則および事業用電気通信設備規則に規定された品質基準を満足しなければ電話番号が払い出されない。本稿はクラウドを取り扱っているので以下の表1に含まれる個々の情報の説明は避ける。ここでは遅延時間の項だけ注目してほしい。

　クラスごとに遅延許容条件が定められていてクラスAなら100ミリ秒以下、Bで150ミリ秒以下、Cでも400ミリ秒以下を達成しなければ番号が付与されない。ベライゾンが公開しているIP遅延統計情報から東京に関連する部分のみ抽出した表2と見比べると理解しやすくなるはずだ。

表2　ベライゾンが公開しているIP遅延統計情報を基に筆者が作成（注意：レイテンシは実測値。SLAとして<100msが規定されているのは台湾、韓国のみ）

　クラスA品質を担保しようとした場合、おおむね5000キロ、クラスB品質で9000キロ程度が分散限界になる。電話ですら距離制約が働くということは遅延に敏感な証券システム（東証arrownetは2ミリ秒以下）などの場合、ほとんど分散させることができないことが容易に想像できる。

　もともと光は秒速30万キロしか進めない。1ミリ秒だと300キロだ。現代の商用システムは光コンピュータはおろか完全な光スイッチングも実現していないので、光ファイバー内を光速で伝送された信号もノードに入るたびに光電変換されここで遅延が増大するので、伝送距離可能な距離はさらに短くなる。しかも伝送経路は地点間を最短距離で結んでいるわけではない。

図1　米Telegeograhyの海底ケーブル地図

　図1は米Telegeograhyが毎年公開している海底ケーブル地図だ。伝送距離はこのように地理的制約を受けるケーブルルートによって決まる。

　実は、これまで論じてきたクラウド普及によって地理的制約撤廃の利益を享受できるのは、伝送遅延を気にしないアプリケーションに限られる。もちろん伝送遅延を気にしないアプリケーションも分散配置する各国の法規制制約は受ける。もっとも、冷静に考えてみるとポケットマネーで気軽に扱えるサービス利用を検討するにしては壮大なスケールの不満ではある。

CAP定理を考慮する

　さて、伝送遅延の影響を考慮して分散度を決定しても次の関門が待ち構えている。CAP定理がそれだ。2000年にEric Brewerが提出したBrewer予想を2002年にSeth GilbertとNancy Lynchが証明し、定理として確立したCAP定理は、分散システムのノード間のデータ複製において同時に以下の3保証を提供することはできないことを教えてくれる。

• 一貫性（Consistency）
• 可用性（Availability）
• 分断耐性（Partition-tolerance）

　同時に保証できるのは3つのうち2つだけだ。一貫性を担保するためには単一障害点を許容しなければならないが、可用性を担保するためには単一障害点（SPoF）を取り除かなければならない。単一障害点を取り除くとシステム分断リスクを抱えることになるが可用性は担保される、といった具合にジャンケンのような構造になっている。

図2　CAP定理

　データベースの完全性を担保するための要件を記述したACIDに基づく実装であるSQLなどは一貫性と可用性を担保しているし、耐障害性を重視するネットワークなどは可用性と分断耐性を担保する設計を重視する。昨今話題のNoSQL系の技術は一貫性と分断耐性（CP型）または可用性と分断耐性（AP型）を組み合わせて実装している。

CAP定理を乗り越える工夫は始まっている

　そう、これまでエンタープライズシステムが慣れ親しんできたDRBMSは、世間で繰り返し言われているようにクラウドのような分散環境と相性が悪いのだ。もちろん事業継続性確保制約を緩め単一IaaSの単一局舎内でSQLを運用し続けることは可能だ。しかし、それではせっかくクラウドが実現した分散環境のメリットを享受できない。

図3　CAPの補完関係

　そこで図3のような補完関係を考慮し、それぞれの型を組み合わせてCAP定理を回避する取り組みが生まれている。既に、米datastaxがCassandraとHadoopを組み合わせ、同社の管理・監視ソリューション「OpsCenter」と組み合わせた「DataStax Enterprise」として商用化している。さらに2012年4月24日に公開されたCassandra1.1は標準でHadoop統合を果たした。Cassandra周辺に限らず、NoSQL系のサービスで強一貫性と高可用性を実現しているものは何らかの方法で上記のような二重化を実現している。もちろん、そもそも両立しない条件を満足するために性格の異なる最低2つの方法論を組み合わせて実現しているから、どこまで価格転嫁するかは事業者判断となるが、いずれかの条件を諦めた場合と比較し実装方法にも因るので一概には言えないが、コストは単純計算するなら二倍以上に膨れてもおかしくない。要するに技術的な無理のツケをコストに転化した解決策だ。

スケールするインフラとは

　スケールするインフラを十全に利用するということは、つまるところ「リアルタイム」性という幻想との決別を意味する。伝送遅延は容赦なく纏わりつくし、CAP定理を懐柔するためには複数のアプローチを積み重ねるしかない。地球規模でハイブリッドクラウドを利用することが一般的になる時代には、明示的に遅延要件とCAP定理要件を指定してシステムの分散性を決定することが求められる。言い換えるなら、シンクロナス＝同期制御に依存した設計からアシンクロナス＝非同期制御を前提とした設計への転換と、アシンクロナス制御下での遅延許容率管理が決定的に重要になると表現できる。

　そのような時代における希少性は低遅延であることだ。遅延におおらかなアプリケーションが低いホスティングコストを求めて世界をさまよう一方で、極めて低いレイテンシを求めるコスト収容力のある（つまり付加価値の大きな）アプリケーションは大消費地の中心にホストされることを求めるだろう。クラウドの普及によるITサービスのグローバル化がもう一方でローカル性を際立たせるようになる点が非常に興味深い。

川田大輔（かわだ だいすけ）

外資系ITベンダー数社を経てITベンチャー創業に参画し取締役CTOを務めた後、コンテンツ事業会社に移り技術戦略を担当。事業開発、技術開発および技術投資業務を経験。2009年より電気通信事業者（旧区分一種）に勤務し、SOAに対応しNIST定義準拠したOSSクラウドアーキテクチャ開発に取り組み、2011年5月に技術公開。他に個人としてガバナンス観点からクラウドアーキテクチャを整理しメトリクス整備を目指す「atoll project」を主宰。本稿での記述内容は個人の見解であり、その責任は全て筆者個人に帰するもので、所属する組織を代表する意見ではありません。