2018/06/01 AWS Summit Tokyo

FreakOutにおけるAWS上での機械学習活用事例

概要

• オンプレとAWSを使用した機械学習フローの違い
• 機械学習のアーキテクチャから学習フローの最適化までを具体的に説明
• SageMakerの利用により複数人の並列評価ができるようになったことについて説明

フリークアウトについて

• DSP デマンドサイドプラットフォーム
• 広告枠がみられた瞬間に取引され、インプレッションが入札制で自動売買（広告リアルタイムオークション）
• 170億/day、ピーク29万/sec
• 適切な入札価格を判断するためにCTR/CVR予測を機械学習で予測

システム概要

• サーバ700台〜
• 5200億 Bid Request/mounth
• python, scala
• Hadoop(Cloudera Distribution), hive, Spark, Presto, MapReduce... total 2PBのデータ、AWSへ移行中

学習フロー

• アプリ→fluentd→HDFS, Spark→MySql、機械学習→HIVE
• 学習モデルはバッチ更新
• オフライン検証
  • Amazon SageMaker 有名な学習アルゴリズムはBuiltinされている
  • DockerImageを利用することで、そのほかの学習モデルを使用することができる

所感

• 内容的に機械学習を使用している、実装している人向けだった。後半ほぼ理解できなかった。
• 寝ている人、スマフォいじってる人、何してるかわからない人が半分くらい。後半メモの手が止まる人8割。超難解。
• 機械学習(AI)の正確性を検証するフレームワークフロー的なものがあることがわかった。
• 開発検証→結果オフライン検証→本番→本番オフライン検証のように本番リリースした後でも少しずつ方向性の修正が必要。

機械学習を利用した動画配信

概要

• Rekognitionの活用
• ライブは配信をよりインタラクティブに
• サービスの早期立ち上げ、早期収益化

動画の価値をあげる

• コンテンツオーナー：動画の魅力をアップ、再利用
• 視聴者：シーンや出演者からコンテンツを探したい
• 動画に内包された情報を抽出して活用する

利用するサービス

• Rekognition(カスタムするならSageMakerのエンドポイント)
  • 深層学習からの画像動画認識サービス
  • 顔表情、有名人、感情、テキスト認識、人物追跡
  • 利用用途
    • 不適切画像の排除
    • メタデータの認識、抽出
  • 画像認識15MB以下、動画OO以下
  • テストもその場で可能
• Lambda
  • S3駆動でEMCの終了を検知して、Rekognitionをキックする、返却データをDBへ入れる
  • 動画や画像を分析するコードを記述する
• EMediaConvert(EMC)
  • FMトランスコードサービス
  • ビデオ、画像処理サービス
  • 出力フォーマット、ビットレートをサポート
  • コンテンツのフォーマット・サイズを変換
  • 秒数ごとに動画から画像を切り出すなどの処理も可能
• EMediaLive
  • 配信サービス
  • ライブチャネルを数分で展開

フロー(Lambdaで終了を検知させて、次の処理をキックさせる)

• (S3)ソース→(ファイル変換)EMC→S3→Lambda→(メタ生成)Rekognition→(メタ保持)DB→EMS→EML
  • コンテンツ索引、メタ生成
  • メタを利用したコンテンツ抽出

コンテンツ索引、メタ生成

• ビデオにメタを付与したい、検索を強化したい、手入力を抑えたい
  • EMCでフレーム画像を抽出
  • Recoginitionで有名人検索は4行で。jsonで返却される
  • どの時間帯に誰がいるかを検出可能

コンテンツ抽出

• EMCでクリッピングしてS3へ配置
• スポーツライブ配信で得点シーンのみ抽出して動画配信
  • 得点板の数値が変わったことをRekognitionで認識する
  • Rekognitionが認識した時間でEMCで前後でクリップを切り出す

スポーツクリッピングサンプル

• aws-samples githubにある(一瞬過ぎてメモれなかった…)

事例

• Sky News Royal Wedding: Who's who
  • MediaLive→MediaPackage→S3→CloudFront
  • S3へ配置することでVOD配信も可能

所感

• 動画関連のサービスは専門性が高く参入しにくかったが、今後障壁が低くなると思う
• 自社でも簡単スピーディにサービス化ができそうなので、広告的な発想で枠を作成することも面白そう
• これから来そうなサービス、Rekognitionとの組み合わせは素晴らしく、今後もAmazonに蓄積されるデータを活用して動画や画像認識ができる。今後の精度やサービスの拡大に期待。

ビズリーチを支えるECSとAWS Batchの活用事例

概要

• 企業の採用管理ツールHrmosについてのAWS採用事例

環境について

