新卒3年目の後悔〜機械学習モデルジョブの運用を頑張った話〜

新卒3年目の後悔〜機械学習モデルジョブの運用を頑張った話〜 DATUM STUDIO株式会社データエンジニア部亀井友裕 2025/6/19 白金鉱業 Meetup Vol.19@六
本木（若手データサイエンティスト交流会）

© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 1
今回話すこと、話さないこと話すこと話さないこと機械学習モデルの運用が辛かった話（経緯と結果、反省とか）機械学習モデルの運用でうまくいった部分（成功には再現性がないが、失敗には再現性がある）

自己紹介亀井友裕（社会人4年目）会社 DATUM STUDIO 株式会社主な業務経験データパイプラインの構築（Databricks）需要予測モデルの運用（Databricks） RAGの精度改善（AWS）コミュニティ SnowVillage（Snowlfakeユーザー会） JEDAI（Databricksユーザー会） X @Camay119 （アイコンは→）

経緯 • 新卒2年目の終わり頃 • 機械学習モデル開発案件にジョイン • 1つの環境にて、2人のメンバーで開発を進める • 新卒3年目に入り、上記案件が運用フェーズに移行 • 運用メンバーのジョインを見据えて、環境を分離しよう！

環境分離をしました dev, stg, prdに環境分離（画像はイメージです） https://docs.databricks.com/aws/en/machine-learning/mlops/mlops-stacks

想定していた環境の使われ方開発環境で動作確認 → 検証環境でテスト → 本番リリースというオーソドックスな流れを想定具体的な運用ルールは決めず、とりあえず運用を開始 https://docs.databricks.com/aws/en/machine-learning/mlops/mlops-stacks ✓ 開発環境 * 機能の開発 & 軽い動作確認 ✓ 検証環境 * 本格的なテスト（あわよくば自動化） ✓ 本番環境 * バグが出ないようにしたい

よし！環境分離もできたし、運用頑張っていくぞ！！

実際の環境の使われ方やりたかったことが全く達成されない地獄のような開発フロー https://docs.databricks.com/aws/en/machine-learning/mlops/mlops-stacks ✓ 開発環境（想定内） * 機能の開発 & 軽い動作確認 ➢ 使われない検証環境（想定外） * 「devで動作確認したので大丈夫です」 ➢ バグが発生しまくる本番環境（想定外 and ヤバい） * 正常性を担保するため、ジョブ実行とダッシュボードを目検で確認 & slackにスクショ掲載(ツラい) *問題が発生すればhotfixで直す ➢ 無駄に煩雑なデプロイ手順 * 検証環境なんて使われてないのに、なんでstg用のconfig書き換えて stgブランチにPR出すんだ...

モヤつきを言語化できないまま約6ヶ月運用を続け、結局そのまま運用を別担当に引き継いでしまった...

一体何が悪かったんだろう…

PJ離脱から半年、当時の状況を改めて整理して一つの結論にたどり着いた

それは…

https://docs.databricks.com/aws/en/machine-learning/mlops/mlops-stacks ✓ 開発環境（想定内）機能の開発 & 軽い動作確認 ➢ 無駄に煩雑なデプロイ手順 * 検証環境なんて使われてないのに、なんでstg用のconfig書き換えて stgブランチにPR出すんだ... ➢ バグが発生しまくる本番環境（想定外 and ヤバい） * 正常性を担保するため、ジョブ実行とダッシュボードを目検で確認 & slackにスクショ掲載(ツラい) *問題が発生すればhotfixで直す ➢ 使われない検証環境（想定外） * 「devで（新規機能の）動作確認をしたので大丈夫です」大体こいつが悪い

どういうこと？新規機能の動作確認のみを実施し、既存機能や後続ジョブの正常確認はやったりやらなかったり… → 検証環境にて疎通確認することで防げたインシデントがたくさんあった既存機能や後続ジョブの動作確認が、必須確認項目に入っていない要件が決まってからデプロイするまでのフローチャート検証環境で「後続のジョブまで一度全部通す」というフローを毎回通っていれば、たくさんのインシデントが防げたはず

どうしてこんなことに？運用開始前の解像度の低さと、運用整備の仕組みづくりに工数を割けなかったのが主な原因どういう経緯でこうなったのかどうして改善されなかったのか運用設計が甘かった「環境分離をしよう！」という方針はあったが、具体的な運用ルールやデプロイフローが定義されていなかった誤った成功体験本番環境でバグが出たけどhotfixでリカバリができたので、「最悪hotfixでなんとかなる」という誤った成功体験が積み重なってしまった運用整備の優先度が低かった顧客要望度の高い新規機能開発が優先され、運用ルールの整備にまで手が回らなかった場当たり（かつ手間がかかる）対応が定着してしまった「とりあえず目検＋Slackにスクショ貼り付けで故障率下がってそうだし、今はそれで十分」という暗黙の了解のもと、既存フローが定着してしまった

こうすればよかったんじゃないか？初期設定と改善をサボらないどういう経緯でこうなったのかどうして改善されなかったのか運用設計が甘かった「環境分離をしよう！」という方針はあったが、具体的な運用ルールやデプロイ手順が定義されていなかった → デプロイ・確認手順を最初に明文化しておくべきだった誤った成功体験本番でバグが出たけど、hotfixでリカバリができたので、「最悪hotfixでなんとかなる」という誤った成功体験が積み重なってしまった → hotfix対応が発生する度に、原因と再発防止の仕組みを考えるべきだった運用整備の優先度が低かった顧客要望度の高い新規機能開発が優先され、運用ルールの整備にまで手が回らなかった → 「品質維持のための整備作業」にも開発リソースを割り当てる運用計画にすべきだった場当たり（かつ手間がかかる）対応が定着してしまった「とりあえず目検＋Slackにスクショ貼り付けで故障率下がってそうだし、今はそれで十分」という暗黙の了解のもと、既存フローが定着してしまった → 目検運用は一時的と定義して代替策を用意すべきだった

新卒3年目の後悔〜機械学習モデルジョブの運用を頑張った話〜

新卒3年目の後悔〜機械学習モデルジョブの運用を頑張った話〜

camay

More Decks by camay

Other Decks in Technology

Featured

Transcript