完全性を担保できない不確かさを持つ条件の下で生き残る確率を高める手法にロバスト設計というアプローチがある。ロバスト（Robust）とはラテン語のrobustus（オークの木のように強い）を語源とする語で、「強靭な、頑健な」という意味を持つ。ロバスト性とは“ある系”が応力や環境変化といった外部要因の影響を受けて自身が変化してしまうことを防ぐ内的な仕組みで、制御工学でいうロバスト制御や、統計学のロバストネス分析、ITの分野の誤り検出訂正などが実例として挙げられる。

　ロバスト設計の考え方の基礎はフォン・ノイマンによって証明されたミニマックス定理を基礎とするゲーム理論だ。ミニマックス定理はゼロサムな条件下での2人のプレーヤーが混合戦略を許容される際に、双方が合理的に想定される損害パターンのうち、損害が最小になる選択を取り続ける限り状況が均衡する最適戦略が必ず存在することを示している。と書くとややこしいが、大ざっぱに例えるなら、「同等の打ち手同士による将棋などの対戦で互いにミスをせずに損害が最小になる手を指し続けると、必ず千日手になることを証明した定理」と書くとご理解いただけるだろうか。この定理を応用すると情報系から不確かさの最悪値の影響を最小化することができる。

　ディペンダブルな設計がモデルの正確性に依存しているのに対して、ロバストな設計は多少いい加減なモデルであっても誤差を補正して安定させることができる点に特徴があるが、その代わりにモデルが雑になるほど誤差補正の粒度が粗くなり精密な結果を得られなくなる性質を持つ。

　恐らく多くの場合「それは絶対に安全なのか？」と問う側がイメージしているのはロバストなアプローチだろう。モデル誤差を限りなく小さくしていくとDEOSと等価に振る舞うことも可能だし、コストやスキル制約に応じて粒度を粗くしてもそれなりに動作してくれる扱いやすい考え方だ。NIST SP500-292が定義したCloud Broker、それから中小規模のIssSやPaaS、SaaSを扱うCloud Providerの設計方針としても適した考え方といえる。

今後普及が期待されるクラウドコンシューマーに適した軽量なレジリエンス設計

　ところで、以前も言葉だけ紹介したことがあるが2011年3月11日を境に国内でも急速に注目を集めているマネジメント標準に「BCMS（BS25999）事業継続マネジメントシステム」があり、この規格にレジリエンシー（Resiliency）という概念が出てくる。「Resilience＝レジリエンス＝弾力、弾性」の変化形だ。BS25999での定義はインシデントに影響されることに抵抗する組織の能力とされていて、もとは生物生態学などの分野で扱われていた概念で、生態系が何らかの被害に遭った際に復元する能力や、そもそも被害を防いだり、被害を緩和したり、適応したりする能力を包括している。

　生物生態学で行われている生物多様性と生態系機能の研究は、より高い多様性を持つ生態系は環境変動リスクに強く、系全体としての安定性が高いことを示している。この生態系の持つ外乱に強い特徴を取り入れるためにBS25999はレジリエンシーという概念を導入した。

　ロバスト設計はモデル精密性に応じた信頼性水準コントロールの方法を教えてくれるが、システムが欠損した場合の復元力を担保する方法は示してくれない。そこではディペンダブルな設計手法を利用して冗長化するなどの対策を行う必要がある。これに対してレジリエンスエンジニアリング（以下、レジリエンス設計）の手法はディペンダブル設計とは逆にシステムが解放系であり代替手段がネットワーク上に存在することを前提に信頼性や耐障害性の確保を考える。つまり、似たようなサービスが数多く存在するなら、そのうちの幾つかが使えなくなっても代替サービスに乗り換えることで完全ではないにせよ継続性を確保することができる、とする考え方だ。

　非常に原始的ではあるが分散ハッシュテーブルを利用したP2Pネットワークが依拠している考え方と近い、と書けば分かりやすいだろうか？　分散ハッシュテーブルはアドホック性とスケーラビリティを両立させる探索手法で、複数のノードに分散されたテーブルの特定レコードを呼び出す経路探索が、どの分散ノードから探索を開始しても全体探索するよりよい条件で到達できることが確率論的に保証されている。この考え方は十分な数のノードに分散して情報を保存しておくことで情報の生き残る確率は高まるが、情報にたどり着くコストは高くなる。

