サーバーレスの取り込み判断 — FaaSをどこに当て、何を従来の構築に残すか

サーバーレスを取り込む判断で多くの構築担当者が直面するのは、「どこまでFaaSに任せ、どこに従来の構築を残すか」という境界設計の問題です。技術的な優劣より先に、ワークロードの性質・ステート有無・コールドスタートへの耐性を整理することが、プロジェクト全体の安定につながります。本稿では、FaaS・コンテナ・VMそれぞれの責任範囲を比較しながら、設計判断の軸を具体的に提示します。

サーバーレスが解決できる問題と解決できない問題の整理

管理コストを削減できる処理の共通パターン

FaaSが最も力を発揮するのは、「起動頻度が不定期・実行時間が短い・ステートを持たない」という三条件が揃う処理です。画像のリサイズやWebhookの受け口、夜間バッチの一部切り出しといったワークロードが代表例です。こうした処理をVMで管理している現場では、デプロイ手順の整備・OSパッチ適用・スケーリング設定の維持に月あたり10〜20時間程度の運用工数がかかることがあります。FaaSへ移行すると実行コードと設定ファイルの管理に集中でき、インフラ維持の負担を大幅に削減できます。

ただし「インフラ管理がゼロになる」という理解は誤りです。FaaSへの移行後も、IAMポリシーの設計・ログ収集パイプラインの維持・デプロイパイプラインの管理といった作業は残ります。サーバーの管理が消えるだけで、クラウドリソースの管理は形を変えて継続します。この前提を見誤ると、移行後に想定外の運用コストが残り続けます。

サーバーレスが苦手とする処理特性

処理時間が長く、大容量メモリを必要とするワークロードはFaaSに向きません。多くのFaaSプラットフォームでは実行時間に上限（15分前後が多い）があり、機械学習モデルのトレーニングや大容量ファイルのストリーム処理はタイムアウトによって強制終了するリスクがあります。また、低レイテンシを必須とするユーザー向けAPIも、コールドスタートの問題から適合しにくいケースがあります。

常時接続を前提とするWebSocketサーバーや、プロセス間でメモリを共有するアーキテクチャも、FaaSの「リクエスト単位で起動・終了」という動作モデルと相性が悪いです。こうした処理は従来のコンテナやVMに留め、FaaSとの役割分担を先に明確にしておくことが設計の出発点になります。

境界設計が先、移行が後

サーバーレスへの移行が行き詰まる現場に共通するのは、「まずFaaSで作ってみる」という進め方です。境界を決めずに始めると、ステートをFaaSに持ち込もうとしたり、長時間バッチをタイムアウト内に収めようとして無理な分割が発生したりします。設計の出発点は「何をサーバーレスで解決するか」ではなく、「どの処理をどのレイヤーで管理するか」という全体像の整理です。この順序を守るだけで、後から発生する設計の手戻りを大きく減らせます。

FaaS・コンテナ・従来VMの責任範囲比較

項目	FaaS	コンテナ（オーケストレーター管理）	従来VM
OS管理	プラットフォーム側	一部構築担当（イメージ選択）	構築担当がフル管理
スケーリング	自動（上限設定のみ）	ポリシー設定で制御可能	手動またはAuto Scalingの設定
デプロイ粒度	関数単位	コンテナ単位	インスタンス単位
可観測性の難易度	高（エージェント不可）	中（エージェント設置可）	低（エージェント自由設置）
起動レイテンシ	コールドスタートあり	コンテナ起動時間あり	最小（常時稼働）
ベンダー依存度	高	中（OCI準拠で移行しやすい）	低〜中

管理責任の境界とトレードオフ

FaaSではOS・ランタイム・スケーリングがプラットフォーム側の管理下に入り、構築担当者はコードと設定ファイルだけを管理します。これは運用負担の軽減に直結しますが、同時にOSチューニング・カーネルパラメータ・ネットワークスタックへの直接介入ができなくなることを意味します。コンテナはOSの上位レイヤーから管理でき、VMは最もフルスタックな制御を持てますが、それぞれ管理対象の範囲が広がります。どのレイヤーを選ぶかは、「どこまで自分たちで制御したいか」という設計方針の問いに帰着します。

デプロイ・スケーリングの制御粒度

コンテナオーケストレーターを使う場合、スケーリングポリシーをCPU使用率・メモリ・カスタムメトリクスで細かく制御できます。対してFaaSのスケーリングはプラットフォーム側が自動的に行うため、急激なトラフィック増加時に同時実行数の上限に達してスロットリングが発生するケースがあります。下流のデータベースや外部APIへの接続数を考慮せずにFaaSをスケールさせると、接続枯渇によるシステム障害につながることがあります。この点はコンテナで丁寧にポッド数上限を管理するアプローチと大きく異なります。

可観測性の確保しやすさ

