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

MLOpsを実現するSRE激闘の歴史

Avatar for Kenta Sato Kenta Sato
September 19, 2020

 MLOpsを実現するSRE激闘の歴史

XP祭り2020登壇資料
MLOpsを実現するSRE激闘の歴史

Avatar for Kenta Sato

Kenta Sato

September 19, 2020
Tweet

More Decks by Kenta Sato

Other Decks in Technology

Transcript

  1. ˜4UPDLNBSL *OD ࣗݾ঺հ • 佐藤 賢太 (@kenta_sato3) • 36歳 •

    2児の父 • 福岡出身 • 元野球選手(アメリカ・オーストラリア・スウェーデン) • コールセンター・企業向けUC (ユニファイドコミュニケーション)パッケージ製品べンダーのSEと して5年ほど経験し、2019年10月にストックマークにSREとして入社 • ストックマークではクラウド、AWSやGCP上でのシステム構築及び運用、SREやMLOpsに携わる
  2. © 2020 Stockmark Inc. 会社名 ストックマーク株式会社 Stockmark Inc. オフィス 東京都港区南青山1丁目12-3

    LIFORK MINAMI AOYAMA S209 設 立 2016年11月15日 創業者 代表取締役CEO 林 達 取締役CTO 有馬 幸介 事業内容 自然言語処理技術を活用した ビジネス意思決定サポートサービスの提供 従業員数 54名 (2020年6月 現在) URL http://stockmark.co.jp | 会社概要 会社概要
  3. ˜4UPDLNBSL *OD ໨࣍ • プロダクト概要 • システムアーキテクチャ概要とMLで実現したいこと • ML初心者SREがMLOpsに挑戦することになった背景 •

    MLOpsとはなにか、なぜ必要か • MLOpsを実現するSREの激闘の歴史 • 課題設定と継続的な改善 • これから
  4. ˜4UPDLNBSL *OD ࢲͷͦΕ·Ͱͷ.-஌ࣝ • DevOps実践 • MLシステム運用歴なし • MLは個人的に勉強(実務経験なし) •

    Coursera Machine Learning • Kaggleに登録したら次にやること ~ これだけやれば十分闘える Titanicの先へ行く入門 10 Kernel ~
  5. ˜4UPDLNBSL *OD .-0QTͱ͸ • 明確な定義はなく、Googleの人が提唱したのが最初(自分の観測範囲) • DevOpsのML版 • MLOpsは、MLシステム開発(Dev)とMLシステムオペレーション(Ops)を統合することを目的とし たMLエンジニアリングの文化と実践です。MLOpsを実践するということは、統合、テスト、リリー

    ス、デプロイ、インフラストラクチャ管理を含む、MLシステム構築のすべてのステップで自動化 とモニタリングを提唱することを意味します。 出典: MLOps: 機械学習における継続的デリバリーと自動化のパイプライン https://cloud.google.com/solutions/machine-learning/mlops-continuous-delivery-and- automation-pipelines-in-machine-learning?hl=ja
  6. ˜4UPDLNBSL *OD ͳͥ.-0QT͕ඞཁ͔ • 役割の溝 • データ収集 → データエンジニア •

    モデル構築 → データサイエンティスト • 本番運用 → ソフトウェアエンジニア、SRE • 同一の予測結果を得る難しさ • CACEの原則 • データや実験の管理 • 経済的な問題 • 継続的な学習とサービングの必要性 • 予測時のデータが学習時から変わってくる
  7. ˜4UPDLNBSL *OD .-0QTΩοΫΦϑϛʔςΟϯά • MLエンジニアの感じている課題感を共有してもらう • コードとモデルのCI/CD機構がほしい • ニュース記事のローデータ(HTML)が欲しい •

    オンプレで作成しているモデルのデプロイをもっといい感じにしたい • MLバッチシステムは構築済みなので、一緒にどこから手を付けて行けばよいかを深堀りすることに
  8. ˜4UPDLNBSL *OD ॳظߏ੒ͷ՝୊ • コード更新のたびに手作業であたたかみのあるデプロイ • EC2 x 2(CPU, GPUインスタンス)

    • SCPコマンドで開発環境からコードをアップロード • SCPコマンドでモデルのアップロード (合計10 GB超え) • SSHでEC2にログインし、Docker imageをビルド (1時間弱) • Lambda x 3にzipで固めたコードをコンソールからデプロイ • 直列で10種類のMLタスクを回すので実行時間が長くなる • デバッグが大変
  9. ˜4UPDLNBSL *OD ՝୊ઃఆᶃ 1. 継続的インテグレーション (CI) 機構がない。 → テストで防げるような不具合が検知できないため、デ プロイ後に発覚して手戻りが発生する。

    2. 継続的デプロイ (CD) 機構がない。 → デプロイ運用コストが大きく、かつ手動デプロイによるミスが 発生しやすい。 3. 監視機構がない。 → バッチ処理が無事完了したかどうかを毎日手動でElasticsearchとS3に確認しないと いけない。
  10. ˜4UPDLNBSL *OD $*$% $PEF .PEFM • CI • PR作成時にAWS CodeBuild上で自動テスト

    • CD • PRマージ • Lambda: Serverless Framework • EC2 • Python boto3のec2とssm • ML model • S3にpush • EFSへ同期し、EC2からマウント
  11. ˜4UPDLNBSL *OD ۤ࿑ͨ͜͠ͱ • 全体の構成の把握 • 構成図等はなく、MLエンジニアの頭の中をdumpしてまとめる作業 • Dockerビルドに長時間かかる •

    マルチスレッドのPythonスクリプトを書いて並列リモートビルド • EC2へのコード、モデルのデプロイ方法
  12. ˜4UPDLNBSL *OD ՝୊ઃఆᶄ • EC2インスタンスの管理が必要 • 新しいMLタスクができた時などは専用のEC2を立ててプロビジョニングする必要がある • 各EC2を起動するLambdaの作り込みが必要 •

    S3更新を起点で処理が走り、記事数が多い時は複数データファイルに分割して並列処理をするようにし ているが、lock制御などをシェルスクリプトで作り込む必要がある • 実行結果監視用機構を作り込む必要がある • 全体のフローの把握が困難
  13. ˜4UPDLNBSL *OD ղܾํ๏ • コンピューティング環境は、EC2からAWS Batchに移行する • EC2の管理が不要になる • Step

    Functionsから直接ジョブ登録できる • ワークフロー制御にはStep Functionsを使う • ワークフローを一元管理し、ジョブの依存関係(DAG)表現できる • フローの途中で通知処理を加えたい場合などに、アプリケーションロジックと分離して実装できる • 並列、配列処理やリトライ、例外処理がフローで実装でき、アプリケーションロジックをシンプル にできる • インフラはterraformでコード化する • インフラ構成をコードとしてドキュメント化 • 変更管理をGitでレビュー • インフラもCI/CDに組み込める
  14. ˜4UPDLNBSL *OD $*$% • GitHub & CodeBuild • ServerlssフレームワークでLambdaをデプロイ •

    Terraformでインフラ管理 • DockerfileやPipfile変更時にDockerイメージをビル ドし、ECRにPUSH • モデルはS3からEFSに同期
  15. ˜4UPDLNBSL *OD ޮՌ • 全体のフローが可視化できて良い • リトライ処理などをアプリケーションに組み込 む必要がなくなり、コードが減り保守しやすく なった •

    処理の途中経過をSNSに通知することで、他のア プリケーションが連携しやすくなった。 • トラブルシューティングが容易になった。 • MLタスクの追加が容易になった。
  16. ˜4UPDLNBSL *OD ՝୊ઃఆͱܧଓతͳվળ • なぜやるのかを明確にする • 「MLOpsをする」ことは目的ではない • ツールありきではない •

    ユーザー(MLエンジニア)と話したり、ボトルネックを特定し、課題を明確にする • どうやるのか • 自分のスキルで解決できそうな課題からやる。ドメイン知識やスキルが増えると徐々に他のところ にも手を出せるようになる。 • すぐに完璧を目指さない。