Amazon EKSによるスケーラブルなCTR予測システム

Amazon EKS による
スケーラブルな CTR 予測システム
Kubernetes Meetup Tokyo #27
2020/01/29
株式会社D2C
データソリューション部
吉⽥駿哉

⾃⼰紹介
株式会社D2C
データソリューション部
吉⽥駿哉 (よしだとしや)
2017年度新卒⼊社(⼊社3年⽬)
主な担当業務
Ø広告配信システムへの機械学習モデル組み込み
1

会社紹介
株式会社D2C
株式会社 NTT ドコモ、株式会社電通、株式会社 NTT アドの3社合弁で設⽴された、
デジタル広告／マーケティング会社
デジタルマーケティング事業
Ø 統合デジタルマーケティングの提案・実施までをワンストップで提供
ドコモ事業
Ø 「dメニュー」などのドコモメディアや各種⼀般メディアにおける優良な広告媒体の企画販売
海外事業
Ø アジアを中⼼とした国々での広告・マーケティング事業を展開
2https://www.d2c.co.jp

今⽇話すこと
話すこと
ØEKS によるジョブワーカーシステムの話
Ø機械学習モデル(CTR 予測モデル)の EKSでの本番運⽤に向けて⼯夫した点について
話さないこと
ØKubernetes による web アプリケーションの話
ØCTR予測の精度に関わってくる部分
3

機械学習×Kubernetes
Ø CTR 予測について
Ø 今回達成したかったこと
Ø なぜ機械学習にKubernetesなのか
実装について
Ø システムアーキテクチャ
Ø 推論処理の流れ
Ø 各システムコンポーネントについて
おわりに
4
アジェンダ

実装について
おわりに
5
アジェンダ

CTR予測とは
CTR 予測
Øユーザの情報(年齢、性別、etc. )や広告配信ログなどのデータを元に広告のクリック率を予測
例:「user id」×「広告 id」の単位で「クリックした」 or 「クリックしてない」を正解ラベルとし、
クリック確率(CTR)を予測する
7
user id 広告 id x_1 x_2 x_3 ... click
aaa001 111111 1 0 0 ... 0
aaa001 111112 2 0 0 ... 1
aaa002 111111 3 1 1 ... 0
aaa003 111112 4 0 2 ... 0
aaa003 111113 5 0 2 ... 0
aaa003 111114 6 0 2 ... 0
aaa004 111111 7 1 3 ... 0
aaa004 111112 8 1 3 ... 1
: : : : : : :
user id 広告 id CTR
aaa001 111111 0.010
aaa001 111112 0.005
aaa002 111111 0.015
aaa003 111112 0.022
aaa003 111113 0.030
aaa003 111114 0.001
aaa004 111111 0.005
aaa004 111112 0.010
: : :
予測

なぜCTR予測をするのか
Ø⼊札 CPC と予測 CTR を⽤いて広告をスコアリングし、スコアに応じたオークションを⾏うことで、
広告主にとって適切な広告をユーザに充てることができる
※CPC (Cost Per Click): 今回の⽂脈では、クリック課⾦型広告でのクリック単価のこと
8

学習に使⽤したフレームワーク
LightGBM
決定⽊アルゴリズムに基づいた勾配ブースティングの機械学習フレームワーク
CTR 学習/推論に使⽤
/ Amazon EMR
⾼速分散処理フレームワーク
特徴量の作成に使⽤
9

今回達成したかったこと
10

プロジェクト始動の経緯
CTR予測を⽇次バッチ処理で⾏いたい
Øその⽇の予測対象のレコードはCTR予測を⾏う直前に作成される
Ø後続の処理にて、CTR の予測値が使われる
11
CTRを予測する予測対象のレコードが作成される
⽇次バッチ(※イメージ)
CTRの予測値を使った後続の処理

課題
Ø前後の処理の関係上、CTR 予測に割ける時間は限られている(1時間くらい)
Ø予測対象レコード数は⽬安10億±3億レコード程度
ØEC2インスタンス⼀台で10億レコード予測の試算をしたら、10時間くらいかかった
Ø⽇によって予測にかかる時間もブレそう
Ø将来的に予測単位を増加する可能性がある
Ø⼤幅に予測対象レコードが増加することになる
12

今回達成したかったこと
Ø10 億レコードを時間内(⽬安 1 時間程度)で予測したい
Øアーキテクチャを変更せずに予測単位の増減に対応したい
13

