🍃このブログは移転しました。
3秒後、自動的に移動します・・・。

AWS Summit Tokyo 2016 3日目に行ってきたメモ #AWSSummit

昨日の反省を活かし、今日はトラックを固定で攻めました。
というわけで、DevCon UseCase Trackに張り付いてました。

というか、人が多すぎて移動する気にならん!

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

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

いま各所で話題のAbemaTV FRESH!の事例。

  • プロダクションでDockerを使ってる
  • 可用性を重視した構成
    • サービス全停止を避ける
    • デプロイでダウンタイムを作らない
    • 一部が障害を起こしても、配信と試聴はできるように
  • スケーラビリティ
    • 人気番組でも劣化させない

そこでMicroservices

  • ドメインによってシステムを分ける
    • User API, Broadcast, Chat, etc..
  • Amazon RDSもサービス別なので、個別にメンテできる
    • 呼ぶ側でのケアが必要(xxは現在利用できません)

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 を使ってメディアストレージ基盤を開発してみた

ドワンゴがAWSを使ってメディアストレージ基盤を開発してみた / Numb さん - ニコナレ

アップロードの流れ

  • ユーザーがCredentialを取得
    • GetFederationToken
  • アップ用S3にアップロード
    • Lambdaでバリデーションして、問題なければ配信用S3へ
    • PDFならPDFを画像に分ける処理がある
    • 音声・動画はElasticEncoderが動く
    • どちらも処理が重いのでSQSにいったん貯める

配信の流れ

  • まずCloudFrontで受ける
    • サムネが必要なパスならELBが捌いてサムネを作る
    • それ以外は配信用S3が返す

つくった機能

  • リトライAPI
    • ASW::Lambda::Client#invoke
  • サスペンドAPI
    • 配信用S3からバックアップS3に退避 + Invalidation
  • プライベートコンテンツ配信API

よかったところ

  • 1人でこの規模を設計・開発・運用できる
  • オンプレより融通が利く
  • EC2ではないのでコストの削減にも
  • アプリ担当者のインフラへの敷居が下がった
  • AWSのサポートが手厚い・レスも速い
  • SDKが提供されてる

苦労したところ

  • AWSの各サービスへの事前知識が必要
  • VPCやネットワークへの知識は必要なまま
  • テストの実装をどうしていくか(3rdのモックは古かったりする)
  • CloudFormationが未整備
  • aws-sdkのドキュメントから読めない部分が多い

ドワンゴはオンプレもAWSもできるし、新人でも色々できる会社です!とのこと。

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

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

恵比寿のC社より。

ログを採る理由

  • 何が起きたかを示す
  • サービス改善に使う
    • 数値なくして改善判断もできない

ログに求める要件

  • 確実に配送される
  • 遅延が少ない
  • サンプリングの必要がない
  • 分析しやすいフォーマットで保持する

Cookpadのログ

  • いまは500-700GB/日のログをfluentdで捌いてる
  • 2010: MySQLに貯めてた
  • 2011: fluentd -> mongo
  • 2012: TreasureData -> S3にも
  • 2013: Amazon Redshift
  • 2014, 2015: Elasticsearchへの送信も
  • あれこれ増えていき、集約ノードへの負担が・・・
    • fluentdがマルチコアで動かないのでプロセスを分けたり・・

Amazon Kinesis Streams

  • 分散メッセージング
  • フルマネージド
    • Apache Kafkaとの違いはココ
  • pull型送信
    • suspend, resumeできる
  • ストリームとして保持できる
  • とにかく安全な土管に送り続ければいい
  • ただし集約ノードの負荷は高いまま
  • レコード数多すぎなくせに、1レコードの容量(1MB)を持て余してた
  • 導入によりレコード数が激減 + シャード数も減らせた
  • Lambdaで集計して、速報データはDynamoDBやRedshiftへ

運用

  • 合計40シャード
    • 動的に増減はさせてない
  • IDS、WAFログも収集していきたい

専門外すぎてどの情報を注視すべきかって勘が効かないのがつらいなー。
話自体はおもしろそうやなーと思って聞いてたけど。

GREE 流!AWS をお得に使う方法

GREEのモバイルの某RPGゲームの話。

  • 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

Amazon Aurora

  • MySQLと完全互換
  • RDS for MySQLよりIOPSが低くなる(binlogを吐いてないから?)
  • MasterがダウンするとSlaceが数秒間使えないのに注意

GREE Ads DSP

  • 広告配信サービス
  • バッチサーバ -> ECS -> EMR -> S3 -> Redshift
  • もとは`json`だったが`ltsv`にしたら集計が速くなった
  • fluentdでS3に直接アップロード
    • リアルタイムの要件がないのでkinesisではない
  • バッチ処理はECSでDocker
  • EMRのスポットインスタンスが安い
    • 上がらない時のハンドリングが面倒
  • Redshiftは使う時だけ上げる
    • なのでS3からインポートして集計

インフラ

  • 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

Lambdaの利用例

  • ログの保存
  • cronの代わり
  • CloudWatchからSNSトピックを発行してSlackに通知
    • AWSの使用料通知するの良い

「インフラ経験のないデータサイエンティスト(ただし最近のITに疎いとは言ってない)」すげーな・・。
にしてもフルマネージドなのでAWSにしました!っていう事例の多さよ!