　そこで情報にたどり着くための効率を高める工夫をすることで実用性を確保しようとしている。植物の生存戦略に例えると荒地戦略にあたるアプローチだ。全体としての性能をディペンダブルなシステムのように厳密に決定する必要があるならオーバーヘッドの大きなアプローチだが、ネットワーク規模の自由度と情報生残性確保に主眼を置き、性能保証は相対的で可とするなら非常に有効な手法といえる。

　実はNIST SP500-292が定義したCloud Consumerつまりクラウド利用者に最も適した安全性確保の手法は、このレジリエンス設計だ。とはいっても、何もクラウド利用者にIaaSを使ってP2Pネットワークを組む（それに近い手法もあるが）ことを推奨しているわけではない。レジリエンスな設計の本質は、環境変化に適応しつつシステムを再生する能力の確保といえる。事業を樹木に例えるなら樹木本体は雷や嵐で倒れることもあるが、種子が残っていればそこから再生することができる。種子の数が多く、そのまき散らされた範囲が広ければ再生の可能性も高まる。同様に、利用者のシステム＝事業にとってのコアコンピタンス（種子）に当たる部分の冗長性と分散性を十分に確保し、それ以外の部分はさまざまなPaaSやSaaS（種子の生育環境であり資源）を利用することでレジリエンスなシステムが実現できる。

　ただし、レジリエンスな設計は十分に多様性に富んだサービス提供元がNIST SP800-148が言うクラウド定義を満足した形で市場に出そろっていなければ機能しない。言い換えると生態系が豊かで大きな広がりを持っていないとリスクの高い手法になってしまう。その点、国内でもNISTのクラウド定義を満足したNTT Communications CLOUDnが登場するなどIaaS層の厚みが増してきた。IaaS層という土壌にどのような生態系が形成されてきているかは公開API数とAPI提供分野のすそ野の広がりを観測することで知ることができる。

　公開APIディレクトリを提供しているprogrammablewebによると公開API数は5639を数えるまでに増加している（2012年4月13日時点）。2005年には月間平均15APIが公開される程度だったが2010年を境にAPI公開はティッピングポイントを超えたらしく2012年に入ってからは1カ月に平均283APIが公開されるまでに加速している。

programmableweb API Directory　2012年4月13日を基に月次API公開数分布（棒グラフ）と総公開API数推移（面グラフ）をプロット

programmableweb API Directory　2012年4月13日を基に月次平均API公開数推移をプロット

　API提供分野も61分野を数え、100以上のAPIが公開されている分野は21に達している。もちろんAPI粒度やタクソノミ構造がマップ化されないと、レジリエンスな設計の必要条件となる多様性が担保されているかを判定できないが、API月次公開数がティッピングポイントを超えた点を評価し、筆者はレジリエンスな設計に取り組みはじめる時期が来ていると考えている。

programmableweb Browse APIs by Category　2012年4月13日を基にグラフ化

　ディペンダブルな設計を要求されるテレコム業界と比較するのは少々酷だが、先に紹介したTM Forum定義のテレコム業界向け標準データモデルSIDでは261パッケージ、1287クラス、定義オブジェクト数2万超がタクソノミ化されている。

TM Forum SID Phase VIII common modelをProgress DataXtend Browserで描画

　現状のprogrammablewebの分類体系はタクソノミとして利用するにはまだ脆弱すぎるので、今後はDMTF CIMI-CIMに準拠した整理をぜひ進めていってほしい。特に重複した機能を提供するAPIの分布が把握できるようになるとレジリエンスな設計に必要な多様性担保の指標となるので有益だろう。

設計面から見る外部サービスの利用の安全性確保が重要な理由

