• home
  • [AWS Summit Tokyo 2017 Day3] AWSが支えるEightのリコメンデーションエンジンの裏側

[AWS Summit Tokyo 2017 Day3] AWSが支えるEightのリコメンデーションエンジンの裏側

名刺管理で有名な株式会社SanSanさんのアプリ、「Eight」での事例です。
とても濃い内容で、StepFunctionsの待ち受け運用とか非常に参考になりました。

ビジネス

  • 個人向け名刺管理アプリ、Eight
  • 名刺の唾がりをビジネスに変える/つながった相手とコミュニケーション
  • 日本の名刺交換の10%をさばいている!(!)
  • 名刺交換のUpdate.相手が転職しても繋がりを維持する
  • 「つながり」をリコメンデーションエンジンで

問題/旧リコメンデーション

  • RedshiftとEC2上のリコメンド計算エンジンで計算、CloudSearchでリコメンド
  • Redshift、複雑怪奇なクエリ、集計性能に依存
  • CloudSearch,全文検索エンジンとしてではなく関係性スコアのソートのみに使っていた
  • パフォーマンスダウン!
  • オペレーションコスト!

リコメンドアーキテクチャ刷新。

  • データ分析
  • アルゴリズム
  • リアルタイム性 <= もっともここを大事に

リアルタイムリコメンデーションエンジンを作り直そう

  • ログデータは今まで通りRedShift
  • 中間データ更新にKinesis + Lambda
  • 中間データはDynamoDBをストレージに

  • => 2ヶ月でできた!

構成

ストリーム
* Kinesis,DynamoDB Stream
コンシューマ
* Lambda
ストレージ
* RedShift,DynamoDB,ElastuCache

  • 名刺間のレーテイングデータをひたすらDynamoとLambdaで生成する。
  • データが更新されたらSQS発火、EC2上のワーカーが中間データから実際のリコメンドデータを生成

コツ

  • KinesisはPut Recordsでリクエストをまとめる
  • メモリ設定でリソースを増やす
  • DynamoDBはなるべくBatchWriteを使う
  • パフォーマンスが大幅に改善された

  • Function数の増加問題

    • Functionをシンプルにしすぎると数が増えすぎて管理できない問題
    • ある意味Function内でルーティングすることでストリームの種類によって処理を分岐する
  • ストリーム – コンシューマ問題
    • StreamとLambdaがお互いを維持できるバランスにならない
    • ストリームをLambdaが書き直して差戻すFunctionを作る(分身の術)

残った問題と解決

  • レーティングデータの陳腐化
  • アルゴリズムが変わり中間データの価値がなくなる
  • RedShiftにある過去ログから全て中間データを作り直した! => Data Pipelineを利用して数時間で再生成!
  • リコメンドのマイグレーション
    • まずLambdaを停止
    • 再生成してから再起動
    • まるで心臓バイパス手術
    • ダウンタイムなしでやるにはワークフロー大事
  • そこでちょうどリリースされたAWS Step Function
    • Lambdaの処理完了
    • DataPipilineの処理まち
    • タイムアウトはStepFunctionの定間隔リトライが使える!!!!!!!!

サーバーレスの利点

* スケーラブル
* 柔軟性
* 気軽さ