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.4k
令和時代のSaaS開発
stormcat24
1
270
History in 5 years of CircleCI and CyberAgent
stormcat24
3
850
Kubernetes Handson Osaka
stormcat24
5
580
Kubernetes Handson
stormcat24
5
4.3k
DockerとKubernetesでアプリケーション開発にコンテナをフル活用!
stormcat24
0
320
Base Image Journey 2018
stormcat24
29
140k
kotlin-fest
stormcat24
13
18k
Other Decks in Programming
See All in Programming
iOSアプリで測る!名古屋駅までの 方向と距離
ryunakayama
0
160
Live Coding: Migrating an Application to Signals
manfredsteyer
PRO
0
130
技術的負債と戦略的に戦わざるを得ない場合のオブザーバビリティ活用術 / Leveraging Observability When Strategically Dealing with Technical Debt
yoshiyoshifujii
0
100
In geheimer Mission: AI Agents entwickeln
joergneumann
0
130
rbs-traceを使ってWEARで型生成を試してみた After RubyKaigi 2025〜ZOZO、ファインディ、ピクシブ〜 / tried rbs-trace on WEAR
oyamakei
0
210
今話題のMCPサーバーをFastAPIでサッと作ってみた
yuukis
0
150
最速Green Tea 🍵 Garbage Collector
kuro_kurorrr
1
160
型安全なDrag and Dropの設計を考える
yudppp
4
270
医療系ソフトウェアのAI駆動開発
koukimiura
1
150
Ruby で作る RISC-V CPU エミュレーター / RISC-V CPU emulator made with Ruby
hayaokimura
5
1.2k
Cloudflare Workersで進めるリモートMCP活用
syumai
12
1.7k
バイラテラルアップサンプリング
fadis
3
640
Featured
See All Featured
Facilitating Awesome Meetings
lara
54
6.4k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
Mobile First: as difficult as doing things right
swwweet
223
9.6k
How to Think Like a Performance Engineer
csswizardry
23
1.6k
Side Projects
sachag
453
42k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
12k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.7k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
52
2.7k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Optimising Largest Contentful Paint
csswizardry
37
3.2k
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.