VMやコンテナでは、エージェント型の監視ツールをインストールしてメトリクスを収集するアプローチが取れます。FaaSでは実行環境への直接アクセスができないため、クラウドプロバイダーが提供するログ・トレースの仕組みに頼ることになります。分散トレーシングやカスタムメトリクスを実装しようとすると、SDKの組み込みやサンプリング設計など、FaaS固有の可観測性設計が別途必要になります。可観測性の要件が高い本番環境では、この点を設計段階で評価しておく必要があります。

コールドスタートを許容できるワークロードの見極め方

コールドスタートが発生する仕組みと影響範囲

FaaSのコールドスタートは、一定時間アイドル状態になった後に関数が呼び出されたとき、実行環境の初期化から行われる現象です。初期化にかかる時間はランタイムや初期化処理の重さによって異なりますが、JVMベースのランタイムでは数秒、軽量なNode.jsやPythonでも数百ミリ秒かかることがあります。ユーザー向けの同期APIでこれが発生すると、体感レスポンスの悪化に直結します。特にアクセスが散発的な時間帯を持つAPIでは、ピーク以外の時間帯にコールドスタートが集中しやすいです。

許容できる処理の判断軸

非同期処理・バッチ処理・Webhookの受け口など、レスポンス速度よりスループットを優先する処理では、コールドスタートの影響を許容しやすいです。「1リクエストあたり数秒の遅延が問題にならないか」という問いが判断の基準になります。メール通知のトリガー・定期集計・サードパーティへのデータ転送といった処理は、この条件を満たすことが多いです。一方、ECサイトの決済フローや、SLAで応答速度を保証しているAPIエンドポイントでは、コールドスタートがSLA違反の原因になります。こうした処理はFaaSではなくコンテナや常時起動のインスタンスに割り当てる判断が必要です。

プロビジョンドコンカレンシーという選択肢とその注意点

コールドスタートを抑制するために、プロバイダーが提供する「事前にインスタンスを温めておく」機能（プロビジョンドコンカレンシーや最小インスタンス数の設定）を使う選択肢もあります。ただし、この設定はインスタンスを常時稼働させることを意味するため、リクエスト従量の課金モデルから外れ、常駐コストが発生します。コールドスタート対策としてこの設定を入れるなら、「それならコンテナを常時稼働させるほうが管理しやすいのでは」という再評価も同時に行う必要があります。コールドスタート対策のためだけにFaaSの利点を相殺する構成になっていないか、立ち止まって確認することが重要です。

ステート管理をサーバーレス外に出す境界設計

FaaSがステートレスを前提とする理由

FaaSの実行モデルは「リクエストごとに独立したコンテキストで動作する」ことを前提としています。同一関数の複数インスタンスがそれぞれ独立して動くため、メモリ上のデータや一時ファイルは次のリクエストに引き継がれません。この設計はスケーリングの容易さを生む反面、ステートをFaaS内に持ち込もうとすると整合性の問題が発生します。インスタンスAで書いた一時データをインスタンスBが参照しようとする処理は、FaaSでは動作しないと考えるべきです。

ステートを外に出す設計パターン

セッション情報・ジョブの進捗・中間データといったステートは、FaaSの外側にある永続化ストアに置く設計が基本です。KVSを使ったセッション管理、メッセージキューを使った非同期ジョブの状態遷移、オブジェクトストレージへの中間ファイル保存がよく使われるパターンです。重要なのは、どのストアに何を持たせるかを設計段階で明示しておくことです。「とりあえずデータベースに入れる」という判断でDBへの接続数が増加し、後から接続プールの設計が必要になるケースは現場でよく見られます。

境界設計で責任範囲を明確化する

ステートを外に出す設計で問題になるのは、「どこまでをFaaSの責任範囲とし、どこからを外部ストアの責任範囲とするか」という境界の明確化です。これが曖昧なまま実装を進めると、FaaSの関数が外部ストアの更新・参照・エラーハンドリングを一手に担う肥大化した関数になりやすいです。責任の境界は、設計フェーズで図にして関係者と合意しておくことが、後の修正コストを下げる上で有効です。境界線を引く作業を実装フェーズに持ち込まないことが、設計の核心です。

ベンダーロックインの許容範囲をどこで設定するか

ロックインのレイヤー別評価

サーバーレスにおけるベンダーロックインは、APIの互換性・イベントトリガーの仕様・管理コンソールの操作方法という複数のレイヤーで発生します。最も移行コストが高いのは、プロバイダー固有のイベントソース（特定のメッセージングサービスやストレージイベント）と密結合した設計です。他プロバイダーやオンプレミスへの移行を検討したとき、イベントトリガー部分の書き直しが全体工数の50%以上を占めることもあります。ロックインのリスクは「どの機能をどの深さで使うか」によって大きく変わります。

抽象化レイヤーの設計判断

