Weitere ähnliche Inhalte Ähnlich wie Amazon EKSによるスケーラブルなCTR予測システム (20) Amazon EKSによるスケーラブルなCTR予測システム3. 会社紹介
株式会社D2C
株式会社 NTT ドコモ、株式会社電通、株式会社 NTT アドの3社合弁で設⽴された、
デジタル広告/マーケティング会社
デジタルマーケティング事業
Ø 統合デジタルマーケティングの提案・実施までをワンストップで提供
ドコモ事業
Ø 「dメニュー」などのドコモメディアや各種⼀般メディアにおける優良な広告媒体の企画販売
海外事業
Ø アジアを中⼼とした国々での広告・マーケティング事業を展開
2https://www.d2c.co.jp
8. 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
: : :
予測
9. なぜCTR予測をするのか
Ø⼊札 CPC と予測 CTR を⽤いて広告をスコアリングし、スコアに応じたオークションを⾏うことで、
広告主にとって適切な広告をユーザに充てることができる
※CPC (Cost Per Click): 今回の⽂脈では、クリック課⾦型広告でのクリック単価のこと
8
41. 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/
43. Kubernetes Job の検討
不採⽤理由
① クラスター外(Lambda とか︖)から Job キックをする必要がある
Øクラスター外で管理するものが増える(キックするコードとか)
Økubectl apply がコケたときは︖
② Parallelismが思ったより柔軟じゃなかった
Øpod毎にJobのパラメーターを変更したり、リソース変更したりできないぽい
Øとなると、キックする側でスケーリングをハンドリングしないといけない
42
45. Kubernetes ワーカー環境
44
Pub/Sub & Fan-Out 構成による並⾏処理
ØPod が Subscriber として、メッセージを受信する
ことで処理が開始
ØスケールはDeployment の replicas によって制御
Øタスク(学習/推論)毎に Queue と NodeGroup を分
けることで、異なるリソース要求に対応
ØJob を冪等に保っているので、リトライ処理はSQS
の可視性タイムアウトを⽤いて⾏うことができる
47. Kubernetes ワーカー環境 / リトライ
受信されたメッセージは、SQS 内で処理中メッセー
ジとして扱われる
処理中メッセージは他 Pod から受信されない
ここで Pod 内でエラーが発⽣したとする
46
52. Pod Autoscaler / Scale Up
Pod AutoScaler は SQS の「利⽤可能メッセージ」
数を polling していて
AWS SQS にメッセージが溜まりだすと*1、
Deployment の replicas を定期的に1つずつ増やし
ていく
*1: 利⽤可能なメッセージ数 > 0
51
Pod
AutoScaler
53. Pod Autoscaler / Scale Up
replicas の増加に伴って、Deployment は
「望ましい Pod 数 ≠ 現状の Pod 数」
となり、Pod 数を replicas に合わせる
(結果的に Pod が追加される)
52
Pod
AutoScaler
54. Pod Autoscaler / Scale Down
AWS SQS のメッセージが0になると、
Deployment の replicas を定期的に1つずつ減ら
していく
削除対象の Pod は SIGTERM を受け取り、
Terminated Graceful Period Seconds 後に
SIGKILL を受けてGraceful Shutdownする
53
Pod
AutoScaler
55. 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
56. Graceful Shutdown / Graceful Killer
python の signal で SIGTERM を受信
SIGTERM を受信して既存の処理をし終えると、
スタンバイ状態(プロセスは終了しない)にする
※プロセスを終了すると、Deployment のセルフ
ヒーリングでpodがリスタートしてしまう
55
57. 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
61. どのように Model を管理するか
機械学習 Model を管理する場合、⽅針として下記の2つが考えられる
1. コンテナに内包する形で、コンテナとして管理する
Ø⭕ ソースコードと紐づけて管理することができる
Ø⭕ Rolling Updateでモデルを更新できる
Ø✖ 再学習のたびにコンテナのビルド~デプロイを⾏う必要がある
2. 外部ストレージで管理する
Ø⭕ 再学習に伴うコンテナのビルド~デプロイ作業は不要
Ø⭕ シンプルなシステム構成
Ø✖ ソースコードと紐づけた管理ができない
60
62. どのように Model を管理するか
機械学習 Model を管理する場合、⽅針として下記の2つが考えられる
1. コンテナに内包する形で、コンテナとして管理する
Ø⭕ ソースコードと紐づけて管理することができる
Ø⭕ Rolling Updateでモデルを更新できる
Ø✖ 再学習のたびにコンテナのビルド~デプロイを⾏う必要がある
2. 外部ストレージで管理する
Ø⭕ 再学習に伴うコンテナのビルド~デプロイ作業は不要
Ø⭕ シンプルなシステム構成
Ø✖ ソースコードと紐づけた管理ができない
61
弊社では、こちらを採⽤
63. どのように Model を管理するか
ØEMR (前処理)を週次実⾏し、特徴量データが S3 に
吐かれると、推論と同じアーキテクチャで学習され、
S3 上のモデルが更新される
(EMR⾃体は別途管理された、job管理ツールより実⾏される)
Ø推論 Pod は常に latest/ 配下の Model を取得するの
で、モデルの更新に伴う作業は発⽣せず、常に最新の
モデルを使⽤する構成
Øロールバックは latest/ 配下のModelの差し替えで対
応可
62
70. Cluster Autoscaler / Scale Up
69
例えば、Pod がデプロイされるが、ノードのリ
ソースに空きがないため、pending 状態だとする
CA は常に Node Group に pending 状態の pod が
ないか、監視している
72. Cluster Autoscaler / Scale Up
Desired Capacity の増加に伴って、ASG は
「望ましいノード数 ≠ 現状のノード数」
となり、ノード数を Desired Capacity に合わせる
71
74. Cluster Autoscaler / Scale Down
例えば、右図のように配置されている Pod の1つが
終了したとする
CA は Scale Up が発⽣しない場合は、Node Group
に削除可能なノードがないか監視している
※削除可能なノードの条件(下記全てを満たす)
Ø Pod による CPU、メモリの合計リソース要求がノードの割り
当て可能値の 閾値 (デフォルト 50%) 未満
Ø ノード上の全ての Pod が他ノードへ移動可
Ø ノードに Scale Down を無効にするタグがついていない
73
75. Cluster Autoscaler / Scale Down
削除対象ノード上で動いている Pod は、CA によっ
て他ノードに移動させても問題ないかチェックされ
た後、移動される
※移動不可な Pod
Ø PodDisruptionBudget によって制限された Pod
Ø kube-system Pod (PDB が設定されていない など)
Ø controller によってサポートされていない Pod
Ø Local ストレージを持つ Pod
Ø リソース不⾜、NodeSelector、NodeAffinity などの制約によっ
て他のノードに移動できない Pod
Ø 特別なタグによって制限されている Pod
74
76. Cluster Autoscaler / Scale Down
CA は削除対象ノード上に Pod がいなくなったこ
とを確認すると、
ASG のDesired Capacityを1減らす
75
77. Cluster Autoscaler / Scale Down
Desired Capacity の増加に伴って、ASG は
「望ましいノード数 ≠ 現状のノード数」
となり、ノード数を Desired Capacity に合わせる
76