DynalystにおけるECSとAutoScalingを用いたアーキテクチャのアップデート | CA BASE NEXT

□ 登壇者
黒金 宗史

□ 発表について
Dynalystはゲームに特化したリターゲティング広告のシステムを開発、運用しています。リクエストは秒間数十万にも上り広告システムの制約上、100ms以内にレスポンスを返さなくてはなりません。
プロダクトに数々のMLモデルを組み込んだりさらにプロダクトをスケールさせるためにはシステムのアップデートが不可欠になりました。
このセッションでは高トラフィックかつ低レイテンシなシステムをより低コストで運用しやすいシステムにするためにECSとAutoScalingを用いてアップデートしたことについてご紹介させていただきます。

セッション動画はこちら

□ CA BASE NEXT (CyberAgent Developer Conference by Next Generations) とは
20代のエンジニア・クリエイターが中心となって創り上げるサイバーエージェントの技術カンファレンスです。
当日はセッション・LT・パネルディスカッション・インタビューセッションを含む約50のコンテンツをYouTube Liveを通じて配信します。
イベントページ

□ 採用情報
サイバーエージェントに少しでも興味を持っていただきましたら、お気軽にマイページ登録やエントリーをおねがいします！

◆新卒エンジニア採用
エントリー・マイページ登録はこちら
採用関連情報のまとめはこちら

◆新卒クリエイター採用
エントリー・マイページ登録はこちら

◆中途採用
採用情報はこちら

Transcript

2. 2019年度 新卒⼊社 AI事業本部 AI本部 領域拡⼤ディビジョン Dynalyst @ur 0 n 黒⾦宗史 Kurogane Shushi
3. ໨࣍ Contents ໨࣍ Contents ໨࣍ Contents ໨࣍ Contents ໨࣍ Contents Agenda 1 . Dynalstについて 2 . 旧アーキテクチャについて 1 . 旧アーキテクチャの概要 2 . 課題に感じていたところ 3 . ECSを⽤いたアーキテクチャのアップデートについて 1 . ECSの説明 2 . ECSを選択した経緯 3 . 新しいアーキテクチャとAutoScaling戦略 4 . よかったこと/悪かったこと
4. Dynalystについて
5. Dynamic Retargeting for Games DSP事業者 スマホ向けリターゲティング広告配信 
 プラットフォーム ⽇本のゲーム向け広告でトップシェア ユーザーごとに最適化した広告を配信 Dynalystについて
6. システムの概況 ⼊札リクエスト/秒 平均レスポンスタイム • ⼊札リクエスト量: 数⼗万リクエスト/秒(数千億リクエスト/⽉) • レスポンスタイム: 平均10ms • ログの量: 数TB/Day(圧縮状態) • ALL AWS • アプリケーションは主にScala
7. • SSPと呼ばれる広告枠を管理しているシステムとインテグレーションしリクエスト を送ってもらう -> 接続しているSSPによってリクエストに傾向がある • OpenRTBというプロトコルに準拠する必要があるため 10 0 ms以内にレスポンスを 返却しなければならない DSPのシステム 10 0 ms 以内 DSP DSP DSP SSP 広告枠１ WEBサイトやアプリ
8. 旧アーキテクチャについて
9. Dynalystのアーキテクチャ ここがメインのサーバーで今⽇話すところ
10. 配信サーバー(旧アーキテクチャ) • EC 2 を固定台数で運⽤している • ミドルウェアは直接インストール • fl uentdでログファイルを監視し 
 kinesisなどに流す • 旧世代のClassicLoadBalancerを使⽤している
11. デプロイフロー(旧アーキテクチャ) • リリースはgithubでタグを切って 踏み台にSSHし特定のサーバーを 選択しデプロイする • 半分は⼿作業
12. •デプロイに労⼒を使う •⻑期的なトラフィックの変化に対応できない •コストの最適化ができていない 課題に感じていたところ
13. •デプロイに労⼒を使う •⻑期的なトラフィックの変化に対応できない •コストの最適化ができていない 課題に感じていたところ
14. • 踏み台サーバーからFabricを⽤いてデプロイする • ロードバランサーからデタッチしバージョンをリリース したロードバランサーにアタッチする • デプロイ先のサーバーはhostsファイルで管理 デプロイに労⼒をつかう Fabric 踏み台サーバー bidインスタンス Classic Loadbalancer デプロイのたびに踏み台にsshし、 デプロイが終わるまで⾒守る必要がある 毎回30分ほどかかる /etc/hosts 10 . 0 . 0 . 1 bid 01 10 . 0 . 0 . 2 bid 02 … .. 
 10 . 0 . 0 . 110 bid 120 $ deploy bid 01 ,bid 02 ,bid 03… bid 1 20
15. •デプロイに労⼒を使う •⻑期的なトラフィックの変化に対応できない •コストの最適化ができていない 課題に感じていたところ
16. DSPのトラフィックの上限/下限は⼤体同じだが、、、 ⻑期的なトラフィックの変化に対応できない
17. ⻑期間で⾒ると上限がどんどん増えている ⻑期的なトラフィックの変化に対応できない 事業的な戦略でリクエスト量が増える場合もある 点線が1ヶ⽉前の リクエスト量 上限が1割ほど増加
18. ⻑期的なトラフィックの変化に対応できない EC 2 Launch Template 踏み台サーバー bid xxx • AWSのコンソールにてLaunchTemplateからEC 2 を作成 • 新しいインスタンスのIPを控えhostsファイルを編集 • 踏み台サーバーからItamaeを使ってプロビジョニング • Fabricにてデプロイ ⼿作業を強いられる上に 1台追加ごとに最⼤30分ほど時間がかかる
19. 課題に感じていたところ •デプロイに労⼒を使う •⻑期的なトラフィックの変化に対応できない •コストの最適化ができていない
20. トラフィックの傾向に合わせてEC 2 を 
 簡易的にスケーリングしていた コストの最適化ができていない 毎朝10台ほどcronでEC 2 をstop リクエストが戻る前にcronでEC 2 を起動 もっと柔軟にスケーリングし コストの最適化ができるはず
