いつも記事を読んでいただきありがとうございます!
モブエンジニア(@mob-engineer)です!
今回は2025.03.04(火)に開催したOpsJAWS Meetup33 AIOpsへ参加しましたのでアウトプットとしてイベントレポートを執筆いたしました。
初学者でもサクッと読めるように平易な表現で執筆しておりますので、お気軽に読んでいただければ幸いです。
誤字脱字、わかりづらい表現に関しては極力なくすように心がけていますが、リアルタイムで執筆しているため、もしかしたら誤字脱字があるかもしれません。
目次
- セッション
- AI自体のOps 〜LLMアプリの運用、AWSサービスとOSSの使い分け〜
- LT
- Amazon CodeGuruをGitHubと統合してアプリケーションの品質管理を楽にする
- AIを先生に~Slack × Bedrock で育成担当の人材不足解消を考える~
- もしもマラソンランナーが operational investigations を有効化したら
- Bedrockによるエラー通知のフィルタリング
- 元祖 AIOps!メトリクス異状検知からはじめよう〜さようなら Lookout for Metrics〜
- Amazon Bedrockガードレールで守る安全なAI運用
- Amazon Q Developerを用いたAWS運用改善~自動化スクリプト生成~
- まとめ
セッション
AI自体のOps 〜LLMアプリの運用、AWSサービスとOSSの使い分け〜
登壇資料
参考サイト
- AIOpsに携わっていますか?
- LLMOpsとは:LLMを利用したOpsの略のこと
- 開発&運用サイクルをいい感じに回すための取り組み
- なぜ必要なのか
- 開発中のデバッグが難しい(≒推論内容がよく分からない)
- リリースしたプロダクトがどのように利用されているか分からない、満足度も分からない
- LLMアプリケーション実装例
- 推論:単発のテキスト生成
- RAG:検索結果をコンテキストに含めて推論(FAQアプリなど)
- AIエージェント:行動計画を推論したのち、ツールを用いて各タスクを推論
- 開発アプローチによって利用するLLMOpsが変わってくる
- ローコード:Dify、Bedrockフローなど
- マネージドサービス:Bedrockナレッジベースなど
- コーディング用ライブラリ:LangChainなど
- 抽象化してくれるので互換を持たせられる
- LLMOpsの流れ
- その1:監視
- メトリクス、ログ、トレースなどの主要項目を見ていく
- メトリクス:数値データ
- AWSであればCloudWatchがよく利用される
- SaaSであればLangSmithが有名
- OSSであればLangfuseが有名
- 自分のAWS環境に無料でデプロイすることが可能
- ログ:システムコンポートネントの動作記録
- トレース:アプリケーション動作がたどる流れ
- 中身的にはLangSmithと似ている
- メトリクス、ログ、トレースなどの主要項目を見ていく
- その2:評価
- 自動評価・人力評価を通じてLLMアプリを改善していく
- 評価エンジン:
- Ragasが有名
- LangChainが発表したOpenEvalsもある
- オンライン評価で利用できる
- Bedrockでも評価機能はあるがオフライン評価なのでリアルには向かない
- メトリクスを元に評価指標を設定することでレポート生成が可能
- 自動評価・人力評価を通じてLLMアプリを改善していく
- その3:プロンプト管理
- ざっくり言えば、最適な回答を導くためのプロンプトデータベース
- GitHubで管理するもの一つの手
- Langfuseの場合GUIlで操作できる
- ざっくり言えば、最適な回答を導くためのプロンプトデータベース
- その1:監視
- 業務で利用する場合
- セルフホスト用ににTerraform・AWSがコードを公開している
- 利用するのであればスモールスタートで行うのが吉
- 質疑応答
- LangSmith、Langfuseの使い分けは
- 正直好みによるがLangSmithの方が楽
- Langfuseのv3のホスティングの難しさ
- v3からデプロイするリソースが多くなり複雑化している
- 有志が公開しているGitHubをクローンして利用するのが吉
- LangSmith、Langfuseの使い分けは
LT
Amazon CodeGuruをGitHubと統合してアプリケーションの品質管理を楽にする
参考サイト
- 自己紹介
- BLUEISH所属のAIエンジニアの方
- 現在5個認定資格を保有している方
- Amazon CodeGuruとは
- 機械学習に基づくコードの脆弱性分析を行うもの
- CodeGuru Securityは開発向けで利用する
- 本番向けにはCode Profilerを利用する
- CodeGuru Security
- 基本的に開発で用いる言語は利用可能
- GitHub、VSCodeと統合させることも可能
- GutHubで実装する場合、WorkflowにGitHub Actionsのyamlファイルを作成する
- PRしたコード内に脆弱性がある場合、コメントしてくれる
- コメント内容に絵文字を入れることを可能
- LLM系ツールと組み合わせてみるのもありでは
- スキャンに時間がかかるため、重要度が高くないアプリ開発であれば入れないという選択肢も
AIを先生に~Slack × Bedrock で育成担当の人材不足解消を考える~
参考サイト
- 自己紹介
- アノテーション所属のエンジニア育成担当の方
- 背景
- AWSテクニカルサポート育成を行っているが教育対象が増えると人員リソースが
- 特に文章レビューが追い付ていない状況が発生していた
- AI活用すれば手軽に行えるのではと思い実装してみた
- AIトレーナー概要
- SlackでAIトレーナーにメンションすると回答する
- Slackで特定リアクションをつけるとリアクションに応じたレスポンスをAIが行ってくれる
- デモ
- 文章レビューもいい感じで行ってくれる
- 長文よりポイントごとにプロンプトを投げた方が精度が上がる
- 社内のヘルプデスク機能を持たせることもできるかもしれない
- まとめ
- 定期的なモデル評価を行うことが必要
- 最終チェックは人が行うことが大切(前段階はAIに任せるイメージ)
もしもマラソンランナーが operational investigations を有効化したら
参考サイト
- 自己紹介
- アイレット所属のエンジニアの方
- 好きなAWSサービスはCloudWatch
- マラソンとは
- 蓄えたエネルギーを消費して、どれだけ速くゴールまで身体を移動できるかを競っている
- 身体機能、トレーニング、環境などに応じて調整することが大切
- operational investigations
- ざっくり言えば、トラブルシューティングの手助けツール
- 人が行うのは内容精査などのコア部分
- ざっくり言えば、トラブルシューティングの手助けツール
- アプリに実装してみた
- 正常性確認をカメのイラストで表示している
- X-Ray、CloudWatchなど
- バグを仕込んでみた
- DynamoDBの場合:
- operational investigationsを利用することでDynamoDBにエラーが多数あるとキャッチしてくれる
- Lamdbaの場合:
- 不正な環境変数(被疑箇所)を見つけてくれる
- operational investigationsを利用しない場合、原因を特定するまでに至らなかった
- ※現在Preview版
- DynamoDBの場合:
Bedrockによるエラー通知のフィルタリング
参考サイト
- エラーログ痛での困りごと
- 警告レベルのログメッセージにerrorが含まれていることで通知されてしまう
- 改善しようすればアプリケーションログ自体の改善が必要
- フィルターパターンが複雑化してくる、定期的なリリースではすぐに対応できない
- ログ周りの悩み事をBedrockに任せてみた
- 試してみた結果
- Steb By Stepで判定する
- フィードバック内容から判定できない場合はTrueとする
- フィードバック内容の矛盾があれば最新情報を選択する
- 一部アプリケーションに関してはうまく通知フィルタリングできていなかったが、効率化ではできていた
元祖 AIOps!メトリクス異状検知からはじめよう〜さようなら Lookout for Metrics〜
参考サイト
- 自己紹介
- DataDoc所属のエンジニアの方
- Jr.Champion・Community Builderの方
- AIOpsについて考えてみる
- 2016年にガードナーから発表されたのが始まり
- それ以前からPoC的に利用していたケースはある
- AWSに関しては2023年から利用され始めた
- 当初出てきたLookOut3兄弟はサービス終了の波にのまれている
- Lookout for Metricsの良かったところ
- 黎明期は意外といいサービスではと言われたが、実態はそこまで使いどころがなかった
- 異常検知のモデルを作るよりプラットフォームにある機能をそのまま使う世界へ
- これからの異常検知
- 誰でも簡単に実装⇒改善できる形に
Amazon Bedrockガードレールで守る安全なAI運用
- 自己紹介
- BLUEISHの代表の方
- AIOps観点でのAI運用のポイント
- LLMの利活用が急増している
- 不適切なインプット・アウトプットを防ぐ必要がある
- Bedrockのガードレール機能が解決の糸口になる
- AI運用の課題
- 回答できないトピック管理:Denied Topicsでシステム的にブロック
- 不適切コンテンツの遮断:Contents filterで検出可能
- Bedrockの強みは事前防御
- アプリ側でブロックするロジックを実装しなくていいため開発コストを削減できる
- ユースケース
- 権限管理、変更管理、モニタリング強化など
- インシデント対応計画に基づいて運用サイクルを回していくことが大切
- まとめ
- Amazon Bedrockガードレール機能を利用すれば事前防御ができる
- 最終的には運用担当が運用ポリシーを見直してくことが大切
Amazon Q Developerを用いたAWS運用改善~自動化スクリプト生成~
- 自己紹介
- ガバメントクラウドに関する運用保守担当をしているアカウントSE
- 課題
- 管理対象が大量にあると運用が厳しくなる
- 最適化したいと思っているが難しいといった課題もある
- その一手としてAmazon Qが一手を打てるのではないか
- 機能紹介
- シンプルな英語でもいい感じのYAMLファイルを生成してくれる
- 人手をかけていた作業(コード資産の変換作業)をAIが代わりに行ってくれる
- ユースケース
- IaCを用いたアーキテクチャの自動化と最適化作業
- 依頼を行うだけで監視アーキテクチャを実装できた
- SSM Parameterのバックアップ処理最適化
- Shellへの理解が浅いメンバーだったためPythonに変えたかった
- メンバーからの要望もいい感じで汲み取ってくれる
- IaCを用いたアーキテクチャの自動化と最適化作業
- まとめ
- IaCの文脈であれば無料サービスで十分対応できるレベル
- 今後、システム開発・運用保守の在り方が変わってくると思っている
まとめ
AIOpsに関する知見は不足していたので、本セミナーを通じてナレッジを蓄積できたと思いまいsた。そのうえで、Langfuseに関してまったく触れていないので、近いうちに時間を作って触らないといけないと思いました!!
最後までお読みいただきありがとうございました!!