ca5
6/4/2016 - 12:26 PM

awssummit2016.md

DockerだらけのFRESHな動画配信プラットフォーム

資料: https://speakerdeck.com/stormcat24/docker-darakefalse-fresh-nadong-hua-pei-xin-puratutohuomu

  • AbemaTVFRESH!

    • 生放送
    • 配信主がいつでも配信を始めることが可能
      • 放送をサービス側でコントロール出来ない
  • Microservice

    • 細かくサービスを区切る
      • DBもそれぞれの機能ごとに独立させる
  • 運用課題

    • RDS再起動等時間がかかるスキーマチェンジの運用
  • ECS

    • ホストをUbuntuに
    • Docker 1.10.3
    • ecs-agent 1.9.0
    • コンテナベースイメージはAlpineLinux
      • イメージを小さくするため
  • コンテナ化方針

    • データストア以外はコンテナ化
    • ログはホストにボリュームマウントし、fluentdに転送
    • アプリケーションやミドルウェアの設定は環境変数で設定できるようにしておく
    • ansibleやchefを使ったProvisioningはしない
  • 環境変数による設定のメリット

    • アプリケーション設定ごとのビルド不要
    • (もう一個聞き逃した)
  • docker化例

    • nginx
    • HAProxy
    • fluentd
  • Task配置の仕方

    • 1クラスタに複数種のTask
      • リソースを効果的に使える
      • どこにTaskが配置されているかわからない
    • クラスタを役割で分ける(FRESHはこちらを採用)
      • 運用上わかりやすい
        • 必要なリソース配分など
      • (聞き逃した)
  • WebAPI

    • Microservice間はインターナルELBを使って通信
    • Nginx + API + fluentd + HAProxyをセットで一つのTaskに
      • DBは1クラスタにひとつ
      • 各TaskにHAProxyをつけてやる
        • HAProxyが落ちたらセットのタスクも全部落とす、といったことができる
    • assetはNodeコンテナに
      • コンテナ間ボリュームマウント
  • JobWorker

    • Task
      • cron
      • fluentd
      • job worker
      • HAPRoxy
  • Wowza Streaming Engine

    • RTMPで配信
    • 視聴はHTTP Live Streaming
    • s3にデータを置いてcloudfront経由配信
  • 今後の課題

    • リソースの最適化
    • Circuit Breaker Pattern
    • Service粒度の最適化
  • Blue Green Deployment

    • AutoScalingGroupをBlue/Greenそれぞれ用意
    • AutoScalingGroupごとにELB切り替え
    • 切替後使わなくなったほうはDesire count 0 にしておく

レコード

ドワンゴがAWSでメディアストレージ基盤を開発してみた

資料: http://niconare.nicovideo.jp/watch/kn1493

  • 2015年のアドベントカレンダーに記載されている

  • メディアストレージ基盤

    • 動画ファイルのアップロード・変換・配信を行う基盤
  • DynamoDBを使ってジョブの管理を行う

    • ruby製ORM dinamo
  • 一時認証keyを発行してユーザーからs3に直接ファイルをアップロードさせる

  • s3 NotificationでLamdaを起動

    • ファイルのバリデーション
    • 配信用バケットにコピー
  • 画像の配信

    • cloudfront で リクエストを一次請け
      • s3とEC2に振り分け
        • 元画像はs3から直接取得
        • サムネイル画像はEC2の画像変換サーバを通して取得
  • フルマネージドサービスを使った部分のテストが難しい

    • サードパーティ製の持っくだと不十分

秒間数万のログをいい感じにするアーキテクチャ

資料: https://speakerdeck.com/kanny/miao-jian-shu-mo-falseroguwoiigan-zinisuruakitekutiya

  • fluentd レシーバー

  • 集約を柔軟にするため

  • 負荷問題

  • マルチコアうまく扱えない

  • kinasis streams

    • pull型でデータを取得できる
    • ログ取り込み側が取り扱いを制御しやすい
  • kinesis producer library

    • 複数レコードを1つに集約出来る
    • メッセージ件数の節約
    • 小さなログに有効
  • 速報値をLamdaで集計してs3におく