LoginSignup
15
18

More than 3 years have passed since last update.

@futakuchi0117(田林 伸一郎)

DevOps, MLOpsとは

Last updated at Posted at 2021-05-04

目次

  1. DevOps
    • DevOpsのない世界・ある世界
    • DevOpsを体現するにはどうすればいいのか？
    • DevOpsのためのツール
    • DevOpsのはじめかた
  2. MLOps
    • MLOpsのない世界・ある世界
    • MLOpsにより何が変わるのか
    • MLOpsとDevOpsの違い
    • MLOpsのためのツール
  3. 私たちにできること

1. DevOps

1.1 DevOpsとは

  • 開発 (Development) と運用 (Operations) を組み合わせた語
  • 開発者と運用者が効率的に連携するためのソフトウェア開発手法・活動・ツールの総称．文化のようなもの．
    • 明確な定義はない
  • 狭義には，システムへの変更をコミットしてから通常の運用に移るまでの時間を短縮することを目的とした一連のプラクティスのこと1
  • 初めてDevOpsという言葉が使われたのは，「10+ Deploys Per Day」というプレゼン

2021-05-05_06-12.png

1.2 DevOpsのない世界，ある世界

※　極端な例です．ない世界が完全にダメというわけでもありません

項目 DevOpsのない世界 ある世界
バージョン管理 フォルダ名にバージョン名や作成日時を記入することでバージョン管理する．
複数人が同じコードを編集することがあり，競合がしばしば発生している．		 Gitを使用し，問題がある場合には適切にロールバックする．
明確なブランチ戦略のもとでコミットやプルリクエストが小まめに行われており，競合はほとんど発生しない．
環境構築 サービスが依存するアプリケーションはインストール手順書を見ながらサーバー上に直接インストールする．長大な手順書のメンテナンスに工数がかかっている． サービスはコンテナ上で動作する複数のマイクロサービスからなる．プロビジョニングもInfrastructure as Codeで自動化されており，手順書は簡潔．
テスト・ビルド 手動でコマンドを実行する． GitプッシュをトリガーとしてCIツールが自動的に実行する．
デプロイ デプロイ時はサーバーの一般公開を一旦止めて，本番サーバーでデプロイ・テストを行い，問題なければサーバーを公開する． stagingブランチへのマージと同時にステージング環境へのデプロイが開始され，masterブランチへのマージと同時に自動で本番環境のローリングアップデートが実施される．
チーム体制 開発チームと運用チームが独立しており，コードの引き継ぎの機会を除いて連携はほとんどない． どのチームのメンバーもフルサイクルエンジニアとして開発運用両方の知見を有している．
文化 運用チームは開発チームの頻繁な仕様変更にうんざりしている．変更が原因の不具合によってサービスが停止するたびに非難の応酬が起きている． 自動テストとステージング環境での検証により，本番環境で不具合が発生する頻度は非常に低い．定期的に開かれる成果報告会では互いの成果を発表し，今後の改善点を話し合う．

1.3 DevOpsを体現するにはどうすればいいのか？

DevOpsツールを使えばDevOpsが体現できるのか？　⇨　No！

DevOpsの実践のためのフレームワークがいくつか提唱されています．

  • The Three Ways （著名な本「The DevOpsハンドブック」に基づく）
    • 1st way: 開発のリードタイムの短縮
    • 2nd way: 本番環境やユーザーからのフィードバック
    • 3rd way: 継続的な実験と検証
  • CALMSモデル
    • Culture（カルチャー）… 開発，運用チームで協力して目的を達成する組織文化
    • Automation（自動化）… 自動化できるものは自動化する
    • Lean（リーン）… ミーティング，手続きなどの無駄を排除する
    • Measurement（測定）… 指標を厳選し，それらを常に確認できるようにする
    • Sharing（共有）… 開発・運用チームの継続的なコミュニケーションと知見の共有

