サーバーレス — 注文が入った瞬間だけ現れる屋台

「サーバーレス」はサーバーが無いという意味ではありません。自分でサーバーを用意しなくていい、という意味です。コードだけ預けておくと、リクエストが来た瞬間だけ実行環境が現れ、終われば消えます。注文が入った瞬間に現れて、客がいなくなると煙のように消える屋台のようなものです。

そのぶん独特の癖があります。誰も来ていない時間は本当にゼロ台なので、久しぶりの1件目は屋台を組み立てるところから始まる。これがコールドスタートです。下の図1でリクエストを送って、屋台が現れて消えるまでを見てください。

コールドスタート — 最初の一杯だけ遅い

リクエストが届いたとき、使える実行環境が残っていなければ、クラウド側はコンテナを立ち上げ、ランタイムを起動し、コードを読み込むところから始めます。この準備時間がコールドスタートで、言語やパッケージの量によって数百ミリ秒から数秒かかります。

一度立ち上がった環境はしばらく生かしたまま置かれるので、続けて来たリクエストは準備を飛ばして即実行できます(ウォームスタート)。図1で連続してリクエストを送ると、2件目以降が一気に速くなるのはこのためです。逆にしばらく放っておくと環境は消され、次はまたコールドスタートに戻ります。

そして同時に5件送ると、5台がそれぞれ立ち上がります。FaaSでは1つの環境が1件のリクエストしか処理しません。だからアクセスが急増しても自動で台数が増える(スケールアウト)一方、急増した瞬間はコールドスタートの山ができる。この癖が、レイテンシに敏感なAPIでサーバーレスが敬遠される理由です。

ゼロまで縮む、という課金モデル

サーバーレスの本当の価値は、速さではなく課金の形にあります。常時起動のサーバーは、誰も使っていない深夜もずっと課金され続けます。対してFaaSは実際にコードが走った時間だけ。図1の下段で、2本のバーの伸び方の違いを見てください。

だから「たまにしか動かない処理」ほど圧倒的に有利です。日次のバッチ、Webhookの受け口、画像アップロード時のサムネイル生成――どれも1日の大半は暇です。逆に常に高トラフィックが流れ続ける処理では、常時起動サーバーのほうが安くなる分岐点が必ず来ます。サーバーレスは万能な安さではなく、「暇な時間が長いほど効く」割引だと捉えるのが正確です。

まとめ

サーバーレスは「呼ばれた瞬間だけ現れて、終わったら消える」実行モデルです。得られるのは台数管理からの解放と、暇な時間がタダになる課金。支払う代償は最初の1件が遅いことと、1環境1リクエストという制約です。アクセスの波が大きく、暇な時間が長い処理ほど噛み合い、常に混んでいて応答時間に厳しい処理ほど噛み合わない――選ぶ基準はこの一点に尽きます。