サーバーレスは「インフラ運用からの解放」という謳い文句で注目されています。しかし設計を誤れば、レイテンシ悪化やコスト爆発という落とし穴が待ち受けています。
この記事では主要なアンチパターン10個を AWS 公式ドキュメントの最新版に沿って整理し、読者が同じ轍を踏まないよう設計ガイドラインを提示します。
サーバーレスの長所と短所を俯瞰する
メリットは〈自動スケーリング〉〈従量課金〉〈運用軽減〉の三拍子ですが、デメリットとして〈コールドスタート〉〈分散モノリス〉〈監視難〉が表裏一体で存在します。弱点ごとに適切な手当てを施せば、サーバーレスは確かな資産になります。
サーバーレス設計で避けたいアンチパターン10選
1. コールドスタート無対策
Lambda では初回呼び出し時に実行環境を起動するコールドスタートが発生します。AWS 公開データによると発生率は総呼び出しの 1 % 未満ですが、レイテンシに敏感なサービスでは無視できません。
主な緩和策は 4 つです。
- Provisioned Concurrency：常時ウォーム状態で待機させる方法。起動遅延を最小化できますが固定費が増えます。
- SnapStart（JDK 11/17 限定）：初期化済みスナップショットから高速起動。ただし Layer と合わせた合計サイズは 250 MB 上限を共有する点に注意。
- ウォームアップスケジューラ：CloudWatch Events などで定期呼び出しし、業務時間帯のみ温める可変コスト型。
- Lambda@Edge／CloudFront Functions：CDN 近接でミリ秒応答を実現。Provisioned Concurrency 非対応で「ゼロ」にはならない点を明記。
2. 分散モノリス
関数どうしを REST API 多段連鎖で結合すると、巨大モノリスと同等の結合度を持つ “分散モノリス” になります。対策は イベント駆動＋Amazon EventBridge で疎結合にし、Schema Registry でイベントスキーマを管理すること。例えば「後方互換」「破壊的変更」のルールを事前に定義し、破壊的変更はバージョン分離すると運用が安定します。
3. オーバーサイズ関数
デプロイパッケージは 250 MB（解凍時）／50 MB（ZIP）を超えるとデプロイ不可。回避策として 10 GB コンテナイメージ または EFS マウント がありますが、EFS は I/O レイテンシが高めで「大型 ML モデル」など読み込み専用アセット向けと割り切るのが安全です。基本は単一責務に分割するのが王道です。
4. 過剰な同期 I/O（チャッティネス）
外部サービスを直列で呼ぶと待機時間＝課金時間となりコストが膨張します。非同期化・並列化に加え、AWS SDK v3 では HTTP/2 のコネクション再利用でレイテンシが 10–40 % 程度低減するケースがあります（ワークロード依存）。
5. ステートフル関数
メモリ変数に状態を残すとインスタンス再利用時に不整合リスクが生じます。ただし Secrets Manager 資格情報の数秒キャッシュ などはコスト効率を高めます。VPC 接続時の ENI 作成遅延は 2019 年に大幅改善され最大 100 ms 級まで短縮されましたが、スパイク時には再び増えるのでモニタリングが重要です。
6. メモリ過剰割り当て
メモリを増やすと CPU も比例して増えますが、「1 MB×100 ms 単価」を基準にベンチマークし最小コスト点を探るのが公式推奨です。1,769 MB が 1 vCPU 相当でバランスが良いとされます。
| メモリ | 1 回実行料金 (100 ms) | 想定実行時間 | 1 回総コスト |
|---|---|---|---|
| 128 MB | 約 0.0000000021 USD | 700 ms | 0.0000000147 USD |
| 1,024 MB | 約 0.0000000168 USD | 120 ms | 0.0000000202 USD |
※同じ処理であっても最適解はワークロードごとに異なります。
7. 共有ライブラリ肥大化
共有ライブラリを Layers で配布するとパッケージサイズを削減できますが、初期化コストが増える可能性があります。Go／Rust の単一バイナリ はレイヤー不要で高速ですが、WebAssembly（WASI） はまだ実験的機能で本番利用は慎重に検討しましょう。
8. 観測性欠如
2025 年時点で Lambda は OpenTelemetry SDK を公式サポートし、CloudWatch ServiceLens と連携できます。AWS X‑Ray も選択肢ですが、二重計装はコストが跳ね上がるためどちらか一方を推奨します。
9. ベンダーロックイン軽視
Step Functions Standard Workflows などに深く依存すると移行コストが膨らみます。ポータビリティを保つには半年～1 年に 1 度、“最低限機能”を異クラウドで CI/CD パイプライン実行し、実際に動くか検証するのが現実的です。
10. 制限無視の無限同時実行
Lambda の初期アカウント上限は 1,000 同時実行。2024 年末のアップデートで各関数が 10 秒あたり 1,000 concurrency まで独立してスケールするようになりましたが、バースト値は min(1,000, accountLimit) で決まります。SQS キューで緩衝し、下流システムの耐用負荷を超えない設計が安全策です。
コールドスタート対策の比較表
| 対策 | メリット | デメリット | 適用シーン |
|---|---|---|---|
| Provisioned Concurrency | レイテンシ安定 | 固定費増 | 24h API |
| SnapStart | 初期化高速 | JDK11/17 限定 | JVM ベース |
| ウォームアップ | 導入容易 | 間欠アクセスに不向き | 朝夕ピーク |
| Lambda@Edge | リージョンより短 CS | PC 非対応 | 低レイテンシ API |
| CloudFront Functions | ミリ秒応答 | 実行制限厳しい | 超軽量ロジック |
まとめ：小さく作り、観測し、素早く修正する
サーバーレスを成功させる鍵は“変化を前提にした設計”です。今日紹介したアンチパターンを避け、小さく試し、メトリクスを観測しながら継続的に改善しましょう。コールドスタートや分散モノリスの罠から解放され、俊敏な開発とコスト最適化を両立できます。
Terraform vs Pulumi vs AWS CDK：Infrastructure as Code最新比較と使い分け