21. ECSを⽤いた アーキテクチャのアップデート
22. • フルマネージド型のコンテナオーケストレーションサービス • インスタンスは管理するEC 2 型と 
 インスタンスも管理しなくて良いFargateが選べる 
 • Cluster - タスクやサービスを使う論理的なグループ • Task De fi nition - コンテナの定義(使⽤するリソースなども含む) • Service - 実⾏環境の様々な設定を定義する • Task - TaskDe fi nitionに基づいて起動されたコンテナの実⾏単位 Elastic Container Service(ECS)
23. CapacityProviderとService Auto Scaling • CapacityProvider ECS Serviceで定義した実⾏数に応じてEC 2 インスタンスなどをオートスケーリングしてくれるもの ECSのコントロールプレーンとCloudWatch、AutoScalingGroupを組み合わせて動く • Service Auto Scaling ECS Taskの実⾏数をスケーリングするもの
24. •デプロイに労⼒を使う •⻑期的なトラフィックの変化に対応できない •コストの最適化ができていない 課題に感じていたところ(再掲)
25. •デプロイに労⼒を使う •⻑期的なトラフィックの変化に対応できない •コストの最適化ができていない 課題に感じていたところ(再掲) 簡単にAutoScalingできるものにしたい
26. • アプリケーションやミドルウェアの起動は何で管理するか • Scale-Inする時にログが⽋損しないか • Scale-Outとデプロイが競合しないか AutoScalingする上で考えていたこと
27. AutoScalingする上で考えていたこと • アプリケーションやミドルウェアの起動は何で管理するか • Scale-Inする時にログが⽋損しないか • Scale-Outとデプロイが競合しないか
28. コンテナの依存関係を設定することでスケールイン時にログの⽋損をなくすことができる Scale-In時のログの⽋損
29. ECS serviceはタスク数やバージョン情報を管理しているのでAutoScalingの タイミングと被っても古いバージョンのタスクが動いていたら⾃動で切り替えてくれる Scale-Outとデプロイの競合 順次v 2 に再デプロイされる
30. • アプリケーションやミドルウェアの起動は何で管理するか Docker化することによりシンプルに • Scale-Inする時にログが⽋損しないか ECSのコンテナ間の依存関係とFluentdの挙動でカバー • Scale-Outとデプロイが競合しないか ECSはコンピュータリソースと実⾏管理が分かれている AutoScalingする上で考えること(再掲)
31. • nginx,Datadog,Scala, fl uentdをそれぞれサイド カーで⼀つのインスタンスに • CapacityProviderとServiceAutoScalingでオー トスケーリングを実現 • EC 2 型を使⽤することでボリュームのマウントが できるためログの収集を今まで通り⾏う • コンテナ間の依存関係を設定しログの⽋損を対策 • ELBからALBに移⾏ 新しいアーキテクチャ
32. • コンテナの起動時に実⾏ファイル(jar) をダウンロードする • 無駄なdocker buildの削減 • Terraformで新しいバージョンのリ リースをするだけで⾃動的にリリース が完了する 新しいデプロイフロー
33. AutoScaling戦略 • 事前に負荷試験などを⾏い1台が捌けるQPSを調べる • ALBのRequestCountPerTargetというメトリクスを使い、 
 ターゲットごとのリクエスト数がちょうど良くなるようにスケーリングさせる
34. AutoScaling戦略 1つのタスクに流れるトラフィックを⼤体ベースラインに合わせるようにスケーリングしている
35. AutoScaling戦略 タスクの起動/停⽌にかかる時間やスケーリング間隔により 少しずれている部分はあるが概ね満たせていることがわかる • ⾚線がリクエスト数 • ⻘いエリアが満たせているキャパシティ • 処理できるQPS x インスタンス数
36. • 良かったこと デプロイがかなり楽になった ミドルウェアの依存度を下げることができた AutoScalingができるようになった スポットインスタンスが導⼊しやすくなった • 悪かったこと 通信費が増えてしまった スケールが遅い 良かったこと/悪かったこと
37. • ECSのコンテナネットワークはawsvpc mode を使⽤する • awsvpc modeを使⽤する場合、外部へのトラ フィック(awsのマネージドサービスを含む)は NATゲートウェイを通さなくてはならない • NATゲートウェイはトラフィックに料⾦がかか るためVPC Endpointを使⽤し料⾦を抑える 通信費の増加
38. スパイクはあるものの問題ないパフォーマンスを出せている 達成できたのか
39. 達成できたのか チームのSlackチャンネルにて、 使ってくれている⼈からも楽になったという報告が！
40. • ECS on EC 2 はスケーリングは速くないがDSPなど 
 トラフィックに傾向があるプロダクトでは⼗分 
 • ECSを使うことでオートスケーリングやオートプロビジョニング 、 
 デプロイなどで発⽣するさまざまな悩みから解放される • ECSを正しく利⽤すれば⾼トラフィック x 低レイテンシーな 
 ワークロードでも簡単にオートケーリングが導⼊できる まとめ