リクルートのデータ活用を加速させるセルフサービス型 A/B テスト基盤の設計と実装 / MLOps_kato

2021/12/08_第14回 MLOps勉強会での加藤の講演資料になります

Transcript

1. リクルートのデータ活用を加速させる セルフサービス型 A/B テスト基盤の 設計と実装 株式会社リクルート データ推進室 データプラットフォーム部 加藤 広大 1
2. ※ 本資料のスコープ 本資料の A/B テストは Web サービスにおける 機械学習を始めとするレコメンドや 検索並び順最適化を行うサイト改善を指します 2
3. • 自己紹介・会社紹介 • データ施策の業務フロー課題 • データサイエンスチーム目線 ◦ 全体像 ◦ 各機能紹介 ◦ A/B テストの設定方法 • 内部実装編 ◦ アーキテクチャ ◦ 各機能の内部実装 ◦ AB テスト機能の実装詳細 • 課題・まとめ 目次 3
4. • 2018/04 現、株式会社リクルート入社 ◦ データ分析によるサービス改善 ◦ データ活用施策推進 ◦ 社内データプロダクトの開発運用兼PdM • 興味関心：k8s, Go, 開発生産性改善 ◦ CKA/CKAD ◦ techblog: Four Keys 〜自分たちの開発レベルを定 量化してイケてる DevOps チームになろう〜 • 使用キーボード： moonlander 加藤 広大 Twitter: @ko_da_k 4
5. 5 リクルートの事業について https://recruit-saiyo.jp/present/
6. 6 所属組織について 事業領域 A 事業領域 B 事業領域 C データ推進室 事業領域 A データソリューション 事業領域 B データソリューション 事業領域 C データソリューション データエンジニアリング・データマネジメント
7. • 自己紹介・会社紹介 • データ施策の業務フロー課題 • データサイエンスチーム目線 ◦ 全体像 ◦ 各機能紹介 ◦ A/B テストの設定方法 • 内部実装編 ◦ アーキテクチャ ◦ 各機能の内部実装 ◦ AB テスト機能の実装詳細 • 課題・まとめ 目次 7
8. 8 Step1: あなたはレコメンドモデル開発者です ユーザへおすすめアイテムを 表示するとします Q. どのようにレコメンドモデルを 連携していますか？
9. 9 Data Science Team Data Engineer Team Service Engineer Team 学習/予測コード納品 予測結果ファイル連携 Data Science Team Data Engineer Team Service Engineer Team
10. 10 Step2: 先程のモデルを改良しました アルゴリズムを変更したモデルを 反映したいです Q. どのようにレコメンドモデルを 「更新」していますか？
11. 11 Step3: 複数モデルの A/B テストをしたいです 複数モデルの比較を 行いたいです Q. どのようにレコメンドモデルを 「比較」していますか？
12. 本日のテーマ データサイエンスチーム主導で モデルの更新や A/B テストを行える セルフサービス型のデータ基盤基盤の 設計と実装 12
13. 13 Data Science Team Data Engineer Team Service Engineer Team 学習/予測コード納品 予測結果ファイル連携 Data Science Team Data Engineer Team Service Engineer Team
14. 14 Data Science Team Data Engineer Team Service Engineer Team 学習/予測コード納品 予測結果ファイル連携 Data Science Team Data Engineer Team Service Engineer Team • エンジニアのリソース上限が施 策ごとの開発ボトルネック • プロダクトの機能開発・ 自動化・信頼性向上に 開発リソースを十分に割けない • エンジニアのリソース上限が 施策ごとの開発ボトルネック • プロダクトの機能開発・ 自動化・信頼性向上に 開発リソースを十分に割けない
15. 15 結論：セルフサービス型のデータプロダクトを提供 Data Science Team Data Engineer Team Service Engineer Team Push/PR CI/CD Job API CI/CD ※ Job 基盤については以下の CNDT2021 の資料を御覧ください https://event.cloudnativedays.jp/cndt2021/talks/1212 Model Output (ファイル連携パターンも対応)
16. • 自己紹介・会社紹介 • データ施策の業務フロー課題 • データサイエンスチーム目線 ◦ 全体像 ◦ 各機能紹介 ◦ A/B テストの設定方法 • 内部実装編 ◦ アーキテクチャ ◦ 各機能の内部実装 ◦ AB テスト機能の実装詳細 • 課題・まとめ 目次 16
17. データサイエンスチーム目線 17
18. 18 データサイエンスチームから見た業務フロー コード群と 設定ファイル Data Science Team Route mlops-community.example.com KeyValue API Prediction API Functions . . . . . . • チーム専用の GitHub Repository で code を管理 ◦ CI/CD 整備済みなのでデプロイやテストも自動化 • Model の API 連携方法は 3 つ (後述) • API の Host は Route という機能で自動生成（後述） Team 専用 Repo
19. 19 モデル連携の方法 コード群と 設定ファイル Data Science Team Route KeyValue API Prediction API Functions . . . . . . • 事前のモデル出力結果を連携する KeyValue API ◦ ユースケース：類似アイテムレコメンド • オンライン推論を行う Prediction API ◦ ユースケース：閲覧状況に基づくリアルタイムレコメンド • 複数 API 外部サービス連携を行う Functions ◦ ユースケース： Team 専用 Repo mlops-community.example.com
20. 1. BigQuery で key/value のカラムを 返す Queryをそのまま API に連携 2. Pandas DataFrame をそのまま API に連携するライブラリの提供 20 KeyValue API (UX)
21. • Request/Response の型定義と predict method を実装すれば オンラインサービングが可能 • 学習済みモデルもまとめて Image に固める • API のデプロイは設定を書いた yaml を push するだけ 21 Prediction API (UX) class Petal(BaseModel): length: float width: float class RequestData(BaseModel): sepal_length: float sepal_width: float petal: Petal class ResponseData(BaseModel): predicted: int label: str class Predictor: def __init__(self): with (SRC_DIR / "my-model.pkl").open("rb") as f: self.model = pickle.load(f) def predict(self, data: RequestData, req: Request) -> ResponseData: # リクエストデータを predict に渡すために変換します features = [[data.sepal_length, data.sepal_width, data.petal.length, data.petal.width,]] # レスポンスデータを組み立てます results = self.model.predict(features) label = "Iris-Setosa" # dummy return ResponseData(predicted=results[0], label=label)
22. • 複数の KeyValue API や Prediction API を呼び出したり外部サービス 連携などを任意の Handler として記述できる。 • Prediction API と同じく、任意の Handler 処理を書いたコードを Push 22 Functions (UX) ユースケース KeyValue API ① ユーザー特徴量 API KeyValue API ② アイテム特徴量 API Prediction API ① マッチングスコア予測 API Functions 外部サービス
23. mlops-community.example.com 23 A/B テストの設定方法 コード群と 設定ファイル Data Science Team Route KeyValue API Prediction API Functions . . . . . . • チーム専用の GitHub Repository で code を管理 ◦ CI/CD 整備済みなのでデプロイやテストも自動化 • Model の API 連携方法は 3 つ (後述) • API の Host は Route という機能で自動生成（後述） Team 専用 Repo
24. 24 Route (UX) apiVersion: api.config.knile.jp/v1alpha1 kind: Route metadata: name: mlops-community-sample spec: backend: # default の設定 name: "mlops-community-sample1" kind: KeyValue test: term: since: "2021-12-08T00:00:00+09:00" # 開始日時 until: "2021-12-31T00:00:00+09:00" # 終了日時 backends: # AB テスト用のバックエンド - name: "mlops-community-sample2" kind: Function slot: A # AB テストのスロット名 percentage: 50 # 50 % を A に割り振り allowedIPs: - 192.168.10.1/32 • 左のような yaml を push • name に応じて subdomain を 自動設定 • KeyValue/Prediction/Functions の Backend に好きな割り振り
25. 25 Route の存在意義 Service Engineer Team model1.example.com model2.example.com • API の Interface は同じなのに Service Engineer Team は 呼び出し先変更をする 開発が必要 • 真に Data Science Team 主導で A/B テストをするなら、最初に API の仕様を決めてしまい モデルのアルゴリズムや パラメータ変更にサービス担当の エンジニアの工数を使わないのが 理想 Data Science Team
26. 26 Route の存在意義 mlops-community-model1 mlops-community-model2 Route mlops-community.example..com Service Engineer Team Data Science Team • 呼び出し先固定で中のロジックを変えることで Service Engineer Team の工数はゼロ →Blue/Green Deployment や Canary Release の考え方を適用 • Data Science Team が自由にリリースを調整できるような設計
27. • 自己紹介・会社紹介 • データ施策の業務フロー課題 • データサイエンスチーム目線 ◦ 全体像 ◦ 各機能紹介 ◦ A/B テストの設定方法 • 内部実装編 ◦ アーキテクチャ ◦ 各機能の内部実装 ◦ AB テスト機能の実装詳細 • 課題・まとめ 目次 27
28. 内部実装編 28
29. 29 Kubernetes cluster istio-system namespace Cloud Load Balancing istio-ingressgateway Pod Team A Team B Istio Network Endpoint Group (NEG) knile-system namespace ※ knile は本資料で紹介している社内プラットフォーム名称です api-gateway Pod Team A namespace Team B namespace KeyValue 1 CustomResource KeyValue 2 CustomResource Functions 1 CustomResource KeyValue 1 CustomResource Prediction 1 CustomResource Route 1 CustomResource Route 1 CustomResource Logging Sink BigQuery Cloud Logging Console Team A Repo Team B Repo Team A Dashboard Team B Dashboard
30. 30 Kubernetes cluster istio-system namespace Cloud Load Balancing istio-ingressgateway Pod Team A Team B Istio Network Endpoint Group (NEG) knile-system namespace ※ knile は本資料で紹介している社内プラットフォーム名称です api-gateway Pod Team A namespace Team B namespace KeyValue 1 CustomResource KeyValue 2 CustomResource Functions 1 CustomResource KeyValue 1 CustomResource Prediction 1 CustomResource Route 1 CustomResource Route 1 CustomResource Logging Sink BigQuery Cloud Logging Console Team A Repo Team B Repo Team A Dashboard Team B Dashboard
31. 31 リポジトリ＋インフラ環境の自動発行 Data Engineer Team Team A Resources Kubernetes Team A BigQuery Team A Cloud Storage Team B Resources Kubernetes Team B BigQuery Team B Cloud Storage • チームごとに CI/CD を整備した状態の専用 Repo や GCP/k8s Resource、Datadog Dashboard を提供 • これらの生成は Data Engineer Team がコードで集約管理 Infra Repo
32. 32 Kubernetes cluster istio-system namespace Cloud Load Balancing istio-ingressgateway Pod Team A Team B Istio Network Endpoint Group (NEG) knile-system namespace ※ knile は本資料で紹介している社内プラットフォーム名称です api-gateway Pod Team A namespace Team B namespace KeyValue 1 CustomResource KeyValue 2 CustomResource Functions 1 CustomResource KeyValue 1 CustomResource Prediction 1 CustomResource Route 1 CustomResource Route 1 CustomResource Logging Sink BigQuery Cloud Logging Console Team A Repo Team B Repo Team A Dashboard Team B Dashboard
33. データサイエンス チーム作成 Job • 演算結果を事前格納し API として提供 • キーの全件更新や差分更新も提供 • Pandas Dataframe や BigQuery の結果をそのまま API に連携できる ライブラリを提供 33 KeyValue API (内部実装) Cloud Bigtable Cloud Storage Pub/Sub BigQuery Kubernetes Engine data-loader (内製) Kubernetes Engine KeyValue API (内製) Write Read
34. データサイエンス チーム作成 Job • 基盤側が提供するライブラリやインタフェースに従って、 モデルの Predict や Load 処理を実装（コードは Python） • GCR に API として起動する Image を Push （API 実装は FastAPI） • GitHub に設定ファイルを Push すると、該当 Model の API が起動 34 Prediction API (内部実装) Kubernetes Engine Prediction API Container Registry 基盤側で提供する インタフェースの実装 pull Push
35. データサイエンス チーム作成 • 基盤側が提供するインタフェースに従って、 任意の Handler を実装 • GCR に API として起動する Image を Push • GitHub に設定ファイルを Push すると、該当の API が起動 35 Functions (内部実装) Kubernetes Engine Functions Container Registry 任意の Handler 実装 pull Push
36. • 個別 API は社内の利用者環境からのみアクセス可能な ドメインを付与→開発時のテストやデバッグを可能に • Route は利用者記載の A/B テスト設定をもとに Service Engineer Team が呼び出せる VirtualService を発行 (詳細は後述) 36 Custom Controller によるリソース制御 KeyValue/Prediction/ Function KeyValue API Storage Cloud Bigtable Private Only host VirtualService Route A/B Test Settings VirtualService
37. • 自己紹介・会社紹介 • データ施策の業務フロー課題 • データサイエンスチーム目線 ◦ 全体像 ◦ 各機能紹介 ◦ A/B テストの設定方法 • 内部実装編 ◦ アーキテクチャ ◦ 各機能の内部実装 ◦ AB テスト機能の実装詳細 • 課題・まとめ 目次 37
38. 38 Kubernetes cluster istio-system namespace Cloud Load Balancing istio-ingressgateway Pod Team A Team B Istio Network Endpoint Group (NEG) knile-system namespace ※ knile は本資料で紹介している社内プラットフォーム名称です api-gateway Pod Team A namespace Team B namespace KeyValue 1 CustomResource KeyValue 2 CustomResource Functions 1 CustomResource KeyValue 1 CustomResource Prediction 1 CustomResource Route 1 CustomResource Route 1 CustomResource Logging Sink BigQuery Cloud Logging Console Team A Repo Team B Repo Team A Dashboard Team B Dashboard
39. • Istio の機能だけではカバーできないユースケース (後述) があるため 独自に Gateway を実装 39 A/B テストのルーティング設定 ※ 過去のテックブログもご覧ください　 Istio で実現する A/B テスト基盤 istio-ingressgateway Pod api-gateway Pod Host ごとに異なる A/B 情報を Header に詰める Header の情報をもとに ルーティングを決める
40. 40 apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: mlops-community-sample ...省略 spec: ...省略 hosts: - "mlops-community-sample.example.com" http: name: mlops-community-sample-rt route: - destination: host: api-gateway.knile-system.svc.cluster.local headers: request: set: x-knile-router-route-name: mlops-community-sample x-knile-router-testgroup-members: ‘[{“routeName”: “mlops-community-sample”, ...省略 }]’ x-knile-router-testgroup-name: autogen.mlops-community.team-a ...省略 apiVersion: api.config.knile.jp/v1alpha1 kind: Route metadata: name: mlops-community-sample spec: backend: # default の設定 name: "mlops-community-sample1" kind: KeyValue test: term: since: "2021-12-08T00:00:00+09:00" # 開始日時 until: "2021-12-31T00:00:00+09:00" # 終了日時 backends: # AB テスト用のバックエンド - name: "mlops-community-sample2" kind: Function slot: A # AB テストの識別子 percentage: 50 allowedIPs: - 192.168.0.1/32 ユーザ記述 Sample 変換後 VirtualService 抜粋
41. 1. 特定のユーザが常に同じ Backend を引き続けることを 強制できなかったため 2. 複数 API でのトラフィック制御ができなかったため 41 なぜ Istio のみでは A/B テストを実現できないか
42. 42 割り振り＋ユーザ固定の両立ができなかった mlops-community-sample1 mlops-community-sample2 80 % 20 % • Istio の Weight-based Routing と Soft Session Affinity の同時利用かつ ユーザの割り振りの固定化ができなかった（基盤構築の 2019/12 時点） header: {“user-id”: “userA”} ※ 以下のテックブログもご覧ください 　 https://engineer.recruit-lifestyle.co.jp/techblog/2019-12-01-istio/
43. 43 複数 API でのトラフィック制御 model-1 model-2 Route alpha-api.example.com model-3 model-4 Route beta-api.example.com alpha-api.model-1 × beta-api.model-3 alpha-api.model-2 × beta-api.model-4 0 % 50 % 100 % 例：alpha-api の model-1 を引いたら beta-api の model-3 を強制したい
44. • 自己紹介・会社紹介 • データ施策の業務フロー課題 • セルフサービス型 A/B テスト基盤の紹介 ◦ アーキテクチャ ◦ 機能紹介（UX / 内部実装） ◦ AB テスト機能の実装詳細 • 課題・まとめ 目次 44
45. • チームごとに独立した リポジトリやリソース を発行 • 事前演算した結果を返す KeyValue API • オンライン推論の Prediction API • 複数 API を束ねる Functions • トラフィックルーティングを設定する Route • Istio の VirtualService で Host ごとに A/B テストの 設定情報を Header に詰めるように設定 • Header を受け取った api-gateway (内製) でルーティングを決定 • 独自の api-gateway が必要な理由は以下の2点 ◦ ユーザ単位で固定した Backend への重み付けした割り振りの実現 ◦ 複数 API をまたいだトラフィック制御 45 まとめ
46. • スキーマ駆動開発 ◦ openapi.yaml の自動生成による開発生産性向上 ◦ Data Science Team の人に openapi.yaml を書いてもらうのは 分析・モデリングに注力してほしいという本題から逸れてしまう • チーム・API ごとのアラート ◦ Datadog Dashboard の自動生成及び Data Science Team への 展開は実装済み→レイテンシ・RPS などはチームごとに確認可能 ◦ 一方、アラートに関しては基盤チームが一次調査を担当している ◦ API 個別のアラート（Handler の実装ミスなど）を Data Science Team が検知できるような運用設計を検討する 46 これから改善していくこと
47. • 採用情報 | 株式会社リクルート • データプラットフォーム開発はじめ、様々な職種で 一緒に働く仲間を募集しております • ご興味ありましたら上記ページや、加藤の Twitter 等に 気軽にご連絡いただければと思います。 47 さいごに
48. • ちょうどいいイラスト • Icons made by https://www.freepik.com from www.flaticon.com • Updated 9/2021 Google Cloud Official Icons and Solution Architectures • pandas - Python Data Analysis Library • Go's New Brand • The Python Logo • Kubernetes icons • icono-k8s-0.3 • https://www.datadoghq.com/ja/about/resources/ • The Python Logo アイコン・イラスト参照先 48