UNICORNの機械学習ワークロードにおけるSpot&AWS Batchの活用

https://unicorn.inc
機械学習ワークロードにおける 
Spot&AWS Batchの活用 
 
11/11/2020 AWS 秋のスポットインスタンス祭り

SEKI INOUE
0.1 PROFILE 自己紹介  
博士（情報理工学）
TOP DATA SCIENTIST  UNICORN, Inc.
CTO  Mist Technologies, Inc.
特任研究員 @ 東京大学
井上碩 @peroxyacyl

ABOUT UNICORN
1.0 ABOUT UNICORN サービスのご紹介  
サービスのご紹介

デジタル広告の価値算定エンジン 
+ 
買付プラットフォーム 
業界内の立ち位置はDSPだが、買い方はかなり異なる 
広告枠 
(2300万種類/月)  
✕ 
広告在庫 
(6400種類/月) 
ユーザー群の行動が 
どう変わるか? 
 
で価値算定 
広告枠の相場 = 他社の値付けは 
価値算定に一切考慮しない* 
*買付時はオークション理論に則って最適化

DISPLAY ADS 自動最適化エンジン  APPLE SEARCH ADS 自動最適化エンジン 
Google
SNS 広
告 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
COVERAGE - メガプラットフォームがリーチできない広告トラフィック  
 
国内最大級の6,000億imp/月を用いて、Google及びSNS広告とは 
異なるユーザーのシチュエーションとカバーできない全領域にてリーチ可能。 
FRAUD PROTECTION - 徹底的なデータクレンジング  
 
誤タップ誘導と不正imp&clickの検出、CTR/CVR分析、不正広告探知の専門機関によ
るコンバージョンデータの検収など、クライアントの広告費用と自社の最適化アルゴリ
ズムを徹底的に保護。 
PERFORMANCE - 自動最適化・高 ARPUとROAS
 
「月間6,000億impのデータ学習 + 徹底的なデータクレンジング」を基に、 
最も理想的な「広告枠 x オーディエンス x クリエイティブ」の組み合わせを 
予測し、ターゲットKPIに合わせて自動最適化。 
WHY - なぜApple Search Adsが重要な広告商品なのか？  
● App Store内で唯一自社のアプリを宣伝できる広告商品 
● アプリを利用する意思がある状態のユーザーとの接触が可能 
● 事業成長のコアに繋げる事ができる広告商品（自然流入の増加） 
● ポストiOS14の環境で最も重要な広告商品 
HOW - 10万通り以上の‘属性 x キーワードの組み合わせ’を自動最適化  
● 100+ のユーザー属性の自動生成 
● 1,000+ のキーワード自動収集 
● 100,000+ のユーザー属性 x キーワードの組み合わせに対する自動入札最適化 
課題 
Apple Search Adsは戦略的には重要。  
しかし、人手には限度がある。  
最適化の努力 運用 
● キャンペーン分類別のセグメント 
● 完全一致キーワードに高い入札単価設定 
● ネガティブキーワードの活用 
● 新しいキーワードの探索活用 
● etc 
● キーワード生成 
● キャンペーン構成の設計 
● キャンペーン / アドグループ設定 
● キーワード選定 / 設定 
● キーワード別の入札調整 
人力 = リソースの制限による運用可能なキーワード量の制限 
効果の最大化が難しい 
機械学習 x 全自動 
人力ではコントロール不可能な量のデータを用いて、効果の最大化を実現 
最適化の努力 運用 
● キャンペーン分類別のセグメント 
● 完全一致キーワードに高い入札単価設定 
● ネガティブキーワードの活用 
● 新しいキーワードの探索活用 
● etc 
● キーワード生成 
● キャンペーン構成の設計 
● キャンペーン / アドグループ設定 
● キーワード選定 / 設定 
● キーワード別の入札調整 
解決案 
UNICORNの  
Apple Search Ads自動最適化エンジン  
ユーザー群の未来の行動を予測して、 
過去の行動を捉えるのではなく、 
広告を広く買付する

