ayumu_aoの日記

SIerから事業会社に転職したエンジニアがなにかを垂れ流してます

AWS Summitに行ってきた!レポート※セッションメモ (2017/06/02)[Sansan]AWSが支えるEightのリコメンデーションエンジンの裏側

AWS Summit 2017/06/02 [Sansan]AWSが支えるEightのリコメンデーションエンジンの裏側

自己紹介

  • 鈴木康寛

サーバーレス×ビッグデータ

アジェンダ

  • Eightにおけるリコメンデーション
  • リコメンドアーキテクチャ刷新
  • リコメンドデータ洗い替え

■Eightにおけるリコメンデーション

Eight=個人向け名刺アプリ

「名刺をビジネスのつながり」に変える

入り口:名刺交換

日本全体の名刺交換の約10%をEightで担っている

約3億枚の名刺データ

名刺管理→ビジネスネットワークへ

キーワードは「つながり」

つながることで

  • 名刺情報のアップデータお
  • フィード投稿閲覧
  • メッセージ送受信

⇒ビジネスネットワークの活性化

リコメンデーション

利用者一人ひとりの指向に合わせコンテンツの推薦

Eightでは人物を推薦

名刺交換リクエストの承認率を上げるためのリコメンデーション

リコメンデーションエンジン

2年前からあったが誰が誰に何をしたかをひたすら蓄積し日時でバッチ処理で更新しCloudSearchに投げ込んでいた

しかし、

  • RedShift:無駄に複雑なクエリ

  • CloudSearch:全文検索として使ってなかった(スコア検索のみ)、更新までのレイテンシー

コストもそれなりにかかっていた⇒増えないつながり

  • パフォーマンス低下
  • オペレーションコスト高騰

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

リコメンドに最適なアーキテクチャとはなにか?

リコメンドの要とは 1. データ分析 2. アルゴリズム 3. リアルタイムフィードバック

キーワードとして「直近の出会いを大事に!」

鮮度が良いほどリクエストを承認しやすくなる

リアルタイムリコメンデーションを目指す!

開発期間は2ヶ月

条件:

  • 2ヶ月でできることにフォーカス
  • スケーラビリティ

やったこと

レーティングデータ

  • リアルタイム性を担保するために中間データを持つ

構想

  • ログ部分は既存のRedShiiftのデータを活用
  • 中間データ更新にKinesis+Lambdaが使えそう
  • 知見があるDynamoDBをストレージに
  • シャード数・キャパシティを上げることでスケーラビリティ

■サーバーレスアーキテクチャ

  • ストリーム :Kinesis、DynamoDB
  • コンシューマ:Lambda
  • ストレージ :RedShift、DymnamoDB、ElasticCache

サーバーレスは夢のツールではなかった。。。

サーバレスに対する誤解

  • パフォーマンス向上
  • オペレーションコストの低下

これは間違いだった。。。。

パフォーマンス

  • 分間1万件の1分間分のアクティビティが1時間たっても処理できない

解決方法 * まとめられる処理はまとめて処理する

※参考情報:Lambdaのメモリ設定はコンプピュータリソースの設定

オペレーションコスト

※処理の単純化を行いすぎるとFunctionが増加しすぎてしまう

(個人的な所感はRDBの正規化、非正規化問題に近いのかも)

ストリーム・コンシューマ問題

コンシューマとストリームを1:1にするとストリームが増えすぎてしまい管理できなくなったりコストがかかってしまう

分ける必要のないものはわけずにまとめる

パラメータにより処理を分岐する形にLambdaに複数処理をまとめる

■リコメンドデータの洗い替え

課題

レーティングデータの陳腐化

原因

  1. Eightサービス側のデータ構造の変更
  2. データ不整合の発生
  3. リコメンドルゴリズムの変更

発生すると今まで蓄積したものは無に帰る

解決策

全過去ログを集計してレーティングデータを作り直す!!

※DataPipelineを利用するとわりと簡易的にRedShiftにためたから可能

キーワード: * RedShiftCopyActivity * HiveActivity

※手順がスライドで紹介されてたので確認!

ダウンタイム無しで行うにはワークフロー管理が必要!!

StepFunctionsで解決!

※複数のLambdaを管理

StepFunctionsとDataPipeLineの組み合わせで行うために!

※スライド参照

Lambdaのタイムアウト問題

  • StepFunctionsのリトライ機能を使い完了していない場合はエラー扱いとして定間隔でリトライ
  • StepFunctionsのParallel、choiceを利用すると処理分岐ができる

DynamoDB Stream経由でCacheをひたすら高速生成

ダウンタイム無しで洗い替え

Lambda停止前と停止後で処理を分けるがどう切り分けるか?

指定時刻よりも新しいものを処理するという設定がLambdaでできる

約9500万件のデータの洗い替えが約9時間で完了

まとめ

サーバーレスの可能性

利点

  • 気軽さ
  • スケーラビリティ
  • 柔軟性

!!AWSを正しく使うことの価値!!