Culture

  • 文化はDevOpsの基盤です
    • 文化を省略してDevOpsのツールを使っても，本来の目的（リードタイムの短縮）への効果は限定的です．
    • 自己組織化をチームの原動力とし，開発と運用の間の壁を明示的に壊す文化が必要です．
  • Conwayの法則
    • 「組織の設計するシステムは，その組織の構造をそのまま反映した設計になる」
    • 例：縦割りの組織からは依存関係の少ない，共有モジュールもないマイクロサービス群が生まれる
  • 組織文化
    • お互いを尊重する，能力や功績を評価する
    • お互いを信頼する，信じて仕事を任せる
    • 失敗に対して，次に同じ問題が起こらないための対策を共有する

Automation

  • これはDevOpsの花形であり，実践の仕方が比較的わかりやすい部分です．
  • 自動化の中心にあるのはCI / CDパイプラインです．
  • 継続的インテグレーション（CI）とは，継続的(Continuous)にコード全体が機能するようにする（Integration）仕組みのことです．
    • コードの細かな変更をすぐに確認して最新バージョンをビルドする
    • 一連のテストを実行する
    • テストが失敗した場合はチームに通知される
  • 継続的デリバリー（CD）とは，テストが通ったときに本番環境へのデプロイ（Delivery）を自動で行う仕組みのことです．

Lean

  • リーンソフトウェア開発は，トヨタ生産方式（TPS）を参考に考案された開発手法のひとつです．
  • リーンとは，開発フローを改善して無駄を最小化しながら，顧客価値を最大化することです．
    • leanという単語には「ぜい肉がなく引き締まって痩せている」といった意味があります．
  • ソフトウェア開発におけるムダの例は以下のような部分で発生します．
    • 未完成の作業（テストされていないコード，開発待ちの仕様）
    • 使われないコードや余分な機能
    • 更新されないドキュメント
    • 余分なプロセス（不要な承認作業）
    • スタッフが複数のプロジェクトを担当することによるコンテキストスイッチの発生
    • 欠陥（要件の欠陥，ソフトウェアのバグ）

Measurement

  • これは改善に不可欠です．プロセスのメトリックを定義します．
    • 組織で物事はどのくらいうまくいっていますか？
    • 改善の余地はどこにありますか？
  • 例えば，Accelerate: State of DevOps では，DevOpsに関する以下の4つの指標を世界の様々な企業で調査いています：
    1. デプロイの頻度
    2. 変更のリードタイム
      • コードのコミットから本番環境でサービスが正常に実行されるまでの時間のこと
    3. 平均修復時間
      • サービスインシデントが発生したときに，復元するのにかかった時間
    4. 変更失敗率
      • 本番環境にデプロイしたあとで，修復を必要とするものの割合

Share

  • 共有とは，CALMSサイクルのフィードバック・ループを意味します．
  • チームがアイデアや問題を共有しあう文化を醸成するのは，対話と協業を促進するだけではなく，組織全体の改善を進めるのに重要です．

1.4 DevOpsを支えるツール類

かなり多いのでごく一部の紹介だけにとどめます．（間違った分類が多々あるかと思います．ごめんなさい…）

  • バージョン管理システム
    • Git (GitHub, GitLab)
    • ブランチ管理手法
      • Git Flow: 5つのブランチによるバージョン管理
  • チケット管理システム
    • Jira, Backlog, Redmine
  • 仮想化とコンテナ
    • Vagrant, Docker … CDの基盤にもなる
    • コンテナオーケストレーション
      • Kubernetes, Mesos, Docker swarm
  • 継続的インテグレーション
    • Circle CI, Jenkins, GitHub Actions, Gitlab CI, etc
  • 自動ビルド
    • AWS CodeBuild, Google Cloud Build
  • テスト
    • インフラ環境のテスト
      • Serverspec, TestKitchen, Ingrataster
    • 受け入れテスト自動化
      • Cucumber, RSpec, selenium, Capybara
  • Infrastructure as Code (IaC)
    • Pupet, Chef, Ansible, AWS CDK, GCP Deployment Manager, Terraform
  • モニタリング
    • AWS CloudWatch, GCP Stackdriver, その他たくさん
  • コミュニケーション，コラボレーション
    • Slack, Teamsなど
  • メッセンジャーBot
    • SlackやTeamsなどのwebhook, AWS SNS, Line Botなどいろいろ

