AI Agent SaaS を支える自社仮想化基盤への挑戦と実運用

Transcript

1. AI Agent SaaS を支える 自社仮想化基盤への挑戦と実運用 @SRE NEXT 2026 Software Engineer - OJI #srenext_a #srenext
2. $ whoami OJI (@OldBigBuddha) SWE @ GMO Flatt Security Inc. 社内用仮想化基盤 “Sunaba（すなば）” を作ってます 未踏 ‘26 クリエータ seccamp ‘23 修了 © 2025 GMO Flatt Security Inc. All Rights Reserved.
3. 目次 会社紹介 / Takumi とは AI Agent SaaS とは AI Agent SaaS に求められる実行基盤 Flatt 内製仮想化基盤「Sunaba（すなば）」 アーキテクチャ・技術のお話 監視について デプロイメントについて © 2025 GMO Flatt Security Inc. All Rights Reserved.
4. Our Mission エンジニアの背中を預かる より多くのエンジニアがものづくりに集中できる社会を、 セキュリティ面からつくる会社
5. 提供サービス 脆弱性診断・ペネトレーションテストを プロフェッショナルサービス / AIで多角的に提供 AI・継続診断 専門家・高度診断 コード・仕様の分析も行い、 専門家が脆弱性を網羅的に発見 継続的なセキュリティレビューを
 AIエージェントで簡単に実現
6. 脆弱性の検出・修正とソフトウェア サプライチェーンリスク対策をAIが自動化 Takumiは、①LLMによる高度なセキュリティ診断(AI DAST, SAST)と脆弱性の自動修正 ②マルウェアパッ ケージのブロックとCI/CD環境のセキュリティ可視化 により”今”開発組織が備えるべきリスクに備えます。 月額7万円(税抜)
7. Takumi Images を今週リリースしました！ https://flatt.tech/takumi/features/images © 2025 GMO Flatt Security Inc. All Rights Reserved.
8. AI Agent SaaS を支える 自社仮想化基盤への挑戦と実運用 @SRE NEXT 2026 Software Engineer - OJI #srenext_a #srenext
9. AI Agent としての Takumi 製品群 脆弱性診断 （ホワイトボックス/ブラックボックス） 自動修正 Dependabot PR AIトリアージ © 2025 GMO Flatt Security Inc. All Rights Reserved.
10. AI Agent “の” SaaS 開発者的には Devin が一番想像しやすい プロンプトを投げたらオンラインでかガチャガチャ処理してくれるヤツ AI Agent を SaaS として提供するには気にすることが沢山 LLM の提供側が不安定なときにどうする？？ 複数の model をタスクごとに切り分けたい場合はどうする？ AI が使う knowledge はどこに置く？ そもそも AI Agent をどこで実行する？ 今回は AI Agent の実行基盤にフォーカスしてお話します © 2025 GMO Flatt Security Inc. All Rights Reserved.
11. 過去: K8s を使って顧客ごとの Pod を常設していた メリット 既存の K8s の上で動く K8s という成熟したエコシステムに身を委ねられる デメリット 1顧客に対して常時 1 Pod 以上が起動するため、
 顧客の利用状況に関わらず費用が発生する コンテナでは隔離が不十分 © 2025 GMO Flatt Security Inc. All Rights Reserved.
