このように並列化された構造を持つIaaSは、原理的に単一障害点（SPOF）を共有している資源粒度以上には障害範囲が拡散しないが、SPOFを排除するために資源プール間でフェイルオーバー構成を行っている場合、一方の障害によって発生した代替資源要求に十分応えられる資源（計算、記憶、伝送そして遅延時間）の余裕がないと、フェイルオーバー構成された資源全体が、要求の集中によるサービス提供不能状態（輻輳崩壊）を起こす可能性が残る。障害範囲を小さく抑え込み、代替資源（冗長資源）に対する障害資源比を低く保つことが輻輳崩壊を防ぐ手段となる（関連記事：クラウドの資源量で考える、単一IaaS事業者への依存リスク）。

　ただし冗長資源は不稼働資源でもあるので、冗長資源比率が高くなるほど全体としての設備稼働率が下がりコストに跳ね返ってくる。過去のAWSの障害報告などを読んでも、この分野にはまだまだ改善の余地があることが見て取れる。クラウドにおける資源管理の問題は経済学でいう資源配分問題に他ならない。この面から考えても、筆者にはIaaS資源の市況商品化には一定の合理性があるように思える。

図3　左上図ではリスク的に見て独立した3つの資源プールからなるノードにおける障害時の挙動を模式化した。障害発生した資源プール内の予備資源によって迂回資源要求を満たせなくなると、ノード内の他の資源プールの予備資源に迂回資源を要求、確保してサービスを継続しつつ復旧作業を行うことになる。しかし左下図のように迂回資源要求量に対応できるだけの予備資源量が確保できない場合、計算資源でも伝送同様に輻輳崩壊が起こり得る。今後は計算資源においてもQoS制御・保証技術が重要性を増してくるだろう。右図ではスケールフリーネットワーク上に配備されたノード群でのノード間資源代替を模式化している。ネットワークは地球規模の広がりを持っていると考えてほしい。スケールフリーな伝送路構造を持っていると想定しているのでノードごとの計算資源保有量もスケールフリーになるはずだが、その描写は省略した。伝送遅延に寛容な、言い換えるとステートレスな通信を許容するシステムであれば、今すぐにでも図にあるような広域資源代替が可能だ。今後、計算資源のQoS制御・保証技術が発達してくると遅延許容条件などの広域資源代替条件を細かに制御するようになるだろう《クリックで拡大》

　米Googleは、GPSと原子時計を利用して図3右図のような地球規模の分散システムにおける時間同期の方法を既に実用化している（参考：Spanner論文）。将来的には類似の仕組みが国際標準化されて広く利用される可能性がある。

可用性の基礎

　既に承知されている方には甚だ基礎的な話をして申し訳ないが、しばらくお付き合い願いたい。可用性とはJIS X0014によると「必要となる外部資源が与えられたときに、ある時点において、又はある一定の期間、機能単位が決められた条件のもとで要求された機能を果たせる状態にある能力」と規定されている。要するに「使える」状態だ。使える状態とは故障していない状態なので、信頼性工学では平均故障間隔（MTBF：Mean Time Between Failure）と表現する。同様に、故障して使えない状態を修復に充てている時間として、平均修復時間（MTTR：Mean Time To Recovery）と表現する。MTBFとMTTRの関係は平均稼働率をAとすると、

というシンプルな式で表せる。また、システムを構成する個々の障害（部品故障など）はランダムに発生するのでポアソン分布する。

　ただし、ネットワーク構造を持っている場合は、ポアソン分布した個々の故障がそれぞれランダムなネットワーク外部性を持っているので、全体として障害はべき乗則に従って分布する。とはいえ、システムの可用性水準を求める観点からは、インスタンスなどの計測単位で発生する個々の障害を他の要素に影響を与えないように封じ込めればよいのだから、結局、利用者にとって必要な障害発生確率はポアソン分布を用いて予測すればよいことになる。MTBFやMTTRがポアソン分布することを利用すれば、平均稼働率をシミュレーションするのはさほど難しくない。

