Web Developer's Struggle Memories

日々の業務から思ったこと、学んだことを書き連ねていきます。

AWS Summit「DockerだらけのFRESH!な動画配信プラットフォーム」に参加してきた

AWS Summit Tokyoに参加してきた記事の第二弾!この発表も物凄くインパクトが有り、Dockerを実際に本番環境でも使っている事例としてかなり参考になった!

こちらに資料が公開されているので、詳しく見たい方はどうぞそちらにアクセスして下さいませw

登壇者

@stormcat24さん

FRESH!とは

  • 4/1 AmebaFRESH!から名称変更
  • ※AbemaTV(無印)とは別のサービス
  • 24時間いつでも何かの配信がされている
    • 定点カメラもあり
  • いつでも配信可能

動画プラットフォームとして目指した価値

  • 可用性とスケーラビリティ
  • 高い可用性
    • サービス前停止でのメンテナンスを極力しない
    • デプロイによるダウンタイムを作らない
    • 絶対的主目的は守りぬく
  • スケーラビリティ
    • 人気番組・特番時のキャパシティ不足、品質劣化を起こさない
  • 技術的に目指すべきの価値の解

Microservices

  • システムを解決すべきドメイン領域によって切り分けるパターン
  • FRESH!の例
    • User API
    • Broadcast
    • Chat
    • Timeline
    • Tracking
  • Microservicesと可用性
    • AmazonRDSの再起動、時間のかかるスキーマチェンジの運用課題
    • Service別にDBを持つため、システム全体を止めてのメンテナンスを回避
    • 呼び出し側のServiceでのケアを用意
      • 例 〜の機能は現在…
      • 例 ☓☓☓ modeを用意
  • Dockerのモチベーション
    • Immurable Infrastructureとの親和性、ポータビリティの高さ
    • イメージを作ってしまえばコンテナを上げるだけ

FRESH!とDocker

  • Amazon EC2 Container Servicesの東京リージョンリリースから利用
  • Ubuntu
  • Docker 1.10.3
  • ecs-agent 1.9.0
  • コンテナ化方針
    • 基本的にデータストア以外はコンテナ化
      • インフラとアプリがコンテナによってセットで扱うメリットがでかい
    • ログはホストにボリュームマウント
    • アプリの設定や、ミドルウェアの設定は環境変数で設定
  • 何がおいしい?
    • 環境差異からの脱却
      • 環境再現のしやすさ
    • インフラのメンテコストの軽減
      • Provisioningほとんどいらねぇ(FRESH!はcloud-initだけ)
  • コンテナ時代の設定管理
    • 環境別の設定ファイルはDockerにはそぐわない
    • 環境変数変更だけ
  • Amazon ECSと設定管理
  • FRESH!がDocker化しているもの
    • REST API(Go)
    • Job Woker
    • React.js
    • Nginx など

DockerとAmazon EC2 Container Servicesでのサービス構成パターン

  • Amazon ECSの予備知識
    • ECSでのコンテナの集合体をTaskとして定義
    • TaskはAmazon EC2
  • 1クラスタに複数種のTask
    • 空きリソースを効果的に利用しやすい
    • 人間的にはどのクラスタが空いているかわかりづらい
  • クラスタを役割で分ける
    • 役割等でECS Clusterをわける
    • わかりやすい(FRESH!はこれを採用)
    • スケールし易い

Microservice群の活用例

  • PublicなService(第一段階)
    • Publicに公開するものはNginxを前段に
    • Nginx+APIがTask
    • ELBからは各TaskのHTTPポートを分ける
  • 第二段階
    • HAProxyのコンテナ利用
      • 各TaskにHAProxyを入れてしまう
      • essential設定でHAProxyが落ちたらTaskも一緒に落ちる
  • PublicなWEB+API
    • webはReact+Flux
    • ネイティブはNginx+Go
  • assetsの扱い
    • assetsはNodeコンテナに属する
    • assets類はNginxから直接配信したい(gzip圧縮)
    • コンテナ間ボリュームマウント
  • Internal Service
    • Internal ELB経由で別のServiceを利用
    • RestAPIを利用
  • Job Worker
    • enqueue/dequeue型のjob worker
    • Amazon SQS
    • 重めの処理を担当
    • cronで自動実行
    • Taskを増やすだけで買ってにスケール
  • Wowza Straming Engine
  • 開発・運用体制
    • サーバサイド6、インフラ1、Not Two Pizza Team
    • サービス:開発者 = N:N
    • 各サービスごとに主担当はいるが他メンバーも面倒が見れる
    • Mocroservices Mapのようなドキュメントの作成
      • 構成図やポート対応表
    • 現状、複雑性より可用性
  • 今後の課題
    • HTTP2対応
    • リソースの最適化(マシンリソースを使い切る)
    • Circuit Breaker Pattern
    • Service粒度の最適化
    • これを運用する開発体制の構築

Blue Green Deployment

  • 稼動系インフラにアプリをデプロイし直すのではなく、インフラごと新しく構築して切り替える
  • どんどん古いものを壊して、作りなおす
  • BlueとGreenのAuto Scaling Groupを用意
  • ECS+2Auto Scaling
    • ELBで切り替える
  • もたらしたもの
    • デプロイの安心感
      • 致命的な状態を含んだ成果物が出ることを防止
    • ドメイン変更
      • サービス名変更でドメインも変更
      • 全てのServiceをダウンタイムゼロで変更

Dockerを検討されている皆様へ

  • 運用経験がない
  • 得体のしれない怖さ
    • 本当に動くの?
    • 地雷いっぱいあるんじゃね?
  • クラスタの管理方法
  • とりあえず開発環境から?
    • もったいない
    • ポータビリティを利用したものなんだから本番でも動くし使える
    • 地雷もだいぶ踏み尽くされてきた
    • とりあえずAWSソリューションアーキテクトの人に相談
  • もう一回いうが、開発環境のみの利用はもったいない

Have a nice container life.