Cacher is the code snippet organizer for pro developers

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

DSP spec

• 3600億在庫/month
• 170億/day
• bid request 5200億 bidrequest/month
• adsvrはperl

DSP Log Analysis

• オンプレHadoop
• Hivek Spark, Presto MapReduce
• 2PB

CTR/CVR予測

• hive テーブル + mysql → sparkでロード
• 学習機でモデルの生成
• hive で モデルのロード, adsvr内部のkvsへ書き込み

オフライン検証

• 本番データを使って実配信しない検証?
• Amazon SageMakerで検証するように鳴った
• ワークフローツールとしてluigiを採用
  • 参考: https://github.com/shotarok/vw-luigi

Amazon SageMaker

• Notebook instanceをあげられる
• buildinで有名なアルゴリズムがすでに用意されている
• docker image を時前で用意して任意のアルゴリズムを使うことができる

データの変遷

1. 最初はHiveQL
   • 条件が複雑になって辛くなっていった
2. nativeなSpark
   • 評価,テストしやすい
   • 実装コスト大
3. 汎用化したSpark
   • 実装コストを軽減
   • yamlを読み込んで、以下を設定できるようにした
     • 抽出するテーブル
     • 特徴量
     • フィルタ

検証内容例

• ハイパーパラメータの調整
  • jupyter notebookでテストを発火させるので、引数を変えながら何度も実行させたりしやすい
• マシンタイプ/数の調整
  • jupyter notebookでテストを発火させるので、マシンの構成を変更させながら何度も実行させやすい

2.Gunosy - ユーザー行動が成す力学系の実現とそれを用 いた推薦システムを支える AWSアーキテクチャ

newspassの推薦システム

spec

• 一日最大10000件程度のニュース記事

背景

• 価値が時間減衰
  • ログが貯まる頃には価値が落ちている
  • ユーザーの興味の変化サイクルが早い
  • 表面的な言葉の一致度のみを取ると質が担保されない

モデル・アーキテクチャ

• 読みたいニュースとは

  • Local Popularity(局所話題性)が大事
    • 自身のコミュニティ, 近所で流行している記事が読みたい
  • 野次馬

• 野次馬のダイナミクスを数学的に表現

  • データ・論文が殆ど無い
  • ざっくりしたモデル内容
    1. ニュース記事を連続的なベクトル空間に置く
       • 似たような記事はユーグリッド距離が近い
    2. ユーザーベクトル
       • 直近M件の記事のクリック重み付けベクトル
       • クリックするたびにベクトルを更新

• 記事ベクトル周りの密度の高いものを推薦

  • 50msec以内に返却したい
    • 平均25msecで返せている

インフラ

• clickログ

  • ログは一旦kinesis streamに入れてる
    • Dynamoに直近M件ずつを保管

• ユーザーベクトル生成

  • DAXを挟んで記事のDynamo tableをキャッシュ
  • Dynamoに保存

• 記事ベクトル

  • シンプルに記事をクロールしてDynamoに保存

• 記事の推薦アルゴリズムで使う行列データ

  • EMRで生成
    • spark
    • presto
  • 各webサーバのメモリに載せ、非同期で更新
  • s3のデータは全部hiveメタストアを通してアクセス

3. freee - 仮想マシン、コンテナ、関数、Kubernetes on AWS の活用方法と展望

containerを取り巻く環境

• 物理マシン
• コンテナ
• FaaS(関数)

関数で済むならそれがいちばんいい
... が 関数のマネージメントのデファクトがまだない と思う人がコンテナを使う

なぜ関数ではなくコンテナ? → ツールが揃ってなくて運用が大変

コンテナオーケストラレーション

• ECS

  • 機能
    • コンテナデプロイ
    • IAMRole
    • ヘルスチェック
    • サービスディスカバリ(Task側にRoute53でDNS名を付与できる)
  • メリット
    • aws公式AMI
    • マネージド
    • segment社の事例とOSS
    • 日本での採用事例が多い
    • スコープ(≒機能)が少ない

• Kubernets

  • 機能
    • コンテナデプロイ
    • サービスディスカバリ
    • ...など(メモしきれなかったけどECSにあるものはだいたいありそう)
  • デメリット
    • 公式AMIがない
    • マネージドサービスがない
    • 事例が少ない
    • スコープが広い

→ ECSより難しい

Kubernetsのいい所

• 拡張性, 便利なツール
• コンテナ運用
• LambdaやECSより汎用的
  • FaaSの選択肢として考えてもいい
• 学習コストは高い。。

EKS

• kubernatesの独自ネットワークがVPCと統合されている
• awsでkubernates使うならEKS使うべき

ECS

• ECS + Fargate が Serverless Kubernates on awsのバックエンド

→ KBSとECS両方知っておくと安心

mixi - モンスターストライクを支えるデータ分析基盤と リアルタイム集計システム

担当: 5人 1TB/day ログ

集計スペック

m4.2xlarge x20 EMR Redshift → 48TB

データ分析基盤の変遷

改善前

• 生ログs3
• adhoc EMR
• Redshiftへデータコピー

課題

• EMRの起動が遅い(起動に30分以上かかる)

  • Hive Metastoreの msck repair tableがボトルネック
  • 対策
    • メタストアの永続化
    • Glueの移行も検討中

• Hiveが遅い

  • バッチ処理に15時間かかっていた
  • 対策
    • ORC化
    • TEZ, CBO, Vectorization
      • vectorizationはたまにバグがある
    • スキャン量を減らす
      • ログの種類でパーティションを分ける
      • APIログをURIでソート
      • ORC indexを利用
        • INSERT OVERWRITE で DESTRIBUTE by, ORDER by を指定
    • 並列実行
      • どうやったんだろう

• バッチ処理

  • ジョブフロー管理ツール
    • 自前のジョブフロー管理ツール
    • 約300ほどのバッチが動いてる・・・

• エンジニア以外の人へのデータ開放

  • zeppelin
  • metabase

→ どちらもECSで運用

• 集計クエリが複雑

  • 分析用に別途テーブルを定義し直した
  • わかりやすいフラグ
    • demensional modeling
      • テーブルを Fact, Dimensionでわける
      • データの理解しやすさを重視

• データの信頼性

  • データは壊れる
  • データの事後検証
    • ジョブフローの後半でデータの品質チェックを実行
      • 異なるデータソースから同じ集計をしてみて比較
      • 変換前後
      • NULLのカラムがないか確認
    • unittest のフレームワークを利用

準リアルタイム集計

• s3 → lambda → kinesis → flink → s3
• flinkの代わりにDynamoだったりするパターンも