[レポート] ソニーのプレイステーションの不正防止対策としてのビックデータ分析 #reinvent #ANT331

ご機嫌いかがでしょうか、豊崎です。本日はre:Inventの初日（12/2）です。

現地からセッションのレポートをお届けいたします。

セッション情報

登壇者

• Nicholas Walsh - Technical Evangelist, Amazon Web Services
• Eric Krauss - Engineering Manager, Commerce Platform - Fraud, SIE
• Tom Lilley - Staff Software Engineer, Sony Interactive Entertainment

セッション概要

ソニー・インタラクティブエンタテインメントはAWSの分析サービスを使用して不正利用を防止する目的のために、ユーザのアクティビティを集約したビックデータプラットフォームであるEVE Fraud Systemを構築しました。これにより、銀行からの拒否や、カードの不正利用を増加することなく、承認を増やしました。このセッションではソニーが以下のサービスを使用してデータの集計を行い、どのように１つの購入のトランザクションを180ms未満にしたかが含まれます。

• Amazon Kinesis Data Analytics
• Amazon Kinesis Data Firehose
• AWS Lambda
• AWS Glue
• Amazon Simple Storage Service (Amazon S3)
• Amazon DynamoDB

AWS analytics enables fraud prevention for Sony’s PlayStation Sony Interactive Entertainment built their EVE Fraud System as a big data platform to aggregate transactional activity of users, resulting in substantially increased approvals with no increase in declines or chargebacks from banks. In this session, learn how Sony used Amazon Kinesis Data Analytics, Amazon Kinesis Data Firehose, AWS Lambda, AWS Glue, Amazon Simple Storage Service (Amazon S3), and Amazon DynamoDB to generate aggregations and retrieve them in a single purchase transaction in less than 180 milliseconds.

セッション内容

EVE Systemについて

• EVE Systemの要件として、スピード、スケーラビリティ、障害時の回復があった
  • スピード
    • ユーザ同士が素早く交流することを可能に
  • スケーラビリティ
    • 新しいシーズンがリリースされる時、非常につよいスパイクアクセが発生
  • 回復力
  • ヒューマンエラーと機械的な故障に対応ができること

• リアルタイム分析：Lambda(AWS Lambdaではない)構成
  • Batchレイヤー
    • 包括的で正確なビューを提供
  • スピードレイヤー
    • 素早く結果を表示するビューを提供

• Lambda構成の利点
  • 複雑さを分解することができる
    • 複雑な増分のアップデートはスピードレイヤーに分離（一時的なデータ）
    • 持続されたデータはマスターデータセットからバッチによって見ることができる（スピードレイヤーのリアルタイムビューは無視することができる）
• 最終的な精度について
  • Batchレイヤー
    • 正確なアルゴリズムを使用
  • スピードレイヤー
    • ほぼ正確なアルゴリズムを使用
• 人為的、または機械的な障害に対する復旧
  • バッチビューの再作成とスピードビューを全て捨てることで平常時に戻すことが可能

• バッチレイヤー
  • Kinesis Data Firehose
    • JSONからETLのためにパースをしてS3へ
  • Amazon S3
    • マスターデータセット
  • AWS Glue
    • １時間、1日ごと、およびオンデマンドで集約されたデータをS3からDyanamoDBに作成
  • DynamoDB
    • バッチで書かれたデータ。増分更新は行わない

• スピードレイヤー
  • Kinesis Data Analytics
    • 1秒ごとにカスタムSQLで集計される
  • Lambda
    • データベースへ書き込むためキーで整理する
    • 高速な並列の書き込みを行うために複数のLambdaで処理
  • DynamoDB
    • Updateとして書かれたデータはされた集約された値を変化させる

• 技術的な挑戦（読み取り）
  • 集約の取得にかかる時間が重要
  • インターバルごとにデータを整理する
  • キーの指定
    • ハッシュキー：間隔ごとと何のデータが集計されるか
    • ソートキー：時間間隔

• 技術的な挑戦（拡張性）
  • 汎用的なメタモデルがキーコンポーネント
    • 例）直近7日間に特定のアカウントが何回購入をしたか？
  • 繰り返しが可能な構造に分解すること

• 技術的な挑戦（ビッグデータ）
  • 1日に数百万件のトランザクションに対して、独自の集計によりより長い期間の大きなサイズのデータを作成可能
    • 例）直近7日間に特定のアカウントが何回購入をしたか？
  • リスク分析に十分な精度を維持しながらアイテムのサイズを小さくするためのapproximationアルゴリズムを導入

結果について

• 購入について
  • 全体的に成功と言える
    • 月間の売り上げに対して3%を改善することに成功した
    • 母数が大きいため3%でも非常に高い効果が出たと言える
    • カードの不正利用の数値を変えずに銀行の承認数の向上を達成
    • レスポンス速度を2秒から195ミリ秒以下に改善
    • 精度の低下について40%改善された

• EVE Purchaseの導入から誤検知が大きく低下している

課題について

• 正確性vsコスト
  • 現在の間隔（１分）でデータを整理すると精度が100%未満になる
  • 1秒間隔にするとコストとアイテム数が増大する
• インフラのコード化
  • CloudFormationは必要とされる全てのデプロイの自動化には対応していない
  • デプロイのあとリソースの構成するためにカスタムのラムダを作成した
• セキュリティ
  • センシティブなプラットフォームのデータ
  • IAMと暗号化は非常に重要
  • それぞれのデータに最小の権限でアクセスする必要があった

 

セッションレポートについては以上となります。