UNICORN Tech Numbers  
UNICORN
秒間HTTPリクエスト数リクエストあたり推論数
一日に学習するモデル数
50万 QPS 
120 モデル / 日
208 推論 / リクエスト 
保有データ量 (一次データのみ)
平均レスポンスタイム
10.31 msec
外部との秒間データ IO
6.7 PB 
4.8 GB / sec

UNICORN Biz Numbers  
※ 株式会社アドウェイズ 2021年3月期第2四半期決算説明会資料 
AWSインフラコスト 
が大部分を占める 
 
スポットインスタンスがな
ければ 
ビジネスが成立しない

SPOT  UNIC
2.0 SPOTUNICORN スポットインスタンスの利用状況  
スポットインスタンスの利用状況

https://unicorn.inchttps://unicorn.inc
 
全体の半分以上がスポットインスタンス 
　ML推論・学習部分では94%  $0.0198
Average cost per VCPU-hour 
 
学習 
　失敗可能なタスク　→　Spot+Batch 
 
推論 
　オートスケール　　→　Spot+ELB 
 
DB 
　負荷が安定　　→　Reserved 
全体：333スポット/602インスタンス 
 
 
うちML関連部分 
　ML学習：　6スポット/6インスタンス 
　ML推論：　301スポット/319インスタンス 
　DB ：　0スポット/98インスタンス 
 
71%
Savings
$0.0041
Average cost per mem(GiB)-hour
 
12xlarge

 
UNICORN モデル群 
学習スケジュール 
学習タスクによって 
● かかる時間 
● つかうCPU 
● 必要なメモリ 
● 必要なディスクサイズ　　が異なる 
 
 
1 8/
AWS Batchでその都度リソースを確保  
第5世代 (c5, c5a, m5, r5)をSPOTで使用

 
UNICORN モデル群 
学習スケジュール 
学習タスクによって 
● かかる時間 
● つかうCPU 
● 必要なメモリ 
● 必要なディスクサイズ　　が異なる 
 
 
1 8/
AWS Batchでその都度リソースを確保  
第5世代 (c5, c5a, m5, r5)をSPOTで使用  
4 vCPU
16GB memory
50GB volume
16 vCPU
2GB memory
500GB volume
8 vCPU
16GB memory
100GB volume

BATCH  ML
3.0 BATCHML AWS Batchと機械学習  
AWS Batchと機械学習

ワークロードの概要 
 
1. データのダウンロード 
2. データの検証 
3. 特徴量変換 
 
4. 学習エポック1 
5. 学習エポック2 
… 
6. 学習エポックN 
 
7. モデルの検証 
8. モデルのアップロード 
S3  RDS  その他DB 
1. データダウンロード  
3. 特徴量変換  
shuffle 
hash等 
S3 
8. モデルアップロード  
4-6.学習 
モデルファイル  特徴量ファイル  学習データセット(~500GB)  
学習サイクル  
高IO : ~1000IOPS  
3.1 BATCHML AWS Batchと機械学習

スポットで中断しても良い学習バッチとは? 
 
↓ 
 
失敗したときのバックアッププランを考える 

学習のチューニング方針  
● モデルバージョン間で大きな推論の差が出ないようにする 
 
○ データセットの期間を長く取る  
○ 環境変化に対する即応性とのトレードオフ  
 
 
1. 学習正常終了 → S3へアップロード（S3 Versioning)  
2. 推論側は、定期的にS3をポーリング  
失敗してもよいML学習ワークロードの例 
失敗した場合は  
一つ前のバージョンを使う  
① モデルのバージョニング 

学習を短く、数を多く 
② マイクロモデルをアンサンブルする 
大きな単一のモデルで推論するのではなく、
小さなモデルを複数用意してそれらの平均を取る
学習を短く済ませ、歩留まりを上げる
p
平均 
サンプリング 
40%
40%
40%
学習 
Batch Job 

