Lambda にクラウドの夢を見る

"AWS Lambda (Preview)"  AWSさんのblogは、こちら。

Lambdaは何に似ているか？

これは、まだPreview版だが、未来を感じさせるプロジェクトである。 最初、「これ面白いですよ」と言われた時、Amazonが関数型の言語でも出したのかなと思ったのだが、そうではなかった。でも、別の意味で、確かに面白い。

細かな説明では、このプロジェクトが何をしようとしているか理解するの、かえって難しいかも。直感的に、一番近いもので説明すると、データベースのTriggerのようなもの。Triggerが、データベースの枠を超えて、クラウド全体に広がったようなもの ..... と書いてみたが、Trigger使ったことない人、沢山いそうなことに気づく。

何故、Trigger使う人が、相対的に減ったかを考えると、この技術がデータベースの「中」の技術であるのが理由だと思う。（今でもデータベース屋さんの必須技術だとは思うのだが）普通は、OSの中である言語で開発をする。データベースのことは、インターフェース越しにしか見なくてもシステムは組める（ような気になる）から。

Map Reduceを引退させた技術

2010年に、Googleは、crawlerが収拾を続ける全世界のWebページのIndexing作業から、MapReduceを解放した。バッチ処理のMapReduceに代わって、この超巨大なデータのリアルタイムのIndexingを可能としたのは、Caffeine / Percolatorだった。Caffeine / Percolator の実装は、一口で言うと、BigTable上のTriggerの化け物のようなシステム。Trigger 最強である。あんなシステムは、普通の企業には作れないし、また、その必要もない。 ただ、そこで行われたBigTableの整合性の見直しは、のちのSpannerに結実する。こちらの技術は、規模を拡大するエンタープライズのデータベース構築にも、着実に影響を与えていくと思う。

話を AWS Lambda に戻そう。今度のLambdaは、Google Caffein/Percolatorが果たしたような巨大な分散システム上の処理の超高速化につながる技術を、クラウドに持ち込むものだと考えれば、面白いと思う。

「計算」を考える

抽象的に考えると、コンピュータの行う計算というのは、ある「状態」が、ある「きっかけ」で「変化」することに帰着する。僕らが主要に関心を持つプログラムは、このフレームの中で、状態が、どう変化すべきかを記述している。（ただ、それだけでは、狭い）もっとも、こうしたTuring Machineの定義のようなスタイルで、計算が進んでいるわけではないのは、皆さん、知っての通りだ。

現実の「計算」では、「状態」を保持しているものは、多様である。 ある場合には、メモリー上のプログラム言語の変数がその役割を果たし、ある場合には、OSのファイルシステムが「状態」を持つ。さらに、OS外のデータベースや各種のデータストアも、その役割を担う。

現実の「計算」では、「きっかけ」も多様である。 人間のコマンドラインからのコマンドの呼び出しが、第一撃だとすれば、プログラムの中での関数・プロシージャの呼び出しがそれに続く。リアルタイム処理の必要から発達した「イベント・ドリブン」なプログラミングは、単に「状態変化」を記述していたプログラムに、「きっかけ」を取り込んだものだと思えばいい。

クラウドの「計算」スタイルの変化を考える

ただ、上に見たような、現実のシステムに存在している「状態」・「きっかけ」の実に多様で階層的に入り組んだありかた、悪く言うと雑然としたありかたは、本質的なものというより、コンピュータの技術の発展の中で、歴史的に形成されたものだ。逆に言えば、今のクラウドで行われている処理のスタイルも、完成形ではない。それは、変化を続けていくだろう。

その点では、5年前の次の指摘は予見的だと思う。

「従来は、データベースとOSとは、明確にことなる存在であった。データの格納場所として、従来のOSが責任を持つのは、そのファイルシステムまでである。 では、OSとファイルシステムとの結びつきは、必然的なものであろうか?　多分、その結びつきは必然的というより、歴史的なものである。 筆者は、クラウドでは、OSとデータベースの機能が融合を始めているのだと考えている。」

2009/02/26 丸山「ScalabilityとAvailability」

クラウドを個々のOSが動くインスタンスと様々なデータストアの組み合わせとしてイメージするだけでは不十分なのだ。クラウド全体が、一つのシステムとして「状態」と「イベント」と「変化」をハンドルする。そうしたシステムへのクラウドの変化の一歩として考えると、AWS Lambdaが進もうとしている方向が、よく見えてくるはずだ。

先のスライドでも述べたように、こうした世界では、BASE ( Basically Available, Soft-State, Eventually Consistent )という考え方が重要になる。「状態」は、Soft Stateになり、整合性は、Eventually Consistent になる。丸山が述べるように、「Eventually Consistencyは、便宜的にConsistency概念を緩めたものではなく、むしろ、Consistency概念の基礎原理なのである。」

クラウドの未来の夢を語ろう

数十年前に、僕らがUNIXに夢中になったとき、僕のUNIXのイメージは、次のようなものだった。「ファイルシステムの森を、プロセスという妖精が飛び回っている。」 イメージの喚起する想像力は、大きな力を持つ。 クラウドも、もっともっと、魅力的なイメージを作り上げられればいいと思う。

「状態」と「イベント」で、システムを記述しようとするとき、関数型の枠組みが最適になるだろうと僕は考えている。Amazonが、このプロジェクトに、Lambdaという名前をつけたのは、正しいと思う。