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

# サーバーレスアーキテクチャ ## 定義 **サーバーレスコンピューティング = 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]]) - **サーバーレス関数の短命性は 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) ## 制約 **同期リクエストのメモリ効率問題**: リクエストを 1 件ずつ別 Function で処理する場合、I/O ブロッキング中にメモリは占有したまま CPU のみ解放される → メモリ使用効率が悪くコスト増。非同期可能なケースではキューを経由して複数イベントを並行処理できる。 ## 未解決の問い - ベンダー非依存のピタゴラスイッチ構成（FaaS + BaaS + CloudEvents）は 2019 年以降どこまで進んだか？ - サーバーレスアーキテクチャとエージェント型 AI システム（LLM エージェント）の関係はどうか？LLM エージェントの「ツール呼び出し」はピタゴラスイッチ構成の新形態か？ - FaaS のコールドスタート問題はその後どのように緩和されたか？（CNCF 白書 2018 時点では主要課題として挙げていた） - CNCF の「相互運用性・API 勧告」は CloudEvents 等の規格化でどこまで実現されたか？ - サーバーレスの短命性(中央値 600ms)に対して、RCA のための観測データをどう収集・永続化すべきか。FaaSRCA は Elasticsearch による Kubernetes ログの永続化で対処するが、より低オーバーヘッドな手法は存在するか。([[サーバーレスRCA]] の問いと連動) ## 関連 - 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]] - 著者: [[Yuuki Tsubouchi]] / [[Claus Pahl]] / [[Pengfei Chen]] / [[Guangba Yu]] - 組織: [[CNCF]] / [[Sun Yat-sen University]] - 参照エンティティ: [[Dynamo]]（Amazon DynamoDB の設計論文）/ [[FaaSRCA]] - 関連概念: [[サーバーレスワークフロー]] / [[インターネットスケールサービス設計]] / [[コンテナオーケストレーション]] / [[サーバーレスRCA]] ## 出典 - [[@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 困難の動機実験)