Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Docker だらけの FRESH な動画配信プラットフォーム
Search
stormcat24
June 03, 2016
Programming
32
18k
Docker だらけの FRESH な動画配信プラットフォーム
2016/06/03 AWS Summit Developers Conference DevCon-Use Case Track
stormcat24
June 03, 2016
Tweet
Share
More Decks by stormcat24
See All by stormcat24
素早く賢く失敗するDeveloper Productivityの実現を目指して
stormcat24
4
5k
KubernetesのマニフェストをそれなりにCIしたい
stormcat24
4
1.4k
令和時代のSaaS開発
stormcat24
1
280
History in 5 years of CircleCI and CyberAgent
stormcat24
3
860
Kubernetes Handson Osaka
stormcat24
5
590
Kubernetes Handson
stormcat24
5
4.3k
DockerとKubernetesでアプリケーション開発にコンテナをフル活用!
stormcat24
0
330
Base Image Journey 2018
stormcat24
29
140k
kotlin-fest
stormcat24
13
18k
Other Decks in Programming
See All in Programming
顧客の画像データをテラバイト単位で配信する 画像サーバを WebP にした際に起こった課題と その対応策 ~継続的な取り組みを添えて~
takutakahashi
4
1.4k
チームで開発し事業を加速するための"良い"設計の考え方 @ サポーターズCoLab 2025-07-08
agatan
1
490
抽象化という思考のツール - 理解と活用 - / Abstraction-as-a-Tool-for-Thinking
shin1x1
1
230
Porting a visionOS App to Android XR
akkeylab
0
910
What's new in AppKit on macOS 26
1024jp
0
170
オンコール⼊⾨〜ページャーが鳴る前に、あなたが備えられること〜 / Before The Pager Rings
yktakaha4
2
1.1k
Claude Code派?Gemini CLI派? みんなで比較LT会!_20250716
junholee
1
690
Gemini CLIの"強み"を知る! Gemini CLIとClaude Codeを比較してみた!
kotahisafuru
2
140
Yes, You Can Work on Rails & any other Gem
kaspth
0
110
マッチングアプリにおけるフリックUIで苦労したこと
yuheiito
0
240
テスターからテストエンジニアへ ~新米テストエンジニアが歩んだ9ヶ月振り返り~
non0113
2
240
初学者でも今すぐできる、Claude Codeの生産性を10倍上げるTips
s4yuba
16
13k
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
370
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
The World Runs on Bad Software
bkeepers
PRO
70
11k
We Have a Design System, Now What?
morganepeng
53
7.7k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.2k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Building an army of robots
kneath
306
45k
Bash Introduction
62gerente
613
210k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
282
13k
Transcript
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チャンネルまで拡大予定
None
None
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.