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

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

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

0aac627116c6e2a87b9ae179500801df?s=128

stormcat24

June 03, 2016
Tweet

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チャンネルまで拡大予定
  5. None
  6. None
  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.