DataEngConf NYC’18 セッションサマリー #2

Copyright © GREE, Inc. All Rights Reserved.
グリー株式会社
開発本部 DataEngineeringGroup
松岡紀行
DataEngConf NYC’18
セッションサマリー #2

Copyright © GREE, Inc. All Rights Reserved.Copyright © GREE, Inc. All Rights Reserved.
【氏名・所属】
• 松岡紀行 / Noriyuki Matsuoka
• 開発本部データエンジニアリンググループ
エンジニアチーム
【略歴】
• 2016/04 グリー株式会社入社
• 2016/06 データエンジニアリンググループ配属
• オンプレのHadoopやEMRベースのログ基盤を運用
• 2018/07 兼務で新規ゲームにクライアントエンジニアとし
て配属
自己紹介

• セッション紹介#01
• Building a Modern Machine Learning Platform on
Kubernetes
• セッション紹介#02
• Artwork Personalization at Netflix
• その他のセッション
• まとめ
アジェンダ

セッション紹介#01
Building a Modern Machine Learning
Platform on Kubernetes
Saurabh Bajaj | Lyft

• ライドシェアサービスを提供する
アメリカの企業
• Uberの競合
• タクシーのような専用車ではなく、
一般人が自家用車で乗車サービスを行う。
• 乗車料金は、都市や利用時間帯によって異なるが、
基本的にタクシーより安い。
企業紹介 - Lyft

• 機械学習のプロセス
• Feature Engineering（特徴選択)
• Prototyping（モデルの開発）
• Model Training（モデルの学習）
• Run in Production（モデルのデプロイ）
• モデル開発には沢山の周辺タスクが発生
• データサイエンティストがモデル開発に集中できるように
機械学習基盤システムを構築したい
機械学習モデル開発の問題点

1. 特定の機械学習フレームワークに依存しない
• tensorflowなど
2. GPUも利用できるように
3. 特定のクラウドに依存しない
• NVIDIAのGPU Cloud、GoogleのCloud TPUや
ASICベースのモデルトレーニングシステム
• 機械学習界隈でのハードウェア・ソフトウェアエコシ
ステムは進化が早い
4. 使いやすく・かつ柔軟性を
• アカデミック出身の人にはインフラ管理に抵抗がある
人も多いので使いやすく。
• 一方で凝った使い方をしたい人には柔軟性を。
機械学習基盤システムに求める要件

Docker Container
• コンテナ技術での抽象化
• 特定のシステムに依存しなくなる
Kubernetes
• プラットフォームを構築するためのリッチなAPIを提供
• 複雑なワークフローを起動可能
• 容易にスケール可能
• クラウド非依存なAPI
• 一方でローレベルなAPIも多数含まれ複雑なため、
さらに抽象化して使いやすくしたい
Container / Kubernetes

• KubernetesをラップしたGUIを作成・提供
• ソフトウェアをボタンで選択
• Jupyter Notebook
• Deeplearning + Tensorboard
• R-Studio
• ハードウェアをボタンで選択
• CPU
• GPU
• スペックの高低
Lyft のアプローチ

• ウェブブラウザで動作する対話型Pythonエディター
• データを可視化して確認しながらプログラムを書けるため、
分析目的などに良く利用される
• Lyftではこれを機械学習のベース環境として提供
（補足）Jupyter Notebook

• Kubernetesの最小構成単位
• 1つ以上のコンテナとリソースの組を抽象化したもの
Kubernetes – Pod

• Podで利用可能な外部ストレージ管理の仕組み
• モデルの学習データのチェックポイントとして利用可能
• NFSも利用可能
Kubernetes – Persistent Volume

• Podに対してアクセスポリシーを定義したもの
Kubernetes – Service
Pod#01
notebook-xxxxx
Pod #02
tensorboard-yy
Service#01
Cluster IP: xxx.xx.xx.xx
Service#02
Cluster IP: yyy.yy.yy.yy
Client
Port 8888
Port 6006

• Serviceよりもさらに外側のルーターコンポーネント
• Serviceよりも多機能
Kubernetes – Ingress
Pod#01
Pod #02
Service#01
Service#02
Client Ingress

• 問題: Imageのサイズが大きい
• Notebookのイメージサイズは平均して12-15GB
• NVIDIAのCUDAドライバーやMLフレームワークのバイナリ
• Notebookの作成のたびにダウンロードすると、
かなりの時間がかかってしまう
• 対応
• 各ノードでキャッシュウォーミングを行って対応
クラスタに関する問題#1

