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

2016/06/03 AWS Summit Developers Conference DevCon-Use Case Track

Transcript

1. Dockerだらけの FRESH!な 動画配信プラットフォーム 2016/06/03 AWS Summit Tokyo 2016 Developers Conference @stormcat24 / CyberAgent, Inc.
2. stormcat24 ‣ Akinori Yamada ‣ CyberAgent, Inc. / AbemaTV, Inc. ‣ Technical Engineer ‣ http://blog.stormcat.io ‣ AmebaFRESH! ⇒ AbemaTV FRESH!
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 1.10.3 ‣ ecs-agent 1.9.0 ‣ 軽量化を図るため、ベースイメージは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) ‣ Job Worker(Go) ‣ React(Node.js) ‣ Chat(Node.js) ‣ 独自Cron(Java) ‣ Nginx ‣ Wowza Streaming Engine ‣ HAProxy ‣ fluentd
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段階） ‣ この段階で実用的 ‣ ログはfluentdで転送 ‣ 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.