サーバレス
Serverless ・ さーばれす
サーバの管理をクラウドに委ね、コードだけを持ち込む実行モデル。呼ばれた分だけ動き、課金される。
✦ 30秒で試す — 航海サーバの台数を、誰も見積もらずに済む仕組みがあるサーバレスの料金は、常時のサーバと比べて？予想してみる概要
サーバレスとは、サーバの存在を意識せずにコードを動かせる実行モデルです。「サーバが無い」わけではありません。物理マシンも OS も確かにどこかで動いていますが、その調達・設定・パッチ適用・台数の増減といった管理をすべてクラウド事業者が引き受け、開発者は関数（処理のかたまり）だけを持ち込みます。AWS Lambda、Google Cloud Run functions、Azure Functions、Cloudflare Workers などが代表的なサービスで、この形態は FaaS（Function as a Service）とも呼ばれます。
動き方も従来と異なります。常時起動して待ち続けるサーバとは違い、サーバレスの関数は「HTTP リクエストが来た」「ファイルが置かれた」「決めた時刻になった」といったイベントが発生したときだけ実行環境が用意され、処理が終わってしばらく呼ばれなければ片付けられます。課金も実行した時間とリクエスト数に対してだけで、何も起きていない間の費用はほぼゼロです。
「サーバレス」という言葉は、FaaS だけでなく、同じ性質（管理不要・自動で伸縮・使った分だけの課金）を持つデータベースやストレージ、メッセージキューなどを含む広い意味でも使われます。文脈によって指す範囲が変わる語彙です。
なぜ生まれたか
クラウドコンピューティングは「サーバを買う」を「サーバを借りる」に変えましたが、借りた仮想マシンの中身、つまり OS の更新、ミドルウェアの設定、セキュリティパッチ、負荷に応じた台数調整は、依然として利用者の仕事でした。しかも借りたサーバは、リクエストが一件も来ない深夜でも動き続け、課金され続けます。「書いたのはたった数十行の処理なのに、それを動かすための管理作業と待機コストが重すぎる」という不釣り合いが残っていたのです。
2014年に発表された AWS Lambda は、この残りの部分ごとクラウドに委ねる答えを示しました。コードを預ければ、実行環境の用意もスケーリングも障害からの回復も事業者側が行い、費用は実行した分だけ。事業者から見ると、これは大量の利用者の「たまにしか動かない処理」を同じ機械の上に詰め込み、動いている瞬間だけ場所を貸す仕組みです。一人ひとりが「いつか来るかもしれない負荷」のために機械を借りっぱなしにする無駄を、事業者側でまとめて吸収したのがサーバレスの発明でした。
詳細
イベント駆動の実行フロー
サーバレスの関数は、何らかのイベントをきっかけ（トリガー）として起動します。代表的なのは、APIゲートウェイ経由で届く HTTP リクエスト、ストレージへのファイル追加、メッセージキューへの投入、スケジュール実行、外部サービスからの Webhook などです。プラットフォームはイベントを受け取ると、空いている実行環境を探し、なければ新しく作って関数を呼び出します。
実行環境は、1回ごとに作って捨てるわけではありません。処理を終えた環境は、しばらくのあいだ温めたまま残され、次のイベントに再利用されます。どれだけ残すかは事業者が決め、保証もされませんが、数分から十数分ほど呼ばれなければ回収されるのが普通です。そして1つの実行環境は、同時には1件のイベントしか処理しません（Lambda の場合）。同時に10件届けば、プラットフォームは環境を10個に増やします。台数を見積もる人も、ロードバランサを設定する人もいない代わりに、この増減の規則を知っておく必要があります。
下の部品で、イベントを1件ずつ送ってみてください。間を空けたり、一度にたくさん送ったり、負荷を「常時」に切り替えたりすると、実行環境の数と課金メーターがどう動くかが見えます。
左の「イベント」を押して、1件送ってください。実行環境はまだ1つもありません。
コールドスタートという固有の代償
「使うときだけ起動する」ことの裏返しが、コールドスタートです。空いている環境がないときに届いたイベントは、実行環境の準備を待たされます。事業者側で環境（多くは軽量な仮想マシンやコンテナ）を立ち上げ、言語のランタイムを初期化し、利用者のコードと依存ライブラリを読み込み、関数の外に書いた初期化処理（DB への接続や設定の読み込み）を走らせる。この合計が数百ミリ秒から、大きなランタイムでは数秒になります。温まった環境に当たれば数ミリ秒で始まる処理が、冷えた環境に当たった1件だけ遅れるのです。
厄介なのは、コールドスタートが「たまにしか呼ばれない関数」と「急に同時に呼ばれた瞬間」に集中することです。前者は温存の時間が切れて毎回冷えており、後者は同時に届いた件数だけ新しい環境を作るので、その全員が遅れます。対策としては、あらかじめ決めた数の環境を温めておく仕組み（AWS の Provisioned Concurrency など）、初期化後の状態をスナップショットとして保存して復元を速くする仕組み（Lambda SnapStart）、依存を減らしてコードを小さくすること、そしてコンテナではなく V8 の isolate という軽量な単位でコードを隔離し、起動をミリ秒以下に抑えた Cloudflare Workers のようなエッジ実行環境があります。
ステートレスという設計前提
サーバレスの関数は、次の実行が同じ環境で動く保証がありません。メモリ上の変数やローカルファイルは、温まった環境が再利用されれば残っていることもありますが、次は消えている前提で書きます。セッションやデータは外部のデータベースやストレージに置くことになりますが、ここに古典的な罠があります。関数は千並列に膨らめるのに対し、同時接続数に上限のある RDBMS は同じ速さでは膨らめません。環境1つにつき1本の接続を開けば、千の環境が千本の接続を求め、DB が先に倒れるのです。そこで、DB の手前で接続を束ねて使い回すプロキシ（接続のコネクションプールを代わりに持つ RDS Proxy など）を挟むか、HTTP で問い合わせて接続の概念が薄い NoSQL・サーバレス型の DB を組み合わせるのが定石です。ほかにも、1回の実行時間に上限がある（Lambda は最大15分）ため長時間の処理には向かない、といった制約があります。
使いどころと、割高になるところ
サーバレスが輝くのは、負荷が間欠的・突発的な処理です。1日数回のバッチ、たまにしか呼ばれない社内 API、画像アップロード時のサムネイル生成、メッセージキューのコンシューマ、Webhook の受け口。待機コストがゼロで、急な増加にも自動で追随できる利点が最大になります。
逆に、負荷が一日中高く安定しているサービスでは、常時稼働のサーバのほうが安くつくことが多くなります。サーバレスの単価は「実行した時間あたり」で見ると、同じ性能の仮想マシンを借りるより高く設定されています。待機の時間が長いうちはその割高さを待機コストゼロが打ち消しますが、ずっと実行し続けているなら、割高な単価を一日中払うことになるのです。どこで逆転するかは、平均してどれだけの割合の時間、処理が動いているか（稼働率）でおおよそ決まります。またアーキテクチャが特定事業者のイベントの形式や周辺サービスに深く結びつくため、他社への移行が難しくなるベンダーロックインも織り込むべきトレードオフです。
運用の景色の変化
サーバレスでは「サーバにログインして調べる」ことができないため、運用の頼りはログと監視に集約されます。数百の小さな関数がイベントで連鎖する構成では、1つのリクエストがどの関数をどの順に通り、どこで遅れたかを追う分散トレーシングが欠かせません。デプロイも CI/CD と IaC（構成をコードで管理する手法）で自動化するのが前提です。管理から解放される代わりに、観測とデプロイの規律が要求される。サーバレスは「楽になる」というより「悩む場所が変わる」モデルだと理解しておくと、期待とのずれが少なくなります。
試問
左の「イベント」を押すと1件、「5件を同時に送る」で5件が同時に届きます。サーバレスの実行環境は呼ばれたときに起動し（コールドスタート、約0.9秒遅れる）、1つの環境は同時に1件だけを実行します。処理を終えた環境は7秒だけ温存され、その間に届いたイベントは起動なしですぐ走り、呼ばれなければ回収されます。
左の「イベント」を押すと1件、「5件を同時に送る」で5件が同時に届きます。実行環境はまだ1つもありません。