• コンテナ化する前はALB,EC2などのよくある構成
• コンテナ化したあとはEc2→ECS(ECR+CloudWatch+Lambda)
• ECRとはECSの管理ツール
• 階層
  • ECSクラスター
  • コンテナインスタンス(EC2, ECSエージェント)→タスク→コンテナ
• ECS 30 ,タスク 45, コンテナインスタンス 24(オートスケール)
• コンテナ化してよかったこと
  • アプリの成果物がdev, prdで同じ
  • リソース共有
  • 水平スケールが容易
  • インフラリソースからアプリケーションが分離できる
• モジュールを3つに分割
  • CPU強めのクラスタ
  • メモリ多めのクラスタ
  • AWS Batch（job定義をキューに入れると実行できる）
    • 金融、サイエンスなどの実績があるためバッチ処理基盤として信頼性が高い
    • Lambdaにするには大きすぎる処理に使用
    • cloudwatchで処理結果metricsが見れない
    • 起動までに時間がかかるため、リアルタイム性が高い処理には向いていない
• ECSを活用してプルリクごとに実行できる環境を作成した
  • SpotFleetを使用してコストを削減している

運用監視について

• CIサーバでECRImageを作成
• CDサーバでDockerImageを更新
• コンテナ内のメトリクス監視はdatadock
• オートスケール（調整がめんどくさく、難しい）
  • タスク
  • オートスケール(コンテナインスタンスとタスクの増減を合わせないとならない)
  • cloudwatchアラート
• ログ
  • cloudwatchLogs→kinesis→fluentd→kibana

他事業の取り組み

• BIZREACH
  • 同じような構成へ移行を検討中
  • 他RedShiftやBigQueryを使用している
• スタンバイ
  • ECSへ移行を検討中

ECS, Batchで運用してみて

• アプリ停止でも勝手に再起動してくれる
• アプリのロールバックが1分くらいでできる
• Batchはすごい便利
• オートスケール中途半端で大変
• EC2の存在を意識する必要もある
  • エージェントのUPdateやインスタンスの台数
• ログの運用は全社のシステムで統一したい

所感

• 実際にメディア運営をしている会社として参考になる情報かと思う
• Dockerが少し前からブームになっているがその運用における課題であったり生の声を聞けるのは参考になった。
• AWS上に多数のサービスをスピーディに構築できるため、スタートアップの少ない資金でもすぐにサービスが作れるかも。。。

Aurora Serverless(MySql相互プレビュー版)

アーキテクチャ

• 従来のAuroraの通りストレージとインスタンスを分断したアーキテクチャ
• ストレージはそのままで、インスタンスをオートスケールさせるモデル。使用がないときは最小0台までオートスケール

使用方法

• データベースエンドポイントを作成
• 必要に応じてデータベースの容量範囲(最大、最小)を指定

課金

• アクティブな時間に応じた1秒単位の課金
• データベースが消費するデータベースの容量、ストレージ、および I/O分

ユースケース

• あまり使用されないアプリケーション
  • 小規模サイト
• 新規アプリケーション
  • 必要なインスタンスサイズが不明な場合、アプリケーションの容量要件に合わせてデータベースを自動スケールする
• 可変ワークロード(予測不可能なワークロード)
  • 1日または1週間に数回だけ、使用されるアプリケーション
  • 予測が困難なピーク
• 開発/テストデータベース
  • 夜間や週末にはデータベースを必要としないため
• マルチテナントアプリケーション
  • 個々のデータベースに応じた容量とスペック

懸念点

• 0台にスケールした後の第一のリクエストのレスポンス
• 従来のプロビジョニングバージョンとサーバーレスの設定間を移行できるとあるが、実際にパラメータ周りの設定はどのようになるのか
• 見積もりが難しそう
• 何を持ってserverlessか課題。結局RDS自体もserverlessなため、こいつの特徴としてはスペックもスケールできるということになるのか・・・

用途

• スパイク的な処理はserverless、常時発生する画面のリクエストなどはAuroraにするとAuroraのスケールを落とせてコストダウンになるかも
• 管理画面とか日中少ししか使わないものはserverlessにしちゃうとか有効そう。

参考

• https://aws.amazon.com/jp/rds/aurora/serverless/
• https://aws.amazon.com/jp/blogs/news/in-the-works-amazon-aurora-serverless/

その他キャッチした情報

• EFS(NAS)が東京リージョンへリリースされた。EC2マウントで安定した性能など、結構使えそう。
• Aurora serverlessについては2018年夏にサービスインの構想だが、最初はusリージョンなどかも。すぐに東京にきたらラッキー
• AWSを使用している会社には必ず専任のハイタッチ営業がいるため、問い合わせ次第でAWSの技術者と打ち合わせを要請できるらしい。。。本当かどうか不明。