（本記事は前編、中編、後編に分かれています。いまお読みの記事は中編です。）

サーバーレスアーキテクチャの性質

　いよいよサーバーレスアーキテクチャの性質を解剖していきたいと思います。これは冒頭で説明した図です。


　さっきモダンCGIの話をしましたが、CGIは実行が終了するとプロセスが破棄されるというシンプルなモデルでした。しかもShared Nothingなのであるプロセスに障害が起きてもほかのプロセスに影響しない。

　しかし問題だったのは、起動するたびにアプリ全体がフォークされていたので、実行の効率がとても悪くて、以前はホスティングサービスでみんながCGIを動かしているとすごくサーバが遅くなったと。


　さすがにこれじゃあかんということで、常駐プロセスのサーバを作ってプリフォークで、あるいはスレッドで実行するモデルが発明されて、だいたいのプログラムはこれで動くようになりました。


　Preforkはオーバーヘッドが少なくて、プロセス同士もメモリを共有しないので安全なのですが、並行性能に難があります。具体的にはメモリフットプリントが大きくて、プロセス数が同時接続数を決めてしまいます。これがかの有名なC10K問題です。

　で、これを解決するためにNode.jsのようなイベント駆動モデルによる並列処理系は、高速にコンテキストスイッチすることで並行処理性能をあげるようにしました。select()とかepoll()を使えばブロックせずに高速に処理できるじゃん、というのがNode.jsの実装です。


　このイベント駆動モデルは並行性能は高いのですが可用性に難があります。Node.jsが顕著ですが、障害で落ちてしまうとリクエストが来ても全部エラーになります。

　これは非常に脆弱なモデルで、ひとつの処理のメモリリークが全体に影響すると。

　こうしてモデルごとに利点と欠点があったわけですが、そもそもCGIの起動に伴うオーバーヘッドが小さくなれば使いやすいのではないかと思うわけです。

　これがAWS Lambdaの実行モデルで、起動に伴うオーバーヘッドがコンテナによって解決し、Shared Nothingで安全、簡単というメリットだけが得られたと。


　というわけで、常駐プロセスをなくして毎回起動するというサーバーレスの実行モデルがShared Nothingをもたらし、必要になったときだけ計算すればいいという処理になります。これらを実現する上で、コンテナという起動に伴うオーバーヘッドの小さい実行環境が必要だったと。


　ということが、サーバーレスアーキテクチャの最初の性質です。

【次ページ】 実行時にコンテナが生成され、終了時に破棄される