サーバレス

概要

サーバレスとは、サーバ の存在を意識せずにコードを動かせる実行モデルです。「サーバが無い」わけではありません。物理マシンも OS も確かにどこかで動いていますが、その調達・設定・パッチ適用・増減といった管理をすべてクラウド事業者が引き受け、開発者は関数（処理のかたまり）だけを持ち込みます。AWS Lambda、Google Cloud Functions、Cloudflare Workers などが代表的なサービスで、この形態は FaaS（Function as a Service）とも呼ばれます。

動き方も従来と異なります。常時起動して待ち続けるサーバとは違い、サーバレスの関数は「リクエストが来た」「ファイルが置かれた」「決めた時刻になった」といったイベントが発生したときだけ実行環境が用意され、処理が終われば消えます。課金も実行した時間とリクエスト数に対してのみで、何も起きていない間の費用はゼロです。

「サーバレス」という言葉は、FaaS だけでなく、同じ性質（管理不要・自動スケール・従量課金）を持つデータベースやストレージ、メッセージングなどを含む広い意味でも使われます。文脈によって指す範囲が変わる語彙です。

なぜ生まれたか

クラウドコンピューティング は「サーバを買う」を「サーバを借りる」に変えましたが、借りた 仮想マシン の中身——OS の更新、ミドルウェアの設定、セキュリティパッチ、負荷に応じた台数調整——は依然として利用者の仕事でした。しかも借りたサーバは、リクエストが一件も来ない深夜でも動き続け、課金され続けます。「書いたのはたった数十行の処理なのに、それを動かすための管理作業と待機コストが重すぎる」という不釣り合いが残っていたのです。

2014年に登場した AWS Lambda は、この残りの部分ごとクラウドに委ねる答えを示しました。コードを預ければ、実行環境の用意も スケーリング も障害からの回復も事業者側が行い、費用は実行した分だけ。インフラ管理という仕事そのものを外部化し、開発者の関心をコードだけに絞り込む——これがサーバレスの発明でした。

詳細

イベント駆動の実行フロー

サーバレスの関数は、何らかのイベントをきっかけ（トリガー）として起動します。代表的なのは HTTP リクエスト（API ゲートウェイ経由）、ストレージへのファイル追加、メッセージキュー への投入、スケジュール実行などです。リクエストが同時に千件来れば、プラットフォームは実行環境を千個並べて捌きます。開発者が台数を見積もる必要はなく、ゼロから大量まで自動で伸縮します。

コールドスタートという固有の代償

「使うときだけ起動する」ことの裏返しが、コールドスタートです。しばらく呼ばれていなかった関数への最初のリクエストでは、実行環境の準備（コンテナの起動、ランタイムの初期化、コードの読み込み）に数百ミリ秒〜数秒かかることがあります。一度温まった環境はしばらく再利用されるため以降は速いのですが、レイテンシに厳しい用途では無視できません。対策として、環境を事前に温めておく仕組み（Provisioned Concurrency など）や、コンテナ ではなく軽量な実行方式（V8 の isolate）を使い起動をミリ秒級に抑えた Cloudflare Workers のようなエッジ実行環境が存在します。

ステートレスという設計前提

サーバレスの関数は、実行のたびに環境が使い捨てられる可能性があるため、状態を持てません。メモリ上の変数もローカルファイルも、次の実行では消えている前提で書きます。セッション やデータは外部のデータベースやストレージに置くことになりますが、ここに古典的な罠があります。関数は千並列に膨らめるのに対し、接続数に上限のある RDBMS は同じ速度では膨らめず、接続枯渇で先に倒れるのです。接続プールを代理するプロキシや、HTTP ベースで接続の概念が薄い NoSQL・サーバレス型 DB を組み合わせるのが定石です。ほかにも、1回の実行時間に上限がある（Lambda は最大15分）ため長時間処理には向かない、といった制約もあります。

使いどころと使いにくいところ

サーバレスが輝くのは、負荷が間欠的・突発的な処理です。1日数回のバッチ、たまにしか呼ばれない社内 API、画像アップロード時のサムネイル生成、メッセージキュー のコンシューマ、Webhook の受け口——待機コストゼロと自動スケールの利点が最大化されます。逆に、負荷が常時高く安定しているサービスでは、常時稼働サーバのほうが安くつくことが多く、実行時間課金は「ずっと動いている」使い方と相性が悪いのです。またアーキテクチャが特定事業者のイベントモデルに深く結びつくため、他社への移行が難しくなるベンダーロックインも織り込むべきトレードオフです。

運用の景色の変化

サーバレスでは「サーバにログインして調べる」ことができないため、運用の頼りは ログ と 監視 の仕組みに集約されます。数百の小さな関数が連鎖する構成では、どこで何が失敗したかを追う分散トレーシングが重要になり、デプロイも CI/CD と IaC（構成をコードで管理する手法）で自動化するのが前提です。管理から解放される代わりに、観測とデプロイの規律が要求される——サーバレスは「楽になる」というより「悩む場所が変わる」モデルだと理解しておくと、期待とのずれが少なくなります。