なぜ機械学習にKubernetesなのか
14

機械学習システム特有の問題
① 環境の差異によって再現性が著しく損なわれる
Ø機械学習フレームワークのバージョン差異などの環境マターによって、学習精度が異なったり、
プログラムが正常に動かない場合がある
② 継続的な学習/デプロイが必要
Ø特徴量の分布などは⽇々変化するので、モデルも追従が必要
③ 学習と推論でライフサイクルと要求リソースが異なる
Ø学習は週次バッチ。推論は⽇次バッチ
Ø学習はシングルインスタンスだが、推論はマルチインスタンス
Ø学習には GPUを使うが、推論は CPU で⾏うなど
15

①コンテナによる再現性の担保
Ø実験/開発環境とプロダクト環境を統⼀化することで、環境依存の問題をなくす
Øモデルのデバッグがしやすくなる
Øシームレスなデプロイが可能
②学習/デプロイ観点での拡張性と将来性
Ø機械学習サイクルを回す要件にマッチしたサービスの提供が活発(kubeflow, spark on k8s, etc.)
Øhelmなどによるインフラの導⼊しやすさ
③異なるライフサイクルと要求リソースに合わせてリソース最適化
ØNode Group や Autoscaler と組み合わせて、学習/推論に必要なリソースを無駄なく供給できる
16

①コンテナによる再現性の担保
Ø実験/開発環境とプロダクト環境を統⼀化することで、環境依存の問題をなくす
Øモデルのデバッグがしやすくなる
Øシームレスなデプロイが可能
②学習/デプロイ観点での拡張性と将来性
Ø機械学習サイクルを回す要件にマッチしたサービスの提供が活発(kubeflow, spark on k8s, etc.)
Øhelmなどによるインフラの導⼊しやすさ
③異なるライフサイクルと要求リソースに合わせてリソース最適化
ØNode Group や Autoscaler と組み合わせて、学習/推論に必要なリソースを無駄なく供給できる
17
Kubernetesが、
エンジニアリングの煩わしい部分を解決し、
データサイエンティストが
Modelingの本質的な部分に注⼒することができる

実装について
おわりに
18
アジェンダ

システムアーキテクチャ
19

20

21
イメージのビルドは circleCI で⾃動化

22
AWS サービスは terraform で構築

23
k8s のデプロイには Helm を採⽤

25
この部分の処理の流れについて

推論処理の流れ (1/11)
26
: EMR : S3 : SNS : SQS : EC2

27

28

29

30

31

32

33

34

35

36

各システムコンポーネントについて
37

Node Group
Kubernetes ワーカー環境
ØPub/Sub & Fan-Out 構成
ØAuto Scaler
Config Injection
どのようにModelを管理するか
38
コンポーネント

Node Group
ØAuto Scaler
Config Injection
39

Node Group 毎に
ØInstance Type
ØAuto Scale
ØIAM Policy
ØTag etc.
Node Group
ライフサイクル、要求リソースが異なるサービス毎に Node Group を作成(学習⽤、推論⽤、etc.)
Node Group の定義は、クラスタ作成時の cluster.yaml にて定義
40https://eksctl.io/usage/eks-managed-nodegroups/

Node Group
ØAuto Scaler
Config Injection
41

Kubernetes Job の検討
不採⽤理由
① クラスター外(Lambda とか︖)から Job キックをする必要がある
Øクラスター外で管理するものが増える(キックするコードとか)
Økubectl apply がコケたときは︖
② Parallelismが思ったより柔軟じゃなかった
Øpod毎にJobのパラメーターを変更したり、リソース変更したりできないぽい
Øとなると、キックする側でスケーリングをハンドリングしないといけない
42

Kubernetes Deployment の採⽤
採⽤理由
pub/sub 構成で Job のキックが受動的になる
ØJob のキック時に kubectl apply が不要
Ømessage visibilityが扱えるキューと組み合わせて Job のリトライを実現
Øスケーリングは負荷ベースで⾃律的に⾏わせることができる
43

44
Pub/Sub & Fan-Out 構成による並⾏処理
ØPod が Subscriber として、メッセージを受信する
ことで処理が開始
ØスケールはDeployment の replicas によって制御
Øタスク(学習/推論)毎に Queue と NodeGroup を分
けることで、異なるリソース要求に対応
ØJob を冪等に保っているので、リトライ処理はSQS
の可視性タイムアウトを⽤いて⾏うことができる

