Docker だらけの FRESH な動画配信プラットフォーム

by stormcat24

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

stormcat24 ‣ Akinori Yamada ‣ CyberAgent, Inc. / AbemaTV, Inc. ‣ Technical Engineer ‣ http://blog.stormcat.io ‣ AmebaFRESH! ⇒ AbemaTV FRESH!

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

全体構成図（※かなり簡略）

Slide 28

Slide 28 text

各Microserviceの構築パターン

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Internal Service ‣ Internal ELB経由で、別の Serviceを利用する ‣ REST APIベース（最近は gRPCの選択肢もある）

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Blue Green Deployment

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

ECS + 2Auto Scaling

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

とりあえず開発環境から？

Slide 48

Slide 48 text

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