【Generative AI Meetup & Google Cloud Next '23 Recap】AI ど素人 SRE の Gen AI 活用事始め

Transcript

1. AIど素人SREのGenAI活用事始め 株式会社スリーシェイク 橋本玄基
2. 自己紹介｜橋本玄基 2 所属: 株式会社スリーシェイク Sreake事業部 経歴: 18年新卒で金融系事業者でのオンプレ運用 -> プログラミング教育系スタートアップで Pythonバックエンド -> スリーシェイクjoin 趣味: ゲーム(積みゲー300本) ペット(ボールパイソン、チュウゴクシュウダ)
3. なぜSREにGenAI? 3 01
4. インフラをシンプルに あらゆる労苦(toil)をなくす 3-shakeのミッション 4
5. about 3-shake 5 Copyright © 3-shake, Inc. All Rights Reserved. • SRE黎明期から培ってきた最先端のテクノロジーとノウハウ • クラウド/データ/セキュリティの技術設計から開発、運用、拡張までをワンストップ提供 • エンジニアをあらゆる労苦（ Toil）から開放する広範な SaaSソリューション モダナイゼーションプラットフォーム 提供価値 エンジニアリング内製化 ソリューション（モダナイゼーション）を包括的提供 SRE/DevOps SecOps DataOps HR インフラの課題 セキュリティの課題 データ活用/サイロ化の課題 採用/人事の課題 ・アプリケーションのデリバリー頻度増 加(= インフラデリバリー増加 ) ・インフラアーキテクチャの複雑化、業 務の属人化加速 (難易度UP) ・慢性的なSRE/DevOps人材不足 ・アプリケーションのデリバリー頻度増 加(= 脆弱性リスク増加） ・増加するサイバー攻撃 ・慢性的なセキュリティ人材不足 ・デジタル化に伴うデータ活用ニーズ 増加 ・XaaS普及によるデータのサイロ化、 ブラックボックス化 ・慢性的なデータエンジニア不足 ・高度化する開発エンジニア要求スキ ルと、内製エンジニアの育成遅れ ・慢性的な開発エンジニア（クラウド対 応エンジニア）不足 SRE/DevOps SecOps DataOps HR
6. 個人的に考えるSreakeがビジネスとミッションを達成するための課題 ・人月商売なのでスケールを続けるためには無限に人を採用しなければならない(極論SREが 全員3-shakeに入ることになってしまうが、それは求めている未来ではない) →少ない工数で効率化した質の高いご支援をするために自動化できるところは自動化したい ・現状では信頼性の投資がまだ難しい企業への価値提供が難しい(低工数のアドバイザー的な ご支援では限界がある) →SREのSaaS化よる低価格かつスケールできる(人に頼らずに提供できる)ようなSREの導入支 援ができないか AIでしょ！！！というタイミングで機械学習の知見なしにある程度AIの自動化という力を借 りれるGenerative AIが盛り上がってきた 人でのサービス提供には限界がある → 将来的には徹底した自動化が求められる 6
7. SRE活動の中で活かすLLM検証例の紹介 7 02
8. 個人的に考えるSreakeがビジネスとビジョンを達成するための課題 ・人月商売なのでスケールを続けるためには無限に人を採用しなければならない(極論SREが 全員3-shakeに入ることになってしまうが、それは求めている未来ではない) →少ない工数で効率化した質の高いご支援をするために自動化できるところは自動化したい →これまで自動化は難しく労苦(toil)とならなかった領域の自動化を考える ・現状では信頼性の投資がまだ難しい企業への価値提供が難しい(低工数のアドバイザー的な ご支援では限界がある) →SRE as a Serviceによる低価格かつスケールできる(人に頼らずに提供できる)ようなSREの 導入支援ができないか →これまでの社内KnowledgeをベースにしたSRE専用チャットボットサービスの検討 Gen AIでの課題解決を検討 8
9. toilの対象を拡張し、promptで自動化を実装する 9 SRE本5章より toilの定義「サービスを稼働させることに直結している作業で、繰り返されたり、手作業 だったりするもの」 toilの特徴 - 手作業であること - 繰り返されること - 自動化できること →自動化のコストが高くてそのままにして - 戦術的であること いるようなタスクをLLMに任せたい - 長期的な価値を持たないこと - サービスの成長に対してO(n)であること
10. toilの対象を拡張し、promptで自動化を実装する例① 10 定期的に行われるレポートの1stインサイトをLLMに任せる。 e.g. ・コスト ・パフォーマンス ・キャパシティ Google Cloudのコストインサイトを定期的にslackへ通知してくれる仕組みの検証例 PaLM API for textで作るGoogle Cloudコストチェッカー (https://sreake.com/blog/google-cloud-cost-check-with-palm-api-for-text/)
11. toilの対象を拡張し、promptで自動化を実装する例② 11 最新化が定期的に必要なドキュメンテーションのメンテナンスをLLMに任せる e.g. ・構成図 ・権限管理 OpenAI API を利用して Terraform から構成図っ ぽい Mermaid を出力してくれるコマンドを作っ た話 (https://sreake.com/blog/mermaid-with-open ai-api/) 自作した構成図 OpenAIがterraformから出したmermaid (登場人物は合っているが依存関係はterraformに引っ張られている) 精度が上がってくるとX as Codeが重要視されるかもしれない もしくはInputが言語以外に多彩に対応してくる
12. toilの対象を拡張し、promptで自動化を実装する例③ 12 最新化が定期的に必要なドキュメンテーションのメンテナンスをLLMに任せる e.g. ・構成図 ・権限管理 OpenAI APIを利用してパブリッククラウド の権限要約をしてくれるCLIコマンドを作 成した (https://sreake.com/blog/summarize-p ermission-with-openai/) code管理されているものに ついて、エンジニア <> 非エンジニ アの通訳をLLMによって自動化す る。
13. 社内KnowledgeをベースにしたSRE専用チャットボットサービスの検討 13 RAGを活用して以下のような課題に対して情報を得やすくする形で提供する(例えばslackへの埋 め込みchat botなど)ことで、SREingをよりハードルの低い作業へ 13 社内Notion GCS Vertex AI Search & Converseation 質問 定期的に最新化
14. Vertex AI Searchを利用した実装例 14 PaLM2に聞いた回答
15. Vertex AI Searchを利用した実装例 15 ↓秘匿情報管理方法の比較をしているドキュメン トがあり、その中で記載があるSOPSを利用した暗 号化について言及されている(Sreakeのプラクティ スをベースに回答ができる) 社内wikiを渡したVertex AI Searchの回答
16. GenAIの課題、というよりデータな課題がいくつか 16 • GCSに投入するのは簡単だが、更新は若干面倒 ◦ NotionのDatasource対応お待ちしてます！！ • 顧客情報混入してしまわないか問題 ◦ 生産性の観点から技術Knowledgeと顧客情報を完全に切り離 したドキュメンテーションはしんどいのであまりエンジニアに 強制したくない ◦ LLMにフィルタリング作業をさせることも考えているが100% 保証できない、、、 ◦ エンジニアの書き心地とKnowledge蓄積の両立法を検討中 • 性質として細かい技術的な困りごとへの対応へはある程度効果が 見られるが設計などの大きな粒度への情報はイマイチ ◦ LLM単品だと一般論を答えるにとどまる ◦ ここに対して適切な情報を保持して具体例まで出せるようにし たい
17. まとめ 17 • SREとしてGenerative AI(≒LLM)を活用する2つの提案 ◦ toilの対象を拡張、promptで自動化を検討する ▪ “自動化可能”というtoilの定義からもう1段階広い領域の自動化を考える • (コストやパフォーマンス)レポートのインサイトをまとめる • ドキュメンテーションの一部自動化　　　　　　　　　　　など • LLMに任せる作業が増えるとX as Codeが進んでいくかも？ ◦ SRE特化型チャットボットの検討 ▪ ナレッジの検索性能を向上させる ▪ 日頃の負荷を減らして実現を目指すためには色々課題あり • 顧客情報の混入回避 • etc…