ロックインを抑制する手段として、クラウドに依存するコードをアダプター層に封じ込め、コアビジネスロジックを独立させる設計があります。ただし、抽象化レイヤーの維持コストとプロバイダー固有機能の活用度はトレードオフです。過度な抽象化はプロバイダーの利便性の高い機能を使えなくし、かえって開発コストを高めます。「どのレイヤーのロックインは許容し、どのレイヤーは封じ込めるか」を意識的に判断することが、設計の精度を上げます。

移行容易性の設計基準

将来の移行リスクを評価するために、「このプロバイダーが3年後にサービスを廃止・価格改定した場合のインパクト」を設計段階で見積もる習慣が有効です。利用する機能ごとにOSS代替があるか、インターフェースを標準化できるかを確認しておくと、ロックインの許容範囲を判断しやすくなります。完全なポータビリティを目指す必要はなく、「移行コストが工数2週間以内に収まる設計か」という基準を持つだけで、意思決定の質は上がります。

コスト構造の変化 — リクエスト従量とインスタンス常駐の判断基準比較

従量課金が有利になる条件

FaaSの従量課金モデルは、リクエスト数が少ない・トラフィックが不規則・アイドル時間が長いワークロードで有利です。月間リクエストが数十万件以下の処理では、同等の処理をVMで動かす場合と比べてコストが数分の一になるケースがあります。特に開発・ステージング環境など、稼働率が低い環境での運用コスト削減には大きな効果があります。本番環境の設計でも、アイドル時間帯が明確に存在するワークロードはFaaSの従量課金と相性が良いです。

インスタンス常駐が有利になる条件

月間リクエストが数千万件を超えるような高頻度・常時稼働のワークロードでは、FaaSの従量課金よりも予約インスタンスや常時稼働コンテナのほうがコスト面で有利になることがあります。また、コールドスタート対策でプロビジョンドコンカレンシーを使う場合は事実上の常駐コストが発生するため、コンテナとの比較を改めて行う必要があります。コスト判断は「現在のトラフィック量」だけでなく、1年後の想定トラフィックで評価することが重要です。

設計段階でのコスト比較アプローチ

コスト構造を判断するには、対象ワークロードの実行時間・メモリ使用量・月間呼び出し回数を試算し、FaaSとコンテナそれぞれで概算見積もりを出すことが必要です。ただし、インフラコストだけを比較するのは不十分です。FaaSに移行した場合の運用工数の削減・デプロイ速度の向上・開発者の認知負荷の変化も含めて総合的に判断することが、実態に即した設計判断につながります。コスト比較は「判断の材料」として使い、それだけで結論を出さない姿勢が重要です。

落とし穴 — タイムアウト・メモリ上限で詰まりやすい設計ミス

タイムアウト設計の失敗パターン

FaaSを導入して最初に行き詰まりやすい問題のひとつがタイムアウトです。外部APIの呼び出しやDBクエリを含む処理をFaaSで実行する際、通常はミリ秒で完了する処理がネットワーク遅延で数秒かかるケースが発生すると、設定したタイムアウト値に引っかかります。あるプロジェクトでは、サードパーティAPIへの呼び出しを含む処理でタイムアウトが頻発し、原因特定と設定変更に2〜3日を費やしたという話があります。この問題を防ぐには、関数ごとに想定される最長実行時間を設計段階で算出し、外部依存ごとのタイムアウト値を明示的に設定することが必要です。デフォルト値のまま本番に持ち込む設計は、後から行き詰まる原因になります。

メモリ・CPU制約の見落とし

FaaSのメモリ割り当ては実行速度にも影響します。多くのプラットフォームでは、割り当てメモリに比例してCPU性能がスケールする仕組みを採用しています。そのため、メモリを絞りすぎると処理速度が落ち、結果として実行時間が増加し、コストが上がるという逆効果が生じることがあります。画像処理や大容量JSONのパースといった処理で512MBと1024MBの割り当てを比較したとき、実行時間が半分になりコストが同等になったケースも報告されています。メモリ設定はコスト削減だけを目的に決めるのではなく、実行時間とのバランスで最適値を探ることが重要です。

サーバーレス導入前の設計確認チェックリスト

以下の項目を設計段階で確認することで、タイムアウト・ステート・コスト・ロックインに関わる主要な設計ミスを事前に防ぎやすくなります。手を動かすフェーズに入る前に、チームで一度通しておくことを推奨します。

• 対象ワークロードの最大実行時間を見積もり、プラットフォームのタイムアウト上限と比較したか
• 処理がステートレスで完結するか、またはステートをどの外部ストアに置くかを決定したか
• コールドスタートが発生した場合のレイテンシ影響を許容できるか評価したか
• 同時実行数の上限がDBや外部APIの接続数上限と整合しているか確認したか
• メモリ割り当てを実行時間とコストの両面で試算したか
• プロバイダー固有機能への依存レイヤーを特定し、ロックインの許容範囲を決定したか
• 月間リクエスト数の現在値と1年後の想定値をもとにコスト比較を行ったか
• 可観測性（ログ・トレース・アラート）の実装方針をFaaS環境向けに設計したか