最新 N バージョンを加重平均する
即応性 + 安定性 
③ バージョニング + アンサンブル 
・・・
1時間前  2時間前  3時間前 
失敗 
4時間前  5時間前  6時間前 
p ← 0.5p' + 0.3p'' + 0.2p'''

BATCHEBS
4.0 BATCHEBS AWS BatchでEBSを使う方法  
AWS BatchでEBSを使う方法

AWS Batchの基本容量はホストあたり8GB 
↓ 
ストレージを足す方法は３つ 

① EFSをマウントする 
EFS = スケーラブルなNAS サイズ課金 + スループット課金 
コンテナ (Batch Job)  
ホスト 8GB 
AWS EFS 
∞ GB 
mount 
volume 
mount 
volume

② ホストのEBSをアップグレード 
ルートボリュームを大きくしたAMIを作成する 
ホスト 100GB 
Customized AMI

② ホストのEBSをアップグレード 
ルートボリュームを大きくしたAMIを作成する 
ホスト 100GB 
Customized AMI 
コンテナの数は不定

③ EBSをコンテナにマウント 
コンテナのdevice socket経由でEBSをマウントする 
ホスト 8GB 
AWS EBS 
20GB 
AWS EBS
80GB 
mount 
volume 
mount 
volume

③Batch JobごとにEBSを動的アタッチ 
Jobごとにサイズを可変にして効率化 
AWS Batchで標準装備のEBS  
Jobごとに作成＋アタッチされた揮発領域用のEBS  
4.5 BATCHEBS AWS BatchでEBSを使う方法

Dockerコンテナでストレージを使う３つの方法 
デフォルトは、インスタンスあたり8GB 
  EFSをマウント  EBSをホストにマウント   EBSをコンテナにマウント  
共有範囲  全Jobで共有  ホスト内で共有  Jobで専有 
マウントの 
タイミング 
Job起動時  AMI作成時  Job起動時 
メリット 
データが永続的 
全体で共有できる 
コンテナがシンプル 
Job毎にサイズ/IOPSが可変  
burst creditがリセット  
断片化しない(st1も視野)  
デメリット  スループットが高価 
サイズ/IOPSの事前設定が必要  
十分なリソースの確保が必要  
データが完全に揮発的  
消しそこねると痛い 

Dockerコンテナでストレージを使う 
UNICORNのワークロードでの費用感 
必要な 
サイズ 
2,500 GB  500 GB x 6 instances   合計 2,500 GB 
必要な 
ProvisionedIO 
1,500 Mbps 
io2 2,000 IOPS 
(500 IOPS x 4 job) 
gp2 
(起動時のburst creditで足りたため) 
月間コスト 
(ap-northeast)  
$10,800 / month  $1,314 / month  $300 / month 

Dockerコンテナ起動時のENTRYPOINTで以下の処理を行う  
① awscliでEBSを作成
$ aws ec2 create-volume
② 使用可能なデバイスファイルを探す (例: /dev/xvdf )
$ [while文などで]
③ 作ったEBSをホストインスタンスにアタッチ
$ aws ec2 attach-volume
④ デバイスのファイルシステムをフォーマット
$ mkfs.xfs -f /dev/$DEVNAME
⑤ マウント
$ mount /dev/$DEVNAME $EBS_PATH
⑥ EBS削除の設定 (後述)
③ EBSをコンテナにマウント 
【EBSをdeviceとしてアクセスする】 
※ 要privilegeフラグ
https://github.com/peroxyacyl/batch.tmpl  

EBSの削除 
EBSが残ると課金が続く  
 
↓ 
確実な削除が必要  
 
 
 
 
 
 
lambdaで監視するのも有効  
 
1 8/
EBS削除のタイミングと方針 
1. 正常終了 
ENTRYPOINTでコマンド後に実行 
 