1.5 DevOpsのはじめかた

  1. Study
    • 情報収集
  2. Practice
    • 実践
    • 評価と振り返り

これらを繰り返し，定着させる．

まずは計測より始めよ

Accelerate: State of DevOps では4つの指標を世界の様々な企業で調査した結果が示されていました

指標 エリートパフォーマー ハイパフォーマー ミディアムパフォーマー ローパフォーマー
デプロイの頻度 オンデマンド（複数回/日） １回/時間〜１回/日 １回/週〜１回/月 １回/週〜１回/月
変更のリードタイム 〜１時間 １日〜１週間 １週間〜１ヶ月 １ヶ月〜６ヶ月
平均修復時間 〜１時間 〜１日 〜１日 １週間〜１ヶ月
変更失敗率 0~15% 0~15% 0~15% 0~15%

例：これらを計測することから始め，DevOpsの導入によってこれらがどう変化したかを観測し，チームを全員エリートパフォーマーにすることを目標に活動する．

2. MLOps

2.1 はじめに

  • OVERFLOWでは，機械学習プロジェクトの87％が，redaptでは90％が本番環境に到達しないと報告されています．
  • どちらも，成功と失敗の違いを生む重要な要素は，チームとして協力して高速にイテレーションを回す能力であることを強調しています．
  • データサイエンティストは実世界のデータを表現および予測するモデルの作成に優れていますが，機械学習モデルを効果的に実装するためには全く別の能力，すなわち高度なソフトウェアエンジニアリングと，DevOpsとして知られるスキルが必要です．

2.2 機械学習プロジェクトの何が大変なのか

下図に示すように，ML システムの中で MLコードで構成されているものはごく一部です．

20200904093850.png

画像引用："Hidden Technical Debt in. Machine Learning Systems", D.Sculley NIPS 2015

システムの残りの部分は，システム構成，自動化，データ収集，データ検証，テスト・デバッグ，リソース管理，モデル解析，プロセス管理，メタデータ管理，インフラストラクチャのプロビジョニング，モニタリングなどです．

このような複雑なシステムを開発運用するため，DevOps を ML システムに適用したのがMLOpsです．

2.3 MLOpsとは

2.4 MLOpsのない世界，ある世界

項目 MLOpsのない世界 ある世界
データの管理 全データは社内のサーバーに保存されており，分析に用いるデータは一度ハードディスクに移して開発チームに郵送する． 全データはクラウドに保存されており，分析時には必要なサブセットをSQLで取得する．
ハイパーパラメータチューニング ハイパーパラメータやデータの組み合わせを手動で書き換えながら，MLモデルを学習・評価する． 実験管理ツールを用いてモデル開発を行う．ハイパーパラメータの探索には数理最適化を使用している．
MLプロセス 分析メンバーはパラメータを変更するごとに，jupyter notebookに記述された前処理・学習・評価の一連のMLテストを順番に実行する． MLプロセスは統合・自動化されており，学習・テストのイテレーションは高速に実行される．
デプロイ 推論モデルの実装時には，学習に用いるノートブックとrequirements.txtを実装メンバーに渡し，実装メンバーは推論コードを抽出した上で，Flaskなどを用いて推論用web APIサーバーを構成する． 推論用web APIサーバーへのデプロイは CI/CD ツールを通じて自動化されており，GCPのAI Platform predictionにより推論エンドポイントを作成するため，メンバーは機械学習モデルの作成に集中することができる．
継続的学習 モデル開発には月単位の時間がかかるため，モデルの再トレーニングはほとんど行わない． 常に環境の変化に対応するため，定期的に最新のデータを用いて再学習が行われる．
CI/CD モデルの更新はほとんどないため，CI, CDは考慮されない． 新しいデータでトレーニングされたモデルは自動的に精度検証・テスト・デプロイ対象となる．
監視 モデルのパフォーマンス低下などを検出するためのモニタリングは行わないため，環境のダイナミクスの変化に対して脆弱． ライブデータに基づいてモデルのパフォーマンスに関する統計情報を収集する．パフォーマンスが一定の水準に満たない場合，再学習パイプラインが自動的に実行される．

