aws_summit_abematv_fresh

Size: px

Start display at page:

Download "aws_summit_abematv_fresh"

けいしょうのえ
5 years ago
Views:

1 Dockerだらけの FRESH!な動画配信プラットフォーム 2016/06/03 AWS Summit Tokyo 2016 Developers / CyberAgent, Inc.

2 Akinori Yamada CyberAgent, Inc. / AbemaTV, Inc. Technical Engineer AmebaFRESH! AbemaTV FRESH! stormcat24

3 Agenda FRESH! とは配信プラットフォームとして目指した価値 Microservices FRESH! と Docker Docker と Amazon EC2 Container Services でのサービス構成パターン Blue Green Deployment Docker を検討されている皆様へ

4 AbemaTV FRESH! とは 4/1 に AmebaFRESH! から名称変更 AbemaTV( 無印 ) とは別のサービスです生放送配信プラットフォーム現在約 500 チャンネル様々なコンテンツプロバイダー ( 配信主 ) が利用年内 1,000 チャンネルまで拡大予定

7 FRESH! のサービス特性 24 時間いつでも常に何かしらの配信がされている放送しっぱなし定点カメラもあり配信主はいつでも配信可能テレビとは違い番組編成をサービス側でコントロールできるものではない

8 配信プラットフォームとして目指した価値とは?

9 答え可用性とスケーラビリティ

10 高い可用性サービス全停止でのメンテナンスを極力しないデプロイによるダウンタイムを作らない仮に一部分が障害を起こしても動画配信視聴というユーザーにとっての絶対的主目的は守りぬく動画配信 + 視聴が 24 時間 365 日いつでも行えるプラットフォームを目指す

11 スケーラビリティ人気番組特番時のキャパシティ不足視聴品質劣化を起こさない容易にスケールできるシステム構成であること ( スケールデメリットがある構成は避ける ) どんな人気コンテンツでも誰もが等しく快適に視聴できること

12 目指すべき価値の解 Microservices Docker + Immutable Infrastructure Blue Green Deployment

13 Microservices システムを解決すべきドメイン領域によって切り分けるパターン FRESH! の例 ( 一部 ) User API Broadcast Chat Timeline Tracking

14 Microservices と可用性 Amazon RDS( 以後 RDS と省略 ) の再起動や時間のかかるスキーマチェンジの運用課題 Service 別に DB を持つためシステム全体を止めてのメンテナンスを回避できる呼び出し側の Service でのケアを用意しておく ( 例 )Disable XXX Service Mode ( 例 ) の機能は現在ご利用いただけません

15 Docker 利用のモチベーション Immurable Infrastructure との親和性ポータビリティの高さイメージ作ってしまえばコンテナ上げるだけ Provisioning でインフラの面倒を続けるよりコンテナの面倒を見る方が敷居が低いのでは? という仮説コンテナを簡単に増やせる仕組みさえあればスケールする

16 FRESH! と Docker Amazon EC2 Container Services( 以後 Amazon ECS または ECS と省略 ) の東京リージョンリリースから利用ホスト OS は Ubuntu Docker ecs-agent 軽量化を図るためベースイメージは Alpine Linux

17 コンテナ化方針基本的にデータストア以外はコンテナ化するインフラとアプリケーションがコンテナによってセットで扱うことができるメリットは大きいログはホストにボリュームマウントし fluentd で Amazon S3( 以後 S3 と省略 ) や Elasticsearch に転送するアプリケーションの設定やミドルウェアの設定は環境変数で設定できるようにする

18 コンテナ化結局何がおいしい? 環境差異問題からの脱却 A の環境では動くが B の環境では動かない的なあるあるな問題環境再現のしやすさインフラのメンテコストの軽減 Provisioning ほとんど要らないよね (FRESH は clout-init だけ )

19 コンテナ時代の設定管理環境別の設定ファイルは Docker にはそぐわない環境変数変更だけで挙動を変えられてこそのポータビリティ環境変数ベースアプリケーションの設定変更にビルド不要環境変数を変えてのデプロイで済む

20 Amazon ECS と設定管理 github.com/stormcat24/ecs-formation docker-compose ライクの Amazon ECS クラスタ構成管理ツール Blue Green Deployment もサポート

21 FRESH! が Docker 化しているもの REST API(Go) Nginx Job Worker(Go) Wowza Streaming Engine React(Node.js) HAProxy Chat(Node.js) fluentd 独自 Cron(Java)

22 Docker と Amazon EC2 Container Service でのサービス構成パターン

23 Amazon ECS の予備知識 ECS でのコンテナの集合体を Task として定義する Task は Amazon EC2( 以後 EC2 と省略 ) インスタンスで構成されるクラスタ上で動作する ECS クラスタ上で Task を起動したりインスタンスのリソースを考慮したスケジューリングをする役割を担うのが Service

