伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する（中編）。QCon Tokyo 2016
10月24日に都内で開催されたイベント「QCon Tokyo 2016」の伊藤直也氏のセッション「Serverless Architecture」は、サーバーレスアーキテクチャの本質について大きな示唆をもたらす内容でした。この記事では、その内容をダイジェストで紹介します。
（本記事は前編、中編、後編に分かれています。いまお読みの記事は中編です。）
サーバーレスアーキテクチャの性質
いよいよサーバーレスアーキテクチャの性質を解剖していきたいと思います。これは冒頭で説明した図です。
さっきモダンCGIの話をしましたが、CGIは実行が終了するとプロセスが破棄されるというシンプルなモデルでした。しかもShared Nothingなのであるプロセスに障害が起きてもほかのプロセスに影響しない。
しかし問題だったのは、起動するたびにアプリ全体がフォークされていたので、実行の効率がとても悪くて、以前はホスティングサービスでみんながCGIを動かしているとすごくサーバが遅くなったと。
さすがにこれじゃあかんということで、常駐プロセスのサーバを作ってプリフォークで、あるいはスレッドで実行するモデルが発明されて、だいたいのプログラムはこれで動くようになりました。
Preforkはオーバーヘッドが少なくて、プロセス同士もメモリを共有しないので安全なのですが、並行性能に難があります。具体的にはメモリフットプリントが大きくて、プロセス数が同時接続数を決めてしまいます。これがかの有名なC10K問題です。
で、これを解決するためにNode.jsのようなイベント駆動モデルによる並列処理系は、高速にコンテキストスイッチすることで並行処理性能をあげるようにしました。select()とかepoll()を使えばブロックせずに高速に処理できるじゃん、というのがNode.jsの実装です。
このイベント駆動モデルは並行性能は高いのですが可用性に難があります。Node.jsが顕著ですが、障害で落ちてしまうとリクエストが来ても全部エラーになります。
これは非常に脆弱なモデルで、ひとつの処理のメモリリークが全体に影響すると。
こうしてモデルごとに利点と欠点があったわけですが、そもそもCGIの起動に伴うオーバーヘッドが小さくなれば使いやすいのではないかと思うわけです。
これがAWS Lambdaの実行モデルで、起動に伴うオーバーヘッドがコンテナによって解決し、Shared Nothingで安全、簡単というメリットだけが得られたと。
というわけで、常駐プロセスをなくして毎回起動するというサーバーレスの実行モデルがShared Nothingをもたらし、必要になったときだけ計算すればいいという処理になります。これらを実現する上で、コンテナという起動に伴うオーバーヘッドの小さい実行環境が必要だったと。
ということが、サーバーレスアーキテクチャの最初の性質です。
イベント駆動であることとリアクティブであること
そして、必要になったときだけ計算する、というモデルは、入力をイベントとして抽象化しイベント駆動にするのがセオリーです。
イベント駆動でLambdaファンクションを実行する、ということを深掘りすると、イベントに対する反応として関数を記述する、こういうイベントがきたら、こういうふうに反応しろ、というプログラムを書く、ということになります。
Lambdaファンクションにイベントへの反応を記述するということは、イベントを送る側は相手になにも期待せずにイベントを送っていて、受け取る側がイベントをサブスクライブしていて反応するわけです。
するとこれはシステムが疎結合になります。基本的にはイベントが非同期に発生し、それをLambdaファンクションが勝手に受け取って処理を実行しているわけです。
これがいわゆる「反応としてのプログラミングモデル」で、リアクティブである、ということなんですね。
サーバーレスアーキテクチャはリアクティブなシステムである
では、Reactive Manifesto（リアクティブ宣言）には、どういうことが書かれているかというと、メッセージ駆動でアプリケーションを作ると、疎結合であるとか、反応するといったアプリケーションになる。それがElastic（伸縮性）につながるし、Resilient（耐障害性）も得られて、高レスポンスをもたらす、と。
サーバーレスアーキテクチャを思い浮かべてみると、ユーザーの要求に高速にレスポンスするシステムだし、必要なときに計算することはElasticにも耐障害性にも相当するし、イベント駆動でもある。
プログラミングモデルもリアクティブだし、Reactive Manifestoによる性質も備えている。サーバーレスアーキテクチャは、リアクティブなシステムだとはっきりいえるわけです。
FaaSではリアクティブなMicroservicesになることが確定する
もともとAWS Lambdaは大きなプログラムをデプロイするようには作られていなくて、イベントごとに処理を担当することになるので、1つのLambdaファンクションごとに1つの関数でデプロイするのが理にかなっています。すると、小さな関数を組み合わせていくことになるので、結果的にFaaSを利用したシステムはMicroservicesに必ずなるのです。
ここがすごいところで、FaaSでイベント駆動でシステムを設計していくと、Microservicesを目指さなくてもそうなってしまう。うれしいかどうかは別にして、そうなってしまう。
つまりFaaSでシステムを組んでいくと、リアクティブなMicroservicesになることが確定する。これがこのアーキテクチャがすごくおもしろいところです。
コレオグラフィは疎結合かつスケーラブルである
最後、この謎の「オーケストレーションvsコリオグラフィ」という概念がでてきました。
これはなにかというと、ビジネスプロセス構築のためにサービス間をどういうアーキテクチャで関連づけるかの議論です。
オーケストレーションは、指揮者がいて全体を指揮します。一方でコレオグラフィはバレーや舞踏などの振り付けで、舞台には指揮者はいなくて、バレリーナはあらかじめどう踊るかを決められていて、バレリーナ同士が舞台上でインタラクションしながら全体が進行していくと。
だんだん分かってきたと思いますが、オーケストレーションは基本的に、自分のサービスの一部を他のシステムに依頼して、依頼した結果が自分のところに帰ってきて、それをくっつけてビジネスプロセスを実現するというものです。
サブルーチンや関数呼び出しなどとほぼ一緒なので、分かりやすいと思います。
一方で、コレオグラフィはイベント駆動で、非同期なイベントの発生によって業務同士が駆動されるというもの。
本質的にイベントをパブリッシュする人とサブスクライブする人のあいだに依存関係はなくて、パブリッシュする人はそれによってどんな処理がされるのかはまったくしらない。処理をする人がいるかもしれないし、いないかもしれない。
この文章を読んだことがあるかもしれませんが、スタバではレジの人が注文を受けると、その内容をコーヒーを作る人に渡して、客にそこで待っててねと言ったら、あとは知らんぷりです。
これはコレオグラフィのことを表していて、この話の面白いのは、もしも注文内容を間違ったら、そのコーヒーを捨てて作り直す、つまりトランザクションが失敗したらもとの状態に戻すのではなく、新しいものを作り直すというところ。
なぜかというと、そのほうがスループットが最大化されるからです。
つまりコレオグラフィは疎結合かつスケーラブルであると。
では、コレオグラフィですべてのビジネスプロセスを設計する方が正しいかというとさすがにそういうことはなくて、同期的呼び出しのほうが単純な例も世の中には多いですし、デバッグもその方がやりやすかったりします。
コレオグラフィでないとMicroservicesの真価が発揮できない
システムをMicroservicesにするということは、サービスとサービスを疎結合にしたいがためにそうするんですよね。
で、特定のサービスを特定のチームだけで面倒をみたいとき、そのサービスがほかのサービスからどう使われているかは知らない方がいい。知ってしまうと依存関係ができてしまい、あっちがデプロイしているときにこっちを止めなくては、みたいなことになってしまいます。
そういうことではサービスの独立性は保てないので、あっちのことは知らんと、Microservicesだからこっちはこっちでサービスを作る、となります。
すると基本的にはコレオグラフィ型のアーキテクチャにしないと、Microservicesの真価が発揮できないんですね。
重要なのは、FaaSは自然とコレオグラフィを指向するということです。なぜかというと、マネージドサービス間を非同期イベントで連携して接続するアーキテクチャなので、これ以外に作りようがないんですね。
分散トランザクションのための状態保存とかがないので、スターバックスのようなやり方をせざるを得ない。だからアーキテクチャが自然とコレオグラフィへと導くんです。
逆に言えば、オーケストレーションを前提としたビジネスプロセスの構築や置き換えには向いていません。
サーバーレスがShared Nothingという制約を導いて、それが、必要になったときだけ計算するというモデルを可能にし、それだったらイベント駆動で書けばいいじゃんとなって、するとリアクティブでMicroservicesでコレオグラフィなシステムが手に入ると。
そして得られるメリットが、サーバーがないので運用負担が小さく、安く、スケーラブルだ、ということです。
というのが、今日言いたかったことの話の流れです。
≫後編に続きます。後編では、実際にサーバーレスアーキテクチャを使った感想、そしてサーバーレスアーキテクチャの今後について。
≫前編はこちら。伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する（前編）。QCon Tokyo 2016
参考：サーバレスでスケーラブルかつ堅牢なシステムを構築するためのデザインパターンとアーキテクチャ。Serverlessconf Tokyo 2017
関連記事
あわせて読みたい
伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する（後編）。QCon Tokyo 2016
≪前の記事
伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する（前編）。QCon Tokyo 2016
