加藤 直 長江 五月 秒間数十万クエリをさばく 機械学習モデルを継続的に 再学習し稼働させる

1. Dynalystでの機械学習ユースケース 2. 機械学習モデルにまつわる課題 3. 推論サーバーのマイクロサービス化 4. 学習パイプラインのPython移行 5. 機械学習モデルの監視

1. Dynalystでの機械学習ユースケース 2. 機械学習モデルにまつわる課題 3. 推論サーバーのマイクロサービス化 4. 学習パイプラインのPython移行 5. 機械学習モデルの監視 加藤が発表します

機械学習エンジニア/データサイエンティスト 最近はMLOps関連の課題に取り組んでいます。 加藤 直 2019年度 新卒入社 AI事業本部 Dynalyst @nkato

Dynalystでの機械学習ユースケース

アプリなどのリターゲティング広告を配信するDSPと呼ばれるプロダクト 一度アプリをインストールしたが離れてしまったユーザーを対象とする広告 Dynalystとは Come back here! I'm bored. 1. Dynalystでの機械学習ユースケース

1. 表示する広告はオークションで決定 2. SSPが枠のオークションを開催 3. DSPが入札 3. 落札者が広告を出す Dynalystはオークション参加者 Web広告の仕組み 1. Dynalystでの機械学習ユースケース

各オークションについて配信価値を予測して、それに基づき価格を決める 価値 ... ユーザーが広告をクリックする確率 (CTR) 広告商品をダウンロード/課金/購入する確率 (CVR) 価値の判断を誤ると 高値で入札 → お金の無駄 安値で入札 → オークションに負け、配信機会の損失 CTR, CVRを正確に予測することが大事 → 機械学習で予測 機械学習をどう活用しているか 1. Dynalystでの機械学習ユースケース

オークション開催回数 ... 月間数千億 推論QPS ... 秒間十数万 1入札にかけられる時間 ... 100ms以内 (一例) オークション開催者によって決められている 推論回数・時間に関する必要要件 1. Dynalystでの機械学習ユースケース

機械学習モデルにまつわる課題

元々は、学習処理がBash/SQL/Pythonで、推論処理がScalaで記述されていた 推論時 ... いくつかの理由からScalaを採用 Dynalystの各サーバーがScalaで記述されている 演算速度が速く、1リクエストにかかる推論時間を短くできる 学習時 ... 基本処理をBashで記述し、一部でPythonの機械学習ライブラリを使用 元々の推論・学習時の処理 2. 機械学習モデルにまつわる課題

パラメータはRedisで繋ぎこみ 推論時 ... Redisからパラメータを取得し Scalaで自前実装した行列演算 で計算 学習時 ... SQL/Pythonでデータ抽出、 学習を実行し、パラメータを Redisに保存 元々のパラメータの繋ぎこみ方法 2. 機械学習モデルにまつわる課題

データサイエンティストがPythonで分析していた機械学習モデルを Scalaに記述しなおす必要があり、実装コストがかかる (そもそもBashやScalaがデータサイエンティストに馴染みがない) 特徴量の変換処理を推論時にはScalaで、学習時にはSQLで記述しているが、 ここの変換処理に差異があるとモデルに乖離が生じる 学習時・推論時のパラメータが別ファイルに置かれ、多重管理になっている なにが問題だったのか 2. 機械学習モデルにまつわる課題

データサイエンティストがPythonで分析していた機械学習モデルを Scalaに記述しなおす必要があり、実装コストがかかる (そもそもBashやScalaがデータサイエンティストに馴染みがない) 特徴量の変換処理を推論時にはScalaで、学習時にはSQLで記述しているが、 ここの変換処理に差異があるとモデルに乖離が生じる 学習時・推論時のパラメータが別ファイルに置かれ、多重管理になっている それらを解決するために、 Pythonによる推論サーバーのマイクロサービス化 推論サーバーを利用した学習パイプラインの移行 プロジェクトを始動 なにが問題だったのか 2. 機械学習モデルにまつわる課題

推論サーバーのマイクロサービス化

推論処理を既存サーバーから切り離し、データサイエンティストの責務を分離する データサイエンティストが機械学習モデルを作成するときに Pythonのみで完結できる状態にする モデル実装をそのまま学習時に利用できる形にして 多重管理を解消する 推論サーバーを実装する目的 3. 推論サーバーのマイクロサービス化

必要要件 推論時間・QPS・インフラコストの観点で実運用に耐える 目標値 推論時間 ... 平均5ms以内、95%tileで10ms以内 QPS ... 推論サーバー1台で9,000QPSくらい 全体で300,000QPSほどを安定的に捌ける状態 推論サーバー実装にあたっての目標 3. 推論サーバーのマイクロサービス化

ざっくりと実装前後を比較 3. 推論サーバーのマイクロサービス化

ざっくりと実装前後を比較 繋ぎこみ部分をどうするか 3. 推論サーバーのマイクロサービス化

ざっくりと実装前後を比較 推論速度が間に合うか 3. 推論サーバーのマイクロサービス化

