Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AIアプリを支えるチームの最適な開発環境を整備する / / Optimizing AI Development Environment with Platform/DevOps Engineers

Kodai Sakabe
February 20, 2024
98

AIアプリを支えるチームの最適な開発環境を整備する / / Optimizing AI Development Environment with Platform/DevOps Engineers

Microsoft AI Tour Tuesday, Feb 20
https://envision.microsoft.com/ja-JP/sessions/3bd5b460-a8fe-406c-8d5a-f7268b6afb9a?source=sessions

AIを使ったアプリを開発する際に個々のソフトウェアエンジニアにどのような環境を用意していますか?これまでローカルPC上の環境だけで開発できたソフトウェアエンジニアは、このAIの時代で様々なAPI連携、ミドルウェア、大規模データを利用することになり、開発環境が複雑になりました。これまでの開発生産性を落とさない AI 時代に必要な開発環境について、これまでチーム開発の環境作りで挑戦と失敗ししながら改善を行っていた経験を元にプラットフォームエンジニアやDevOps、インフラエンジニアからみた視点でご紹介できればと思います。

Kodai Sakabe

February 20, 2024
Tweet

More Decks by Kodai Sakabe

Transcript

  1. 12:50 PM-1:05 PM 本セッションについて  話すこと  AI アプリにおける CICD

    とフィーチャーフラグ  Azure におけるマネージドサービスから OSS まで様々な手段を紹介  Radius / OpenFeature / Azue Development Environment  話さないこと  Azure OpenAI といった AI 関連のマネージドサービス  本番環境のリファレンスアーキテクチャ  Azure 以外の Microsoft の製品 資料は Speaker Deck サンプルコードは GitHub でご確認いただけます AI を組み込んだアプリは、従来のアプリケーションに比べて複雑なアーキテクチャになることは避けられません。
  2. 12:50 PM-1:05 PM Agenda  AI アプリの特徴  Developer Environment

     Azure Developer  Appendix  OpenFeature  Radius
  3. 12:50 PM-1:05 PM AI とアプリの境界点 データフローの分離 Baseline OpenAI end-to-end chat

    reference architecture https://learn.microsoft.com/azure/architecture/ai-ml/architecture/baseline-openai-e2e-chat
  4. 12:50 PM-1:05 PM 本番環境での変化(主に見直しされるポイント) SLO  AI とアプリでアーキテクチャ を疎結合 

    それぞれスケールできるアー キテクチャ  セキュリティとガバナンス対 策、ネットワークを準備  ミドルウェアや API 外部連 携による SLA の低下 Cost  新規ミドルウェア  外部連携  データ量  ネットワーク  モデル  セキュリティ End-to-end simulation  モデル調製  カテゴリ  評価  Side-by-side  プロンプト  OpenFeature CICD  新規デリバリー  ミドルウェアの CICD  A/B テスト  データによる意思決定
  5. 12:50 PM-1:05 PM Building for the future: The enterprise generative

    AI application lifecycle with Azure AI https://azure.microsoft.com/en-us/blog/building-for-the-future-the-enterprise-generative-ai-application-lifecycle-with-azure-ai/
  6. 12:50 PM-1:05 PM Achieve generative AI operational excellence with the

    LLMOps maturity model https://azure.microsoft.com/blog/achieve-generative-ai-operational-excellence-with-the-llmops-maturity-model/
  7. 12:50 PM-1:05 PM Initial  様々な発表がある中で使 うモデルを決め、サービスへ の導入開始  ガイダンスやドキュメントを

    見つけること自体が難しい 状態ながらモニタリング Defined  新製品やフレームワークのコ ンポーネントの正しい組み 合せ改善  RAG などの組み合わせを 行い、制度の改善開始 Managed  大規模言語モデルは固有 のデータは知らないことから Prompt の改善と評価を リアルタイムで実施。  さまざまなユースケースにモ デルの最適化 Optimized  ソリューション全体としてプ ライバシー、セキュリティ、ガ バナンスの整備  ソリューション全体として評 価、改善、検証するための 経験やツール  スケールと運用経験の知 見を専用 CICD までの仕 組み LLMOps におけるレベル別 Achieve Generative AI operational excellence with the LLMOps maturity model https://azure.microsoft.com/blog/achieve-generative-ai-operational-excellence-with-the-llmops-maturity-model/
  8. 12:50 PM-1:05 PM 組織のパフォーマンスに 影響ある Four keys metrics Deployment frequency

    デプロイの頻度 Change lead time コード変更からデプロイするまでの時間 Change failure rate デプロイによる障害率 Failed deployment recovery time デプロイ失敗から復旧にかかる時間 Accelerate State of DevOps 2023 P12 https://cloud.google.com/devops/state-of-devops
  9. 12:50 PM-1:05 PM 継続的改善の仕組みを導入期に作れるかが重要 Initial  様々な発表がある中で使 うモデルを決め、サービスへ の導入開始 

    ガイダンスやドキュメントを 見つけること自体が難しい 状態ながらモニタリング Defined  新製品やフレームワークのコ ンポーネントの正しい組み 合せ改善  RAG などの組み合わせを 行い、制度の改善開始  Developer experience Managed  大規模言語モデルは固有 のデータは知らないことから Prompt の改善と評価を リアルタイムで実施。  さまざまなユースケースにモ デルの最適化  Feature flag で on/off  シームレスな Demo Optimized  ソリューション全体としてプ ライバシー、セキュリティ、ガ バナンスの整備  ソリューション全体として評 価、改善、検証するための 経験やツール  スケールと運用経験の知 見を専用 CICD までの仕 組み Achieve Generative AI operational excellence with the LLMOps maturity model https://azure.microsoft.com/blog/achieve-generative-ai-operational-excellence-with-the-llmops-maturity-model/ 継続的改善の仕組み準備
  10. 12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。

    Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal (https://devportal.microsoft.com/) Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion
  11. 12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。

    Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal (https://devportal.microsoft.com/) Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion
  12. 12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。

    Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal (https://devportal.microsoft.com/) Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion
  13. 12:50 PM-1:05 PM Azure Developer を支える開発環境 Dev Center Microsoft Dev

    Box ならびに Azure Deployment Environments をプロジェクト単位 にまとめチーム利用可能にし、開発者ポータルを提 供。 Azure Deployment Environments 専用の環境を新規作成。 ARM テンプレートなら びに Azure RBAC の利用できるためセルフサービス ができる Microsoft Dev Box イメージギャラリーを使った VM 起動 GitHub Codespaces Remote Container Azure Virtual Desktop Windows DaaS 環境。マルチセッション可能 Windows 365 マネージド AVD に近いビジネスユーザー利用 DevTest Lab 2016 年リリースした開発用 VM
  14. 12:50 PM-1:05 PM Azure Developer を支える開発環境 Dev Center Microsoft Dev

    Box ならびに Azure Deployment Environments をプロジェクト単位 にまとめチーム利用可能にし、開発者ポータルを提 供。 Azure Deployment Environments 専用の環境を新規作成。 ARM テンプレートなら びに Azure RBAC の利用できるためセルフサービス ができる Microsoft Dev Box イメージギャラリーを使った VM 起動 GitHub Codespaces Remote Container Azure Virtual Desktop Windows DaaS 環境。マルチセッション可能 Windows 365 マネージド AVD に近いビジネスユーザー利用 DevTest Lab 2016 年リリースした開発用 VM
  15. 12:50 PM-1:05 PM Deploy environments in CI/CD by using GitHub

    GitHub Actions で環境の構築 https://devportal.microsoft.com
  16. 12:50 PM-1:05 PM Dev Centers / Azure Deployment Environments 

    Dev Center からプロジェクトが作られ、配下にリソースグループ、サブスクリプシ ョン等が紐づけされる  Azure Deployment Environments は、 azd で作れる環境を Dev Center 配下に provisioning する  リソースグループに環境ができるため  リソースグループ単位でコスト管理ができる  リソースグループ単位で権限も管理ができる  Developer portal ができ、 Ops や Infra エンジニアによって IaC や Azure portal 上で厳密に管理された領域を触れずに利用できる  開発チーム単位または個人単位で Azure 全体を利用実現
  17. 12:50 PM-1:05 PM 継続的改善の仕組みを導入期に作れるかが重要 Initial  様々な発表がある中で使 うモデルを決め、サービスへ の導入開始 

    ガイダンスやドキュメントを 見つけること自体が難しい 状態ながらモニタリング  Developer experience Defined  新製品やフレームワークのコ ンポーネントの正しい組み 合せ改善  RAG などの組み合わせを 行い、制度の改善開始 Managed  大規模言語モデルは固有 のデータは知らないことから Prompt の改善と評価を リアルタイムで実施。  さまざまなユースケースにモ デルの最適化  Feature flag で on/off  シームレスな Demo Optimized  ソリューション全体としてプ ライバシー、セキュリティ、ガ バナンスの整備  ソリューション全体として評 価、改善、検証するための 経験やツール  スケールと運用経験の知 見を専用 CICD までの仕 組み Achieve Generative AI operational excellence with the LLMOps maturity model https://azure.microsoft.com/blog/achieve-generative-ai-operational-excellence-with-the-llmops-maturity-model/ 継続的改善の仕組み準備
  18. 12:50 PM-1:05 PM 本セッションについて  話すこと  AI アプリにおける CICD

    とフィーチャーフラグ  Azure におけるマネージドサービスから OSS まで様々な手段を紹介  Radius / OpenFeature / Azue Development Environment  話さないこと  Azure OpenAI といった AI 関連のマネージドサービス  本番環境のリファレンスアーキテクチャ  Azure 以外の Microsoft の製品 資料は Speaker Deck サンプルコードは GitHub でご確認いただけます AI を組み込んだアプリは、従来のアプリケーションに比べて複雑なアーキテクチャになることは避けられません。
  19. 12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。

    Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal (https://devportal.microsoft.com/) Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion
  20. 12:50 PM-1:05 PM OpenFeature What's a Feature Flag?  フィーチャーフラグは、ソースコード

    を変更することなく、製品やサー ビスの特定の機能やコードパス の動作を有効化、無効化、変 更することを可能にするソフト ウェア開発手法 What's OpenFeature?  OpenFeature は、コミュニティ 主導のフィーチャーフラグのAPIを 提供する CNCF Sandbox で あり、フラグ管理ツールと連動で きる Why standardize?  フィーチャーフラグを標準化するこ とで、ツールやベンダーを共通の インターフェイスで統一し、コード レベルでのベンダーロックインを 避けることができる。また、コミュ ニティ全体で共有できる拡張 機能や統合機能を構築するた めのフレームワークを提供する。 https://openfeature.dev/
  21. 12:50 PM-1:05 PM リアルタイムのフラグ管理 main.go func main() { // Use

    flagd as the OpenFeature provider openfeature.SetProvider(flagd.NewProvider()) // Initialize OpenFeature client client := openfeature.NewClient("GoStartApp") // Initialize Go Gin engine := gin.Default() // Setup a simple endpoint engine.GET("/hello", func(c *gin.Context) { // Evaluate welcome-message feature flag welcomeMessage, _ := client.BooleanValue( context.Background(), "welcome-message", false, openfeature.EvaluationContext{}, ) if welcomeMessage { c.JSON(http.StatusOK, gin.H{"message": newWelcomeMessage}) return } else { c.JSON(http.StatusOK, gin.H{"message": defaultMessage}) return } }) Client と Provider(flagd) 導入 Sample https://github.com/koudaiii/gostart
  22. 12:50 PM-1:05 PM flagd server https://github.com/open- feature/flagd OpenFeature 公式のフラグ管理 のプロバイダー。

    json ファイルと docker run するだけ。 プロバイダー用 SDK があるため自 作可能。クライアント側でイベント 、フックが提供されているため、イ ベント駆動で処理を追加すること やプロバイダーのステータスからハン ドリング可能。 Flags.flagd.json { "flags": { "welcome-message": { "variants": { "on": true, "off": false }, "state": "ENABLED", "defaultVariant": "off" } } } “on” にファイル上書きで無停止切替
  23. 12:50 PM-1:05 PM 新しい機能をサービスに安全に追加するための9つのステップ 1. Create a new runtime configuration

    directive : 新しい機能のための config を作成し、 default は false に設定。 2. Release a new binary : 参照がない状態でリリース 3. Update the configuration file : config を更新して見えるようにする。ユーザーの導線なし。 4. Update the canary jobs : カナリージョブのみで config を有効にする 5. Update all jobs : 全部公開。この時点で新しい機能が有効。 6. Change the default flag value : flag を default で true になるように変更。 7. Update the configuration file again : config を更新して、 config 参照をなくします。 8. Edit the conditional code execution : 条件付きのコード実行を常に実行するように編集します。 9. Remove the now-unused code : 今は使われていないコードを削除します。 https://www.usenix.org/system/files/login/articles/login_1410_05_klein.pdf Daniel V. Klein、Dina M. Betser、Mathew G. Monroe
  24. 12:50 PM-1:05 PM OpenFeature  AI の機能を安全にリリースするためのフィーチャーフラグ  リアルタイムで制御可能な仕組み 

    その他 secrets や環境変数と分離できる  最適なモデル検証のため flag 利用  API on/off  プレビュー機能として実現 on/off
  25. 12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。

    Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal (https://devportal.microsoft.com/) Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion
  26. 12:50 PM-1:05 PM Why is building and running microservice apps

    hard?  Complex architectures  Cross-platform portability Enforcing best-practices Troubleshooting experiences
  27. 12:50 PM-1:05 PM Envrironment XXX_URL には、 接続可能であ れば、 Docker や

    AWS RDS や Azure SQL DB 利用可能であり 、 Application と Environment が切り離されている状態を radius が行っている。 func main() { ctx := context.Background() // cf. "sqlserver://sa:pa@localhost:1433?database=db" mssqldbURL := os.Getenv("MSSQL_SERVER_URL") // Open a MSSQL database. sqldb, err := sql.Open("sqlserver", mssqldbURL) if err != nil { panic(err) } ・・・ main.go
  28. 12:50 PM-1:05 PM rad init Console on MacOS $ curl

    -fsSL "https://raw.githubusercontent.com/radius-project/radius/main/deploy/install.sh" | /bin/bash $ rad init Initializing Radius. This may take a minute or two... Install Radius v0.30.0 - Kubernetes cluster: minikube - Kubernetes namespace: radius-system Create new environment default - Kubernetes namespace: default - Recipe pack: local-dev Scaffold application first-app Update local configuration Initialization complete! Have a RAD time
  29. 12:50 PM-1:05 PM radius-system and recipes Console on MacOS $

    kubectl get deployments -n radius-system NAME READY UP-TO-DATE AVAILABLE AGE applications-rp 1/1 1 1 2d21h bicep-de 1/1 1 1 2d21h contour-contour 1/1 1 1 2d21h controller 1/1 1 1 2d21h ucp 1/1 1 1 2d21h $ rad recipe list RECIPE TYPE TEMPLATE KIND TEMPLATE VERSION TEMPLATE default Applications.Datastores/redisCaches bicep ghcr.io/radius-project/recipes/local-dev/rediscaches:0.30 default Applications.Datastores/sqlDatabases bicep ghcr.io/radius-project/recipes/local-dev/sqldatabases:0.30 default Applications.Messaging/rabbitMQQueues bicep ghcr.io/radius-project/recipes/local-dev/rabbitmqqueues:0.30 default Applications.Dapr/pubSubBrokers bicep ghcr.io/radius-project/recipes/local-dev/pubsubbrokers:0.30 default Applications.Dapr/secretStores bicep ghcr.io/radius-project/recipes/local-dev/secretstores:0.30 default Applications.Dapr/stateStores bicep ghcr.io/radius-project/recipes/local-dev/statestores:0.30 default Applications.Datastores/mongoDatabases bicep ghcr.io/radius-project/recipes/local-dev/mongodatabases:0.30
  30. 12:50 PM-1:05 PM radius getting started guide app.bicep import radius

    as radius @description('The Radius Application ID. Injected automatically by the rad CLI.') param application string resource demo 'Applications.Core/containers@2023-10-01-preview' = { name: 'demo’ properties: { application: application container: { image: 'ghcr.io/radius-project/samples/demo:latest’ ports: { web: { containerPort: 3000 } } } } } https://docs.radapp.io/getting-started/
  31. 12:50 PM-1:05 PM connection rad run app.bicep $ rad run

    app.bicep Building app.bicep... Deploying template 'app.bicep' for application 'first-app' and environment 'default' from workspace 'default'... Deployment In Progress... Completed db Applications.Datastores/redisCaches . demo Applications.Core/containers Deployment Complete Resources: demo Applications.Core/containers db Applications.Datastores/redisCaches Starting log stream... + redis-r5tcrra3d7uh6-5489d59f5-2gmbw › redis + redis-r5tcrra3d7uh6-5489d59f5-2gmbw › redis-monitor https://docs.radapp.io/getting-started/ https://github.com/koudaiii/first-app
  32. 12:50 PM-1:05 PM Radius  マイクロサービスで複雑になったアーキテクチャをシンプルなプラットフォーム実現  軽量の Kubernetes を利用して

    GitHub Codespaces 上で実行可能  Kubernetes を利用した開発環境  Bicep を local に対して実行するため、 Bicep がよりインフラからアプリエンジニ アに対して利用しやすい  Application と Environment を分離、 Environment は rad switch コマン ドで環境切替