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

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

by CyberAgent

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

2019年度新卒⼊社 AI事業本部 AI本部領域拡⼤ディビジョン Dynalyst @ur 0 n 黒⾦宗史 Kurogane Shushi

Slide 3

Slide 3 text

໨࣍ Contents ໨࣍ Contents ໨࣍ Contents ໨࣍ Contents ໨࣍ Contents Agenda 1 . Dynalstについて 2 . 旧アーキテクチャについて 1 . 旧アーキテクチャの概要 2 . 課題に感じていたところ 3 . ECSを⽤いたアーキテクチャのアップデートについて 1 . ECSの説明 2 . ECSを選択した経緯 3 . 新しいアーキテクチャとAutoScaling戦略 4 . よかったこと/悪かったこと

Slide 4

Slide 4 text

Dynalystについて

Slide 5

Slide 5 text

Dynamic Retargeting for Games DSP事業者スマホ向けリターゲティング広告配信   プラットフォーム⽇本のゲーム向け広告でトップシェアユーザーごとに最適化した広告を配信 Dynalystについて

Slide 6

Slide 6 text

システムの概況⼊札リクエスト/秒平均レスポンスタイム • ⼊札リクエスト量: 数⼗万リクエスト/秒(数千億リクエスト/⽉) • レスポンスタイム: 平均10ms • ログの量: 数TB/Day(圧縮状態) • ALL AWS • アプリケーションは主にScala

Slide 7

Slide 7 text

• SSPと呼ばれる広告枠を管理しているシステムとインテグレーションしリクエストを送ってもらう -> 接続しているSSPによってリクエストに傾向がある • OpenRTBというプロトコルに準拠する必要があるため 10 0 ms以内にレスポンスを返却しなければならない DSPのシステム 10 0 ms 以内 DSP DSP DSP SSP 広告枠１ WEBサイトやアプリ

Slide 8

Slide 8 text

旧アーキテクチャについて

Slide 9

Slide 9 text

Dynalystのアーキテクチャここがメインのサーバーで今⽇話すところ

Slide 10

Slide 10 text

配信サーバー(旧アーキテクチャ) • EC 2 を固定台数で運⽤している • ミドルウェアは直接インストール • fl uentdでログファイルを監視し   kinesisなどに流す • 旧世代のClassicLoadBalancerを使⽤している

Slide 11

Slide 11 text

デプロイフロー(旧アーキテクチャ) • リリースはgithubでタグを切って踏み台にSSHし特定のサーバーを選択しデプロイする • 半分は⼿作業

Slide 12

Slide 12 text

•デプロイに労⼒を使う •⻑期的なトラフィックの変化に対応できない •コストの最適化ができていない課題に感じていたところ

Slide 13

Slide 13 text

•デプロイに労⼒を使う •⻑期的なトラフィックの変化に対応できない •コストの最適化ができていない課題に感じていたところ

Slide 14

Slide 14 text

• 踏み台サーバーから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

Slide 15

Slide 15 text

•デプロイに労⼒を使う •⻑期的なトラフィックの変化に対応できない •コストの最適化ができていない課題に感じていたところ

Slide 16

Slide 16 text

DSPのトラフィックの上限/下限は⼤体同じだが、、、⻑期的なトラフィックの変化に対応できない

Slide 17

Slide 17 text

⻑期間で⾒ると上限がどんどん増えている⻑期的なトラフィックの変化に対応できない事業的な戦略でリクエスト量が増える場合もある点線が1ヶ⽉前のリクエスト量上限が1割ほど増加

Slide 18

Slide 18 text

⻑期的なトラフィックの変化に対応できない EC 2 Launch Template 踏み台サーバー bid xxx • AWSのコンソールにてLaunchTemplateからEC 2 を作成 • 新しいインスタンスのIPを控えhostsファイルを編集 • 踏み台サーバーからItamaeを使ってプロビジョニング • Fabricにてデプロイ⼿作業を強いられる上に 1台追加ごとに最⼤30分ほど時間がかかる

Slide 19

Slide 19 text

課題に感じていたところ •デプロイに労⼒を使う •⻑期的なトラフィックの変化に対応できない •コストの最適化ができていない

Slide 20

Slide 20 text

トラフィックの傾向に合わせてEC 2 を   簡易的にスケーリングしていたコストの最適化ができていない毎朝10台ほどcronでEC 2 をstop リクエストが戻る前にcronでEC 2 を起動もっと柔軟にスケーリングしコストの最適化ができるはず

Slide 21

Slide 21 text

ECSを⽤いたアーキテクチャのアップデート

Slide 22

Slide 22 text

• フルマネージド型のコンテナオーケストレーションサービス • インスタンスは管理するEC 2 型と   インスタンスも管理しなくて良いFargateが選べる   • Cluster - タスクやサービスを使う論理的なグループ • Task De fi nition - コンテナの定義(使⽤するリソースなども含む) • Service - 実⾏環境の様々な設定を定義する • Task - TaskDe fi nitionに基づいて起動されたコンテナの実⾏単位 Elastic Container Service(ECS)