2.5 MLOpsにより何が変わるのか

  1. 機械学習モデルのローンチ頻度
  2. 機械学習モデルの変更のリードタイム
    • 学習，評価，コードのテスト，デプロイに至るまでの時間
  3. 実験の再現性と品質の担保
    • コード・ハイパーパラメータ・モデル・データ・実験結果の整合性が取れたバージョン管理

他にも色々あると思いますが，主に上３つだと考えます．

2.6 MLOpsのワークフロー

MLOpsのワークフローは、MLモデルの構築やテスト，デプロイ，監視，更新といった作業を簡素化・自動化することです．

2021-05-05_07-54.png

MLOpsの成熟度

Google Cloudのドキュメントによれば，上で挙げたMLの手順の自動化レベルによって，MLプロセスの成熟度が決まります．

  • MLOps level 0: Manual process
    • 自動化を含まない
  • MLOps level 1: ML pipeline automation
    • MLパイプラインを自動化　（上図の緑色の範囲）
  • MLOps level 2: CI/CD pipeline automation
    • MLパイプラインおよびCI/CDパイプラインを自動化　（上図のオレンジの範囲）

2.7 MLOpsとDevOpsの違い

  • CI (Continuous Integration) は，もはやコードやコンポーネントのテストだけではなく，データ形式とモデルのテストや検証も重要な要素となっています．
  • CD (Continuous Delivery) は，単一のソフトウェアパッケージやサービスのデプロイだけでなく，MLトレーニングパイプラインを含むようになります．
  • CT (Continuous Training) はMLシステムに特有の目新しい項目であり，モデルを自動的に再トレーニングし，(システムにデプロイすることで) 予測サービスを提供できる状態にすることを目的とします．
  • CE（Continuous Evaluation; 継続的評価）は稼働中の推論モデルの精度をリアルタイムに監視する仕組みです．これにより機械学習システムの品質劣化を検知することを可能にします．
    • このような品質劣化は，環境のダイナミクスの変化によりしばしば引き起こされます．

2.7 MLOpsを支えるツール

こちらも多いので軽く列挙するだけにとどめます．大事なツールが抜けていたり，分類が間違っているものがあると思います．ごめんなさい

  • DevOpsで紹介したツール類すべて
  • モデルサービング
    • Flask, FastAPI, TensorFlow Serving, TorchServe, Triton Inference Server, OpenVINO, KFServing, BentoML, AI Platform Prediction, Sagemaker, etc
  • 機械学習プラットフォーム：マネージドなML, CI/CDパイプラインの提供
    • AWS Sagemaker, GCP AI Platform, Azure Machine Learning, Kubeflow
  • 実験管理ツール
    • MLFlow, Trains, comet, neptune, etc
  • パイプライン管理ツール
    • Apache Airflow, digdag, Metaflow, Kedro, Pipeline X, etc
  • 分析・モデリングツール
    • Jupyter
  • ハイパーパラメータ最適化
    • Scikit-Optimize, Optuna
  • データ収集・管理
    • AWS, GCP, Azureなどクラウドサービスに多数

3. 私たちにできること

  • まずは計測より始めよ
    • Accelerate: State of DevOps で4つの指標が調査されていたように，①何らかの指標を定め，②計測し，③DevOps, MLOpsを実践し，④指標の変化を観察する．
  • 挑戦し，振り返り，人生を豊かなものにする

参考

この記事の主な情報源です

  • The DevOps ハンドブック 理論・原則・実践のすべて
    • DevOps の理論と実践について解説した本．「3 つの道」を中心とした原則のほか，Google などの企業の具体例が書かれている．
  • Google Cloud
    • DevOps, MLOpsともに良質なドキュメントが揃っている．GCPでの実践例も紹介されている．
  • Accelerate: State of DevOps
    • DORA社（現在はAlphabetの子会社）がGoogle Cloudと共同で実施したDevOpsの動向の調査レポート．似たようなレポートは他社も色々出している．

免責事項

  • この記事の内容は間違いを含む可能性があります．この記事の内容によって生じた直接的・間接的な損害に対し，一切の責任を負いかねますのでご了承ください．

  1. https://ja.wikipedia.org/wiki/DevOps ↩

15
18
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
15
18