伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する（前編）。QCon Tokyo 2016
クラウド上でアプリケーションを構築する新しい手法として「サーバーレスアーキテクチャ」が急速に注目を集めています。しかし一方で、サーバーレスアーキテクチャを採用することで得られる本質的なメリットはなにか、そもそもサーバーレスアーキテクチャとはなにを指すのか、などについてはまだ識者の間でも議論されていることです。
10月24日に都内で開催されたイベント「QCon Tokyo 2016」の伊藤直也氏のセッション「Serverless Architecture」は、こうしたサーバーレスアーキテクチャの本質について大きな示唆をもたらす内容でした。この記事では、その内容をダイジェストで紹介します。
（本記事は前編、中編、後編に分かれています。いまお読みの記事は前編です。）
Serverless Architecture
一休 CTO 伊藤直也氏。
先に結論を言ってしまうと、サーバーレスアーキテクチャとはサーバーのないアーキテクチャと言われていて、単純にはAWS LambdaとかAzure FunctionsとかGoogle Cloud FunctionsなどのクラウドのFunction-as-a-Service（FaaS）を使うことを指すのですが、それだけだとサーバーレスアーキテクチャという大げさな名前を付けるのは適当ではないと思っていて。
ステートレスなFaaSがリアクティブ、Microservices、コレグラフィへと導く、というのがサーバーレスアーキテクチャの僕の考えです。
ただ現場の感覚では、運用が楽でスケールして安い。従来の、インスタンスをずっと立ち上げておく運用やオンプレミスサーバの運用よりずっとよいですと。
ただ、どんなものでもそうですが、これは銀の弾丸ではなくて向いていないシステムもありますが、アーキテクチャの性質を見てみると、いま一般に考えられているよりも広がっていくのではないか、というのがいまの自分の考えです。
で、今日の説明はこの図の通りに説明していくつもりです。
どういうことかというと、サーバーレスな実行環境を使うとShared Nothingになってステートレスになるので、必要になったときだけ計算するという体（てい）になると、これがメリットとして運用負荷が少ないとか安いにつながっていきます。
これをさらに深掘りしていくと、必要なときになったときだけ計算するということは、イベントを受け取って実行するようにモデリングをするとうまいくいきそうだというのは皆さんお分かりになると思います。なので系の全体をイベント駆動で結んで、これがリアクティブやMicroservicesやコレオグラフィといった性質を見せて、これが総体としてスケールアウトというメリットを導くと。
こうなります。これを具体的に見ていきたいと思います。
Function-as-a-Service（FaaS）とはなにか？
サーバーレスといったときに、多くの人が思い浮かべることが2つあって、ひとつはサーバーの箱やLinuxといったOSがない、ということ。もうひとつは、ソフトウェア的なサーバ常駐プロセス、例えばApacheのようなものがない、ということ。
前者の意味のサーバーレスは、PaaSのようにサーバーの運用をクラウドに任せて自分たちでサーバーを運用しなくていいということで、これは新しい概念ではないので置いといて、今回は後者の、常駐プロセスの意味でのサーバーがないというところ、つまりFaaSに焦点を当ててみます。
FaaSとは何かというと、これらのマネージドサービスのことです。
AWS Lambdaがいちばんメジャーなので、このAWS Lambdaで説明すると、AWS上で任意の小さな関数を実行するためのサービスです。
自分で関数のコード（Lambdaファンクション）を書いたら、それを実行する環境がいままでのアプリケーションサーバのようなものではなく、AWS Lambdaという謎の環境にデプロイすると。PythonやNode.js、Javaなどをサポートしています。
AWS Lambdaはいろんなイベントを受け取って、それを契機に関数を実行するんですね。
実行時にコンテナが生成され、終了時に破棄される
重要なことは、AWS LambdaのLambdaファンクションは実行時にコンテナが生成され、終了時に破棄されるので、常駐しているプロセスはないんです。ここがポイントです。
ふつう、アプリケーションサーバのようなプロセスが常駐していて、コードをデプロイするとこのサーバ上でコードが実行されるのですが、AWS Lambdaでは実行時にコンテナが生成されて終了時に破棄されることになっています。
これはコンテナの生成のオーバーヘッドが小さいおかげです。CGIに近いモデルで、「モダンCGI」と呼ぶ人もいます。
この、実行時に生成されて終了時に破棄されるという性質から分かるように、Lambdaファンクションは基本的にステートレスなんです。なのでLambdaファンクションが実行時に持っている状態や変数の内容は、終わったらきれいに消えます。
ステートレスという性質はアプリケーションによい影響をもたらしていて、それはShared Nothingなので、なにか実行時に障害が発生してもほかの実行には影響しないし、コンテナ1つで処理しきれなければ、コンテナを100個起動して処理すればいいので、スケールが簡単です。
つまり、AWS Lambdaはスケールするし、安いと。
Lambdaファンクションはステートレスにしか書けないという前提があるので、単純にたくさん実行すれば簡単にスケールさせられます。また、実行が終わったら破棄されて、次に必要なときにまた起動されるため、Node.jsのプロセスがいつのまにか落ちていてアプリケーションが正常に動かない、といったこともありません。
また、計算した分しか費用が掛からない、つまりAWS Lambdaが起動している時間分しか課金されません。これは費用感としてはインスタンスを立ち上げてプロセスを常駐させているのと比べると、1桁も2桁も、びっくりするくらい安くなります。
ここまでがAWS Lambdaの基本的な話で、サーバーレスアーキテクチャを単純化すると、FaaSを利用したシステム設計アーキテクチャなのですが、より本質的にはイベント駆動で系を設計した、リアクティブでコレオグラフィなMicroservicesのことです。
これってなんのこっちゃと思われると思うので、ここをこれから説明します。
AWS Lambdaのユースケース
サーバーレスアーキテクチャのイメージがわきにくいと思うので、まず簡単な事例から紹介しましょう。
一休でもAWS Lambdaを使っています。これは典型的なユースケースで、ホテルの人が画像をAmazon S3にアップロードすると、そのサムネイルをAWS Lambdaで生成しています。
Amazon S3に画像が保存されるとイベントが発生して、そのイベントをサブスクライブしているAWS LambdaのLambdaファンクションが実行されてサムネイルを生成し、それがAmazon S3に保存されると。
イベントによってLambdaファンクションが起動されるというのがポイントで、これによってAmazon S3とAWS Lambdaは疎結合になっているんですね。Amazon S3はイベントを発生すると、それを誰が受け取ってどう処理するのかはまったく知らないのです。
先日開催されたServerless Conference Tokyoの日経新聞さんの事例がけっこうすごくて、iPadの画面などで紙の紙面とおなじものが読めるという紙面ビューアーの裏がサーバーレスアーキテクチャになっていると。
具体的には、写真のデータをモバイルデバイス用に圧縮変換する処理をAWS Lambdaにたくさんおいて、イベントを連係させて最終的にユーザーに届くようにしていると。
ここで伝えたいのは、複数のLambdaファンクションをたくさんあちこちに置いて、それぞれイベントをサブスクライブさせて処理を連係させて大きなアプリケーションを作っているところです。
要するに、FaaSでイベント駆動設計をつきつめていくと、小さい関数がたくさんシステムの系に存在するようになって、それが連係していくという、Microservicesみたいになってくるんです。
つまり、サーバーレスとMicroservicesは相性が良くて、Microservicesの実装手段が1つ明らかになった、というのが昨今の状況です。
≫中編に続く。中編ではサーバーレスアーキテクチャの性質を解剖することで、リアクティブ、Microservices、コレオグラフィというキーワードへと導かれていきます。
≫後編はこちら。伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する（後編）。QCon Tokyo 2016
参考：サーバレスでスケーラブルかつ堅牢なシステムを構築するためのデザインパターンとアーキテクチャ。Serverlessconf Tokyo 2017
関連記事
あわせて読みたい
伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する（中編）。QCon Tokyo 2016
≪前の記事
NetflixのChaos Monkeyがバージョンアップ。マルチクラウドに対応し、AWS、Google CloudのインスタンスやDockerコンテナが落とせるように
