サーバーレスアーキテクチャ

# サーバーレスアーキテクチャ ## 定義 **サーバーレスコンピューティング = FaaS + BaaS**（[[@2018__CNCF WG Serverless__Serverless Overview Whitepaper v1.0]]; Berkeley View on Serverless Computing, 2019）。「利用課金かつ自動スケーリング」が必須条件（Berkeley View）。本質は「**サーバという単位を意識しない**」こと（[[Yuuki Tsubouchi]] による定義の敷衍）。 **CNCF 公式定義**（[[@2018__CNCF WG Serverless__Serverless Overview Whitepaper v1.0]]）: サーバーが消えるわけではなく、消費者が「プロビジョニング・保守・更新・スケーリング・キャパシティ計画」に時間とリソースを費やす必要がなくなるという概念的位置づけ。二大メリットは「ゼロサーバーオプス」と「アイドル時課金なし」。 **サーバーの二義性と対応関係**: - **マシンサーバー**（物理・仮想マシン）を意識しなくさせるのが **BaaS**。アプリケーション指標（クエリ数・データ量）でキャパシティ計画が可能になり、インスタンス台数・スペックが隠蔽される - **ネットワークサーバー**（常時起動プロセス）を意識しなくさせるのが **FaaS**。イベント駆動でプロセスを起動し、Graceful Restart・事前キャパシティ計画・メモリリーク管理を不要にする **代表的 FaaS**: AWS Lambda（2014 年登場）、Knative（OSS）、OpenFaaS（OSS）。 **代表的 BaaS**: Amazon DynamoDB・Google BigQuery（データストア）、SendGrid（メール）、Auth0（認証）。 ## ピタゴラスイッチ構成 FaaS が「糊」として複数 BaaS をつなぐアーキテクチャパターン。BaaS 上で発生するイベントを Function への入力とし、Function 内で別 BaaS の API を呼び出し、さらに別 Function を起動する連鎖（Rube Goldberg machine 的な構成）。クラウドプロバイダー固有の FaaS-BaaS 連携に依存するため、ベンダー非依存での実現には CloudEvents 等のイベント標準化が必要。 ## サーバーフルコンピューティング（対概念）サーバー上でのソフトウェア動作を意識してプログラミング・デプロイすること（Berkeley View での用語定義）。マシンサーバーのキャパシティ見積もり・ネットワークサーバーの Graceful Restart・メモリリーク管理などが開発者の負担となる。 ## 横断的知見 - [[Yuuki Tsubouchi]] の HeteroTSDB（サーバーレス時系列データベース）は「ピタゴラスイッチ構成」の具体例であり、DynamoDB TTL イベント → Lambda → S3 という BaaS-FaaS 連携を実装している。(Source: [[@2019__yuuk.io__Rethinking-Serverless-Architecture]]) - CGI との比較: FaaS は「イベントを契機にプロセス起動」の点では CGI と似るが、BaaS の性質を持たない・HTTP 以外のイベントを扱えない・スケールが Web サーバーホスト単位になる点で根本的に異なる。(Source: [[@2019__yuuk.io__Rethinking-Serverless-Architecture]]) - 2019 年時点では Function のメモリサイズ指定が必要であり、マシンサーバーを完全には隠蔽できていない（著者による制約の指摘）。(Source: [[@2019__yuuk.io__Rethinking-Serverless-Architecture]]) - **VM → コンテナ → サーバーレス/unikernel の軽量化トレンドはコンテナ研究側からも 2017 年に予兆されていた**: Pahl ら(IEEE TCC 2019)は §6 Conclusions で「containers represent a progression from virtual machines towards lightweight application management. Lately, there is an observable continuing trend towards serverless architectures and other mechanisms to manage orchestration and deployment complexity such as unikernel technology towards more lightweightness」と明示し、サーバーレスを「コンテナ後の軽量化系譜」に位置付けた。これは [[Yuuki Tsubouchi]] の「FaaS + BaaS = サーバーレス」定義(2019)と同時期の独立した観察であり、コンテナオーケストレーションの研究者・実務者が「軽量化軸」を共通言語として認識していたことを示す。(Source: [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]], [[@2019__yuuk.io__Rethinking-Serverless-Architecture]]) - **CNCF 公式定義と Yuuki Tsubouchi 解釈は視点が異なる補完的な説明**: CNCF 白書（2018）は「消費者がサーバー管理作業を行わなくてよい」という**外部・運用視点**、Yuuki Tsubouchi の解釈は「マシンサーバー(BaaS が隠蔽)とネットワークサーバー(FaaS が隠蔽)という 2 種類のサーバーを意識しなくなる」という**内部・アーキテクチャ視点**。どちらも同じ現象を説明する相互補完的な視点であり、矛盾しない。(Source: [[@2018__CNCF WG Serverless__Serverless Overview Whitepaper v1.0]], [[@2019__yuuk.io__Rethinking-Serverless-Architecture]]) - **CaaS/PaaS/Serverless の 3 択の中心的評価軸は「制御粒度・運用負荷・課金粒度」**: CNCF 白書(2018)が体系化した比較表では、制御粒度(CaaS=最大、PaaS=中、Serverless=最小)・インフラ管理責任の移管先・課金単位(確保時間 vs ms 単位の実行時間)の 3 軸が選択の主決定要因となり、CaaS の高い管理コストと Serverless のコールドスタートがそれぞれのトレードオフとして対置される。(Source: [[@2018__CNCF WG Serverless__Serverless Overview Whitepaper v1.0]]) - **「サーバーレス」という用語の起源と FaaS の登場は時期が異なる**: 用語自体は 2012 年の IronWorker(Iron.io)が普及の起点だが、FaaS の実用化はその 2 年後の 2014 年 AWS Lambda 登場まで待つ必要があった。つまり「サーバーレス」という概念への期待が先行し、技術的実装が追いついた。(Source: [[@2018__CNCF WG Serverless__Serverless Overview Whitepaper v1.0]]) - **「サーバーの意識からの解放」という定義上の恩恵は、コスト会計の実務では単価の高さという裏面を持つ**: CNCF 白書(2018)は「消費者がプロビジョニング・保守・更新・スケーリング・キャパシティ計画に時間を費やさなくてよい」という運用負荷ゼロの利点を強調するが、`Observability Engineering` 第2版第20章はコンピュート調達を資本的支出・リザーブド容量・永続的定義容量・中断可能定義容量・永続的弾力容量(FaaSより持続的)・中断可能柔軟容量(FaaS)の6モデルに整理し、FaaSは「完全な利用効率(実行中のみ課金)と引き換えにCPU秒あたりの単価が高い」というトレードオフを明示する。CNCF が運用者視点で語る「ゼロサーバーオプス」は、コスト最適化の現場では「単価の高さをどう正当化するか」という別の意思決定問題に置き換わる。(Source: [[@2018__CNCF WG Serverless__Serverless Overview Whitepaper v1.0]], [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]]) - **FaaS のコールドスタートは、2018年時点では「主要課題」とだけ記述されていたが、2026年時点では計装によって定量化・削減する具体的な実務手法が確立している**: CNCF 白書(2018)はコールドスタートを課題として列挙するにとどまるが、`Observability Engineering` 第2版第20章は、メイン関数開始時点でスパンを作り初期化完了時点で終端する計装パターンと、呼び出しごとの「running」「sleeping」スパンによって初期化コストを可視化し、Lambda Power Tuner のようなツールでCPU×実行時間のコスト関数を最小化する具体的な手順を示す。プロビジョンドコンカレンシーは「手動キャパシティ計画が必要な上に有意な割引もなく、初期化コストを長期間で償却する永続アプリケーションの利点も得られない」ため、コールドスタート対策として推奨されない。(Source: [[@2018__CNCF WG Serverless__Serverless Overview Whitepaper v1.0]], [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]]) - **サーバーレス関数の短命性は RCA に根本的な困難をもたらす**: Microsoft Azure 本番トレース(4億4500万件、14日間)では関数実行時間の中央値が 600ms であり、Serverless TrainTicket でも 90.78% が 0〜6 秒以内。この短命性のために関数はパルス状の非連続テレメトリを生成し、長期連続データを前提とする系列ベース RCA 手法(Eadro 等)が直接適用できない。[[FaaSRCA]] は GAT ベースのグラフオートエンコーダを用いてスカラー値の瞬時データから根本原因を特定することでこの問題を回避する。(Source: [[@2024__arXiv__FaaSRCA - Full Lifecycle Root Cause Analysis for Serverless Applications]] §II-A, §III-A) - **LLM エージェントのツール呼び出し連鎖は、サーバーレスの「オンデマンド起動」原則そのものとは相性が悪いが、ワークフローステージ単位の分解によりモジュール化デプロイへ落とし込める**: 本 concept の未解決の問いは「サーバーレスアーキテクチャとエージェント型 AI システムの関係」を長らく開いたままにしていたが、[[@2026__Unknown__Agentic Workflows are Serverless Applications, so deploy them that way!]] はこれに直接取り組む position paper である。エージェントは (1) 長時間・非決定的な実行時間、(2) ツール実行等のステートフルな動作という2点でサーバーレスの前提(断続的リクエスト到着・パッケージ化されたオンデマンド起動)に反するが、著者らはエージェントワークフローを Control Flow Graph としてモデル化し、LLM 推論呼び出し・ツール呼び出しという既存のステージ単位に分解して個別に Function インスタンス化する「モジュール化デプロイ」を提案する。単一パッケージの monolithic deployment ではオーケストレータもツールサンドボックスも一括でロード・スケーリングされるのに対し、モジュール化デプロイではオーケストレータだけを keep-alive させツール環境を並行ロードすることでコールドスタート影響を圧縮できるとする。(Source: [[@2026__Unknown__Agentic Workflows are Serverless Applications, so deploy them that way!]] §1, §4.1) - **3種のエージェントアーキタイプ(単線パイプライン・反復ループ・scatter-gather マルチエージェント)の実測トレースは、いずれも GPU VRAM が推論非実行中も解放されないまま残るという共通の非効率を示した**: これは §72-73 で述べた「FaaS のコールドスタート対策(計装によるコスト可視化)」の知見が GPU 資源には及んでいないことを示す新しい観察であり、エージェントワークフロー特有の「明確なステージ境界とアイドル期間」がサーバーレスの資源効率化にとって好都合な性質であることを裏付ける。(Source: [[@2026__Unknown__Agentic Workflows are Serverless Applications, so deploy them that way!]] §3) - **CNCF 白書(2018)が課題として列挙するだけだった「コールドスタート」と「GPU オートスケーリングの困難性」は、2020年時点の代表的な機械学習推論サーバーレス基盤(KFServing)の本番運用ですでに具体的な障壁として現れていた**: [[@2018__CNCF WG Serverless__Serverless Overview Whitepaper v1.0]] は FaaS のコールドスタートを一般論として課題に挙げるが、[[Knative]] を基盤とする [[KFServing]] の本番運用報告([[@2020__arXiv__Serverless inferencing on Kubernetes]])は、5〜30GB 級のモデルアーティファクトのダウンロード時間がスケールツーゼロからの起動レイテンシを許容できないほど大きくし、低レイテンシ要件とサーバーレスの利点がトレードオフになる具体例を示した。さらに GPU duty cycle メトリクスが取得困難で CPU/GPU 指標の統合も難しいため、Knative Pod Autoscaler(KPA)のリクエストベース(同時実行数ベース)オートスケーリングという、GPU/CPU メトリクスに依存しない汎用解へ回避したと報告する。これは、LLM 時代に [[LLMサービング管理]] が扱う「コールドスタートが反応的オートスケーリングを無効化する」という課題(PreServe・FaaScale)が、LLM 以前の一般的な機械学習モデルサービングの時点(2020年)ですでに同型の構造で観測されていたことを示す。(Source: [[@2018__CNCF WG Serverless__Serverless Overview Whitepaper v1.0]], [[@2020__arXiv__Serverless inferencing on Kubernetes]]) - **「数百〜数千個の小規模モデルを個別サーバーなしで多重化する」という課題は、2020年のKFServingの時点ですでに未解決課題として明示されていた**: [[@2020__arXiv__Serverless inferencing on Kubernetes]] §6 は、異なるデータ部分集合で学習された多数の小規模モデルに対して個別のモデルサーバーを立てるのは実用的でなく、透過的な共有・スケジューリング・シャーディングの仕組みが必要だと述べる。これは、のちの multi-model serving・LLM マルチテナンシー研究(§58 の BOute 等が扱う「モデル・GPU 配置の協調最適化」)が取り組む課題設定を、LLM 以前の時点で先取りしていたことを示す。(Source: [[@2020__arXiv__Serverless inferencing on Kubernetes]] §6) ## 拡張型ソフトウェアとの接続 [[Jeremy Morrell]] のウェブ拡張論は、FaaS をユーザーが作成・共有する拡張コードの実行境界として再解釈する。従来の FaaS + BaaS が Function をサービス間の糊として使うのに対し、ウェブ拡張型ソフトウェアはイベント、UI、データ取り込み、スケジュールをユーザー固有のコードへ開く。ただし、サーバーレスが隠蔽するインフラ管理を、拡張の作者・権限・監査・失敗処理の設計へ置き換えるため、運用負荷が消えるのではなく責任境界が変わる。(Source: [[@2019__yuuk.io__Rethinking-Serverless-Architecture]], [[@2026__jeremymorrell.dev__Extensible Software in the age of LLMs]]) ## 制約 **同期リクエストのメモリ効率問題**: リクエストを 1 件ずつ別 Function で処理する場合、I/O ブロッキング中にメモリは占有したまま CPU のみ解放される → メモリ使用効率が悪くコスト増。非同期可能なケースではキューを経由して複数イベントを並行処理できる。 ## 未解決の問い - Dynamic Workers のような動的コード実行基盤で、FaaS のコールドスタート・課金粒度と、ユーザー拡張の監査・ロールバック・データ分離をどう同時に満たすか。 - ベンダー非依存のピタゴラスイッチ構成（FaaS + BaaS + CloudEvents）は 2019 年以降どこまで進んだか？ - サーバーレスアーキテクチャとエージェント型 AI システム（LLM エージェント）の関係はどうか？LLM エージェントの「ツール呼び出し」はピタゴラスイッチ構成の新形態か？→ [[@2026__Unknown__Agentic Workflows are Serverless Applications, so deploy them that way!]] はモジュール化デプロイ(CFG ステージ単位の Function 分解)という設計案を示したが、実装・定量評価は伴わない position paper にとどまる。「ツール呼び出し連鎖がピタゴラスイッチ構成(FaaS+BaaS 連鎖)の新形態か」という問い自体には未回答。エージェントの状態(orchestration state・tool execution state・KV cache state)の永続化戦略がどこまで実用段階にあるかも未検証。 - CNCF の「相互運用性・API 勧告」は CloudEvents 等の規格化でどこまで実現されたか？ - サーバーレスの短命性(中央値 600ms)に対して、RCA のための観測データをどう収集・永続化すべきか。FaaSRCA は Elasticsearch による Kubernetes ログの永続化で対処するが、より低オーバーヘッドな手法は存在するか。([[サーバーレスRCA]] の問いと連動) - `Observability Engineering` 第20章が示す6つのコンピュート調達モデル(資本的支出〜中断可能柔軟容量)は、ワークロードのスパイク耐性・スケール特性という定性的基準で選択されるが、これを定量的な意思決定モデル(損益分岐点となる利用率・スパイク頻度)に落とし込んだ研究や実務知見はあるか。 - KFServing(2020)が未解決として挙げた「大規模モデルのキャッシュ・アーティファクト共有」は、[[LLMサービング管理]] が扱う FaaScale(モデル転送とマルチキャストの co-design)や PreServe(ワークロード予測による先行起動)によってどこまで解決されたか。2020年時点の課題設定と2026年時点の解法を直接対応づける後続文献はあるか。 ## 関連 - Source: [[@2018__CNCF WG Serverless__Serverless Overview Whitepaper v1.0]] / [[@2019__yuuk.io__Rethinking-Serverless-Architecture]] / [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]] / [[@2024__arXiv__FaaSRCA - Full Lifecycle Root Cause Analysis for Serverless Applications]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]] / [[@2020__arXiv__Serverless inferencing on Kubernetes]] - 著者: [[Yuuki Tsubouchi]] / [[Claus Pahl]] / [[Pengfei Chen]] / [[Guangba Yu]] - 組織: [[CNCF]] / [[Sun Yat-sen University]] - 参照エンティティ: [[Dynamo]]（Amazon DynamoDB の設計論文）/ [[FaaSRCA]] / [[AWS Lambda]] / [[KFServing]] / [[Knative]] - 関連概念: [[サーバーレスワークフロー]] / [[インターネットスケールサービス設計]] / [[コンテナオーケストレーション]] / [[サーバーレスRCA]] / [[パフォーマンスエンジニアリング]] / [[LLMサービング管理]] / [[KVキャッシュ管理]] ## 出典 - [[@2018__CNCF WG Serverless__Serverless Overview Whitepaper v1.0]](CNCF WG Serverless v1.0、定義・歴史・CaaS/PaaS 比較・Function ライフサイクル) - [[@2019__yuuk.io__Rethinking-Serverless-Architecture]] - [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]](§6 Conclusions の軽量化トレンド観察) - [[@2024__arXiv__FaaSRCA - Full Lifecycle Root Cause Analysis for Serverless Applications]](§II-A 短命性実測データ、§III-A RCA 困難の動機実験) - [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]]("Infrastructure Purchasing Models" 6モデル整理・"Cost Optimizing Serverless" コールドスタート計装) - [[@2026__Unknown__Agentic Workflows are Serverless Applications, so deploy them that way!]](エージェントワークロードのサーバーレス適合性調査・3アーキタイプの資源フットプリント実測・モジュール化デプロイ提案) - [[@2020__arXiv__Serverless inferencing on Kubernetes]](Knative ベースの機械学習推論サーバーレス基盤 KFServing の GPU オートスケーリング解説・2020年時点の本番運用経験・未解決課題)