名刺管理で有名な株式会社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の定間隔リトライが使える!!!!!!!!

サーバーレスの利点

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