AI Agent SaaS を支える自社仮想化基盤への挑戦と実運用 / ai-agent-saas-virtualization

by GMO Flatt Security

Embed

Start on current slide

Slide 1

Slide 1 text

AI Agent SaaS を支える自社仮想化基盤への挑戦と実運用 @SRE NEXT 2026 Software Engineer - OJI #srenext_a #srenext

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Our Mission エンジニアの背中を預かるより多くのエンジニアがものづくりに集中できる社会を、セキュリティ面からつくる会社

Slide 5

Slide 5 text

提供サービス脆弱性診断・ペネトレーションテストをプロフェッショナルサービス / AIで多角的に提供 AI・継続診断専門家・高度診断コード・仕様の分析も行い、専門家が脆弱性を網羅的に発見継続的なセキュリティレビューを  AIエージェントで簡単に実現

Slide 6

Slide 6 text

脆弱性の検出・修正とソフトウェアサプライチェーンリスク対策をAIが自動化 Takumiは、①LLMによる高度なセキュリティ診断(AI DAST, SAST)と脆弱性の自動修正 ②マルウェアパッケージのブロックとCI/CD環境のセキュリティ可視化により”今”開発組織が備えるべきリスクに備えます。月額7万円(税抜)

Slide 7

Slide 7 text

Slide 8

Slide 8 text

AI Agent SaaS を支える自社仮想化基盤への挑戦と実運用 @SRE NEXT 2026 Software Engineer - OJI #srenext_a #srenext

Slide 9

Slide 9 text

Slide 10

Slide 10 text

AI Agent “の” SaaS 開発者的には Devin が一番想像しやすいプロンプトを投げたらオンラインでかガチャガチャ処理してくれるヤツ AI Agent を SaaS として提供するには気にすることが沢山 LLM の提供側が不安定なときにどうする？？複数の model をタスクごとに切り分けたい場合はどうする？ AI が使う knowledge はどこに置く？そもそも AI Agent をどこで実行する？今回は AI Agent の実行基盤にフォーカスしてお話します © 2025 GMO Flatt Security Inc. All Rights Reserved.

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Takumi においてコンテナ分離では何が不十分だったか将来的にはツールとしてコンテナ（Docker）を使いたかった DinD はなるべく避けたい…… kernel panic を起こすとその Pod が動いている Node ごとダウンするコンテナエスケープも怖い（とはいえVMでもエスケープも発生しえるので、銀の弾丸はない） © 2025 GMO Flatt Security Inc. All Rights Reserved.

Slide 13

Slide 13 text

Takumi においてコンテナ分離では何が不十分だったか任意コード実行を許容するとコンテナエスケープの可能性がある kernel panic を起こすとその Pod が動いている host ごとダウンするホワイトボックス診断だけ（実装を読むだけ）のときはこの形式で耐えたブラックボックス診断など任意コード実行が伴うサービスの提供には適さない © 2025 GMO Flatt Security Inc. All Rights Reserved.

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

なので “Sunaba（すなば）” をフルスクラッチで作った Flatt 内製のKVMベースの仮想化基盤任意のタイミングで任意の数の VM を動かせるもちろん削除も任意のタイミング VM の起動はリクエストを投げてから約５秒ピーク時は週次で約 100万 VMs を捌ける開発期間は3〜4か月、移行含めて約半年現在は Takumi の AI Agent 機能がすべて  Sunaba 上で走っています © 2025 GMO Flatt Security Inc. All Rights Reserved.

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

トピック 1: Firecracker を採用 AWS が OSS で開発している KVM ベースのハイパーバイザー語弊100％で雑に紹介すると超軽量な QEMU AWS Lambda のバックエンドで使われている最近は Lambda MicroVM を提供しているのは  Lambda の裏がもともと VM だった+VM隔離の需要が  増えたからだと予想している © 2025 GMO Flatt Security Inc. All Rights Reserved.

Slide 24

Slide 24 text

トピック 1: Firecracker を採用国内で Firecracker の採用事例が今のところ公開情報では無さそう良かった点 VM の起動が爆速思想からスリムなのでセキュリティの観点的にありがたい辛い点先行事例がないので常に試行錯誤 VM だけど Live migration がない ※firecracker は Live migration を必要とする長命VMの運用を前提としていないため © 2025 GMO Flatt Security Inc. All Rights Reserved.

Slide 25

Slide 25 text

Slide 26

Slide 26 text

トピック 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.

Slide 27

Slide 27 text

トピック 3: auto scale 「Sunaba 全体であと何台 VM を生成できるか？」を閾値として自動でスケール in/out 共に完全自動化リクエストが全然ないときはnode を減らして維持費削減リクエストが多いときは node を増やしてなるべく枯渇しないようにリクエストが多いときは node を増やしてなるべく枯渇しないように © 2025 GMO Flatt Security Inc. All Rights Reserved.

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Sunabaの”期待通り動いている”はどう定義するか正直試行錯誤中 VM 内で何が起きているかまではトラックできないまずはこれらをSLIとして定義リクエストに対するリソース不足率各 VM の起動にかかった時間 + error rate とか latency みたいな一般的なもの Sunaba はかなり実験的な基盤なので、SLO は一旦仮ぎめ程度リソース不足はインスタンスの起動時間x2まで許容する VM の起動時間の目標時間は作るVMに依存よるので一律定義が難航…… ここらへんは今後の課題 © 2025 GMO Flatt Security Inc. All Rights Reserved.

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Sunaba のデプロイメント Sunaba は VM という stateful なものを持っている => 旧バージョンのインスタンスを即削除はできない（すべてのAI Agent が停止していることを担保しなくてはいけない） Sunabaは基盤なのでリリース時のダウンタイムを許容できない => 少しでも異常があればまずは動く状態に戻すことを優先する内製なので ArgoCD なんて便利なものは存在しない => 自分たちでデプロイ手順を設計し、その上で自動化を行う © 2025 GMO Flatt Security Inc. All Rights Reserved.

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Blue-Green deployment 良い点: 少しでも想定の問題が発生すれば元の動いた状態に即座に戻せるトラフィック比率の変更だけなので、再デプロイは不要トラフィックが多い環境でも小負荷から試せて安心悪い点: デプロイ中は2クラスタを維持するためコスト増トラフィックが少ない時間帯や環境だと検証がしづらい © 2025 GMO Flatt Security Inc. All Rights Reserved.

Slide 38

Slide 38 text

VMPool の Drain 削除したいインスタンスには VM を新規で作らない B/Gデプロイメント完了後、スケールインのとき kubectl drain と動きはほぼ一緒何台動いているか？はインスタンス（VMPool）が自己申告 VM が0台かつ Drain 状態のときに始めて削除が走る当然この機構も自作 © 2025 GMO Flatt Security Inc. All Rights Reserved.