# サーバーレスRCA ## 定義 サーバーレス RCA(Serverless Root Cause Analysis)は、FaaS(Function-as-a-Service)アーキテクチャ上で動作するサーバーレス関数の障害根本原因を特定する技術領域である。[[サーバーレスアーキテクチャ]] 固有の性質 — 短命なライフサイクル(中央値 600ms)、パルス状の非連続テレメトリ、ゼロへのスケールダウン、プラットフォーム(Kubernetes)側と関数実行側の二層構造 — により、従来のマイクロサービス向け RCA 手法をそのまま適用できない。(Source: [[@2024__arXiv__FaaSRCA - Full Lifecycle Root Cause Analysis for Serverless Applications]]) サーバーレス関数のライフサイクルは **作成(creation) → 実行(execution) → 破壊(destruction)** の 3 段階に区分される。作成・破壊段階はプラットフォーム側(Kubernetes コンポーネント)、実行段階はアプリケーション側(関数インスタンス)に帰属する。 ## マイクロサービス RCA との主な差異 | 観点 | マイクロサービス | サーバーレス | |---|---|---| | データの連続性 | 長期連続時系列 | 瞬時パルス状(スカラー値) | | ライフサイクル | 常時起動 | 短命(数百ms〜数分) | | スケール | 常時リソース消費 | ゼロへのスケールダウン | | 障害発生箇所 | アプリ側のみ分析可 | プラットフォーム側(作成・破壊段階)も分析必要 | | トレース | 標準的な分散トレーシング | Kubernetes コンポーネント間は組み込みトレースなし | ## FaaSRCA の設計パラダイム [[FaaSRCA]](arXiv 2412.02239、2024)は現時点でこの課題に取り組む代表的な手法であり、以下の設計方針をとる: - **Global Call Graph (GCG)**: プラットフォーム側(Kubernetes deployment/replicaset/pod)とアプリケーション側(関数インスタンス)を単一のヘテロジニアス属性グラフで統合。 - **教師なしグラフオートエンコーダ**: GAT(Graph Attention Network)ベースのオートエンコーダで正常パターンを学習。障害時の Z スコアで根本原因ノードをランク付け。 - **マルチモーダルデータ統合**: ログ(BERT エンベディング)・メトリクス(高次元射影)・トレース(レイテンシ)を結合して各ノードの属性ベクトルを構築。 - **ライフサイクル段階単位の粒度**: 「どの関数の」「どのライフサイクル段階で」障害が起きたかを特定(インスタンスレベル粒度を超える細粒度)。 ## 横断的知見 - **系列ベース手法はサーバーレスに不適合である**: FaaSRCA の動機実験では、マイクロサービス向けの代表的 RCA 手法 Eadro をサーバーレスに適用した場合、関数数が増えるほど HR@1 が低下することを実証した。サーバーレス関数が長期連続データを生成しないため、Eadro が前提とするシーケンスモデリングが成立しない。(Source: [[@2024__arXiv__FaaSRCA - Full Lifecycle Root Cause Analysis for Serverless Applications]] §III-A) - **プラットフォーム側データの欠如は ML Workflow で HR@k を 48 ポイント以上低下させる**: FaaSRCA のアブレーション(w/o P)では ML Workflow での HR@k が 90.57% → 41.84% に急落した。一方 TrainTicket では 92.50% → 62.84% の低下。プラットフォーム障害(kube-scheduler 遅延・kubelet 遅延・ネットワーク障害等)の影響が大きいワークロードほど、プラットフォーム側データの統合が根本的に重要であることを示す。(Source: [[@2024__arXiv__FaaSRCA - Full Lifecycle Root Cause Analysis for Serverless Applications]] §V-D, Table III) - **ヘテロジニアスグラフの扱いが精度を左右する**: Direct-FaaSRCA(Z スコアなし、再構成誤差の絶対値でランク)は FaaSRCA より大幅に精度が低い(TrainTicket: 68.74% vs 92.50%)。プラットフォームノードとアプリノードの再構成誤差分布が異なるため、絶対値比較では誤分類が生じる。Z スコアによる「各ノード自身の正常パターンとの比較」がヘテロジニアス性を暗黙的に解消する。(Source: [[@2024__arXiv__FaaSRCA - Full Lifecycle Root Cause Analysis for Serverless Applications]] §V-C, §V-D) ## 未解決の問い - FaaSRCA は Serverless TrainTicket と ML Workflow という 2 つのベンチマークで評価されているが、AWS Lambda・Google Cloud Functions などのマネージドサーバーレスプラットフォームへの適用性はどうか。Kubernetes/Knative に限定された設計要素(Audit/Event ログ、所有関係トレース構築)は他プラットフォームで代替できるか。 - プラットフォームデータ収集(Kubernetes Audit ログ、Elasticsearch への永続化)のオーバーヘッドは許容範囲内か。Knative 以外のサーバーレスフレームワークへの移植コストは。 - サーバーレス関数のコールドスタートは RCA においてどのように扱うべきか。コールドスタート自体が「作成段階の遅延」として根本原因に分類されるのか、それとも正常挙動として除外すべきか。 - サーバーレス関数の関数数・同時実行数が大規模になった場合(数百〜数千関数)、GCG の構築・GAE 訓練の計算コストはどう変化するか。 ## 関連 - 親概念: [[根本原因分析]] / [[ドメイン別RCA]] - 兄弟概念: [[グラフベースRCA]] / [[サーバーレスアーキテクチャ]] / [[サーバーレスワークフロー]] - 関連エンティティ: [[FaaSRCA]] / [[Pengfei Chen]] / [[Guangba Yu]] / [[Sun Yat-sen University]] - 関連ソース: [[@2024__arXiv__FaaSRCA - Full Lifecycle Root Cause Analysis for Serverless Applications]] ## 出典 - [[@2024__arXiv__FaaSRCA - Full Lifecycle Root Cause Analysis for Serverless Applications]](§II 背景、§III 動機実験、§IV 設計、§V 評価)