クラウドというスケールするインフラでビッグデータを運用すると、把握すべきオブジェクト（＝ノードの数）とその関係（＝リンク）が爆発的に増える。人間に管理可能な粒度に情報量を減らし、迅速に運用するには？
クラウドの運用規模が成長するにつれて、爆発的に拡大する複雑さの問題が顕在化してくる。OpenStackやCloudStackなど含めてあらゆるクラウド関連パッケージが解決を目指しているのは結局、この複雑さの問題をどう抑え込むか、という点に集約される。この問題についてきちんと理解しておくことで、目的に応じて技術を選択する軸がはっきりしてくるはずだ。
2012年11月6日に投開票された米大統領選挙の舞台裏でオバマ大統領の再選を支えたクラウド（Amazon Web Services：AWS）ベースの選挙支援システムは、AWSのブログをはじめ多くのメディアが取り上げているのでご存じの方も多いだろう。ところで、Ars technicaが掲載しているオバマ陣営のIT関連支出明細を見ると、これほど大きなシステムを構築・運用したにも関わらず、AWS関連の支出構成比は非常に小さかったことが分かるので少々引用しよう。まずは元記事の支出分野ごとにサマリーしてみた。
| 費目 | 費用 | うちAWS費用 | AWS費用の割合 |
|---|---|---|---|
| ハードウェア、ソフトウェア購入費用 | 339万8888.03ドル | ||
| Webホスティング、Webサービス費用 | 149万4681.43ドル | 25万7287.97ドル | 17.2％ |
| 技術コンサルティングサービス費用 | 361万5928．12ドル | ||
| 合計 | 850万9497.58ドル | 25万7287.97ドル | 3.0％ |
オバマ陣営のIT支出はInformationweekの記事が指摘するように、データ統合と高度なデータ分析、意思決定支援、有権者とのコミュニケーションを図るためのサービス開発に重点を置いた配分だったようだ。まさに「ハイパフォーマンス企業ではITが市場機会発見や新製品開発に非常に大きな役割を果たす」（※1）というイノベーションエンジンとしてのITの在り方を実践しているといえるだろう。
※1 Juniper Networksの委託に基づいて英Economist Intelligence Unitが調査し2012年12月16日に公開した報告書「Can the IT Department Keep Up With Exponential Growth？（IT部門は急速な成長に追随できるか？）」で指摘。
オバマ陣営の選挙支援システムでは200以上のアプリケーションを実行し、数百万人のユーザーをサポートした。スケールアウト型のシステムとしてデザインされ、選挙キャンペーン終了後はバックアップを残して、マシンは全てシャットダウンされ跡形もなく消え去るという、まさにクラウドの面目躍如たるケースとして注目すべき事例といえる。p2012.orgによると、選挙支援システム開発を含む選挙キャンペーン組織は2011年4月4日に42人体制で発足し、2012年7月のピーク時には650人がシカゴの選挙対策本部で働いていたという。GIGAOMのデリック・ハリス氏のエントリによると、オバマ陣営の技術チームは、極めて厳しい時間制約（プロジェクト開始2011年4月4日から運用終了2012年11月6日までの18カ月間）の下、わずか14カ月で15倍に膨れ上がるスタッフに対応して業務に必要なサービスを提供した。それだけでも普通の情報システム部門なら悲鳴を上げるところだが、Key-Valueストア導入やSNS対応機能開発など、2008年の前回選挙当時にはなかった新機軸を盛り込みつつ、AWSのダウンといったアクシデントをも乗り越えている。ここに挙げた材料だけでも感動的なドキュメンタリーが1本作れそうだ。
ハーパー・リード氏率いるオバマ陣営の技術チームは、これらの課題を時間制約内に処理するために“車輪の再発明”を避けることを基本方針に置いたという。それがキャンペーンに利用された14のAWSサービスだけでなく上述したオバマ陣営のIT関連支出明細の支出先ベンダー構成にも表れている。AWSだけでなく日本でもおなじみのAkamai、Salesforce.com、PayPal、Githubといった定番サービスからlayeredtechといったHIPPAやPCIに準拠したコンプライアンスマネージドサービス、PKIインフラを提供するentrust、広告管理システムのMARIN SOFTWAREといった機能まで、既存サービスを大量に組み合わせてシステム構築している。
これらの手法から筆者は、ハーパー・リード氏が意識的に広い意味でのSOAに基づくレジリエンスなシステム開発を志向していたと推測している。「クラウドのベンダーロックインを回避するための処方せん」で紹介したThe Open Group提唱のSOCCIが目指すアーキテクチャモデルと「エンドユーザーによるクラウド設備実査要求は百害あって一利なし」で紹介したレジリエンス設計の考え方だ。
ハーパー・リード氏の技術チームは、単にさまざまなWebアプリケーションを導入するのではなく、有機的に結び付けてプロジェクトゴール（オバマ氏再選）を実現するために必要なサービスを構築する部品として使いこなしている。システム開発・構築プロジェクトにおけるゴールのレベルを、誰にでも見える形で一段引き上げたと評することができないだろうか？
プロジェクト全体の成功確率を高めるために、サブプロジェクトであるITプロジェクトのゴールをより高いところに置く。すると見渡さなければならない領域が広がるために、開発スコープが広がる。従来通りの粒度でスコープの広がりに対応していたら、とてもではないが「オバマ再選プロジェクト」全体の制約条件を満足させることはできなかっただろう。
独自の機能開発を最小限に抑え込み、既存のサービスを最大限活用してITシステムで処理できる業務範囲を最大化し、独自機能と既存サービスを有機的に組み合わせることに注力し、低コストのインフラを並列化して大量に利用して応答性能を確保することで、プロジェクトゴール到達の可能性を高めたのだと整理できる。
これは言い換えるなら、開発プロジェクトの抽象化度を高めるアプローチといえる。そこでは重要なキーファクターは、重箱の隅を突くような精度向上ではなく、適切な抽象化粒度と組み合わせ条件の決定となる。さらに言い換えるなら、複雑性クラスの相互関係制御ともいえるだろう。
筆者は巨大なシステム（クラウド）の複雑性を抑えるには、健全な抽象化が最初の一歩だと考える。三省堂大辞林によると「抽象化」とは、「事物や表象を、ある性質・共通性・本質に着目し、それを抽（ひ）き出して把握すること。その際、他の不要な性質を排除する作用（＝捨象）をも伴うので、抽象と捨象とは同一作用の二側面を形づくる」ことをいう。また、「健全」とは論証が妥当であり、かつ、その前提の全てが真であることをいう。
つまり、健全な抽象化とは、「対象に対して、論証が妥当であり、かつその前提の全てが真である範囲において、詳細を捨象し一度に注目すべき概念を減らした結果を対象の本質と見なす操作またはその結果」といえる。簡単に言ってしまうなら、同じ統計表（対象）に含まれる数値は同じルール（妥当で真）で四捨五入（捨象）し、単純化しなければダメという話だ。
健全な抽象化という基本的なルールが理解できると、複雑性クラスの相互関係という考え方は分かりやすい。「利用者がIaaSの信頼度を計算するには？」での論考を一歩進めてクラウドのサービスモデルを例に取ってみよう。
エンドユーザー視点を中心に置いたNIST SP500-292のモデルでは、IaaS、PaaS、SaaSの分類基準は曖昧なものになってしまっている。しかし健全な抽象化を複雑性クラスをベースとした視点で導入すると、がぜん見え方が違ってくる。
図1 CCUGCが作成したレイヤーモデルがそもそもアーキテクチャ階層を基準にした視点とUXを基準にした視点の混成物だった。CCUGCが作成したモデルを下敷きに作成されたNIST SP500-292は、アーキテクチャ階層を基準とした視点と実装を基準にした視点の混成物となっていて、ブロック配置がCCUGCモデルと逆転している
図2 実際に各種のサービスを組み合わせてシステムを構築しようとするとUX基準は使いにくい。サービス実装の仕方によっては複雑な入れ子構造が各所で見られるだろう。システムを使い込み、拡張が進んでいくに従ってサービス間のリンク構造はランダムネットワーク的な構造になっていく。そのとき特定の箇所で起こった障害がシステム全体のメルトダウンを誘発する可能性を低く抑え込むためには、組み合わせるサービスの適切な粒度管理が重要になるおなじみのIaaS、PaaS、SaaSは、それらを支える物理資源群まで含めて抽象度の問題として捉えると、抽象度の低い物理資源（オンプレミス）から物理資源を抽象化して抽象計算資源として切り出し自由度を高めたIaaS、さらにIaaSの抽象計算資源を隠蔽してメタ制御装置と見せることで抽象度を一段引き上げたPaaS、メタ制御装置すら隠蔽してアプリケーションI/Oだけを見せる、最も抽象度の高いSaaSと整理することができる。
図3 チューリングマシンであるコンピュータは、計算可能なあらゆるものを模倣するのでUXや実装方法などの基準で階層を切り分けることには無理がある。抽象度（＝複雑性クラス）と継承関係のネットワーク構造を基準にレイヤー管理を行うことで、恣意性の入り込む余地が小さくすっきりとした管理モデルを実現できる《クリックで拡大》ちなみに物理資源（オンプレミス）を構成する伝送装置であるルータなどの通信機器でさえ実態は計算機が伝送装置をエミュレートしているため、具象／抽象という軸を使って説明すると入れ子構造が大変ややこしいことになる。実際に評価尺度を整備する段階では複雑性クラスとして取り扱うのがよいだろう。この考え方を応用した監視・運用フレームワークを実装するとシステムの一部で何らかの障害が発生した際に、その障害がシステム全体を巻き込んだ輻輳（ふくそう）障害に拡大するリスクを低減してくれるだろう。
話を戻す。現在PaaSと目されているAWSの諸サービスに限らず国内クラウド事業者の提供しているいわゆるPaaSサービス群も、この健全な抽象化という評価軸を通して見ると少々いびつな構造となってしまっているものが少なくないように見受けられる。今後、機会があればPaaSのレイヤー分界点評価を行ってみたい。
さて、特定事業者が提供するサービスに閉じたシステムを構築していくだけならそれでもさして問題にならないだろう。だが、それでは「クラウドのベンダーロックインを回避するための処方せん」で提示した問題に自らはまりに行っているようなものだ。ここは利用サービスの抽象粒度を強く意識して、ハーパー・リード氏ばりのマッシュアップに挑戦し、「市場機会発見や新製品開発に非常に大きな役割を果たす」IT利用を実現していただきたい。
健全な抽象化によって適切な分界点が確定可能になるころには、「【第3回】利用者がIaaSの信頼度を計算するには？」で予想した標準IaaS制御言語を超えて、統合的なクラウドサービス記述フレームワークが登場する環境も整うだろう。この分野では2009年にMicrosoft Researchが提案したOrleansの挑戦が非常に先進的で勉強になる。IaaS制御言語は、最終的にはこういったフレームワークに統合され、開発者はモデリング言語を利用してサービスを記述し、IaaS制御言語はその裏側で人知れず動作するような形になるのかもしれない。
クラウドサービス記述フレームワークは、その初期こそ新サービスの「記述」に焦点が当てられるだろう。しかしさまざまなサービスがランダムネットワーク的な構造で接続されたクラウドエコシステムは、成長に伴って複雑適応系的な振る舞いを見せるようになる。そのときクラウドサービス記述フレームワークは、新サービス投入などによって起こるかく乱を観測し、好ましい均衡に誘導するためのツールになっていくのではないかと想像している。ここまで至ると、健全な抽象化がなされているかどうかは開発者が意識して決定するものではなく、クラウドサービス記述フレームワークのメトリクス機能によって“クラウドという一種の自然環境の観測結果”として評価されるものになっているだろう。
このように整理してみるとハーパー・リード氏が率いるチームは「ビッグデータは世の中を変えるか？」で提示したビッグデータ利用を前提とした競争を仕掛け、見事に勝利を収めたと結論できる。
クラウドベースのマッシュアップやレジリエンスなSOAベースの開発、ビッグデータ利用といったキーワードは既に概念をもてあそぶ段階を過ぎている。これらの手法を利用してイノベーションエンジンとしてのITによって、実際に目に見える価値の増大を競合より先に、より高いレベルで実現した利用者だけが生き残れる大生存競争の段階に突入したと認識するべきだ。
「インクルーシブマーケティング」実践のポイントは？ ネオマーケティングが支援サービスを提供
ネオマーケティングは、インクルーシブマーケティングの実践に向けたサービスを開始した...
Xが新規アカウントに課金するとユーザーはどれほど影響を受ける？ そしてそれは本当にbot対策になるのか？
Ｘが新規利用者を対象に、課金制を導入する方針を表明した。botの排除が目的だというが、...
Googleの次世代AIモデル「Gemini 1.5」を統合 コカ・コーラやロレアルにも信頼される「WPP Open」とは？
世界最大級の広告会社であるWPPはGoogle Cloudと協業を開始した。キャンペーンの最適化、...
ITmediaはアイティメディア株式会社の登録商標です。
