クラウドコンピューティング

佐藤さんのクラウドコンピューティングの話．３連荘でしたが、課金システム、電源管理、インフラ特性、分散システムと留意点は面白い．

　クラウドコンピューティングといえば、ここ数週間のあいだにGoogleのApp EngineやIBMのクラウドコンピューティングの料金設定が発表されています(IBMのサービスはただのホスティングサービスのような気がしますが)。
　個人的な予測を少々。いまのクラウドコンピューティングインフラは基本的には計算リソースやストレージに応じた課金モデルを採用しています。これはクラウドコンピューティングといっても、インフラ自体が有限であるために、計算リソースやストレージを使い果たされることを恐れているからですが、今後、コンピュータの値段やストレージの値段はさらに安くなるでしょうから、ハードウェアの値段はただ同然。運用上のコストは電気代がほとんどになりそう。クラウドコンピューティングの課金は電気代に限りになく近づくというのが当時の予測でしたが、この先を考えると電気代は温室効果ガスの排出問題などがあり、電気代の料金モデルが10年先はいまとは代わる可能性があります。ラーニングコストは自体は電気代に近づいていくと思いますが、ただ、課金というは経済的な合理性以外に、課金システムが作れるのかという問題があります。そうなると再考してみる必要はあるかもしれません。例えば計算能力やストレージは数で勝負することができます。つまりサーバの数を増やせばある程度は計算能力はのばせます。また、ストレージも結局はハードディスクの数と容量次第。問題はネットワークで、計算能力やストレージほどは伸びないのではないでしょうか。そうなると予想できるのは、クラウドコンピューティングインフラとクライアント間で流れるデータ量(または流量)による課金ではないでしょうか。結局、個々のステップ数とかプロセッサ時間で細かく課金するのもいいのですが、おおざっぱに見てしまえば、クラウドコンピューティングインフラとクライアント間で流れるデータ量(または流量)だけでいいのかもしれません。
　Azureはそのアーキテクチャは可用性とスケールアウトを徹底的に重視した設計。Eric BrewerのCAP定理がいうところの、C+AでもA+PでもP+Cでもなく、Aの可用性だけを重視したような感じ(分類としてはA+Pでしょうがね)。Azureは参照系のアプリケーションには向くのかもしれませんが、更新系はサポートが弱いという段階ではなく、Entity(Azure上のデータ管理単位)間のトランザクションはサポートしないなど、トランザクション的処理は眼中にないという感じ。もちろん、キューベースでトランザクションを実装する方法はありますが、通常のトランザクションと同じセマンティックスを実現できるわけではありませんから。Microsoft にいわせれば更新系はWindows Serverをオンプレミスで使ってくださいということなのでしょう。これはGoogleには真似できない割り切りの良さといえましょう。Azureは他のクラウドコンピューティングインフラと違って、素直に分散ハッシュを使っているそうですが、当該分野の研究者なら常識なのですが、Chordベースのデータ参照方式なので、Pastryなどの他の方式に比べてノード数が増えたときにホップ数の増加が大きい傾向があります。Azureはスケールアウトを重視したのであればChord以外の選択もあったと思うのですが、どうなのでしょうか。それとも実際のアプリケーションではホップ数はそれほど増えないのでしょうかね。
Azureはオンメモリのデータ管理を前提しているというのか、ストレージへの記録は可能な限りに遅らせることを想定しているようですね。これはなかなか興味深い設計です。なぜかという電源システムの可用性が予想できるからです。オンメモリベースでデータを管理すると速度は上がりますが、コンピュータの電源が落ちるとデータは消えるので、通常はストレージに記録します。ただし、クラウドコンピューティングインフラではデータは冗長に管理されるので、あるコンピュータの電源が落ちても、他のコンピュータがデータが保持されているので大丈夫ということなのでしょう。とはいっても停電があると複製先のコンピュータもいっしょに落ちることがありますが、Microsoftは非常用電源を確保すれば停電による多数のサーバが同時に落ちることはないという自信があるのでしょう。予想通りだとすると電源管理はGoogleよりもMicrosoftの方が進んでいるかもしれません。なお、こうしたオンメモリベースのデータ管理が広く使われるようになると、将来的にはMRAMやFeRAMなどの不揮発性メモリへの需要が生まれることから、将来のメモリ技術にも影響を与えることになります。
　クラウドコンピューティングインフラ用のソフトウェアというか、サービスを実装したことがある人ならばわかると思いますが、クラウドコンピューティングはソフトウェア開発上の物理要求が、小中規模のサーバ群とは根本的に違うし、クラウドコンピューティングでもインフラによってまったく違う。Azureを例にとるとAzureはデータ量を増やしてもサービスの性能低下はあまりおきないはずですが、データ更新の仕方に性能が大きく依存することが想定されます．
　クラウドコンピューティングインフラ用のソフトウェア開発では、ターゲットのインフラに合わせてアーキテクチャを決めてから(または与えられてから)、そのアーキテクチャのなかで、ターゲットのアプリケーションをどう作り込むのかということになってしまいます。
　コンピュータやネットワーク、データベースの構築や運用はクラウドコンピューティングのインフラ側がやってくれるので、ネットワークエンジニアやデータベースエンジニアと呼ばれている人たちの需要は大きく減るので、ソフトウェア開発能力によってSI業者の淘汰が進むというものでした。たしかにその通りだと思いますが、現状でクラウドコンピューティング向けのサービスを作るには、クラウドコンピューティングインフラの内部機構や癖をどれだけ知っているかに依存します。
　国内の大手SI業者に限ると、上流設計に特化して、下流設計は下請け任せという傾向があります。もちろん、上流設計のなかでもビジネス・モデルや要求仕様は、クラウドコンピューティングでもオンプレミスのシステムでも変わりはないと思いますが、クラウドコンピューティング上のサービス開発で、パフォーマンスとスケールアウトを考慮したサービスにするには、上流設計の段階でそのサービスを動かす側、つまりクラドコンピューティングインフラの特性を考慮しないといけなくなります。このため、国内SI業者にとってはクラウドコンピューティングは扱いにくいのではないでしょうか。いずれにしてもクラウドコンピューティングのが広まると、上流設計と下流設計の境界が上がるのか、上流と下流で設計が分けられなくなるのかは興味があるところですね。もちろん、上流設計ができて、クラウドコンピューティングインフラの内部的仕組み、例えば祖結合における複製技術やトランザクション、分散ハッシュなどの1990年代後半以降の分散システム研究を知っている方々はすごく重宝されることだけは間違いないでしょう。
　インフラの違いは抽象化されるので気にしなく済むと考えることもできますが、個人的には抽象化は難しいと予想しています。その理由ですが、90年代の分散システムの研究は、分散システム特有の問題を隠蔽する方法(研究者用語でいうとTransparencyといいます)にフォーカスされていましたが(××-Transparencyと名付けた研究ばかり)、結局、分散されているものを集中に見せかけるのは無理があったわけで、隠蔽には失敗しました。結局、Transparencyとは真逆のURLが生き残りましたが、URLは分散システムの構造をわざわざ見せている方法なので皮肉ですよね。それはともかく、この歴史を考えると超大規模な分散システムであるクラウドコンピューティングインフラがそれぞれの癖というか、特性や制約を抽象化するのは難しいのではないでしょうか。
　クラウドコンピューティングはSI業者だけでなく、(当方を含めて)研究者の淘汰も進めそうです。流行のWebサービスも90年代前半のCORBAのサブセットにすぎないこともあって、これまでの分散システムの研究は1990年前半以前の知識しかない研究者でも生きて来れらることになってしまいました。でもクラウドコンピューティングでは1990年代後半以降の知識が必要になりますから、これで分散システムの研究者も世代交代が進みそうです。ただ、心配なのは分散システムについてはコンピュータサイエンス系の大学院で教えることが多いのですが、海外の定番教科書ですらいまだに密結合の分散システムのことばかり(もちろん基礎としては大事ですが)。

　上流工程技術屋の仕事は変わらないが、クラウドコンピューティング特性を生かす設計が必要となる．クラドコンピューティングインフラの特性としてようやく分散システム研究が生きてくる時代になってきた．