　さて、解放されたネットワーク上の多様なサービスの利用を前提としたレジリエンス設計は言うに及ばず、完全性を追求するディペンダブル設計すら外部性を取り入れ、静的なシステムから動的なシステムにパラダイム転換しようとしている状況を見てきた。では動的で外部性を取り込んだシステムの開発や運用、利用に当たって、諸賢の顧客や上司は何と問うてくるだろう？　それは恐らく、「その外部サービスは安全なのか？」だろう。

　自社システムの安全性を含むガバナンスを確立するさまざまな手法についてはクラウドガバナンス現在進行形で紹介してきたのでここでは繰り返さない。冒頭に再掲したように問題はガバナンスモデルを跨ぐ外部サービス利用時のガバナンスをどのように実現するかだ。

　ディペンダブル設計は境界領域と境界条件が変化することを嫌うのでディペンダブルであることを要求されるシステムが外部サービスを利用する場合、外部サービスに対しても自システムと同等のガバナンス水準を求めることになる。同等のガバナンス水準に達していることを証明する方法は共通指標つまり標準を利用しない限り全ての要素について突合していくしかない。

　ところが誤解を恐れず書くなら、これまで紹介してきたさまざまなガバナンス標準のうち、一意のガバナンス水準を認証条件に定めている標準はPCI DSSだけだ。ISMSなどの標準では極端に言ってしまうとポリシーとマネジメント対象を定め、マネジメントサイクルを回していることしか分からない。しかし、ITシステムが外部ITサービスを利用する場合、その外部ITサービスが、どの程度の水準でマネジメントを回しているかまで分からないと境界領域と境界条件を一定に保つことができなくなるため困ってしまう。

マネジメントされていて当然、注目すべきはマネジメント水準

　そこで有用なのがCMM（Capability Maturity Model：能力成熟度モデル）という考え方だ。CMMとは組織の能力を成熟度別に段階定義し定量的に比較可能にする参照モデルだ。もともとはソフトウェア開発の組織能力を測定するために開発されたSW-CMM（CMM for Software）が始まりで、システムエンジニアリングに関するSE-CMMや人材開発に関するP-CMM、情報セキュリティを取り扱うSSE-CMMなど分野別にさまざまなモデルが開発されている。

　自システム視点に立つならCMMに基づいて同一水準または上位水準にある外部サービスは「安全」な接続先と判断でき、例えばSAMLを利用したトラストサークルに含めることができる。もちろん、自システムより下位のCMM水準にある外部サービス接続を許容する場合はリスクを伴うので、ディペンダブルなシステムが外部サービス利用する場合は通常、自システムと同一のCMM水準を持つものに限られるだろう。

　もう一方でレジリエンス設計の場合、ディペンダブル設計のような厳密なことを言っていると設計自体出来なくなってしまうのでケースバイケースな対応が可能な柔軟な仕組みが好ましい。機能や情報ごとに独立したルールを設定し、ルールごとにアクセス制御条件を変化させるような仕組みがよい。XACMLを利用したポリシーベースのアクセス制御ルール実装が適切な選択だろう。

　ロバスト設計を採用する場合、要求する信頼性水準に合わせてディペンダブルなアプローチを採るのかレジリエンスなアプローチを採るのか選択することになる。実のところ、ロバストな設計はディペンダブルな設計とレジリエンスな設計のような対立項にはならない。関係を図示すると下図のようになる。

現状は課題が山積みだがクラウドオーディターの登場によって解決可能

　来たるべきCloud Auditorの時代を前にした現状はまだまだ混沌としていると言わざるを得ない。筆者がヒアリングした限りでも18号監査報告書などの第三者認証提供が可能なクラウド事業者に設備実査を要求する利用者がまだまだいるらしい。意地の悪いことを言うと利用者が事業者の実査をするというのであれば、例えばそのデータセンター（DC）が本当にTier IIIを満足しているか実査するためには建築確認と同等の作業が必要だし、マネジメント状況を実査するためにはマネジメント認証審査と同等の作業をしなければならない。実査を要求する利用者がDC見学をしただけで、どれほどのことが分かると考えているのか筆者には想像がつかない。正直なところ入館作業が必要ない見学者をDCに受け入れること自体がセキュリティ上のリスクだ。無意味なDC見学を要求するくらいなら、事業者が提出した第三者認証資料を精査する方がはるかに理にかなっている。利用者によるクラウド設備実査要求は百害あって一利なしだ。

