【クラウドコンピューティング】 Scale OutアンチテーゼとeCloud構想

Scale Outがクラウドの本質ではない！？

　ちょっと古いが、2008年10月に、クラウドの本質と動向という記事のなかで、１．スケールすること、２．安く利用できることがクラウドの本質であると書いた。大量のコモディティサーバを用意して分散KVSを配置することでスケーラビリティとアベイラビリティを確保することが基本で、プライベートクラウドは、この考えを企業内に応用したものである。

　これに対するアンチテーゼとして最近よく耳にすることは、サーバ単体の能力は十分に大きく、その能力を超えて処理しなければならないような大規模なケースはあまりないのではないかということ。真偽はわからないが、ムーアの法則が十分に成り立っており、CPU処理能力向上は将来においても続く見通しであることも背景にある。

　約5,000万PV/月くらいのサイトまでなら、アプリケーションサーバ１台で捌ける（ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない）

一般に、クラウドといえばCAP定理などに象徴される、超大規模な分散ストレージについての話になりがちだが、そんな最先端の基礎理論が必要になるのはトップ1%のなかの1%ぐらいのサービスで、世の中のほぼすべてのサービス開発者にとって、むしろクラウドの恩恵というのは以上のように一見地味な進化の中にこそあるのである
スケールアウトからスケールアップへの回帰

　また、クラウド・プラットフォームの不特定大量のプロセッサー資源をエラスティック(柔軟）にプロビジョニング（配置）して効率よく資源活用することが最大の効果であり、全体の最適化によりコスト削減を実現する仕組みの方が重要との意見もある。

　scalabilityやスループットの高さよりも、すべてのアプリをpartition-tolerantに書くよう強制して巨大インフラに細粒度で集約し、桁違いの全体最適を実現できることが重要と思う。でないと大規模サービス以外はあまり必要ない＞NoSQLとかKVS（App EngineやNoSQLはスケーラブルだからエラいのではない）

　プライベートクラウドでも、リアルタイムに、必要なITリソースを調達できるメリットが強調されている。

　海外で、ある金融機関に監査が入り、顧客の口座データや資金の動きをバッチ処理し、異常がないかを調べることになったという。期限は3日後。数十台のサーバが必要だが、今からIT部門にリソースを要求しても、とても間に合いそうにない。

　そこで、この金融機関の担当部門はAmazon EC2を使ってバッチ処理を行った。それを知ったCIOは激怒した。重要な口座データをインターネット経由のパブリッククラウドで処理するなど、とんでもないと。ところが、担当部門の責任者は、「リソースをすぐ使えるよう準備していないIT部門の方が怠慢」と逆切れ。これを教訓に、この金融機関はプライベートクラウドを導入したそうである。メリットを共有する「業界クラウド」の可能性--IBMに聞くプライベートクラウドの価値

　しかし、全体の最適化もそうだが、システムの規模が大きくなることで運用コストも増大する。特に、プライベートクラウドの経済性についての疑問は大きいようである。

　プライベートクラウドは、正しい方向への第一歩のように感じるかもしれないが、しかし規模の経済としては、プライベートクラウドは本当のクラウドコンピューティングの効率性に遠く及ばない。何が違うか？ 規模、共有されたリソースファブリック、高いリソースの利用率でこそよいサービスが低コストで提供できるのだ。
つまりHamilton氏はプライベートクラウドはパブリッククラウドと比べて効率性もサービスレベルも悪く、しかしコストは高い、といった点を突いているわけです。
プライベートクラウドに未来はないのか？

プライベートクラウドの価値


　ところが、まったく逆の発想もある。

私たちのJEANSは、アプリケーションと基盤を疎結合化し、サーバー・クラウドなどの最新技術でアプライアンス・フレームワークを構築する企業システム革新への提案です。日本のお客様のIT変革を阻む大きな要因として、IT環境における強い安定志向と、それを達成するための案件個別のきめこまかな非機能要件（NFR）の作りこみが考えられると思います。この密結合に起因する変化対応能力の課題を解決できれば、グローバルな競争を凌駕する開発、保守、運用の革新を起こすことができると考えます。アプリケーションと基盤をNFRにフォーカスして疎結合化するために、新しくアプライアンス・フレームワークを設計し、いろいろとお客様実環境での実証性をスタディしたいと考えています。ミッションクリティカル環境にフォーカスし、仮想化技術やクラウド・コンピューティング技術を最大限活用してこの構想の実現をめざしています。”eCloud研究会” 参画について．JEANSの背景

　Googleはあれだけの規模のデータセンターを少ないコストで運用できているのだがら、運用コストの削減はたぶん可能だと思う。そういった技術を企業システムに応用することのメリットは計り知れないだろう。
　この提案で驚いたのは、開発コストにまで言及している点である。現在、ＩＴ投資の70%以上が運用系に費やされており、その原因が非機能要件（NFR）の作りこみの現状があるということ。この構想では、もう一度プラットフォーム側の可能性を見極め、そして、（HWではない）アプライアンス・フレームワークによる解決を試みる。つまり、NFR作りこみが必要ないぐらいの高度なプラットフォームを専用で用意（≒アプライアンス）することで、業務アプリは非常にシンプルにできる。そうなれば、3K,4Kといわれる酷いシステム開発の現状を打破できる。

CAP定理を超越した発想
　

　CAP定理は、Consistency, Availability, Partitionsを同時に満たすことができないという有名な定理であるが、中島さんは、「Consistency, Availability, Partitionsは全て満足した上でスケールアウト環境での高性能を出さなければならない」といわれているように、CAP定理を根底から覆すような発想をしておられる。今に始まったことではないが、中島さんは、ある意味無茶苦茶な方である。

さて、スケールアウト構成での最も重要な課題はデータの信頼性、一貫性、即ちConsistencyです。プロセッサー・ベルの技術用語ではCoherenceです。クラウドレベルのレイヤーの議論になると、CAP定理とかBASEだとかの主張の下、ACIDが出来ないならアプリケーションで緩めてもいいじゃん、というようなWS-*（Web Service astar)前夜の議論が当たり前のようになっていますが、ハードウェア・レベルではそれは絶対許されません。そんな事が簡単に許されるならSUNが ROCKチップに失敗してギブアップする苦渋など無いわけです。CAP定理の逆、すなわち Consistency, Availability, Partitionsは全て満足した上でスケールアウト環境での高性能を出さなければならない。それがコンピュータ本来の、HWの基本です。SWとHWの話をゴチャゴチャに論じているように見えるかもしれませんが、ROCKが火を点けたTransactional Memoryの技術はその風景にあります。
　さて、Hot Chips 21でクレームされているPOWER7のこの面での潜在能力、アプローチは中々凄いと思います。確かに Intel Nehalem-EXのQPIによる大幅な性能向上は驚愕です。しかしそれを超えて、POWER7で主張されているPOWER6に対する有効 Compute Throughput ５倍(1.6TB/s)のメッセージは大きい。これはフィールド・アップグレード等の面で、POWER7がPOWER6の足回りを基本的に受け継いだ以上物理的なチップI/Fの性能向上だけでは達成されないターゲットを、eDRAMのオンチップ搭載も含めた数々の技術革新によってクリアしようとしている点でIBMらしい味が感じられます。

