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

2016/06/03 AWS Summit Tokyo 2016 Developers Conference

@stormcat24 / CyberAgent, Inc.

stormcat24

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

Agenda‣ FRESH!とは

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

‣ Microservices

‣ FRESH!とDocker

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

‣ Blue Green Deployment

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

AbemaTV FRESH!とは‣ 4/1にAmebaFRESH!から名称変更

‣ ※AbemaTV（無印）とは別のサービスです

‣ 生放送配信プラットフォーム

‣ 現在約500チャンネル、様々なコンテンツプロバイダー（配信主）が利用。年内1,000チャンネルまで拡大予定

FRESH!のサービス特性‣ 24時間いつでも、常に何かしらの配信がされている

‣ 放送しっぱなし定点カメラもあり

‣ 配信主はいつでも配信可能

‣ テレビとは違い、番組編成をサービス側でコントロールできるものではない

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

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

高い可用性‣ サービス全停止でのメンテナンスを極力しない

‣ デプロイによるダウンタイムを作らない

‣ 仮に一部分が障害を起こしても、動画配信・視聴というユーザーにとっての絶対的主目的は守りぬく

動画配信＋視聴が24時間365日 いつでも行えるプラットフォームを目指す

スケーラビリティ‣ 人気番組・特番時のキャパシティ不足、視聴品質劣化を起こさない

‣ 容易にスケールできるシステム構成であること（スケールデメリットがある構成は避ける）

どんな人気コンテンツでも 誰もが等しく快適に視聴できること

目指すべき価値の解‣ Microservices

‣ Docker + Immutable Infrastructure

‣ Blue Green Deployment

Microservices‣ システムを解決すべきドメイン領域によって切り分けるパターン

‣ FRESH!の例（一部）

‣ User API

‣ Broadcast

‣ Chat

‣ Timeline

‣ Tracking

Microservicesと可用性‣ Amazon RDS（以後RDSと省略）の再起動や、時間のかかるスキーマチェ

ンジの運用課題

‣ Service別にDBを持つため、システム全体を止めてのメンテナンスを回避できる

‣ 呼び出し側のServiceでのケアを用意しておく

‣ （例）Disable XXX Service Mode

‣ （例）〜の機能は現在ご利用いただけません

Docker利用のモチベーション‣ Immurable Infrastructureとの親和性、ポータビリティの高さ

‣ イメージ作ってしまえば、コンテナ上げるだけ

‣ Provisioningでインフラの面倒を続けるより、コンテナの面倒を見る方が敷居が低いのでは？という仮説

‣ コンテナを簡単に増やせる仕組みさえあればスケールする

FRESH!とDocker‣ Amazon EC2 Container Services（以後Amazon ECSまたはECS

と省略）の東京リージョンリリースから利用

‣ ホストOSはUbuntu

‣ Docker 1.10.3

‣ ecs-agent 1.9.0

‣ 軽量化を図るため、ベースイメージはAlpine Linux

コンテナ化方針‣ 基本的にデータストア以外はコンテナ化する

‣ インフラとアプリケーションがコンテナによってセットで扱うことができるメリットは大きい

‣ ログはホストにボリュームマウントし、fluentdでAmazon S3（以後S3と省略）やElasticsearchに転送する

‣ アプリケーションの設定や、ミドルウェアの設定は環境変数で設定できるようにする

コンテナ化、結局何がおいしい？‣ 環境差異問題からの脱却

‣ Aの環境では動くが、Bの環境では動かない的なあるあるな問題

‣ 環境再現のしやすさ

‣ インフラのメンテコストの軽減

‣ Provisioningほとんど要らないよね（FRESHはclout-initだけ）

コンテナ時代の設定管理‣ 環境別の設定ファイルはDockerにはそぐわない

‣ 環境変数変更だけで挙動を変えられてこそのポータビリティ

‣ 環境変数ベース

‣ アプリケーションの設定変更にビルド不要

‣ 環境変数を変えてのデプロイで済む

Amazon ECSと設定管理‣ github.com/stormcat24/ecs-formation

‣ docker-composeライクのAmazon ECSクラスタ構成管理ツール

‣ Blue Green Deploymentもサポート

FRESH!がDocker化しているもの‣ REST API(Go)

‣ Job Worker(Go)

‣ React(Node.js)

‣ Chat(Node.js)

‣ 独自Cron(Java)

‣ Nginx

‣ Wowza Streaming Engine

‣ HAProxy

‣ fluentd

Dockerと Amazon EC2 Container Serviceでの

サービス構成パターン

Amazon ECSの予備知識‣ ECSでのコンテナの集合体をTaskとして定義する

‣ TaskはAmazon EC2（以後EC2と省略）インスタンスで構成されるクラスタ上で動作する