Kubernetes ワーカー環境 / リトライ
ある Pod が、SQS の利⽤可能メッセージから
メッセージを受信する
45

受信されたメッセージは、SQS 内で処理中メッセー
ジとして扱われる
処理中メッセージは他 Pod から受信されない
ここで Pod 内でエラーが発⽣したとする
46

SQS メッセージは破棄されることなく、可視性
タイムアウト分だけ待機する
47

可視性タイムアウト後、SQS メッセージは再び
利⽤可能メッセージに戻るので、他の Pod に再
び受信され、処理される
48

Node Group
ØAuto Scaler
Config Injection
49

Pod Autoscaler
Øsqsのメッセージ数をトリガーにDeploymentのreplicasを制御(k8s-sqs-autoscaler を参考*1)
Øタスク処理(学習/推論)を⾏う Deployment は、タスク実⾏時以外は replicas = 0 としている
Ø--max-pods を変更することでスケーリングの規模のチューニングが容易
50*1 : https://github.com/sideshowbandana/k8s-sqs-autoscaler

Pod Autoscaler / Scale Up
Pod AutoScaler は SQS の「利⽤可能メッセージ」
数を polling していて
AWS SQS にメッセージが溜まりだすと*1、
Deployment の replicas を定期的に1つずつ増やし
ていく
*1: 利⽤可能なメッセージ数 > 0
51
Pod
AutoScaler

Pod Autoscaler / Scale Up
replicas の増加に伴って、Deployment は
「望ましい Pod 数 ≠ 現状の Pod 数」
となり、Pod 数を replicas に合わせる
(結果的に Pod が追加される)
52
Pod
AutoScaler

Pod Autoscaler / Scale Down
AWS SQS のメッセージが0になると、
Deployment の replicas を定期的に1つずつ減ら
していく
削除対象の Pod は SIGTERM を受け取り、
Terminated Graceful Period Seconds 後に
SIGKILL を受けてGraceful Shutdownする
53
Pod
AutoScaler

Graceful Shutdown / Graceful Period
SIGTERM 以降は新規のメッセージを受け付けない
Job の処理時間は Terminated Graceful Period Seconds 以内に収める必要がある
54
Scale out (Available Message > 0)
jobをBrokerから受信する
Podのステータスは
SIGTERM SIGKILL SQS Message Visibility Timeout
Scale In (Available Message = 0)
Podのステータスは
Visibility Time (Amazon SQS)
Terminated Graceful Period Seconds (k8s Deployment)
これ以降は新規jobを受け付けない
Dead Line

Graceful Shutdown / Graceful Killer
python の signal で SIGTERM を受信
SIGTERM を受信して既存の処理をし終えると、
スタンバイ状態(プロセスは終了しない)にする
※プロセスを終了すると、Deployment のセルフ
ヒーリングでpodがリスタートしてしまう
55

Cluster Autoscaler
Cluster Autoscaler on AWS / Auto Discovery*1
Øタスク処理(学習/推論)が乗る Node Group は、処理時以外はDesired Capacity = 0 としている
ØAuto Scaling Group(以下、ASG)の max Node 数を変更することで、スケーリングのチューニング
が容易
ØHelm Hubからインストール*2
ØCluster Autoscaler (以下、CA)の詳しい挙動についてはリンクから*3
56
*1: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider/aws
*2 : https://github.com/helm/charts/tree/master/stable/cluster-autoscaler
*3: https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#when-does-cluster-autoscaler-change-the-size-of-a-cluster

Node Group
ØAuto Scaler
Config Injection
57

Config Injection
設定ファイルをコンテナ外で管理することで
Ø設定ファイルの⼀元化
Ø環境毎に異なる設定を挿⼊できる
Ø学習パラメータ等の変更のたびにコンテナをビ
ルドし直す必要がなくなった
58

Node Group
ØAuto Scaler
Config Injection
59

どのように Model を管理するか
機械学習 Model を管理する場合、⽅針として下記の2つが考えられる
1. コンテナに内包する形で、コンテナとして管理する
Ø⭕ ソースコードと紐づけて管理することができる
Ø⭕ Rolling Updateでモデルを更新できる
Ø✖ 再学習のたびにコンテナのビルド~デプロイを⾏う必要がある
2. 外部ストレージで管理する
Ø⭕ 再学習に伴うコンテナのビルド~デプロイ作業は不要
Ø⭕ シンプルなシステム構成
Ø✖ ソースコードと紐づけた管理ができない
60