Slide 23

Slide 23 text

CapacityProviderとService Auto Scaling • CapacityProvider ECS Serviceで定義した実⾏数に応じてEC 2 インスタンスなどをオートスケーリングしてくれるもの ECSのコントロールプレーンとCloudWatch、AutoScalingGroupを組み合わせて動く • Service Auto Scaling ECS Taskの実⾏数をスケーリングするもの

Slide 24

Slide 24 text

•デプロイに労⼒を使う •⻑期的なトラフィックの変化に対応できない •コストの最適化ができていない課題に感じていたところ(再掲)

Slide 25

Slide 25 text

•デプロイに労⼒を使う •⻑期的なトラフィックの変化に対応できない •コストの最適化ができていない課題に感じていたところ(再掲) 簡単にAutoScalingできるものにしたい

Slide 26

Slide 26 text

• アプリケーションやミドルウェアの起動は何で管理するか • Scale-Inする時にログが⽋損しないか • Scale-Outとデプロイが競合しないか AutoScalingする上で考えていたこと

Slide 27

Slide 27 text

AutoScalingする上で考えていたこと • アプリケーションやミドルウェアの起動は何で管理するか • Scale-Inする時にログが⽋損しないか • Scale-Outとデプロイが競合しないか

Slide 28

Slide 28 text

コンテナの依存関係を設定することでスケールイン時にログの⽋損をなくすことができる Scale-In時のログの⽋損

Slide 29

Slide 29 text

ECS serviceはタスク数やバージョン情報を管理しているのでAutoScalingのタイミングと被っても古いバージョンのタスクが動いていたら⾃動で切り替えてくれる Scale-Outとデプロイの競合順次v 2 に再デプロイされる

Slide 30

Slide 30 text

• アプリケーションやミドルウェアの起動は何で管理するか Docker化することによりシンプルに • Scale-Inする時にログが⽋損しないか ECSのコンテナ間の依存関係とFluentdの挙動でカバー • Scale-Outとデプロイが競合しないか ECSはコンピュータリソースと実⾏管理が分かれている AutoScalingする上で考えること(再掲)

Slide 31

Slide 31 text

• nginx,Datadog,Scala, fl uentdをそれぞれサイドカーで⼀つのインスタンスに • CapacityProviderとServiceAutoScalingでオートスケーリングを実現 • EC 2 型を使⽤することでボリュームのマウントができるためログの収集を今まで通り⾏う • コンテナ間の依存関係を設定しログの⽋損を対策 • ELBからALBに移⾏新しいアーキテクチャ

Slide 32

Slide 32 text

• コンテナの起動時に実⾏ファイル(jar) をダウンロードする • 無駄なdocker buildの削減 • Terraformで新しいバージョンのリリースをするだけで⾃動的にリリースが完了する新しいデプロイフロー

Slide 33

Slide 33 text

AutoScaling戦略 • 事前に負荷試験などを⾏い1台が捌けるQPSを調べる • ALBのRequestCountPerTargetというメトリクスを使い、   ターゲットごとのリクエスト数がちょうど良くなるようにスケーリングさせる

Slide 34

Slide 34 text

AutoScaling戦略 1つのタスクに流れるトラフィックを⼤体ベースラインに合わせるようにスケーリングしている

Slide 35

Slide 35 text

AutoScaling戦略タスクの起動/停⽌にかかる時間やスケーリング間隔により少しずれている部分はあるが概ね満たせていることがわかる • ⾚線がリクエスト数 • ⻘いエリアが満たせているキャパシティ • 処理できるQPS x インスタンス数

Slide 36

Slide 36 text

• 良かったことデプロイがかなり楽になったミドルウェアの依存度を下げることができた AutoScalingができるようになったスポットインスタンスが導⼊しやすくなった • 悪かったこと通信費が増えてしまったスケールが遅い良かったこと/悪かったこと

Slide 37

Slide 37 text

• ECSのコンテナネットワークはawsvpc mode を使⽤する • awsvpc modeを使⽤する場合、外部へのトラフィック(awsのマネージドサービスを含む)は NATゲートウェイを通さなくてはならない • NATゲートウェイはトラフィックに料⾦がかかるためVPC Endpointを使⽤し料⾦を抑える通信費の増加

Slide 38

Slide 38 text

スパイクはあるものの問題ないパフォーマンスを出せている達成できたのか

Slide 39

Slide 39 text

達成できたのかチームのSlackチャンネルにて、使ってくれている⼈からも楽になったという報告が！

Slide 40

Slide 40 text

• ECS on EC 2 はスケーリングは速くないがDSPなど   トラフィックに傾向があるプロダクトでは⼗分   • ECSを使うことでオートスケーリングやオートプロビジョニング、   デプロイなどで発⽣するさまざまな悩みから解放される • ECSを正しく利⽤すれば⾼トラフィック x 低レイテンシーな   ワークロードでも簡単にオートケーリングが導⼊できるまとめ

Slide 41

Slide 41 text

No content