12. Takumi においてコンテナ分離では何が不十分だったか 将来的にはツールとしてコンテナ（Docker）を使いたかった DinD はなるべく避けたい…… kernel panic を起こすとその Pod が動いている Node ごとダウンする コンテナエスケープも怖い （とはいえVMでもエスケープも発生しえるので、銀の弾丸はない） © 2025 GMO Flatt Security Inc. All Rights Reserved.
13. Takumi においてコンテナ分離では何が不十分だったか 任意コード実行を許容するとコンテナエスケープの可能性がある kernel panic を起こすとその Pod が動いている host ごとダウンする ホワイトボックス診断だけ（実装を読むだけ）のときはこの形式で耐えた ブラックボックス診断など任意コード実行が伴うサービスの提供には適さない © 2025 GMO Flatt Security Inc. All Rights Reserved.
14. なのでVMを使いたいが…… VM を常時起動しておくのは当然費用が高すぎる 実質 K8s Node を1顧客に割り当てるようなもの © 2025 GMO Flatt Security Inc. All Rights Reserved.
15. ではリクエストのたびに短命なVMを生みたいと思うが…… 正直クラウドの VM 起動は遅い AI にリクエスト投げたら環境構築に数分待たされるのは許容できない VM はあくまで環境なのでその後にセットアップや推論が始まる… リージョンごとの Quote を考えると短命VMには正直向いてない © 2025 GMO Flatt Security Inc. All Rights Reserved.
16. つまりこういう環境が欲しい セッションごとにVMを使って隔離 VM の起動は一瞬で完了してほしい 実行基盤は可能な限り実行時間に対して従量課金 使っていない間は費用は発生しないが理想 © 2025 GMO Flatt Security Inc. All Rights Reserved.
17. つまりこういう環境が欲しい セッションごとにVMを使って隔離 実行基盤は可能な限り実行時間に対して従量課金 使っていない間は費用は発生しないが理想 VM の起動は一瞬で完了してほしい 欲しいときに欲しいだけの VMを秒で生成し、 不要なタイミングで 即殺すことができる理想的な環境が欲しい…… © 2025 GMO Flatt Security Inc. All Rights Reserved.
18. なので “Sunaba（すなば）” をフルスクラッチで作った Flatt 内製のKVMベースの仮想化基盤 任意のタイミングで任意の数の VM を動かせる もちろん削除も任意のタイミング VM の起動はリクエストを投げてから約 ５秒 ピーク時は週次で約 100万 VMs を捌ける 開発期間は3〜4か月、移行含めて約半年 現在は Takumi の AI Agent 機能がすべて
 Sunaba 上で走っています © 2025 GMO Flatt Security Inc. All Rights Reserved.
19. Sunaba のざっくりアーキテクチャ © 2025 GMO Flatt Security Inc. All Rights Reserved.
20. かなり K8s を参考にした構成 © 2025 GMO Flatt Security Inc. All Rights Reserved.
21. アーキテクチャの詳細はこちらをご覧ください https://speakerdeck.com/flatt_security/architecture-conference-2025 © 2025 GMO Flatt Security Inc. All Rights Reserved.
22. 技術的おもしろトピック3選 Firecracker を採用 CoW を活用して VM ごとの容量を削減&高速起動 オートスケーリング © 2025 GMO Flatt Security Inc. All Rights Reserved.
23. トピック 1: Firecracker を採用 AWS が OSS で開発している KVM ベースのハイパーバイザー 語弊100％で雑に紹介すると超軽量な QEMU AWS Lambda のバックエンドで使われている 最近は Lambda MicroVM を提供しているのは
 Lambda の裏がもともと VM だった+VM隔離の需要が
 増えたからだと予想している © 2025 GMO Flatt Security Inc. All Rights Reserved.