機械学習 Model を管理する場合、⽅針として下記の2つが考えられる
1. コンテナに内包する形で、コンテナとして管理する
Ø⭕ ソースコードと紐づけて管理することができる
Ø⭕ Rolling Updateでモデルを更新できる
Ø✖ 再学習のたびにコンテナのビルド~デプロイを⾏う必要がある
2. 外部ストレージで管理する
Ø⭕ 再学習に伴うコンテナのビルド~デプロイ作業は不要
Ø⭕ シンプルなシステム構成
Ø✖ ソースコードと紐づけた管理ができない
61
弊社では、こちらを採⽤

ØEMR (前処理)を週次実⾏し、特徴量データが S3 に
吐かれると、推論と同じアーキテクチャで学習され、
S3 上のモデルが更新される
(EMR⾃体は別途管理された、job管理ツールより実⾏される)
Ø推論 Pod は常に latest/ 配下の Model を取得するの
で、モデルの更新に伴う作業は発⽣せず、常に最新の
モデルを使⽤する構成
Øロールバックは latest/ 配下のModelの差し替えで対
応可
62

実装について
おわりに
63
アジェンダ

導⼊してみて
ØFan-Out構成による並⾏予測を⾏うことで、10億レコード程度なら1時間弱で予測しきることがで
きるようになった
Øスケールの max replica、max node を調整することで現状の⼗数倍のレコード数でも同程度の時
間で予測しきることができるようになった
Ø構築したワーカー環境のリトライ機構のおかげで、耐障害性も⭕
Ø導⼊して数ヶ⽉、Model学習の調整などのリリースを数回⾏っているが、システム障害は0
ØAutoscalerによるリソースの最適化によって、インスタンス代削減を実現
64

課題と今後の展望
継続的学習の観点で課題が残っている
k8s 外にて推論結果のモニタリングは⾏っているが(Spark、Tableau)、Modelの妥当性は結果主義
になっているので、再学習Modelを更新する際にModelの妥当性を考慮する機能を導⼊したい
65

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

Cluster Autoscaler / Scale Up
69
例えば、Pod がデプロイされるが、ノードのリ
ソースに空きがないため、pending 状態だとする
CA は常に Node Group に pending 状態の pod が
ないか、監視している

CA は pending 状態の Pod を⾒つけると ASG の
Desired Capacityを1増やす
70

Desired Capacity の増加に伴って、ASG は
「望ましいノード数 ≠ 現状のノード数」
となり、ノード数を Desired Capacity に合わせる
71

pending 状態だった Pod はリソースに空きがあ
る新規で作成されたノードにデプロイされる
72

Cluster Autoscaler / Scale Down
例えば、右図のように配置されている Pod の1つが
終了したとする
CA は Scale Up が発⽣しない場合は、Node Group
に削除可能なノードがないか監視している
※削除可能なノードの条件(下記全てを満たす)
Ø Pod による CPU、メモリの合計リソース要求がノードの割り
当て可能値の閾値 (デフォルト 50%) 未満
Ø ノード上の全ての Pod が他ノードへ移動可
Ø ノードに Scale Down を無効にするタグがついていない
73

削除対象ノード上で動いている Pod は、CA によっ
て他ノードに移動させても問題ないかチェックされ
た後、移動される
※移動不可な Pod
Ø PodDisruptionBudget によって制限された Pod
Ø kube-system Pod (PDB が設定されていないなど)
Ø controller によってサポートされていない Pod
Ø Local ストレージを持つ Pod
Ø リソース不⾜、NodeSelector、NodeAffinity などの制約によっ
て他のノードに移動できない Pod
Ø 特別なタグによって制限されている Pod
74

CA は削除対象ノード上に Pod がいなくなったこ
とを確認すると、
ASG のDesired Capacityを1減らす
75

Desired Capacity の増加に伴って、ASG は
「望ましいノード数 ≠ 現状のノード数」
となり、ノード数を Desired Capacity に合わせる
76

Amazon EKSによるスケーラブルなCTR予測システム

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Amazon EKSによるスケーラブルなCTR予測システム

Similaire à Amazon EKSによるスケーラブルなCTR予測システム (20)

Amazon EKSによるスケーラブルなCTR予測システム