Tweet
Tweet

Slide 1

Slide 1 text

リブセンスにおける 機械学習システムの信頼性エンジニアリング Machine Learning Casual Talk #6 田中 祥太郎

Slide 2

Slide 2 text

自己紹介 田中 祥太郎 / @yubessy ● 株式会社リブセンス テクノロジカルマーケティング部 データプラットフォームグループ ● ML基盤のプロダクトオーナー 各種MLシステムの開発・運用 ● Python / Julia GCP / GKE / Amazon Redshift / Elasticsearch ● 9月から京都オフィス勤務 MLの仕事を手伝ってもらえる学生アルバイト募集中

Slide 3

Slide 3 text

話したいこと ● リブセンスではMLシステムについてどんな課題を抱えている (いた) か？ ● SREの考え方をMLシステム開発・運用に適用することはできるか？ ● 実際のMLシステム開発・運用にどう取り組んでいるか？

Slide 4

Slide 4 text

リブセンスでのML利用

Slide 5

Slide 5 text

リブセンスのサービス

Slide 6

Slide 6 text

なぜMLを使うのか 成功報酬型ビジネスモデル ● 求人票の掲載：無料 ● 応募者の採用：課金 掲載無料 = 営業努力だけでは収益を上げにくい → データ活用によるマーケティング・UX向上に注力 → MLをはじめとする最適化手法により収益性を向上

Slide 7

Slide 7 text

例 コンテンツと行動ログによる求人レコメンド マッハバイト・転職会議・転職ナビで導入 ● Contents-Based Filtering 求人コンテンツの類似度を利用 ● Collaborative Filtering ユーザフィードバックを利用 BPMF(Bayesian Probabilistic Matrix Factorization)によるレコメンド http://analytics.livesense.co.jp/entry/2017/12/05/105618

Slide 8

Slide 8 text

例 CVR予測に基づく検索ランキング制御 マッハバイトで導入 求人のCVR (応募率・採用率) を予測 予測値に基づいて検索ランキングを制御

Slide 9

Slide 9 text

以前のMLシステム開発・運用

Slide 10

Slide 10 text

最初の導入と利用の拡大 最初：転職会議のメールマーケティングで簡単なレコメンドを導入 → 大きな効果が得られた → 他のサービスでも利用したい → 社内でのML利用の広がり ● レコメンド・検索ランキング制御 ● 多腕バンディットによる導線最適化 ● クチコミのタグ分類によるUX向上

Slide 11

Slide 11 text

MLシステムがアプリケーションと密結合 ● 各サービスの環境に合わせて毎回からシステムを構築し直す ● 開発：MLチーム ↔ 運用：サービスチーム MLチームによる継続的改善が困難 ● 精度が落ちてもMLチームだけでは手を入れられない ● 新しい技術やリソースを投入したくても環境を容易に変更できない → つくったMLシステムが放置され負債化 開発したものの改善が進まない

Slide 12

Slide 12 text

負債化・属人化による問題が頻発 さまざまな問題が実際に発生 ● DBのカラムの値が変化 → モデルの精度が低下 → 直すまでに数ヶ月 ● 手元Macで検証 → 本番にデプロイ → OOM (swap領域不足) 対症療法の効果は限定的 ● コーディング規約・単体テスト導入 ↔ モデルの精度は保証できない → MLに対する信頼性の低下 = 機会損失の危機 「効果は出るけど負債化しやすい」

Slide 13

Slide 13 text

MLシステムの信頼性エンジニアリング

Slide 14

Slide 14 text

以前の状態 これまでは問題が起きてから対応に追われていた ● 問題が起きるたびに割り込みが入ってエンジニアが疲弊 ● 問題対応に個々のシステムや環境ごとの知識と経験が必要 ● 対応が場当たり的になり、原状回復がやっとになってしまう 開発・リリース 問題発生 場当たり的対応・原状回復

Slide 15

Slide 15 text

システムの信頼性についての必要十分条件を定義し、それに従って対応したい ● 問題の発生を前提としてシステムを設計する ● 問題のトリアージを容易にして過剰な対応を避ける ● 必要な場合には要件に立ち返り、設計から見直す 目指したいこと 開発・リリース 問題発生 トリアージ・設計の見直し 信頼性要件の定義

Slide 16

Slide 16 text

必要だったもの：システムの信頼性を体系的に扱う方法 SREの原則にあるサービスレベルの考え方を参考にする Site Reliability Engineering に学ぶ サービスレベル指標 (SLI) の導入 サービスレベル目標 (SLO) の設定 SLO実現のために手段を適用

Slide 17

Slide 17 text

MLシステムの信頼性とその指標 (=SLI) にはどんなものがあるか？ → ２種類の指標に基づく信頼性が考えられそう MLシステムの信頼性とは？ 通常と同じ指標で計測できる信頼性 ● オンライン処理 ○ Web APIのレイテンシ ○ リクエストに対するエラー率 ● バッチ処理 ○ ジョブのスループット ○ ジョブの成功頻度 ML特有の指標が必要な信頼性 ● モデルの精度 ○ 分類モデルの誤り率 ○ 回帰モデルの誤差 ● モデルのメタ指標 ○ ノイズに対する頑健性 ○ 再学習時の精度の安定性

Slide 18

Slide 18 text

