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

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

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

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

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

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

7. CTR 予測について 6

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

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

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

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

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

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

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

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

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

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

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

21. システムアーキテクチャ 20

22. システムアーキテクチャ 21 イメージのビルドは circleCI で⾃動化

23. システムアーキテクチャ 22 AWS サービスは terraform で構築

24. システムアーキテクチャ 23 k8s のデプロイには Helm を採⽤

25. 推論処理の流れ 24

26. システムアーキテクチャ 25 この部分の処理の流れについて

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

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

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

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

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

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

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

47. Kubernetes ワーカー環境 / リトライ受信されたメッセージは、SQS 内で処理中メッセージとして扱われる処理中メッセージは他 Pod から受信されないここで Pod 内でエラーが発⽣したとする 46

48. Kubernetes ワーカー環境 / リトライ SQS メッセージは破棄されることなく、可視性タイムアウト分だけ待機する 47

49. Kubernetes ワーカー環境 / リトライ可視性タイムアウト後、SQS メッセージは再び利⽤可能メッセージに戻るので、他の Pod に再び受信され、処理される 48

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

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

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

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

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

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

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

68. 補⾜資料 67

69. Cluster Autoscaler 68

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

71. Cluster Autoscaler / Scale Up CA は pending 状態の Pod を⾒つけると ASG の Desired Capacityを1増やす 70

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

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

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

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

You are reading a preview.

Check these out next

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

More Related Content

Slideshows for you (20)

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

Recently uploaded (20)