• 問題: 新しいインスタンスの起動に時間がかかる
• Kubernetesには負荷に応じてクラスタを自動的に
拡張するAuto Scalerがある
• 一方で新しいインスタンスの起動には
AMIを使用しても5~10分くらいの時間がかかる
• 対応
• KubernetesのPreemption機能で対応
• Pod間に Priority （優先度）をつけておき、
新しい重要なPodがリソース不足で投入できない場合に
優先度の低いPodを追い出すこと

• 問題: 大量のCredentialsの管理
• Podが外部と通信等を行うためにはCredentialsが必要
• 例：GITHUB_TOKEN
• 対応
• KubernetesのSecrets機能の利用
• KubernetesではSecretsを利用すれば
安全・簡単にCredentialsを管理可能
• Base64エンコーディングで難読化
• コンテナ内で環境変数として参照可能
• LyftではGUIからユーザが簡単に設定可能

• MLモデルの実験には沢山の試行回数が必要
• Optimizerを入れ替える
• Parameterを入れ替える
• …
• LyftにおけるTrainingのやり方
• NotebookでModel classやtraining methodを書く
• モデルを含んだDockerファイルを作成してpush
• CUDAドライバーなど必要なものがあればそれらもimport
• GUIのTrainingページでモデルを選択＆実行をクリック
Training

• ハイパーパラメータのチューニングも時間がかかる
• 何度も値を調整しながら学習を繰り返す必要がある
• Katib
• ハイパーパラメータチューニングフレームワーク
• kubeflowプロジェクトの1つ
• Google VizierをOSSで実装したもの
• パラメータ空間を定義すれば、
あとは指定したアルゴリズム
（グリッドサーチなど）でチューニング
Tuning

• Kubernetesは特に使ったことがないのですが、強力な機
能が揃っていることや、関連する便利なOSSが増えている
ことを考えると、少なくともML基盤では、あるいはそれ
以外でも非常に魅力的に感じました。
• 個人の意見ですがECSと比べてyamlやCLIでの管理が充
実していると感じたので使ってみたい
• Lyftほど大きな企業ならともかく、普通の企業であれば
kubeflowのエコシステムに乗っかったほうが良い？
• 全体的に無駄な時間の削減を強調していて、アメリカのAI
スペシャリストの給与相場を考えると、切実な問題なんだ
ろうなと思いました。
所感

• カンファレンスサイト（概要のみ）
• https://www.dataengconf.com/speaker/building-a-
modern-machine-learning-platform-on-
kubernetes?hsLang=en-us
参考

セッション紹介#02
Artwork Personalization
at Netflix
Tony Jebara | Netflix

• 映像ストリーミング配信等を行う
アメリカの企業
• 古くから機械学習を用いてレコメンド機能等に注力
企業紹介 - Netflix

• Personalized Ranking
• Personalized Page Generation
• Personalized Promotion
• Personalized Image Selection
• Learning Collaborative Search
• Personalized Messaging
• Personalized Marketing
• Personalized Life Time Value
• Personalized Content Acquisition
Netflix が行っている機械学習

アートワークのパーソナライズ
（出典）https://medium.com/netflix-techblog/artwork-personalization-c589f074ad76 （2点とも）

• 古典的な手法
Batch Machine Learning
（出典）https://medium.com/netflix-techblog/artwork-personalization-c589f074ad76 （2点とも）

• Regret（後悔）を最小化するためには
Online Learningが適している
• Regret: 最初からユーザの好みが既知だった場合の結果
と実際の結果の差分
• Batch的にではなく逐次的にモデルを改善していく
• 関連する有名な問題: Multi-Armed Bandits
Online Learning

• 以下を毎ターン繰り返す
• Learner は Action を選ぶ
• Environment は Action に従って Reward を返す
• Learner は累積報酬を最大化するように
方針をアップデートする
• ポイント
• 情報の探索と活用をバランスよく行う必要がある
Bandits 問題
Learner
(Policy)
Environment
Action
Reward

• 以下を毎ターン繰り返す
• Environment は Context を渡す
• Learner は Context を考慮しながら Action を選ぶ
• Environment は Action に従って Reward を返す
• Learner は累積報酬を最大化するように
方針をアップデートする
• Context: スロットの大きさ等の特徴ベクトル
• 教師あり学習と異なり、正解を教えてもらえる訳ではない
Contextual Bandits 問題
Learner
(Policy)
Environment
Action
Reward
Context

• Context: ユーザの視聴履歴・国
• Action: 選択されたアートワーク
• Reward: ユーザがポジティブな反応をしたかどうか
• ポジティブ
• コンテンツを楽しんで視聴した
• ネガティブ
• コンテンツを視聴しなかった
• 途中で視聴をやめた
• 楽しめなかった
アートワークへの適用