　ちなみに、クラウドでは、「ScalableでAvailableで、かつ、Eventually Consistentなシステムは可能である。」というように、Cの部分を緩くすることで、３つをほぼ同時に満たすことを目指している。この命題の実現こそが、現在のエンタープライズ向けのクラウド・システムが目標としているところなのである。
　ところが、中島さんは、Eventually Consistentはナンセンスだとおっしゃっている。Googleを否定するわけではないが、ill-structuredだと。利用者側の対応に任せられてしまうことのデメリットの方が大きいと感じられているようだ。これはもっともなご意見である。

またレプリケーション型のデータ・モデルでデータ整合性を担保するためには、アプリケーション層で 3-Phase Commit 相応の最終的なコミット・コントロールが必須だ、というところでしょうか。プラットフォーム側の厳密さに期待できないという点でill-structured なわけですね。利用者側の対応に任せられてしまうということです。逆にこの ill-structured さがグーグルのスケールを可能にしているわけですから、”角を矯めて牛を殺す”ことがないようにもしなければならない。
　これを”出来ない論議”で終わらせないためにプライベート・クラウドの主張があるわけですが、このアプローチに対しても出来ない論が強くあります。現行のきめ細かにカストマイズされた多様な NFR (Non-Functional Requirement) 構築に対応出来ないというのも大きなクレームです。

　しかし私は疑問を抱かざるを得ない。
　複雑さを考える---Complexity Quanta and Platform Definition
Summary of Jim Waldo‘sKeynote at the 10th Jini Community Meetingでいわんとしていることは、「それぞれの段階を通り抜ける際、我々は、何かを失う」ということ。
　何も失わずにすべてを手に入れることなんて可能なのだろうか。これはとても難しい命題のように思える。
　昨日、"eCloud"というリスティング広告に引っかかって、中島御大のサイトを発見した私であるが、とりあえず見なかったことにしようと思う。
　（リタイヤされた元上司のサイトを半年もたってやっと見つけました。連絡ぐらいくれればいいのに。）

　

マルチ・スレッドへ：我々は、順序を失う（複数のことが同時に起こる）。これは、難しい。なぜなら、我々は、自然には、シーケンシャルに考えるから。
マルチ・プロセスへ：単一のコンテキスト（すなわち、我々が信頼しうる共有コンテキスト）を失う。グローバルな状態が、開発のあらゆるところで利用される。（すべてをスタティックに考えよ）
マルチ・プロセスからマルチ・マシンへ：我々は、状態を失う。「システム」のグローバルな状態というのは、虚構である。興味深い分散システムには、整合的な状態というものは存在しない。（Lamport:http://research. microsoft.com/users/lamport/pubs/pubs.html）分散OSのプロジェクトは、グローバルな状態を導入しようとしたが、大々的に失敗した。
信頼できないマルチ・マシンたちへ：誰を信ずることが出来るか分からない難しい状況の中で、我々は信頼を失う。

しかし、我々は何かを得てきた
Seq to MT: 並列処理
MT to MP: プロセスの分離(安全を与える)
MP to MM: 独立した失敗(何かまずいことが起きても、システムの部分は生きのこる)
MM to MMU: スケール(webスケール、インターネットスケール). 誰か他の人のリソースを利用せよ（あるいは、他の誰かが、我々のリソースを利用することを認めよ）