24 1 クラスタに複数種の Task 1 つの ECS クラスタに複数種類の Task が配置される方式空きリソースを効果的に利用しやすい人間的にはどこにどの Task が配置されてるかがわかりにくい

25 クラスタを役割で分ける役割等で ECS Cluster を分ける方式わかりやすい FRESH ではこの方式を採用スケールが必要な役割のものは AutoScaling Group と併用

26 基本的な考え方役割 ( ドメイン領域 ) で 1 つの Microservices Microservices は ECS クラスタ単位で構成する

27 全体構成図かなり簡略

28 各Microserviceの構築パターン

29 Public な Service( 第 1 段階 ) Public に公開するものは Nginx を前段に Nginx+API が Task Elastic Load Balancing( 以後 ELBと省略 ) からは各 Taskの HTTPポートにリクエストを振り分ける

30 PublicなService 第2段階この段階で実用的ログはﬂuentdで転送 EC2 Slave群を参照するためにHAProxyを利用

31 HAProxyのコンテナ利用各TaskにHAProxyを入れてしまおうという考え essential設定でhaproxy が落ちれば他コンテナも道連れで落ちるようにできる HAProxyだけ落ちるという異常な状態を回避

32 PublicなWeb + API WebはReact + Fluxでの SSR/SPA構成ネイティブはNginx -> API WebはNginx -> Node -> API

33 assetsの扱い assetsはnodeコンテナに属する assets類はnginxから直接配信したい(gzip圧縮) コンテナ間ボリュームマウント(volume_form)

34 Internal Service Internal ELB経由で別の Serviceを利用する REST APIベース最近は grpcの選択肢もある

35 Job Worker Enqueue/Dequeue型のJob Worker Amazon SQS 以後SQSと省略) 重めの処理を担当定時ジョブは独自Cronから Enqueue Task増やすだけでスケール

36 Wowza Streaming Engine 動画配信サーバ配信は RTMP 視聴は HLS(HTTP Live Streaming) Amazon S3 Amazon CloudFront( 以下 CloudFront と省略 )

37 基本的にService群の組み合わせ

38 運用開発体制サーバサイド 6+ インフラ 1 Not Two Pizza Team サービス : 開発者 = N : N 各サービス毎に主担当はいるが他のメンバーも面倒が見れるようにしている Microservices Map のような俯瞰できるドキュメントの作成構成図やポート対応表現状複雑性より可用性を優先している

39 FRESH! の今後の課題 HTTP2 対応リソースの最適化 ( マシンリソースを使い切る ) Circuit Breaker Pattern Service 粒度の最適化多くの Microservices を運用するチーム開発体制

40 Blue Green Deployment

41 Blue Green Deployment 稼働系インフラにアプリケーションをデプロイし直すのではなくインフラごと新しく構築して切り替えてしまう手法旧系統から新系統にロードバランサーを切り替えるロールバックも容易カジュアルにインフラを壊していこう

42 2Auto Scaling Group Pattern Blue と Green の Auto Scaling Group を用意する Auto Scaling Group 単位で ELB をつけかえる Auto Scaling Group 上にそれぞれ ECS のクラスタを作成デプロイ後古いクラスタは DesiredCount=0 にしてインスタンスを破棄

43 ECS + 2Auto Scaling

44 Blue Green がもたらしたものデプロイの安心感致命的な状態を含んだ成果物が出ることを防止 *.amebafresh.tv -> *.abemafresh.tv の悲しみのドメイン変更サービス名変更でドメインも変えることに全ての Service をダウンタイムゼロで移行成功

45 Docker を検討されている皆様へ

46 Docker 投入考えられる障壁運用経験が無いなんとなく感じがちな得体のしれない怖さ (((((( ; Д )))))) 本当にちゃんと動くの? 地雷いっぱいあるんでしょ? クラスタの管理方法

47 とりあえず開発環境から?

48 開発環境のみの利用はもったいない Docker ポータビリティはそもそも環境を問わない実行環境を目指したもの既に開発環境で利用しているなら本番でも動きますよ? 地雷もだいぶ踏み尽くされてきましたとりあえず AWS ソリューションアーキテクトの皆様に相談してみましょう!

49 開発環境のみの利用はもったいないです (2 回目 )

50 Have a nice container life.

AWS Deck Template

AWS Deck Template AWS OpsWorks のご紹介 Amazon Data Services Japan 2013/06/25 Agenda AWS OpsWorks とは OpsWorks の特長 OpsWorks 利用の流れ OpsWorks のメリット Chef とは OpsWorks のライフサイクルイベントどのようなアプリケーションが OpsWorks に向いているのか? OpsWorks の機能詳細