サーバーレス

サーバーレスとは

サーバーレス (Serverless) は、サーバーのプロビジョニング、スケーリング、パッチ適用、可用性管理をクラウドプロバイダーに完全に委ね、開発者はビジネスロジックの実装に集中できるコンピューティングモデルである。「サーバーがない」のではなく「サーバーを意識しない」という意味だ。

AWS Lambda が代表的なサーバーレスコンピューティングサービスであり、2014 年の発表以降、サーバーレスアーキテクチャの普及を牽引してきた。

「サーバーレスかどうか」を実務で見分ける軸は 3 つある。①待機している時間に課金されないか ②需要に応じた台数の増減を自分で設計しなくてよいか ③OS やミドルウェアの更新が運用の対象から外れているか。この 3 つは製品名では決まらない。名前に Serverless を冠していても、最小容量を確保する設定にすれば待機中の課金は発生する。採用を判断するときは、課金の単位と最小容量の設定値を製品ごとに確かめる。

サーバーレスは 2 つの層に分かれる。自分で書いたコードを実行させる FaaS (Function as a Service) と、認証やデータベースのように機能そのものを利用する BaaS (Backend as a Service) である。Lambda は FaaS、Cognito や DynamoDB は BaaS に当たる。委譲する範囲が違うため、設計を縛るものも変わる。FaaS では実行時間やパッケージサイズといった実行環境の制約が上限になり、BaaS ではサービスが提供する機能の範囲そのものが上限になる。後者は「あと少し違う挙動が欲しい」ときに逃げ道がない。

サーバーレスの特性

• 自動スケーリング: リクエスト数に応じて実行環境が自動的に増減する。台数の設計は不要だが、アカウントとリージョンごとに同時実行数の上限があり、そこに達した呼び出しは絞られる
• 従量課金: 実行時間とリクエスト数に対してのみ課金される。アイドル時のコストはゼロ
• 運用負荷の軽減: OS のパッチ適用、サーバーの監視、キャパシティプランニングが不要
• イベント駆動: HTTP リクエスト、キューメッセージ、スケジュール、ファイルアップロードなど、様々なイベントをトリガーに実行される

サーバーレスの構成要素

サーバーレスは Lambda だけではない。以下のサービスを組み合わせてアーキテクチャを構成する。

• コンピュート: Lambda, Fargate
• API: API Gateway (REST / HTTP API)
• データベース: DynamoDB (オンデマンド), Aurora Serverless
• ストレージ: S3
• メッセージング: SQS, SNS, EventBridge
• オーケストレーション: Step Functions
• 認証: Cognito

EC2 との比較

違いの本質は、課金の起点とスケールの粒度にある。EC2 は起動している時間に対して払い、サーバーレスは処理した分に対して払う。稼働率が低いワークロードほど差が開き、逆に常時埋まっているワークロードでは差が消える。

観点	サーバーレス (Lambda)	EC2
課金	実行時間 × メモリ	起動時間 (アイドル含む)
スケーリング	自動 (ミリ秒単位)	Auto Scaling (分単位)
最大実行時間	15 分	無制限
コールドスタート	あり (数百ミリ秒〜数秒)	なし (常時起動)
運用負荷	低い	高い (OS 管理が必要)

実務での適用判断

サーバーレスが適するケース:

• リクエスト数の変動が大きいワークロード (夜間はほぼゼロ、日中にスパイク)
• イベント駆動の処理 (ファイルアップロード時の変換、キューメッセージの処理)
• 小規模チームで運用負荷を最小化したい場合

サーバーレスが不向きなケース:

• 15 分を超える長時間処理
• 常時高負荷で、アイドル時間がほとんどないワークロード (EC2 の方がコスト効率が良い)
• コールドスタートが許容できない低レイテンシ要件

コールドスタート対策

コールドスタートは「初回だけ遅い」現象ではない。呼び出しが届いたときに再利用できる実行環境が無ければ、Lambda はそのつど新しい環境を用意する。この初期化では、拡張の起動、ランタイムの起動、ハンドラーの外に書いた静的コードの実行という 3 段が順に走り、その所要時間が応答時間にそのまま乗る (2026 年 8 月時点の公式ドキュメントでは、この初期化フェーズに 10 秒の制限がある)。同時に届くリクエストが増えて既存の環境が全て埋まれば、そのたびに新しい環境が作られるため、稼働し続けているサービスでも一定の割合で発生する。

対策は 3 方向に分かれる。①初期化を軽くする (依存の削減、静的コードで重い初期化をしない) ②環境を事前に確保しておく Provisioned Concurrency ③初期化済みのスナップショットから復元する SnapStart。②は確保した分が常時課金されるため「待機中の課金はゼロ」という前提が崩れる。③は 2026 年 8 月時点で Java 11 以降・Python 3.12 以降・.NET 8 以降のマネージドランタイムに限られ、コンテナイメージや他のランタイムでは使えず、Provisioned Concurrency との併用もできない。設定値の詳細は Lambda を参照。

同じイベントが 2 回届く前提

イベント駆動でつなぐと、同じイベントが 2 回届くことを前提にした設計が要求される。非同期の呼び出しは失敗時に自動で再試行され、キューやストリーム経由の配信も「少なくとも 1 回」が基本になる。決済や在庫の更新をそのまま書けば、再送は二重処理になる。

防ぎ方は、イベントに含まれる一意な識別子を鍵にして処理済みかどうかを記録し、2 回目以降は処理を飛ばして同じ結果を返す形にすることだ。ここで注意が要るのは記録先である。関数の実行環境は使い回されることも捨てられることもあるため、変数やローカルディスクに置いた「処理済み」の印は当てにできない。DynamoDB のような外部の永続層に置く必要がある (イベント駆動アーキテクチャ・ステートレス)。

SAM でのサーバーレス API

SAM (Serverless Application Model) は、ここまでの構成要素の組み合わせを 1 つのテンプレートで宣言するための CloudFormation の拡張である。以下は HTTP API 経由で関数を呼び、その関数に DynamoDB テーブルへの操作権限だけを与える最小の記述になる。

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Runtime: nodejs22.x
    Handler: index.handler
    Events:
      Api:
        Type: HttpApi
        Properties:
          Path: /hello
          Method: GET
    Policies:
      - DynamoDBCrudPolicy:
          TableName: !Ref Table

export const handler = async (event: APIGatewayProxyEventV2) => {
  return { statusCode: 200, body: JSON.stringify({ message: 'Hello' }) };
};

テンプレートで注目すべきは Policies の指定である。実行ロールを自分で組み立てる代わりに、テーブル名を渡して必要な権限だけを生成させている。サーバーレスでは関数の数がそのまま権限の数になるため、広い権限を 1 つ作って全関数で共有すると、どの関数が何に触れるのかが最初に分からなくなる。関数ごとに必要な範囲だけを宣言する書き方を崩さないことが、規模が増えたときの唯一の防波堤になる。