AI前提のサービス運用について再考する

Transcript

1. AI前提のサービス運⽤について再考する 渡部⿓⼀ ドキュメントの鮮度を維持する「しくみ化」の⽅法
2. ⾃⼰紹介 • 株式会社IVRy SRE • 渡部⿓⼀ • @ryuichi_1208 • EOL対応‧障害対応
3. サービスの運⽤⼤変じゃないですか？
4. 課題 • システムは複雑化していき運⽤コストは増えていきがち • Webサーバ+DBのようなシンプルな構成と同様の運⽤をしていくのは難しい ◦ 技術要素、クラウド、プラットフォームエンジニアリング、SRE • 何が⼤変なのかわからないくらい⼤変になったり
5. どうするとよいのかの考察 • ベテランエンジニアを囲って置く ◦ IT業界は特に流動性が⾼いと⾔われている中で現実的ではない • たくさんエンジニアを採⽤して育てる ◦ プロダクトの成⻑速度に対して間に合う場合を除いて現実的ではない • 今いる⼈が全⼒で頑張る ◦ 組織改編、異動⼀つで変わる
6. どうするとよいのかの考察 • チームメンバーに依存した運⽤のやり⽅でどうにかするのは難しそう • チームの⼊れ替わりを前提とした運⽤が必要となる ◦ チームレジリエンス
7. ⼈の⼊れ替わりが発⽣しても強いチームを作る • ⼊れ替わりに強いチーム ◦ オンボーディングの仕組みが整っている ◦ 属⼈化、暗黙知が少ない ◦ ドキュメントがある
8. ドキュメントの運⽤は難しい • ドキュメントがあることでチームレジリエンスが⾼まりそう • ⼀⽅でドキュメント⾃体の運⽤は難しい ◦ サービス運⽤のためのドキュメントとなるとシステムの複雑化に対して、 ド キュメント数が多くなる ◦ その多いドキュメントを更新するのも検索するのも⼤変
9. いい感じに更新していい感じに検索をしたい
10. 開発ドキュメント/運⽤ドキュメントの性質的な違い • 開発ドキュメント ◦ ソフトウェアやシステムをどのように作るか、どう動くかを記述 ◦ 設計思想、API仕様、コンポーネント間の連携などを説明し、開発者が効率 的に開発‧機能追加できるようにすることを⽬的 • 運⽤ドキュメント ◦ 稼働中のシステムをどのように監視し、問題発⽣時にどう対応するかを記述 ◦ 障害発⽣時の復旧⼿順、メンテナンス⽅法を具体的に⽰し、安定稼働させ、 障害等に迅速かつ正確に対応することを⽬的
11. サービス運⽤におけるドキュメント • 運⽤時に使うドキュメントPlaybook、Runbookと呼ばれる ◦ Playbook ▪ ある事象に対してどのように対応するかの全体⽅針 ◦ Runbook ▪ 単体の事象に対して対応⽅法を細かく書いたドキュメント • 特定のアプリケーションエラーが出た際の対応⽅法などを記載 • サービスメンテナンスの⼿順 ▪ プロダクション環境に対して操作する⼿順が書かれている
13. サービス運⽤におけるドキュメント • 事象ごとに⽣成されていく • マイクロサービスだとサービス単位でドキュメントが作られる ◦ 100、200とかのマークダウンが並んでいく • 知りたい⼿順にどうやってアクセスするんだ...?
14. ドキュメント検索問題
15. いい感じに検索したい • 所謂キーワード検索だけだと⾟い • GitHubやNotionに情報散らばっていたりもする • ⽣成AIを使っていい感じにする ◦ ChatGPT、Gemini、etc…をそのままだとできない ◦ ファインチューニング、RAG
16. いい感じに検索したい • RAG ◦ LLMによるテキスト⽣成に外部情報の検索を組み合わせることで、回答精度 を向上させる技術 • 集約してベクトル検索にするだけでキーワード検索よりだいぶマシ • ⾃然⾔語で欲しい情報までアクセスできるのは体験として良い • 実装⽅法 ◦ ⾃前実装(OSS) ◦ SaaSを使う(RAGOps、NotionAI)
17. RAG実装⽅法 • ⾃前実装 ◦ 特定のユースケースに合わせて検索や⽣成ロジックを柔軟に調整可能 • ノーコード(Dify) ◦ ⼿軽にAIアプリを作れるOSSのLLMアプリ開発プラットフォーム ◦ コードを書く量が少なく、簡単な設定で利⽤可能
18. ⾃前構成
19. ⾃前実装 • メリット ◦ ソースが特定のサービスに紐づけずに横断して検索とかができる ▪ Notion + GitHub + ScrapBox • デメリット ◦ サーバの運⽤コスト ◦ 横断させると更新されていないソースを元に検索してきて誤り
20. Notion AI • ⽂章作成、タスク管理、アイデア出しなど、Notionでのさまざまな作業を⽀援 • NotionのDBをソースに設定した上で⾃然⾔語でクエリが投げれる
21. Notion AI • メリット ◦ Notionにデータを貯めておけば特に設定は不要でイニシャルコストが低い ◦ 認証機能というのがある • デメリット ◦ 精度は正直微妙 ◦ ヒントが得られるかも？くらいの認識
22. RAGで全て解決？ • RAGで検索性はだいぶ向上した • ドキュメントに古い情報が書いてあると誤った情報を返してくる • プロダクション環境に対して操作するのに誤った情報で操作をすると障害になり 得る • 正しい情報を元に回答を⽣成して欲しい
23. ドキュメント更新問題
24. いい感じに更新されたい • サービス運⽤は24/365で⾏われる • オンコールなど夜間対応とかで不具合があった時に対応する時に古いドキュメン トを参照して作業してしまうと障害に繋がってしまう可能性がある ◦ ドキュメント⾃体が古い場合でもその情報を元に回答が⽣成されてしまう
25. いい感じに更新されたい • いい感じに更新されている鮮度が保たれたドキュメントを維持したい • 更新が古いドキュメントを検索対象から外す？ ◦ 最終更新⽇が古い≠誤っているドキュメント ▪ 決まりきった⼿順は更新されない • ドキュメントを活⽤したタイミングで活⽤された印をつける
26. いい感じに更新されたい • チーム全体で更新される頻度は増えた • 更新⽇時が古い && スコアが低い ≠ 誤ったドキュメント ◦ 年⼀くらいの作業はどっちも更新されない • 間違っているかどうかは最終的には⼈が判断するしかない ◦ ⼀⼈でドキュメント⾒てプロダクションに⼿を加えるケースはあまり多くな いので現時点では⼤きな課題ではない
27. 今後期待している
28. MCP • LLMにコンテキストを提供する⽅法を標準化するオープンプロトコル ◦ 各AIツールベンダーが独⾃のインターフェースやAPI設計しているところか ら標準化される世界へ • ファイルシステム、DB、API などへのアクセスを提供するサーバがあればそれら の情報を元に⾃然⾔語で問い合わせを⾏って動的に回答を⽣成することができる
29. MCP • MCPクライアントを設定することで「Notion + GitHub + ScrapBox + etc…」みた いなドキュメント管理していても統⼀的にLLMにクエリが投げやすくなる • ドキュメントに加えてMCPサーバを実装すれば動的な回答も可能になる ◦ ryuichi1208/mackerel-mcp-server ◦ Mackerelのメトリクスやアラート情報を集約しながらその状況に適したド キュメントの提案などが可能になる可能性がある • Cursorとかでローカルにドキュメント持ってきて事⾜りるケースもだいぶ多い
30. うまくいかなかった施策
31. イミュータブルドキュメント • ドキュメントをイミュータブルにして更新しない • 更新する際は新しく採番する(RFC⽅式) • アラート対応して初めてアプリケーションの構成が実は変わっていたということ に気づくケースは多くある ◦ 開発と運⽤を別チームでやっているとありがちでその場でシュッと直せる⽅ がサービス運⽤においては有効だった
32. まとめ
33. まとめ • システムの複雑化とチームの流動性を前提としたチームレジリエンスの向上が、 現代のサービス運⽤における重要課題 • 特に本番環境に影響を与えるRunbook等のドキュメントの鮮度維持は、安全な サービス運⽤の⽣命線 • MCPのような技術標準や動的な情報連携により、将来的にはより⾼度な運⽤⽀援 が期待される
34. ご清聴ありがとうございました