markdown awssummit2018备忘录

Posted 2021-05-06

## 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だったりするパターンも