Serverless
概要
サーバーレスとは、個々の関数を書き、クラウドプロバイダーが何かのトリガー(HTTPリクエスト、ファイルのアップロード、スケジュールされたタイマーなど)が発生したときだけそれを実行する方式です。裏側には依然としてサーバーがありますが、それを目にすることも管理することもありません。コードが実際に実行された時間分だけ、しばしばミリ秒単位で課金されます。
強み
- プロビジョニング、パッチ適用、稼働維持すべきサーバーがない。
- ゼロから数千の同時実行まで自動でスケールする。
- 従量課金制で、アイドル状態のコードにはコストがかからない。
- クラウドイベント(キュー、ストレージ、データベース)ときれいに連携する。
- バースト的または予測しにくいトラフィックに向いている。
トレードオフ
- コールドスタート:最近実行されていない関数は、起動に余分な時間がかかることがある。
- 実行時間の制限(多くは数分)があり、長時間のジョブは除外される。
- 非常に高く安定した量では、素のサーバーと比べてコストが予想を超えることがある。
- ローカルでのテストとデバッグが、通常のアプリよりも厄介。
- ベンダーロックイン — 各プロバイダーのイベントモデルやAPIが異なる。
使いどころ
トラフィックが不均一で、インフラの面倒を見たくないAPI、Webhook、スケジュールジョブ、イベント駆動のタスクにはサーバーレスを選びましょう。クラウドサービス間のつなぎ込みコードで真価を発揮します。
バイブコーディングとの相性
サーバーレスは、作業の単位が単一の自己完結した関数であるため、AI主導の開発と相性が良いです。エージェントが生成、テスト、デプロイしやすいのです。AWS SAM、Serverless Framework、Vercelのようなフレームワークを使えば、AIは関数、そのトリガー、権限を1つの設定ファイルで定義できます。コツ:エージェントには妥当なタイムアウトとメモリサイズを明示的に設定させ、依存関係を最小限に保たせましょう。パッケージが少ないほどバンドルが小さくなり、コールドスタートが速くなります。
# serverless.yml — AWS Lambda 関数
service: my-api
provider:
name: aws
runtime: nodejs20.x
timeout: 10
functions:
hello:
handler: handler.hello
events:
- httpApi:
path: /hello
method: get
# スタックをデプロイする
npx serverless deploy