図4

　ちなみに、IaaSのようなネットワーク外部性を持つサービスの場合、SPOFを共有している資源プール単位で障害に遭うし、個々の仮想サーバの障害はライブマイグレーションなどの技術によって救済可能なので、広い意味での可用性管理の観点では、利用者が仮想サーバ1台ごとの信頼度計算を行うことにはあまり意味がない。

　個々の仮想サーバレベルでの信頼度計算に意味があるとしたら、仮想サーバ上で動作するアプリケーションの信頼度を計測し、要求する可用性水準を満足させるためにどの程度の並列化を行うべきかを決定する場合だろう。この場合には直列モデルの信頼度計算を行うことになる。また、異なる事業者が提供するPaaSを組み合わせてシステム構成する際も、直列モデルでの信頼度計算が役立つ。だが、定義のおさらいで触れた通り、抽象化された資源（IaaS）を隠蔽し、IaaSに対してポータビリティを持つ、真の意味でPaaSと呼べるサービスはまだほとんど市場に存在しない。Java EE 7の仕様リーダー Linda DeMichiel氏が2012年9月9日のブログで、Java EE 7の開発スケジュールを維持するためにPaaSとマルチテナンシーに関連した機能の実装をJava EE 8まで延期したことからも、真の意味でのPaaS実装が非常に難しいことが感じられるはずだ。

　現時点では、利用者がIaaSの信頼度計算を行う場合は、SPOFを共有するアベイラビリティゾーン単位で並列モデルを利用するのが妥当だ。

図5

　ところで、約款に掲載されているSLAを見ると、サービスとして提供されている諸機能は、信頼度の値が与えられている。年間使用可能時間割合99.95％といった数値だ。SLA99.95％などとはっきり定義されており、かつ、第三者認証などによって、そのSLAが信頼に足ると考えられるなら、後は必要な信頼度になるように、並列モデルで要求する信頼度に達するまで並列化すればよい。

　注意すべき点として、事業者によっては使用可能時間（または使用不能時間）の定義に条件が付加されている場合がある。例えば「5分未満の通信遮断は使用不能時間に参入しない」と約款に規定されているような場合だ。

　5分未満の通信遮断が問題になる用途を想定している場合、通信遮断の発生頻度を一定時間計測する信頼性試験を行って、利用者が信頼度を決定してから利用したり、想定している用途で収容可能なコスト上限まで並列化して運用開始し、運用後に得られた信頼度データに基づいて並列度を引き下げていくといった工夫をして、SLAの制限を乗り越えようとしている利用者もいるかもしれない。だが、筆者としてはお勧めできない。

　事業者が「保証しない」とした領域での品質は、どのように揺らいでも事業者は文句を言われる筋合いがないのだ。例えば、5分未満の通信遮断は保証しないとしている事業者において、過去実績では5分未満の通信遮断の24時間当たりの平均発生率が1回だったとしても、将来は3回になるかもしれない。こういった品質の変更や揺らぎに対して、静的に構成された利用者独自の可用性向上策は無力だ。しかも、このような場合は事業者の保証範囲を逸脱しているので補償を要求するのは難しい。

　利用するサービスがきちんとMeasured Service（計測機能）を実装していてログ出力できるものであり、利用者が基本的な信頼度計算の方法とポアソン分布の概念さえ理解しているならば、正味の信頼度を得るのはさして難しくない。このような場合は利用者が独自にリアルタイムに信頼度を算出し、必要な並列度を保つように動的に制御するといった運用が可能だ。こういった情報の風通しの良さはクラウドのよいところだ。

　将来的には、SLAの値と運用実績の監査証明がセットで比較可能になり、構成をデザインして必要な信頼度の値を与え、必要な冗長度を実装対象となるIaaSごとに割り出してくれるような設計（運用）支援ツールも登場するだろう。インスタンスの時価や伝送遅延も考慮して、最適な利用者システム展開先の提示も可能になるかもしれない。これはSOCCIが提示する未来像に近い姿だ。