既存サーバー(Scala)から推論サーバー(Python)に リクエストを投げる構成 → プロトコルとしてgRPCを採用 URLからパラメータをパースするコストを削減 することで高速な通信を実現 Protocol BuffersというIDLでインタフェースを 定義し、Scala、Pythonを含む多言語で扱える CTR、CVRなど複数モデルに必要な特徴量を全て 投げる → 結果をまとめて取得 繋ぎこみ部分をどうするか Introduction to gRPC | gRPC より引用 https://www.grpc.io/docs/what-is-grpc/introduction/ 3. 推論サーバーのマイクロサービス化

ロジスティック回帰(LR)やCatBoostを例に比較 (表記QPSは計算部分のみのQPS) pure-predict ... sklearnをラップして高速化する らしいが、スパース行列に対応して おらず普通に入力すると測定不能 実運用に耐えうるのは自前実装のみという結果に (sklearnやCatBoostはバッチ推論前提で 単独の推論に対するパフォーマンスは弱い？🤔) 推論速度が間に合うか アルゴリズム QPS sklearnのLR 15,436 pure_predictのLR × 自前実装(numpy)のLR 91,882 CatBoost 22,302 3. 推論サーバーのマイクロサービス化

全体構成 3. 推論サーバーのマイクロサービス化

全体構成 特徴量の処理、モデル定義は 推論時と学習時で同じファイルを使用 3. 推論サーバーのマイクロサービス化

AI事業本部の横断組織 DSC との協力体制 芝田 将さん ・ プロジェクト全体の設計相談 ・ Cythonによる高速化 計算時間 : 90%減少 全体のスループット: 1.35倍 ・ 並列化した際に機械学習モデルの パラメータを共有化することで、 サーバー全体を省メモリ化 詳細は [PyData.Tokyo Meetup #23] で検索 3. 推論サーバーのマイクロサービス化

1. Dynalystでの機械学習ユースケース 2. 機械学習モデルにまつわる課題 3. 推論サーバーのマイクロサービス化 4. 学習パイプラインのPython移行 5. 機械学習モデルの監視 長江が発表します

機械学習エンジニアとしてDynalystのML基盤の 開発を行っています。 長江 五月 2021年度 新卒入社 AI事業本部 Dynalyst @nsakki55 @nsakki55

学習パイプラインのPython移行

学習パイプライン設計 データ抽出 S3 生データ 特徴量生成 S3 特徴量 データ モデル学習 S3 モデル ファイル 精度評価 logloss AUC データ評価 分布 モデル登録 DynamoDB モデル バージョン モデルデプロイ ECS ローリング アップデート 4. 学習パイプラインのPython移行

ECS DS・MLが 機能追加 ECS ECR ECR image tag: commit hash 学習ワークフロー 学習スケジュール管理 S3 DynamoDB 推論サーバー インフラ管理 update CI / CD : コミットハッシュでバージョン管理 改善後: 学習と推論処理のコードを共通化 従来 : 学習・推論コードを別実装 4. 学習パイプラインのPython移行

FeatureClass( time=feature.hour or 0, user=feature.user or -1.0, category=feature.category or -1, media=feature.media_id or "", ) 特徴量生成処理を学習・推論で共通化 学習・推論時の生データをClass化 property変数に特徴量処理を実装 @dataclass class FeatureClass: time: datetime user: float category: int media: str @property def hour(self) -> str: return str(self.time.hour) @property def category_media(self) -> str: return f"{self.category}_{self.media}” python サンプルコード 4. 学習パイプラインのPython移行

特徴量処理が想定通りの値か モデルごとの特徴量はあってるか 特徴量のデータ型はあってるか ワークフローが適切な引数で呼ばれているか サンプルデータでモデル学習が収束するか ローカルとCIで共通環境でテスト seed値を固定してテスト × テストを書く文化 4. 学習パイプラインのPython移行

DSC との協力体制 芝田 将 さん C++ の FFMライブラリの Python バインディングを実装 従来 : FFM ライブラリをsubprocess で呼び出す 依存関係のインストールの手間 モデル開発のボトルネック 改善後 : python ライブラリとして import して使用 環境構築が容易に・柔軟な開発が可能に subprocess.run("./ffm-train --auto-stop") subprocess.run("./ffm-predict") import ffm ffm.trian(train_data, auto_stop=True) ffm.predict(valid_data) 4. 学習パイプラインのPython移行

機械学習モデルの監視

実際にあった事例 😨 学習データの特定の特徴量が想定通りの値でないまま運用されていた 特定のモデルの学習データ量が徐々に減っていた データ量の変化によるモデル精度への影響に気づくことができなかった 導入した監視指標 👀 監視している指標 学習時のモデル精度 実績ベースのモデル精度 学習データの分布 5. 機械学習モデルの監視

学習時のモデル精度指標 モデル学習時のオフライン精度指標を監視 急激なモデル性能の変化に気付ける 5. 機械学習モデルの監視

実績ベースのモデル精度指標 実績値に基づいたオンライン精度指標を監視 実績値・予測値の乖離に気付ける 5. 機械学習モデルの監視

学習データの分布 各特徴量の値の時系列変化を監視 5. 機械学習モデルの監視

Future Work 複数のモデル学習の並列化 ローカル検証環境の整備 ABテスト実験管理の整備

ご視聴ありがとうございました。