2.プログラムの異常終了 
ENTRYPOINTでtrapする 
 
 

EBSの削除 
EBSが残ると課金が続く  
 
↓ 
確実な削除が必要  
 
 
 
 
 
 
lambdaで監視するのも有効  
1 8/
EBS削除のタイミングと方針 
3. スポットインスタンスの回収 
4. ジョブの手動キャンセル 
中断通知内のdetachが間に合わない 
キャンセルの場合は即時に落ちる 
→ Delete On Termination機能を使う 
 
 

Tips  
/devをコンテナにマウント 
コンテナ内の/devは  
デバイス追加時に更新されない  
 
 
 
 
/devを仮想ボリュームとして  
コンテナにマウントする  
 
 
第三者のdocker imageには注意  
1 8/
Host
/dev
/xvda … 8GB
/xvdf … 200GB ← EBSをアタッチしても...
Container
/dev
/xvda
← ここは増えない
/hostdev
/xvda
/xvdf ← こっちは増える
マウント 
-v /dev:/hostdev 
 

https://unicorn.inchttps://unicorn.inc https://github.com/peroxyacyl/batch.tmpl  
EBSベンチマーク 
コンテナ直接アタッチのパフォーマンスは問題なし 
コンテナ専有EBS (io2 2000IOPS) 
コンテナ専有EBS (gp2 100GB) 
ホスト　共有EBS (gp2 100GB) 
コンテナ専有EBS (st1 500GB) 
5.1 APPENDIX 補足

Dockerコンテナでストレージを使う 
UNICORNのワークロードでの費用感 
必要な 
サイズ 
2,500 GB  500 GB x 6 instances   合計 2,500 GB 
必要な 
ProvisionedIO 
1,500 Mbps 
io2 2,000 IOPS 
(500 IOPS x 4 job) 
gp2 
(起動時のburst creditで足りたため) 
月間コスト 
(ap-northeast)  
$10,800 / month  $1,314 / month  $300 / month 

https://unicorn.inchttps://unicorn.inc
5.2 APPENDIX 補足 
開発でもBatchを使う 
　チューニングなどの高コストな計算をクラウドにオフロード 
$ ./runbatch.sh --cpu 4 --memory 16000 --volume 100 "python optuna.py"
このコマンドは下記を行う  
 
● ディレクトリをdockerに固めてECRにpush  
● job definitionの発行  
● 4 vCPUs, 16GB メモリ, 100GB EBS を確保 
● batch上で python optuna.py を起動 
● Log StreamのURLを出力  
 
 
 
https://github.com/peroxyacyl/batch.tmpl

6.0 summary まとめ 
まとめ
1. 弊社ではスポットインスタンスでコストをオンデマンドより71%下げている 
2. 学習ワークロードでは、失敗したときのバックアッププランを作る 
a. アンサンブル学習が歩留まりを上げるために有効な一例 
 
3. AWS BatchはJobごとに異なる負荷を持つときに効率的 
...だが, 作業用ストレージ領域が足りない 
4. EBSをコンテナに直接マウントする方式が有効 
 
5. 開発やチューニングにもAWS Batchは使える 
https://github.com/peroxyacyl/batch.tmpl

10.0 WE ARE HIRING UNICORN採用  
We are hiring
golang
ruby
rust
assemblyTypeScriptSQL
自然言語処理 
Data Visualization 
強化学習 
Rich Creative Design 
Data ETL 
App SDK 
Tech. Account Managing 
JS SDK 
SRE 
Microservice Orch. 
contact@unicorn.inc

unicorn.inc

UNICORNの機械学習ワークロードにおけるSpot&AWS Batchの活用

More Related Content

What's hot (20)

Similar to UNICORNの機械学習ワークロードにおけるSpot&AWS Batchの活用 (20)

UNICORNの機械学習ワークロードにおけるSpot&AWS Batchの活用