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.4k
KubernetesのマニフェストをそれなりにCIしたい
stormcat24
4
1.2k
令和時代のSaaS開発
stormcat24
1
240
History in 5 years of CircleCI and CyberAgent
stormcat24
3
800
Kubernetes Handson Osaka
stormcat24
5
540
Kubernetes Handson
stormcat24
5
4.2k
DockerとKubernetesでアプリケーション開発にコンテナをフル活用!
stormcat24
0
290
Base Image Journey 2018
stormcat24
29
130k
kotlin-fest
stormcat24
13
17k
Other Decks in Programming
See All in Programming
実践サーバーレスパフォーマンスチューニング ~その実力に迫る~ / Practical Serverless Performance Tuning ~A Close Look at its Power~
seike460
PRO
2
230
Hi, have you met Kotlin Multiplatform? | DevFest Vienna 2024
prof18
0
220
Kubernetes上でOracle_Databaseの運用を楽にするOraOperatorの紹介
nnaka2992
0
170
RDBの世界をぬりかえていくモデルグラフDB〜truncus graphによるモデルファースト開発〜
jurabi
0
180
4年間変わらなかった YOUTRUSTのアーキテクチャ
daiki1003
2
670
色んなオートローダーを覗き見る #phpcon_okinawa
o0h
PRO
5
430
Micro Frontends for Java Microservices - dev2next 2024
mraible
PRO
0
230
rtcamp 10 (vk-illuminati)
yumcyawiz
1
210
Vitest Browser Mode への期待 / Vitest Browser Mode
odanado
PRO
1
310
【YAPC::Hakodate 2024】TypeScriptエンジニアが感じたPerlのここが面白い
kimitashoichi
1
460
Vertical Architectures for Scalable Angular Applications
manfredsteyer
PRO
0
180
ACES Meet におけるリリース作業改善の取り組み
fukucheee
0
150
Featured
See All Featured
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
9
630
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Being A Developer After 40
akosma
85
590k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.7k
Designing the Hi-DPI Web
ddemaree
280
34k
Music & Morning Musume
bryan
46
6.1k
10 Git Anti Patterns You Should be Aware of
lemiorhan
653
59k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Bash Introduction
62gerente
608
210k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
23k
GitHub's CSS Performance
jonrohan
1030
450k
Adopting Sorbet at Scale
ufuk
73
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.