• Contextual Bandits 問題を解くためのアルゴリズム
• ε-greedy法
• LinUCB
• Thompson Sampling
• 例: ε-greedy法
• εの確率で「探索」
• 1-εの確率で「活用」
Contextual Bandits アルゴリズム

実際に適用した場合の例
（出典）https://medium.com/netflix-techblog/artwork-personalization-c589f074ad76

• 本番で使用する前にオフラインで性能評価を行いたい
• Replay 手法
• 保存してある過去のアクションログを用いて
擬似的に評価
オフラインでのモデルの性能評価

• メリット
• 実データを使っており指標として信頼性がある
• 計算しやすい
• デメリット
• 沢山のデータが必要
• 過学習する可能性がある
オフラインでのモデルの性能評価

• APIの適用場所は幅広く、ピーク時は20M RPS を超える
• 手法1: Live Compute
• アクセスが有った際にモデルを適用（計算）
• 問題点
• SLA を満たすのが難しい
• 遅延を抑えるにはシンプルなアルゴリズムに制限される
• 手法2: Online Compute
• 事前にモデルを適用してキャッシュ
• 問題点
• 適用されるモデルは最新じゃない可能性がある
• 実際には使われないキャッシュも用意する必要がある
オンラインでのモデルの適用

• 内容としてはほぼ機械学習の話でしたが、基調講演として
発表されていて、参加者も次々と質問するほど熱心に聞い
ていたのが印象的でした。
データに携わる上で、教養として機械学習に関する基本的
な知識は身につけておきたいと改めて思いました。
• 「アートワークをユーザによって変える」というアイデア
自体個人的には目からウロコでしたが、Netflixとしては将
来的に「ユーザがテレビの前にただ座っているだけで最適
なコンテンツが流れ最高な体験ができる」世界を目指して
いるらしく、視野を拡げるために視座を高く保つというの
は大事だと改めて感じました。
所感

• カンファレンスサイト（概要のみ）
• https://www.dataengconf.com/speaker/artwork-
personalization-at-netflix?hsLang=en-us
• ブログ（画像引用元）
• https://medium.com/netflix-techblog/artwork-
personalization-c589f074ad76
参考

その他のセッション

• 内容
• Prestoの紹介
• 他のSQL Engineと比べた際のPrestoの良さとして、特定の
Data sourceに依存しない、ということを強調していました
• Starburstが提供するPresto Enterpriseの紹介
• 所感
• 人は多く、Prestoの根強い人気を感じました
• Prestoを再評価する良いきっかけになりました
• 弊社ではEMRのPrestoを使っていて、Prestoが特定のData
sourceに依存しないという点はあまり意識したことはなかっ
たですが、時代の流れとしても特定のプラットフォーム・技術
非依存、という性質はより重視されてきていると思ったため
Presto: Fast SQL-on-Anything

• 内容
• Facebookでデータ基盤を構築・運用した経験から得た
プライバシーやセキュリティに関するお話
• Multi-tenancyモデルでのセキュリティの問題
• GDPRの『忘れられる権利』の対応に苦労したお話
• 個人情報に関連するデータに対して Semantic Type を定義
• 個人情報を取り扱うテーブルは最低限に抑え、
残りのテーブルは過去の全てのデータに対して匿名化を施した
• IP -> masked IP、name -> null
• 所感
• 数少ないプライバシーやセキュリティの話で、リスク
削減と性能のトレードオフの難しさを再認識しました
Analyzing Data in the Cloud: Privacy and Security

まとめ

• 全体の話の傾向
• 全体としてMLやAIに関するセッションがかなり多かっ
た印象
• データ分析基盤においては処理パフォーマンスよりも、
ストリーミングやスケジューラに着目した話が多かっ
た印象
• Apache Kafka、Apache Airflowなど
• 所感
• 概観としては、AWS・GCPなどクラウドで簡単にデー
タ分析基盤が構築できるようになった今、それらを組
み合わせて如何に分析基盤を効率よく運用するか、ま
た、データにML等を適用して如何に事業的価値を出せ
るか、ということに注目が集まっていると感じました
まとめ

ありがとうございました！

DataEngConf NYC’18 セッションサマリー #2

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à DataEngConf NYC’18 セッションサマリー #2

Similaire à DataEngConf NYC’18 セッションサマリー #2 (20)

Plus de gree_tech

Plus de gree_tech (20)

DataEngConf NYC’18 セッションサマリー #2

Notes de l'éditeur