‣ ECSクラスタ上でTaskを起動したり、インスタンスのリソースを考慮したスケジューリングをする役割を担うのがService

1クラスタに複数種のTask‣ 1つのECSクラスタに複数種類の

Taskが配置される方式

‣ 空きリソースを効果的に利用しやすい

‣ 人間的には、どこにどのTaskが配置されてるかがわかりにくい

クラスタを役割で分ける‣ 役割等でECS Clusterを分ける方式

‣ わかりやすい

‣ FRESHではこの方式を採用

‣ スケールが必要な役割のものは、AutoScaling Groupと併用

基本的な考え方‣ 役割（ドメイン領域）で1つのMicroservices

‣ MicroservicesはECSクラスタ単位で構成する

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

各Microserviceの構築パターン

PublicなService（第1段階）‣ Publicに公開するものは

Nginxを前段に

‣ Nginx+APIがTask

‣ Elastic Load Balancing(以後ELBと省略）からは各TaskのHTTPポートにリクエストを振り分ける

PublicなService（第2段階）‣ この段階で実用的

‣ ログはfluentdで転送

‣ EC2 Slave群を参照するためにHAProxyを利用

HAProxyのコンテナ利用‣ 各TaskにHAProxyを入れて

しまおうという考え

‣ essential設定でHAProxyが落ちれば他コンテナも道連れで落ちるようにできる

‣ HAProxyだけ落ちるという異常な状態を回避

PublicなWeb + API‣ WebはReact + Fluxでの

SSR/SPA構成

‣ ネイティブはNginx -> API

‣ WebはNginx -> Node -> API

assetsの扱い‣ assetsはNodeコンテナに

属する

‣ assets類はNginxから直接配信したい(gzip圧縮)

‣ コンテナ間ボリュームマウント(volume_form)

Internal Service‣ Internal ELB経由で、別の

Serviceを利用する

‣ REST APIベース（最近はgRPCの選択肢もある）

Job Worker‣ Enqueue/Dequeue型のJob

Worker

‣ Amazon SQS（以後SQSと省略)

‣ 重めの処理を担当

‣ 定時ジョブは独自CronからEnqueue

‣ Task増やすだけでスケール

Wowza Streaming Engine‣ 動画配信サーバ

‣ 配信はRTMP

‣ 視聴はHLS(HTTP Live Streaming)

‣ Amazon S3

‣ Amazon CloudFront（以下CloudFrontと省略）

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

運用・開発体制‣ サーバサイド☓6＋インフラ☓1、Not Two Pizza Team

‣ サービス：開発者 = N : N

‣ 各サービス毎に主担当はいるが、他のメンバーも面倒が見れるようにしている

‣ Microservices Mapのような俯瞰できるドキュメントの作成

‣ 構成図や、ポート対応表

‣ 現状、複雑性より可用性を優先している

FRESH!の今後の課題‣ HTTP2対応

‣ リソースの最適化（マシンリソースを使い切る）

‣ Circuit Breaker Pattern

‣ Service粒度の最適化

‣ 多くのMicroservicesを運用するチーム・開発体制

Blue Green Deployment

Blue Green Deployment‣ 稼働系インフラにアプリケーションをデプロイし直すのではなく、

インフラごと新しく構築して切り替えてしまう手法

‣ 旧系統から新系統にロードバランサーを切り替える

‣ ロールバックも容易

‣ カジュアルにインフラを壊していこう💪

2Auto Scaling Group Pattern‣ BlueとGreenのAuto Scaling Groupを用意する

‣ Auto Scaling Group単位でELBをつけかえる

‣ Auto Scaling Group上にそれぞれECSのクラスタを作成

‣ デプロイ後、古いクラスタはDesiredCount=0にしてインスタンスを破棄

ECS + 2Auto Scaling

Blue Greenがもたらしたもの‣ デプロイの安心感

‣ 致命的な状態を含んだ成果物が出ることを防止

‣ *.amebafresh.tv -> *.abemafresh.tvの悲しみのドメイン変更

‣ サービス名変更でドメインも変えることに

‣ 全てのServiceをダウンタイムゼロで移行成功

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

Docker投入、考えられる障壁‣ 運用経験が無い

‣ なんとなく感じがちな、得体のしれない怖さ(((((( ；ﾟДﾟ))))))

‣ 本当にちゃんと動くの？

‣ 地雷💣いっぱいあるんでしょ？

‣ クラスタの管理方法

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

開発環境のみの利用はもったいない‣ Dockerポータビリティは、そもそも環境を問わない実行環境を目指

したもの

‣ 既に開発環境で利用しているなら、本番でも動きますよ？

‣ 地雷💣もだいぶ踏み尽くされてきました

‣ とりあえずAWSソリューションアーキテクトの皆様に相談してみましょう！

開発環境のみの利用は もったいないです（2回目）

Have a nice container life.