昨日の反省を活かし、今日はトラックを固定で攻めました。
というわけで、DevCon UseCase Trackに張り付いてました。
というか、人が多すぎて移動する気にならん！
Docker だらけの FRESH な動画配信プラットフォーム
いま各所で話題のAbemaTV FRESH!の事例。
- プロダクションでDockerを使ってる
- 可用性を重視した構成
- サービス全停止を避ける
- デプロイでダウンタイムを作らない
- 一部が障害を起こしても、配信と試聴はできるように
- スケーラビリティ
- 人気番組でも劣化させない
そこでMicroservices
Docker
- Immutable Infrastructureとの親和性
- ポータビリティの高さ
- コンテナに焦点をあてて運用
- ECS at TokyoでDocker1.10.3、Ubuntu < Alpine Linux
- データストア以外をコンテナにまとめる
- ログはホスト -> fluentd -> S3
- 設定ファイルはもたず、環境変数でやる
- ECSクラスタの構成管理ツール
- クラスタを役割で分ける方式を採用
- このクラスタの単位が各Microservice
- パブリックな部分
- Task: Nginx + API
- 前でELBが捌く
- HAProxyを各Taskに入れる
- HAProxyが落ちたら他のコンテナも一緒に落ちるように
- assetsはNodeのコンテナでNginxでgzip
- 内部の通信はInternal ELB経由のREST（gRPCではない
- JobはSQSに貯める
- 定期処理はCronからEnqueue
- Wowza Streaming Engine
- RTMPで配信して、HLSで試聴
- .ts / .m3u8はS3
運用体制
- サーバーサイド x 6 + インフラ x 1
- サービス:開発者 = N:N
- ドキュメントなど可用性を重視してる
- Microservices Map、ポート対応表など
今後やりたいこと
- HTTP/2対応
- リソース最適化
- Circuit Breacker Pattern
- サービス粒度の改善
Blue Green Deployment
- ELBの向き先を変えるだけ
- サービス名の変更の対応もダウンタイム0で
Dockerつかってこ
- コンテナ運用のよさ
- 開発環境で動いてるなら本番でも動くので心配無用
- 地雷もだいぶ踏まれてきてる
仕事でやらんから実際はさっぱりやけど、このへんの知識ばっかり無駄に増えてきてる感がある今日このごろ・・。
ドワンゴが AWS を使ってメディアストレージ基盤を開発してみた
- RubyとAWSでつくるメディアストレージ基盤 - Qiita
- 車輪の再発明を避ける
- チームの枠を越えて共通で使えるものは共通で使う
- メディアストレージ基盤
- 画像・PDF・音声・動画、あわせてメディアファイル
- 投稿・変換・配信をまとめてやる
- ジョブをDynamoDBに貯めて捌く
- DynamoのRuby用ORMつくった
- DynamoDBのためのdinamoという簡易的なORMをかいた - Qiita
- 使ってるOSSは、Grape, dinamo, rabi, shoryukenなどなど
アップロードの流れ
- ユーザーがCredentialを取得
- GetFederationToken
- アップ用S3にアップロード
- Lambdaでバリデーションして、問題なければ配信用S3へ
- PDFならPDFを画像に分ける処理がある
- 音声・動画はElasticEncoderが動く
- どちらも処理が重いのでSQSにいったん貯める
配信の流れ
- まずCloudFrontで受ける
- サムネが必要なパスならELBが捌いてサムネを作る
- それ以外は配信用S3が返す
つくった機能
よかったところ
秒間数万のログをいい感じにするアーキテクチャ
恵比寿のC社より。
- CookpadはRuby + Ruby on Rails
- Dockerで半数以上動いてる
- 2011年にAWSに完全移行
- ピーク時は15000req/sをさばく
ログを採る理由
- 何が起きたかを示す
- サービス改善に使う
- 数値なくして改善判断もできない
ログに求める要件
- 確実に配送される
- 遅延が少ない
- サンプリングの必要がない
- 分析しやすいフォーマットで保持する
Cookpadのログ
運用
- 合計40シャード
- 動的に増減はさせてない
- IDS、WAFログも収集していきたい
専門外すぎてどの情報を注視すべきかって勘が効かないのがつらいなー。
話自体はおもしろそうやなーと思って聞いてたけど。
GREE 流！AWS をお得に使う方法
- Webサーバー: 12-50台
- アクセス: 3000 - 30000 / min
DynamoDBのいいところ
- AtomicCounterで競合しない
- Conditional updateできる
- コストが可視化できる
安く抑えるには
- writeはreadの10倍高いのを意識
- deleteせずに済むならしない
- Secondary indexを乱用しない
- read capacityを抑える
- randomにitem取得
運用ででた問題
- Throttling問題
- ThroughputがCapacityを超えた時に発生
- 過去5分のあまりで補填（Burst）してくれるがそれでもスグ枯渇する
- Partitionを分けると、Capacityも分かれてしまう
- 均一に振り分けないと、一部でThrottlingしてしまう
- あまりに同じキーが読まれるなら、DynamoDBの外にキャッシュすべし
- あまりに同じキーに書き込むなら、テーブル単位でシャーディングする
Dynamic Dynamo
- GitHub - sebdah/dynamic-dynamodb: Dynamic DynamoDB provides auto scaling for AWS DynamoDB
- CloudWatchのメトリクスを元に、自動的にCpacityの調整をしてくれる
- Partitionが割れてスケールダウンしたときにThrottlingしないよう注意
- Hotキー問題は相変わらず
- 大規模なものはやはり手動で対応
インフラ
- EC2やRDSは高い
- その他は比較的安い
- EC2で処理してたスナップショットの取得をLambdaでやるように
- Lambdaは失敗する可能性がある
- 同時実行される可能性もあるので悲観的ロックを
- 関数は最大5分しか動かないので、関数を分ける
- EC2、API Gatewayも使わない
- SDKとCredentialを直接埋め込んで、Lambdaを実行する
- Credentialの取り扱い注意！
- 非同期処理にして実行時間を短縮する
- EC2は平日の出勤時間帯だけ使うとか
- RDSよりオンプレMySQLのがちょっとだけ安い（3割くらい？）
- Lambda安い！使ってこ！
ちょっとした処理（試算するまでもなく無料で収まる）でしかLambda使ったことなかったけど、もっと負荷のある処理でもいけそうやねー。
仕事でなんかもっと使いみちないかな・・。
タウンワークにおけるサーバレスアーキテクチャデザイン
- Core Teachnology Labプロジェクト
- データサイエンス + エンジニアリング + インフラのプロジェクト型組織
- データサイエンティストが主導する組織
タウンワークの特徴・要件
- 週次で入れ替わる求人
- 応募したら離脱するユーザー
- ECなどで使われる従来のレーティングなどの手法は使えない
- ユーザーの行動をもとに特徴量を計算して、最適な求人を予想
- 月曜に発行されるのでアクセスもそこが一番多い
- リアルタイムな予測をする必要があった
ログ基盤の整備が必要
- 貯めるだけではなく
- 多様に処理できる必要があった
- アクセスごとに特徴量を更新する処理
- 予測モデルを定期的に作成
- Kinesis x Lambdaで！
特徴量の更新・予測を高速に処理する
- 高速にR/WできるDB
- 変更に柔軟に対応できるDB
- NoSQLにしたいが運用はしたくない
- 最終的にDynamoDB x ElasticCacheを使うことに
運用どうしてるか
- 特徴量の更新は影響範囲がデカい
- そこでBlue-Green Deployment
- ただしDBまわりがネック
- そこでCloudFormation
- jsonでオーケストレーションできる