　利用者サイドに厳しいことを申し上げたが、事業者サイドにも非はある。利用者が気休めにもならない設備実査要求を繰り返す理由の一端に、事業者の情報提供姿勢の問題がある。メトリクス提供に消極的であったり障害報告公開が不十分な姿勢であったりする事業者に利用者が疑いの目を向けるのは当然だ。クラウド利用への信頼醸成には利用者向けの技術情報提供だけでなくメトリクス公開等を含むオペレーション情報の徹底した公開と、公開した情報の正確性を担保するガバナンス体制の公開が重要だ。

　筆者は事あるごとにメトリクス整備の重要性を説いているので以前から拙稿を読んでくださっている諸賢はまた始まった、と飽き飽きしておられるかもしれないがここでも繰り返す。

　初めに正確な情報提供を事業者各社が率先して行わなければ、事業者と利用者の情報非対称性が市場を維持できないほどに拡大し、結果、利用者は取引しないというリスクミニマム戦略を選択しクラウド利用に踏み切らず、事業者は販売機会を失うことになるだろう。これはミクロ経済学でいうシグナリングに当たり、情報の非対称性を緩和し取引を活発化させる最も基礎的な取り組みだ。多様な料金プランや機能差異化による差別化はスクリーニングと位置付けられるが、シグナリングによって基礎を固めるのが先決だ。

　話を戻すと公開APIが増加し、レジリエンス設計が一般化すると動的な境界領域と境界条件の変化に柔軟に対応するためにXACMLなどを利用してルールベースで外部サービスに許容するアクセス範囲を制御するようになる。だからといって個々の外部サービスの境界領域と境界条件が設計時に想定していたCMM水準の許容範囲から逸脱した場合は、即座に接続遮断できなければ「安全」を確保できない。そこでNIST SP500-292が定義したCloud Auditorの必要性が理解できるようになる。

　現在提供されているマネジメント標準はPCI DSS（PCI DSS v2 Virtualization Guidelinesによって動的なマネジメントに取り組んではいるが）も含めてNIST SP800-145がいうところのRapid elasticityが実現する即時動的なマネジメント対象の変化を想定していない。当然、力任せにマネジメントサイクルをRapid elasticityが実現する変更速度に合わせて運用することで対応が可能と、ということはできるが現実的な解決策とはいえないだろう。

　恐らく、Cloud Auditorには監査対象となるサービスを現在のFIRST のようにリアルタイムで観測しCloud Sleuthのようにメトリクスとして整理し、CMM評価を行い、サービスの監査報告をリアルタイム出力する能力が求められるはずだ。マネジメント標準もタクソノミと実査データを比較評価し、影響範囲を判定するネットワークモデルを備えるようになるだろう。外部サービス利用者はこのCloud Auditorが提供するリアルタイム監査情報を自身のアクセス制御ルールに組み込んで接続認可を判定すれば「安全」ということになる。実に合理的な未来像が描ける。

　筆者は2012年3月にステルスモードを解除したばかりの米newvemに注目している。同社はCloud Sleuthのような横断的メトリクス提供能力は持たないが、利用者のAWS利用状況を分析し、無駄のない効率的な利用方法をアドバイスする最適化サービスを提供している。この機能は言い換えるならリアルタイムにマネジメントPDCAを回すものといえ、Cloud Auditorの機能の一部を実現しているといえる。

http://tctechcrunch2011.files.wordpress.com/2012/03/newv.png

　白状すると筆者は従来、この機能が実現される時期は3～5年後になると予測していた。評価モデルの標準化がなされ、メトリクスが整備され、自動最適化技術の成熟を待って初めて実現されるものだと気長に構えていたので、突然このサービスが公開されて非常に驚いた。アラン・ケイ先生がおっしゃる「未来を予測する最善の方法」の実践事例としても興味深く、真のCloud Auditorが登場する時期はさほど遠い未来ではないと予測を修正している。

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

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