信頼性をどう評価するか？実際にSLIを計測することはできるか？ → 可能なところからはじめる・既存の仕組みや過去の記録を活用 MLシステムの信頼性をどう評価するか？ システム監視 ポストモーテム オフライン評価 KPIダッシュボード ※SREの原則では主に定量指標を扱うが、ここでは定性指標も含めている

Slide 19

Slide 19 text

信頼性の目標とそれを達成する手段は？ 信頼性を定義・計測できたら、次はどうするか？ → 目標 (=SLO) を設定し、それを達成するための手段を考える 疑問： ● MLシステムでも、通常指標には通常と同じ水準の目標を設定すべき？ ● 通常指標とML指標それぞれの問題には、別の手段で対応できる？

Slide 20

Slide 20 text

MLシステムは通常に比べ、不安定で制御しにくい → 通常と同じSLIに対し、同水準のSLOを設定するのは非現実的 ● 予測モデルの計算量が大きい → Webリクエストのレイテンシが大きくなる ● 学習が確率的に失敗 → ジョブ監視を同様にするとアラートが飛びまくる 注意１：通常と同じ水準の信頼性を求めにくい 学習データ アルゴリズム 学習 モデル 入力データ 出力データ 予測（推論）

Slide 21

Slide 21 text

注意２：それぞれの信頼性は分割統治しにくい 通常の問題に見えても原因がMLにあったり、その逆もある → 通常指標とML指標で、対応手段や対応者を完全に分離するのは難しい ● 少しのデータ増でOOMが発生 ← レコメンドで求人数×求人数の行列を生成 ● ある日突然モデルの精度が低下 ← キャンペーンでデータ傾向が著しく変化 事象 ＼ 原因 サービスやインフラの問題 MLモデル・アルゴリズムの問題 Web API やジョブのエラー Webエンジニアが対処可能 Webエンジニアだけでは対処困難 MLモデルの精度低下・不安定化 MLエンジニアだけでは対処困難 MLエンジニアが対処可能

Slide 22

Slide 22 text

MLシステムに対してSREができること 1. MLの性質に応じた指標や目標を設定する ○ 求められるレベルが通常とMLとで異なることを受け入れる ○ 関係者間でサービスレベルに対する認識を合わせておく 2. 通常・ML両方の信頼性の観点から問題を捉える ○ MLの問題にみえてもサービスやインフラが原因のケースやその逆に注意 ○ 通常・MLそれぞれのシステムの性質に合わせて適切な手段を選択する 3. １と２を支える仕組みを整備する ○ 実験的なシステムでも安全に検証が行える環境をつくる ○ 問題の原因の切り分けをしやすいようシステムを設計する

Slide 23

Slide 23 text

リブセンスでの取り組み

Slide 24

Slide 24 text

MLチームにSREの役割をおく ● MLE：MLモデルの発揮する価値を最大化する ● SRE：システムの信頼性と開発効率を考慮して設計や運用を担う MLE, SRE が共同でプロジェクトに携わる レコメンドプロジェクト 検索順位プロジェクト SRE MLE SRE MLE

Slide 25

Slide 25 text

● システムごとにどの程度の信頼性を求めるかの共通認識をつくる ● 過剰な信頼性を求めることによる開発・運用コスト増を防ぐ ● 不安定なシステムがクリティカルな用途で使われるのを防ぐ MLシステムをフェーズに区分 フェーズ 開発・運用の目的 サービスレベル SREの役割 コンセプト検証 コンセプトの実現性の検証 SLI / SLO を定めない インフラやデータの整備と提供 技術検証 最適な技術手段の検証 個別に判断 システム設計やトラブル対応の協力 実運用 継続的な価値提供 SLI / SLO を定める 安定性・メンテナンス性の維持

Slide 26

Slide 26 text

● MLチーム内で運用を担うことで 問題対応を迅速・柔軟に ● 複数のシステムを集約して 運用・管理を一元化 ● サービスと疎結合にすることで 問題の原因を特定しやすく ● 開発・本番のデータソースを 一元化して結果の再現性を担保 Kubernetes を利用したコンテナベース機械学習基盤の構築 https://analytics.livesense.co.jp/entry/2018/01/18/090000 ML専用の検証・運用基盤を構築

Slide 27

Slide 27 text

● アルゴリズムの問題と それ以外を切り分けやすく ● 精度検証や問題の原因調査を コンポーネント毎に可能に ● アルゴリズム実装の再利用で 管理すべきコードを削減 ● 最近では Argo Workflow を ワークフローエンジンに採用 マルチコンテナ構成による機械学習アルゴリズムとアプリケーションの疎結合化 https://analytics.livesense.co.jp/entry/2017/12/08/105045 モデルとアプリケーションを疎結合化

Slide 28

Slide 28 text

まとめ

Slide 29

Slide 29 text

話したかったこと ● リブセンスではMLシステムについてどんな課題を抱えている (いた) か？ ○ ML導入の効果は大きかったが、開発後の改善が難しい ○ 負債化による問題が顕在化し、MLへの信頼性が失われかねない状況 ● SREの考え方をMLシステム開発・運用に適用することはできるか？ ○ 原則：SLIの導入と計測・評価は部分的にはできそう ○ 実践：SLOの設定とその実現手段はMLの性質を踏まえて考える ● 実際のMLシステム開発・運用にどう取り組んでいるか？ ○ 現実的な範囲で求める信頼性を定義し、それをもとに手段を考える ○ 信頼性と開発効率を両立できる仕組みを整備