「サーバーレス（Serverless）」は、インフラ管理から解放され、使った分だけ課金される非常に魅力的な選択肢です。 しかし、実際に導入してみると、インフラ管理の手間が減った代わりに、アプリケーション設計における特有の制約や複雑さと向き合う必要が出てきます。

サーバーレスが「全員のための正解」にならないのはなぜか、その理由となる主要な制約と、それを踏まえた向き不向きについて整理しました。

サーバーレスの主な制約

サーバーレス（特に FaaS）を採用する上で、避けては通れない現実的な制約がいくつかあります。

1. 実行モデルの制約

サーバーレスは「短時間・イベント駆動」が前提のモデルです。

  • 実行時間の制限: AWS Lambda のように、最大 15 分といった上限があります。これを超えるような重い処理には向いていません。
  • 常駐プロセスの不可: 処理が終わればインスタンスは破棄されるため、バックグラウンドで常に動かし続けるようなプロセスは持てません。
  • ステートレス前提: ローカルのメモリやディスクの内容はリクエストを跨いで保持されません。状態はすべて外部のデータベースやストレージに持たせる必要があります。

2. コールドスタート問題

一定期間呼ばれていなかった関数が実行される際、環境の初期化が走ることでレスポンスが遅れる現象です。 Java や .NET のような起動の重い言語や、VPC 内に配置する場合などに顕著になりやすく、低レイテンシが求められる API ではユーザー体験に影響を与える可能性があります。

3. デバッグ・観測性の難しさ

システムが複数の小さな関数に分散されるため、従来のモノリスな構成に比べてトラブルシューティングが難しくなります。

  • ローカル環境での完全な再現が困難。
  • 複数の関数を跨ぐ処理のトレースが複雑。
  • 全体像を把握するために、専用の観測ツール（CloudWatch Logs, X-Ray, Datadog など）を使いこなすスキルが不可欠になります。

4. ベンダーロックイン

サーバーレスはクラウドベンダーが提供する各種サービス（DB、ストレージ、トリガー）と密接に連携します。 そのため、後から他社クラウドやオンプレミスへ移行しようとしても、アーキテクチャ全体を書き直す必要が出てくるなど、移行コストが非常に高くなります。

5. コスト予測の難しさ

「使わない時は 0 円」というメリットがある反面、アクセスが急増した際にコストがどこまで膨らむか予測しにくい面があります。 また、24 時間 365 日ずっと高い負荷がかかり続けるような処理では、固定のインスタンスを借りるよりも割高になるケースが多いです。

6. アーキテクチャの複雑化

インフラ管理が不要になった分、その責任はアプリケーション設計へと移動します。

  • リトライと冪等性: 失敗時のリトライ方針や、2 回実行されても問題ない設計。
  • 分散トランザクション: 複数の関数に跨る処理で、一部が失敗した時の整合性確保。

これらをすべてコードレベルで解決する必要があり、チームの設計スキルがダイレクトに生産性に影響します。

向き不向きの判断基準

サーバーレスが向いているケース

  • 予測困難なスパイクがある処理: 急なアクセス増に自動でスケーリングさせたい場合。
  • 間欠的な処理: 1 日に数回しか走らないバッチや、Webhooks の受け口。
  • イベント駆動のパイプライン: ファイルがアップロードされたら変換処理を走らせる、といったトリガーベースの処理。

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

  • 長時間実行が必要な処理: 動画変換や巨大なデータの解析バッチ。
  • WebSocket などの長時間接続: 常に接続を維持し続ける必要があるリアルタイム通信。
  • 極めて低いレイテンシが常時求められる API: コールドスタートを許容できないシステム。
  • 常時高負荷なシステム: 常にリクエストが来続けるなら、固定インスタンスの方がコスト効率が良い。

まとめ

サーバーレスは魔法の杖ではなく、**「インフラ管理をクラウドベンダーに委ねる代わりに、アプリケーション設計の厳密さを引き受ける」**という選択です。

導入を検討する際は、運用負荷の軽減というメリットだけでなく、分散システム特有の複雑さをチームが許容できるか、という視点で判断することが重要です。