IaaSでの高可用性実現

　さて、IaaS実装それ自体が高可用性を実現する途上にあることと、基礎的な信頼度計算の方法について見てきたが、その事業者の約款と、取得している第三者認証の内容をきちんと見極めてさえいれば、利用者は現時点でもIaaS事業者の高可用化を待つことなく、IaaS上に高可用性システムを実装することが可能だ。

　可用性を高めたいならデータセンター（DC）などのSPOFを共有しない複数のIaaS事業者を利用して、ハイブリッドクラウドを構成すればよいだけだ。前回作成した比較表でAPIを装備した7サービスなら実装可能だろう（比較表：35のIaaSクラウドをガバナンス要求で徹底比較）。

ちなみに、DC指定可能なサービスを使えばハイブリッド構成は不要なのではないか？　という向きもあるだろうから付記しておくと、AWSのようにアベイラビリティゾーンと明示的にうたっている場合はご指摘の通りとなる。しかし、DCが複数用意されていても、Measured Serviceを実現するCloud OSS機能など、計測・制御機能などがDC同様に分割されていない場合は要注意だ。Cloud B/OSSを収容した親システム側が障害に見舞われた場合、子システム側の可用性が担保されるかは事業者ごとの実装に依存するためだ。

　ここまで検討してきた高可用性ハイブリッドクラウド実装に必要な機能を考えてみよう。

図6　 NIST定義に従って整理したハイブリッドクラウドの模式図。Virtual Machine Manager、Virtual Network Manager、Virtual Storage Managerは総称してCloud Orchestration機能を実現する。最終的にCloud Orchestration機能はCloud OSSに吸収されていくだろう《クリックで拡大》

　繰り返しになるが、概念としてのクラウドの本質とは動的な並列化だ。動的な並列化を実現するには、Measured Serviceを用いて利用している資源の状態をリアルタイムに把握し、状態変化を計測し、APIを利用してOn-demand self-serviceにResource poolingされた資源プールからRapid elasticityに仮想資源を呼び出し配備して、動的にBroad network accessできなければならない。計算・伝送・記憶のそれぞれについて、クラウド定義に基づく全ての機能がそろっていないと動的並列化は実現できない。

　計算資源の動的配備はハイパーバイザーによって実用化されて久しい。伝送資源についてもSDNの隆盛によって環境が整いつつあるし、記憶資源についてもクラウドストレージと呼ばれるスケールアウト可能な記憶資源が構築可能になりつつある。これら資源の利用を横断的に認証認可する認証基盤と、CSA CCMなどに準拠した共通のデータモデルに基づいて計測し制御する基盤が出そろってくると、高可用性を実現したハイブリッドクラウドの実装がぐっと簡便に可能になる。米Ping Identityが以前から提供している「PingOne」や、2012年9月11日に米セールスフォースが発表したファイル共有サービス「Chatterbox」、ID管理サービス「Salesforce Identity」はこの文脈で評価が可能だろう（関連記事：Chatterの新機能から見る――ソーシャル革命が変える私たちの未来）。

　NIST SP500-292が描くアーキテクチャモデルを下敷きに、最近の技術開発動向や市場に投入され始めた新しいサービスを俯瞰すると、今後は「newvem」などの計測サービスやAPI共通化に挑戦している「DeltaCloud」「OpenStack」「CloudStack」といったクラウドフレームワークが、IaaSの全ての機能を抽象化するのではないかと筆者は考えている。これらは、個々のIaaS事業者が提供しているAPIを抽象化し、最終的にはCSA CCM標準に基づくIaaS制御言語を生み出していく。このIaaS制御言語が誕生したときこそ、真のPaaS時代の幕開けになるのではないだろうか。

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

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