24. トピック 1: Firecracker を採用 国内で Firecracker の採用事例が今のところ公開情報では無さそう 良かった点 VM の起動が爆速 思想からスリムなのでセキュリティの観点的にありがたい 辛い点 先行事例がないので常に試行錯誤 VM だけど Live migration がない ※firecracker は Live migration を必要とする長命VMの運用を前提としていないため © 2025 GMO Flatt Security Inc. All Rights Reserved.
25. トピック 2: CoW（Copy-on-Write）で VM ごとの容量を削減&起動高速化 CoW を使うことで Read-Only な層と Writable な層を分けて管理できる © 2025 GMO Flatt Security Inc. All Rights Reserved.
26. トピック 2: CoW（Copy-on-Write）で VM ごとの容量を削減&起動高速化 Read-Only の部分は VM 間で共有できる => 容量削減 Read-Only の部分は file copy ではなく symbolic link => file copy と比較して爆速 = VM の起動が高速 © 2025 GMO Flatt Security Inc. All Rights Reserved.
27. トピック 3: auto scale 「Sunaba 全体であと何台 VM を生成できるか？」を閾値として自動でスケール in/out 共に 完全自動化 リクエストが全然ない ときはnode を減らして 維持費削減 リクエストが多いときは node を増やしてなるべく 枯渇しないように リクエストが多いときは node を増やしてなるべく 枯渇しないように © 2025 GMO Flatt Security Inc. All Rights Reserved.
28. Sunabaの実運用 © 2025 GMO Flatt Security Inc. All Rights Reserved.
29. Sunabaの運用話 監視 デプロイメント © 2025 GMO Flatt Security Inc. All Rights Reserved.
30. Sunabaの”期待通り動いている”はどう定義するか 正直試行錯誤中 VM 内で何が起きているかまではトラックできない まずはこれらをSLIとして定義 リクエストに対するリソース不足率 各 VM の起動にかかった時間 + error rate とか latency みたいな一般的なもの Sunaba はかなり実験的な基盤なので、SLO は一旦仮ぎめ程度 リソース不足はインスタンスの起動時間x2まで許容する VM の起動時間の目標時間は作るVMに依存よるので一律定義が難航…… ここらへんは今後の課題 © 2025 GMO Flatt Security Inc. All Rights Reserved.
31. Sunabaの”動いている”を観測するために Sunaba は基盤であり、エラー発生やデグレをいち早く検知・対応する必要が ある 一方で実体は GCE Instance の集合なので、自分たちでメトリクスやログを収 集するセットアップをしないといけない © 2025 GMO Flatt Security Inc. All Rights Reserved.
32. Sunabaの監視アーキテクチャ もともと別プロダクトで構築した監視基盤があるのでそこに一元化 Sunaba は Google Cloud、監視基盤は AWS なので Site-to-Site VPN Grafana Alloy を使ってログ・メトリクスを送信 © 2025 GMO Flatt Security Inc. All Rights Reserved.
33. Grafana Alloy とは？ Grafana Labs 製のテレメトリコレクター いろんな形式のデータを一元的に収集できるので楽 画像引用: https://grafana.com/docs/alloy/latest/ © 2025 GMO Flatt Security Inc. All Rights Reserved.
34. デプロイメント © 2025 GMO Flatt Security Inc. All Rights Reserved.
35. Sunaba のデプロイメント Sunaba は VM という stateful なものを持っている => 旧バージョンのインスタンスを即削除はできない （すべてのAI Agent が停止していることを担保しなくてはいけない） Sunabaは基盤なのでリリース時のダウンタイムを許容できない => 少しでも異常があればまずは動く状態に戻すことを優先する 内製なので ArgoCD なんて便利なものは存在しない => 自分たちでデプロイ手順を設計し、その上で自動化を行う © 2025 GMO Flatt Security Inc. All Rights Reserved.
36. Blue-Green deployment 旧バージョン（Blue）から新バージョン（Green）へ徐々にトラフィック比率を 変更することでリリースを完了させる手法 © 2025 GMO Flatt Security Inc. All Rights Reserved.
37. Blue-Green deployment 良い点: 少しでも想定の問題が発生すれば元の動いた状態に即座に戻せる トラフィック比率の変更だけなので、再デプロイは不要 トラフィックが多い環境でも小負荷から試せて安心 悪い点: デプロイ中は2クラスタを維持するためコスト増 トラフィックが少ない時間帯や環境だと検証がしづらい © 2025 GMO Flatt Security Inc. All Rights Reserved.
38. VMPool の Drain 削除したいインスタンスには VM を新規で作らない B/Gデプロイメント完了後、スケールインのとき kubectl drain と動きはほぼ一緒 何台動いているか？は インスタンス（VMPool）が自己申告 VM が0台かつ Drain 状態のときに始めて削除が走る 当然この機構も自作 © 2025 GMO Flatt Security Inc. All Rights Reserved.
39. まとめ AI Agent SaaS を提供するときに実行基盤は重要トピックのひとつ 特にユースケースに合わせた隔離が求められる Flatt は理想の環境を目指してSunabaを内製した 開発も運用もすべてが試行錯誤 皆さんの会社でどんな環境を使っているか、ぜひお聞かせください © 2025 GMO Flatt Security Inc. All Rights Reserved.