サーバレスとは
サーバを「使わない」のではなく、サーバ運用（スケール・OS/ミドル管理・冗長化）をクラウドに委任する実行モデル。利用者はコードとアプリロジックに集中できます。
代表例
- AWS Lambda
- GCP Cloud Functions
- Azure Functions
- Cloudflare Workers
サーバレスが向いているケース
- 画像やテキストのアップロード／軽い前処理など、シンプルなデータ加工
- 初期費用と運用負担を抑えて、小さく始めたい新規サービスの立ち上げ
- 必要なスペックを事前に予測しづらい新規サービス
サーバレスが向いていないケース
- 長時間かけてデータ処理が必要な、複雑なプログラム
- 応答速度の要件が厳しく求められるケース
メリット
- 構築や保守、管理が必要ない
- 自動スケーリングができる
- 従量課金制によるコスト削減ができる
デメリット
- ベンダーロックインで移行が困難になる
- 環境や言語の制限がある
サーバレスの形態
| 形態 | 使いどころ | 弱み/注意 | 代表例 |
|---|---|---|---|
| FaaS | イベント駆動API/非同期処理/バッチ/Webhook | コールドスタートによる処理遅延/テストの難しさ/タイムアウト/依存肥大 | AWS Lambda, Cloud Functions, Azure Functions |
| Edge Functions | リダイレクト/認証前段/AB/軽量API/部分SSR | 重処理・長時間・強い一貫性は不向き | Cloudflare Workers, Vercel Edge Functions |
| サーバーレスコンテナ | 常時稼働寄り/長めの処理に対応/ネイティブ依存がしやすい | アイドル状態でも課金/コールドスタートによる処理遅延 | Cloud Run, Fargate |
| BaaS | 開発スピード短縮/運用コスト削減 | 拡張の限界 | Firebase, Supabase |
| サーバーレスDB/ストレージ/キュー | スケールするデータ層/疎結合化 | モデル差/接続枯渇/整合性設計 | DynamoDB/Firestore/Neon/PlanetScale、S3、SQS 等 |
| ワークフロー/ジョブ | 失敗再試行/分岐/オーケストレーション | 複雑化しすぎないように注意 | Step Functions, Cloud Workflows |
典型アーキテクチャ例
FaaS
- API Gateway + Lambda + DynamoDB
BaaS
- Firebase：Authentication + Firestore + Cloud Storage + Cloud Functions + Hosting
- Supabase：Auth + Postgres + Storage + Realtime + Edge Functions
- Amplify：Cognito + AppSync(GraphQL) + DynamoDB + S3 + Lambda(拡張) + Amplify Hosting
アンチパターン
- 高頻度・常時実行処理：サーバレスよりEC2/ECS/K8sの方が安い
- 長時間バッチ：制限に引っかかる → 分割処理 or コンテナ常駐へ
- 巨大依存ライブラリ：コールドスタート悪化。軽量化やコンテナ化を検討
- ステートフル処理：FaaSは不向き、別の仕組みで補う必要あり
運用（監視・CI/CD・IaC）
- 監視・ロギング：CloudWatch, Cloud Logging, Datadog, OpenTelemetry
- CI/CD：GitHub Actions, GitLab CI, Vercel/Netlify の自動デプロイ
- IaC（Infrastructure as Code）：Terraform, AWS CDK, Pulumi で構成管理
- テスト：ローカルエミュレーションツール（SAM CLI, LocalStack, Miniflare など）
まとめ
サーバレスはサーバ運用をクラウドに任せ、開発者がアプリロジックに集中できる実行モデルであり、適材適所で使うことでコスト・運用負担を大幅に削減できます。