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
4.9k
KubernetesのマニフェストをそれなりにCIしたい
stormcat24
4
1.3k
令和時代のSaaS開発
stormcat24
1
260
History in 5 years of CircleCI and CyberAgent
stormcat24
3
840
Kubernetes Handson Osaka
stormcat24
5
570
Kubernetes Handson
stormcat24
5
4.3k
DockerとKubernetesでアプリケーション開発にコンテナをフル活用!
stormcat24
0
320
Base Image Journey 2018
stormcat24
29
140k
kotlin-fest
stormcat24
13
17k
Other Decks in Programming
See All in Programming
読もう! Android build ドキュメント
andpad
1
240
Preact、HooksとSignalsの両立 / Preact: Harmonizing Hooks and Signals
ssssota
1
740
PHPer's Guide to Daemon Crafting Taming and Summoning
uzulla
2
1.1k
2025/3/18 サービスの成長で生じる幅広いパフォーマンスの問題を、 AIで手軽に解決する
shirahama_x
0
160
Windows版PHPのビルド手順とPHP 8.4における変更点
matsuo_atsushi
0
370
小さく段階的リリースすることで深夜メンテを回避する
mkmk884
2
130
Devin , 正しい付き合い方と使い方 / Living and Working with Devin
yukinagae
1
530
DomainException と Result 型で作る型安全なエラーハンドリング
karszawa
0
160
フロントエンドテストの育て方
quramy
9
2.6k
Boost Your Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
160
いまさら聞けない生成AI入門: 「生成AIを高速キャッチアップ」
soh9834
12
3.8k
ニックトレイン登壇資料
ryotakurokawa
0
140
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.8k
Designing for humans not robots
tammielis
251
25k
How to Think Like a Performance Engineer
csswizardry
22
1.5k
Mobile First: as difficult as doing things right
swwweet
223
9.5k
Faster Mobile Websites
deanohume
306
31k
Unsuck your backbone
ammeep
670
57k
The Invisible Side of Design
smashingmag
299
50k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
The Cost Of JavaScript in 2023
addyosmani
48
7.6k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
17
1.1k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
Raft: Consensus for Rubyists
vanstee
137
6.9k
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.