サーバーレスファーストで考えるクレジットカードビジネスの最適化 / Business Optimization for Credit Card by Serverless

Transcript

1. サーバーレスファーストで考える
   クレジットカードビジネスの最適化
   Synspective Inc.
   Senior Infra Engineer
   新井 雅也
   2023-08-31
   私たちのサーバーレスアーキテクチャ構成はこれだ！ Lunch LT
   

   View Slide

2. 新井 雅也
   M a s a y a A R A I
   msy78
   前職はNRI。現在は宇宙業界スタートアップ企業である Synspective Inc. に所属。
   自社開発している衛星の地上局管制システムのインフラ構築・運用を担当。
   クラウドを活用した全体のアーキテクチャ設計・開発が得意。
   傍らでFintechスタートアップの技術アドバイザーを担当。
   好きな技術・サービスは、ECS/Fargate、Kubernetes、Cloud Run、Golang、Pulumi
   AWS Container Hero, AWS Ambassador 2022, AWS Top Engineer 2020-2022
   Google Cloud Partner Top Engineer 2023
   Senior Infra Engineer
   

   View Slide

3. ⚠ おことわり ⚠
   • 本発表の目的は情報提供のみであり、内容の確実性を保証するものではありません。
   • 本発表の内容は、イベント登壇時点(2023年8月31日)の情報をもとに作成しています。
   • 特に断りがなければ、本資料にて登場するAWSおよびGoogle Cloudサービスはすべて東京
   リージョンを前提にしています。
   

   View Slide

4. プロダクト事例のご紹介：次世代クレジットカードサービス Nudge
   

   View Slide

5. アプリで簡単申込み
   氏名・生年月日・住所+本人確認書類1点で申込
   アプリベースで管理も手軽に
   決済金額はリアルタイムでアプリに通知・反映
   返済は自分のタイミングに合わせて
   自分に合った金額を、自由なタイミングで返済可能
   利便性の高い少額VISAクレジットカード
   上限金額10万円も、返済すれば即時に利用枠は復活
   利用者にとって安心で便利なクレジットカード
   

   View Slide

6. View Slide

7. ユーザーに使う楽しみを：「好き」に貢献できるカード
   ユーザー（ファン）が普段通りクレジットカード支払いをするだけで、
   「好き」なスポーツチームやアーティスト等に貢献でき、お返しとして”特典”をもらえる仕組み
   ファンの方々
   （ユーザー様）
   還元（応援）
   通常のクレカのポイント相当分
   特典
   スポーツチーム・アスリート
   アーティスト etc
   店舗・EC等
   クレカ決済
   日常のお買い物をナッジカードで
   クレジットカード
   手数料
   

   View Slide

8. サーバーレスファーストで考える
   クレジットカードビジネスの最適化
   Synspective Inc.
   Senior Infra Engineer
   新井 雅也
   2023-08-31
   私たちのサーバーレスアーキテクチャ構成はこれだ！ Lunch LT
   

   View Slide

9. サーバーレスファーストで考える
   クレジットカードビジネスの最適化
   Synspective Inc.
   Senior Infra Engineer
   新井 雅也
   2023-08-31
   私たちのサーバーレスアーキテクチャ構成はこれだ！ Lunch LT
   

   View Slide

10. 開発者がアプリケーション開発を行う上で
    サーバやそれに付随するOSの存在を意識しないこと
    本発表におけるサーバーレスの定義
    

    View Slide

11. 本発表におけるサーバーレスの定義
    開発者がアプリケーション開発を行う上で
    サーバやそれに付随するOSの存在を意識しないこと
    u システム全体で見れば、サーバーレスを担うサービスを利用していても、
    コンピューティングリソースを担うサーバ自体は存在する
    u サーバーレスを利用する＝クラウドベンダーからコンピューティングリソースに課金する
    

    View Slide

12. なぜサーバーレスファーストなのか？
    

    View Slide

13. クラウドでサーバーレスを利用する
    ＝サーバ部分に纏わるあれこれをクラウド事業者に移譲する
    引用: https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-dp.html
    

    View Slide

14. クラウドでサーバーレスを利用する
    ＝サーバ部分に纏わるあれこれをクラウド事業者に移譲する
    引用: https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-dp.html
    差別化を生まない重労働の排除
    事業への本質的な
    活動に注力するため、
    サーバーレスによって
    ナッジが解消したい関心事
    

    View Slide

15. クラウドでサーバーレスを利用する
    ＝サーバ部分に纏わるあれこれをクラウド事業者に移譲する
    寄与
    PCI DSSへの準拠
    データ分析業務
    Nudgeとして
    重要な事業活動の
    一部
    寄与
    差別化を生まない重労働の排除
    

    View Slide

16. クラウドでサーバーレスを利用する
    ＝サーバ部分に纏わるあれこれをクラウド事業者に移譲する
    寄与
    PCI DSSへの準拠
    データ分析業務
    Nudgeとして
    重要な事業活動の
    一部
    寄与
    差別化を生まない重労働の排除
    まずは
    こちらから
    

    View Slide

17. クレカサービスを事業として成立させるために必要なPCI DSS準拠
    

    View Slide

18. View Slide

19. (1)カード番号 (2)カード会員名 (3)有効期限 (4)サービスコード
    ※磁気ストライプ情報の読み取り方法と制限事項
    (5)磁気ストライプデータ
    (6)PIN/PINブロック
    (7)セキュリティコード
    カード会員データ
    機密認証データ
    カード会員データもしくは機密認証データを
    「処理」「通過」「保持」する事業体のシステムはPCI DSS準拠が必須
    

    View Slide

20. カード発行主体（イシュアー）として、
    PCI DSS準拠はビジネスを実現する上での「当然の責務」
    

    View Slide

21. クレジットカード番号等取扱業者は、経済産業省令で定める基準に従い、その取り扱うクレジット
    カード番号等の漏えい、滅失又は毀損の防止その他のクレジットカード番号等の適切な管理のために必
    要な措置を講じなければならない。
    割賦販売法 第三十五条の十六より
    カード発行主体（イシュアー）として、
    PCI DSS準拠はビジネスを実現する上での「当然の責務」
    万一、セキュリティ保護のための社内体制整備や措置が不十分な包括信用購入あっせん業者が存在し
    た場合、速やかに業務を 停止させた上で、措置の是正や早急の体制整備（体制整備の後、業務を再開
    させる）が必要として、業務停止命令を導入。
    割賦販売法の令和２年改正後の 主な動向と課題
    

    View Slide

22. PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目に対する方針検討と準拠が必要
    安全なネットワークの
    構築維持
    カード会員データの
    保護
    脆弱性管理プログラムの
    維持
    強力なアクセス制御手法
    の導入
    ネットワークの定期的な
    監視およびテスト
    情報セキュリティ
    ポリシーの維持
    1.カード会員データを保護するために、ファイアウォールをインストールして維持する
    2.システムパスワードおよびその他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない
    3.保存されるカード会員データを保護する
    4.オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する
    5.マルウェアにしてすべてのシステムを保護し、ウィルス対策ソフトウェアを定期的に更新する
    6.安全性の高いシステムとアプリケーションを開発し、保守する
    7.カード会員データへのアクセスを、業務上必要な範囲内に制限する
    8.システムコンポーネントへのアクセスを識別・認証する
    9.カード会員データへの物理アクセスを制限する
    10.ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
    11.セキュリティシステムおよびプロセスを定期的にテストする
    12.すべての担当者の情報セキュリティに対応するポリシーを整備する
    (56項目)
    (38項目)
    (42項目)
    (78項目)
    (70項目)
    (47項目)
    ※PCIDSS v3.2.1を前提に記載
    

    View Slide

23. PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目に対する方針検討と準拠が必要
    安全なネットワークの
    構築維持
    カード会員データの
    保護
    脆弱性管理プログラムの
    維持
    強力なアクセス制御手法
    の導入
    ネットワークの定期的な
    監視およびテスト
    情報セキュリティ
    ポリシーの維持
    ファイアウォールと適切なパラメータ設計
    データの暗号化とネットワーク保護
    ウィルス対策と脆弱性管理、セキュアコーディング
    データへのアクセス制御、アクセスの識別、物理セキュリティ
    セキュリティ監視、監査証跡、セキュリティテスト
    セキュリティポリシー
    ※PCIDSS v3.2.1を前提に記載
    要約すると
    

    View Slide

24. AWS Lambda
    AWS Fargate
    Amazon EC2
    AWSにおけるコンピューティングサービスと責任共有モデル
    サーバーレスサービス
    

    View Slide

25. AWS Lambda
    AWS Fargate
    Amazon EC2
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマーIAM
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマー IAM
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマー
    IAM
    AWSにおけるコンピューティングサービスと責任共有モデル
    サーバーレスサービス
    

    View Slide

26. AWS Lambda
    AWS Fargate
    Amazon EC2
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマーIAM
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマー IAM
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマー
    IAM
    AWSにおけるコンピューティングサービスと責任共有モデル
    サーバーレスサービス
    DockerfileやECSに
    おけるタスク定義は
    利用者側の責務 VPCとの連携は
    利用者側の責務
    ランタイムの
    ライフサイクル管理は
    利用者側の責務
    

    View Slide

27. AWS Lambda
    AWS Fargate
    Amazon EC2
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマーIAM
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマー IAM
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマー
    IAM
    サーバーレスサービス
    ファイアウォールと
    適切なパラメータ設計
    データの暗号化と
    ネットワーク保護
    ウィルス対策と脆弱性管理、
    セキュアコーディング
    データへのアクセス制御、
    アクセスの識別、物理セキュリティ
    セキュリティ監視、監査証跡、
    セキュリティテスト
    PCI DSS
    クラウド利用者側に責任が発生するレイヤーは
    すべてPCI DSSへの準拠の検討が求められる
    

    View Slide

28. AWS Lambda
    AWS Fargate
    Amazon EC2
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマーIAM
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマー IAM
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマー
    IAM
    サーバーレスサービス
    ファイアウォールと
    適切なパラメータ設計
    データの暗号化と
    ネットワーク保護
    ウィルス対策と脆弱性管理、
    セキュアコーディング
    データへのアクセス制御、
    アクセスの識別、物理セキュリティ
    セキュリティ監視、監査証跡、
    セキュリティテスト
    PCI DSS
    クラウド利用者側に責任が発生するレイヤーは
    すべてPCI DSSへの準拠の検討が求められる
    

    View Slide

29. AWS Lambda
    AWS Fargate
    Amazon EC2
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマーIAM
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマー IAM
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマー
    IAM
    サーバーレスサービス
    ファイアウォールと
    適切なパラメータ設計
    データの暗号化と
    ネットワーク保護
    ウィルス対策と脆弱性管理、
    セキュアコーディング
    データへのアクセス制御、
    アクセスの識別、物理セキュリティ
    セキュリティ監視、監査証跡、
    セキュリティテスト
    PCI DSS
    OS設計が絡むとPCI DSS準拠に必要な作業が膨大になる
    ・カーネルパラメータチューニング
    ・最小限のOSパッケージ導入
    ・起動プロセスの制限
    ・OSユーザ・グループ設計
    ・ディレクトリ・ファイル権限設計
    ・sudo設計
    ・ログイン履歴ログやローテーション設計
    ・SSH等ログイン制御
    ・PAM設計
    ・OS脆弱性に対するパッチ運用
    etc…
    スタートアップにとって、継続的な運用負荷が解消されないことは死活問題
    →強力システム要件やサービス制約の理由がない限り、サーバーレス以外の選択肢は合理的ではない
    

    View Slide

30. AWS Lambda
    AWS Fargate
    Amazon EC2
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマーIAM
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマー IAM
    ハードウェア
    AWSグローバルインフラ
    コンピュート・ストレージ・
    DB・ネットワーク
    ネットワーク設定
    アプリケーション
    カスタマーデータ
    OS設定
    ランタイム
    AWS IAM
    カスタマー
    IAM
    サーバーレスサービス
    ファイアウォールと
    適切なパラメータ設計
    データの暗号化と
    ネットワーク保護
    ウィルス対策と脆弱性管理、
    セキュアコーディング
    データへのアクセス制御、
    アクセスの識別、物理セキュリティ
    セキュリティ監視、監査証跡、
    セキュリティテスト
    PCI DSS
    サーバーレスファーストとして、AWS FargateおよびAWS Lambdaを採用
    これらのサービス選定
    を主軸にシステム構築
    

    View Slide

31. サービス毎の利用目的と照らし合わせて、選定基準する方向性は持ちつつも、
    柔軟な選定ができるように、幅を持たせている
    

    View Slide

32. AWS Lambda
    AWS Fargate
    サービス毎の利用目的と照らし合わせて、選定基準する方向性は持ちつつも、
    柔軟な選定ができるように、幅を持たせている
    ある程度のドメイン規模(API 5本以上など)の
    バックエンドAPI群
    例) モバイル向けBFF
    決済ドメイン向けAPI (API約30本)
    イベント発火による小規模なApp処理
    例) 与信後ファイルUP契機によるカード発行
    カード印刷ファイル連携後の他システム連携
    銀行からの返済電文受け取り後のAPI連携
    

    View Slide

33. AWS Lambda
    AWS Fargate
    サービス毎の利用目的と照らし合わせて、選定基準する方向性は持ちつつも、
    柔軟な選定ができるように、幅を持たせている
    ある程度のドメイン規模(API 5本以上など)の
    バックエンドAPI群
    例) モバイル向けBFF
    決済ドメイン向けAPI (API約30本)
    イベント発火による小規模なApp処理
    例) 与信後ファイルUP契機によるカード発行
    カード印刷ファイル連携後の他システム連携
    銀行からの返済電文受け取り後のAPI連携
    • 大体のWebアプリ向けバックエンド処理はいずれでもできる (正解はない)
    • その時に捻出可能な開発リソース、開発規模、事業特性によっても選定方針が変わる
    • 自分たちが決めた前提（PCI DSS準拠の都合で、EC2採用は極力見送りたい = サーバーレスファースト)の上では
    都度検討
    →W-Aの軸を考えながら、合理的に言語化してチームで合意できればOKとしている
    • 1wayではなく、2-way(必要に応じて、あとからLambdaをFargateに集約する等)ぐらいの思考の余裕を設ける
    技術選定に関する考え方
    

    View Slide

34. スマホアプリ
    外部接続システム
    (返済機能)
    サービスプラットフォーム
    管理者Web
    外部接続システム
    (eKYC機能)
    外部接続システム
    (ペイメント関連)
    外部接続システム
    (カード印刷関連)
    スマホアプリ用
    フロントAPI
    管理者Web用
    フロントAPI
    外接システム用
    フロントAPI
    マイクロサービス別
    各API
    腐敗防止層
    外接向けAPI
    カード
    返済
    申込
    通知
    指定信用情報機関
    (CIC)
    バッチ連携
    決済
    会員
    管理者
    外部接続システム
    (金融機関)
    データ
    ベース
    ナッジにおけるサービスプラットフォームは
    サーバーレスを前提としたAWSサービスで構成
    コンテンツ
    

    View Slide

35. スマホアプリ
    外部接続システム
    (返済機能)
    管理者Web
    マイクロサービス別
    各API
    Amazon
    API Gateway
    NLB
    API
    NLB
    API
    API
    ALB
    カード管理API
    返済系API
    申込系API
    通知系API
    外接連携API
    Amazon Aurora
    Amazon ECS
    バッチ用S3
    バケット
    バッチ用
    AWS Sfn
    Amazon
    API Gateway
    指定信用情報機関
    (CIC)
    会員系API
    決済系API
    管理者API
    コンテンツ用
    S3バケット
    Amazon
    CloudFront
    外部接続システム
    (eKYC機能)
    外部接続システム
    (ペイメント関連)
    外部接続システム
    (カード印刷関連)
    外部接続システム
    (金融機関)
    サービスプラットフォーム
    ナッジにおけるサービスプラットフォームは
    サーバーレスを前提としたAWSサービスで構成
    API(非同期)
    

    View Slide

36. クラウドでサーバーレスを利用する
    ＝サーバ部分に纏わるあれこれをクラウド事業者に移譲する
    寄与
    PCI DSSへの準拠
    データ分析業務
    寄与
    差別化を生まない重労働の排除
    

    View Slide

37. クラウドでサーバーレスを利用する
    ＝サーバ部分に纏わるあれこれをクラウド事業者に移譲する
    寄与
    PCI DSSへの準拠
    データ分析業務
    寄与
    差別化を生まない重労働の排除
    次は
    こちら
    

    View Slide

38. ナッジにおけるデータ分析業務とサーバーレス
    

    View Slide

39. スマホアプリ
    外部接続システム
    (返済機能)
    管理者Web
    マイクロサービス別
    各API
    Amazon
    API Gateway
    NLB
    API
    NLB
    API
    カード管理API
    返済系API
    申込系API
    通知系API
    外接連携API
    Amazon Aurora
    Amazon ECS
    バッチ用
    AWS Sfn
    Amazon
    API Gateway
    指定信用情報機関
    (CIC)
    会員系API
    決済系API
    管理者API
    コンテンツ用
    S3バケット
    Amazon
    CloudFront
    外部接続システム
    (eKYC機能)
    外部接続システム
    (ペイメント関連)
    外部接続システム
    (カード印刷関連)
    外部接続システム
    (金融機関)
    サービスプラットフォーム
    ナッジにおけるサービスプラットフォームは
    サーバーレスを前提としたAWSサービスで構成
    API
    ALB
    バッチ用S3
    バケット
    API(非同期)
    

    View Slide

40. API
    ALB
    バッチ用S3
    バケット
    API(非同期)
    スマホアプリ
    外部接続システム
    (返済機能)
    管理者Web
    マイクロサービス別
    各API
    Amazon
    API Gateway
    NLB
    API
    NLB
    API
    カード管理API
    返済系API
    申込系API
    通知系API
    外接連携API
    Amazon ECS
    バッチ用
    AWS Sfn
    Amazon
    API Gateway
    指定信用情報機関
    (CIC)
    会員系API
    決済系API
    管理者API
    コンテンツ用
    S3バケット
    Amazon
    CloudFront
    外部接続システム
    (eKYC機能)
    外部接続システム
    (ペイメント関連)
    外部接続システム
    (カード印刷関連)
    外部接続システム
    (金融機関)
    サービスプラットフォーム
    Amazon Aurora
    「データの民主化」のもと、
    各メンバーがデータと向き合いながら業務を推進
    シード期〜シリーズAまでは業務DBにログインしてアドホック分析を実施
    

    View Slide

41. API
    ALB
    バッチ用S3
    バケット
    API(非同期)
    スマホアプリ
    外部接続システム
    (返済機能)
    管理者Web
    マイクロサービス別
    各API
    Amazon
    API Gateway
    NLB
    API
    NLB
    API
    カード管理API
    返済系API
    申込系API
    通知系API
    外接連携API
    Amazon ECS
    バッチ用
    AWS Sfn
    Amazon
    API Gateway
    指定信用情報機関
    (CIC)
    会員系API
    決済系API
    管理者API
    コンテンツ用
    S3バケット
    Amazon
    CloudFront
    外部接続システム
    (eKYC機能)
    外部接続システム
    (ペイメント関連)
    外部接続システム
    (カード印刷関連)
    外部接続システム
    (金融機関)
    サービスプラットフォーム
    Amazon Aurora
    「データの民主化」のもと、
    各メンバーがデータと向き合いながら業務を推進
    シード期〜シリーズAまでは業務DBにログインしてアドホック分析を実施
    ビジネス担当
    データの傾向をもとに、
    業務にフィードバック
    Google Sheets
    バッチ処理にて
    一部データを出力
    u 会員申込状況・与信状況 → マーケ施策
    u 決済金額・決済回数 → ビジネスKPIの元ネタ
    u 利用者の特性 → プロダクト改善
    u 返済・延滞・督促状況 → 債権管理業務施策
    etc
    

    View Slide

42. Google Sheets
    組織規模やビジネス規模が大きくなるにつれて、
    業務DBに対する直接的なアクセスは様々な課題を生む
    プロダクト開発担当
    与信＆債権担当
    データサイエンティスト
    マーケティング担当
    ユーザ離脱の傾向を押さえて、
    プロダクト改善に繋げたい...
    ビジネス担当
    未返済の利用者傾向を分析し、
    与信モデル改善に役立てたい...
    GMV等のビジネスKPIを可視化し、日々のビジネスの成長を
    ステークホルダーと共有しつつ、次の打ち手を考えたい...
    クレカ新規デザインの反応を見て、
    ファンへの施策を検討したい...
    決済金額と返済率の相関や
    与信通過時の特性との相関を分析したい...
    バッチ処理にて
    一部データを出力
    

    View Slide

43. プロダクト開発担当
    与信＆債権担当
    データサイエンティスト
    マーケティング担当
    ユーザ離脱の傾向を押さえて、
    プロダクト改善に繋げたい...
    ビジネス担当
    未返済の利用者傾向を分析し、
    与信モデル改善に役立てたい...
    GMV等のビジネスKPIを可視化し、日々のビジネスの成長を
    ステークホルダーと共有しつつ、次の打ち手を考えたい...
    クレカ新規デザインの反応を見
    て、
    ファンへの施策を検討したい...
    決済金額と返済率の相関や
    与信通過時の特性との相関を分析したい...
    Amazon Aurora
    Google Sheets
    バッチ処理にて
    一部データを出力
    DBアクセスやスプレッドシード出力が悪いのではなく、スケールによりリスクが発生するという文脈で対処が必要と判断
    組織規模やビジネス規模が大きくなるにつれて、
    業務DBに対する直接的なアクセスは様々な課題を生む
    u 不要なテーブルアクセスがなされる可能性
    u そもそも、担当者も不要なリスクを犯したくない
    u テーブルごとのアクセス制限は運用上避けたい
    u テーブル追加毎にケアする必要
    （機微情報を保存するテーブルは別）
    u 重いクエリ発行によるオンライン業務影響を避けたい
    u スプレッドシートに対してあらゆるデータが分散する
    u 想定外のデータ漏えいリスク
    

    View Slide

44. Amazon Aurora
    データの民主化をもとに、データドリブンな文化を根ざすためにも、
    業務DBとは別に分析用の環境を別途設ける
    データ分析プラットフォーム
    DWH
    「データの分析」が主役なので、サーバーレスファーストな思想前提のもと、
    W-Aとのバランスを鑑みながら技術選定や方式を検討
    プロダクト開発担当
    与信＆債権担当
    データサイエンティスト
    マーケティング担当
    ビジネス担当
    可視化
    

    View Slide

45. Amazon Aurora
    ナッジにおけるデータ分析設計の主要な考慮ポイント
    データ分析プラットフォーム
    DWH
    可視化
    DWHとして何を利用するか？ 機微情報はどのように
    処理するか？
    データ抽出時における
    オンライン業務への考慮は？
    

    View Slide

46. Amazon Aurora
    データ分析プラットフォーム
    DWH
    機微情報はどのように
    処理するか？
    可視化
    DWHとして何を利用するか？
    データ抽出時における
    オンライン業務への考慮は？
    ナッジにおけるデータ分析設計の主要な考慮ポイント
    

    View Slide

47. サーバーレスETLであるAWS Glueを活用して、
    機微情報含めたデータの前処理を実施
    

    View Slide

48. Amazon Aurora
    データ分析プラットフォーム
    DWH
    可視化
    AWS Glue
    データの民主化をもとに、データドリブンな文化を根ざすためにも、
    業務DBとは別に分析用の環境を別途設ける
    

    View Slide

49. Amazon Aurora
    データ分析プラットフォーム
    DWH
    可視化
    AWS Glue
    機微情報はどのように
    処理するか？
    DWHとして何を利用するか？
    データ抽出時における
    オンライン業務への考慮は？
    ナッジにおけるデータ分析設計の主要な考慮ポイント
    

    View Slide

50. Amazon Aurora
    検討前のDB接続構成
    Instance
    (Master)
    Instance
    (Replica)
    Endpoint
    (default/writer)
    Endpoint
    (default/read only)
    App
    

    View Slide

51. Amazon Aurora
    AWS Glueによるデータ抽出を考慮したDBアーキテクチャ
    Instance
    (Master)
    Instance
    (Replica)
    Endpoint
    (default/writer)
    Endpoint
    (default/read only)
    App
    AWS Glue
    日次で決まった時刻に
    DBからデータを抽出開始
    

    View Slide

52. Amazon Aurora
    Instance
    (Master)
    Instance
    (Replica)
    Endpoint
    (default/writer)
    Endpoint
    (default/read only)
    App
    AWS Glue
    データ抽出時にオンライン業
    務と同じエンドポイントを利
    用すると、App側通信処理に
    影響が出る可能性
    キャッシュ汚染、スロークエ
    リが発生する可能性
    AWS Glueによるデータ抽出を考慮したDBアーキテクチャ
    

    View Slide

53. Amazon Aurora
    Instance
    (Master)
    Instance
    (Replica)
    Endpoint
    (default/writer)
    Endpoint
    (default/read only)
    App
    AWS Glue
    同じAuroraクラスター内に、
    分析用のServerless v2インスタンスを作成
    → 抽出時間帯のみ必要なコンピューティ
    ングリソースを消費＝コスト最適化
    →オンライン側への影響を回避
    Endpoint
    (custom/read only)
    インスタンスを追加すると、
    defaultのエンドポイントにも
    参加してしまうため、
    カスタムエンドポイントに寄
    せる
    Serverless v2
    (for ETL)
    AWS Glueによるデータ抽出を考慮したDBアーキテクチャ
    

    View Slide

54. Amazon Aurora
    Instance
    (Master)
    Instance
    (Replica)
    Endpoint
    (default/writer)
    Endpoint
    (default/read only)
    App
    AWS Glue
    Serverless v2
    (for ETL)
    Endpoint
    (custom/read only)
    ETL用のカスタムエンドポイントを作成
    し、Aurora Serverless v2のみ参照するよ
    うに仕向ける
    Endpoint
    (custom/for ETL)
    AWS Glueによるデータ抽出を考慮したDBアーキテクチャ
    

    View Slide

55. Amazon Aurora
    Instance
    (Master)
    Instance
    (Replica)
    Endpoint
    (default/writer)
    Endpoint
    (default/read only)
    App
    AWS Glue
    Serverless v2
    (for ETL)
    Endpoint
    (custom/read only)
    Endpoint
    (custom/for ETL)
    データ抽出
    データ抽出
    データ抽出に必要なタイミングのみ、
    秒単位でワークロードがスケール
    AWS Glueによるデータ抽出を考慮したDBアーキテクチャ
    

    View Slide

56. Amazon Aurora
    Instance
    (Master)
    Instance
    (Replica)
    Endpoint
    (default/writer)
    Endpoint
    (default/read only)
    App
    AWS Glue
    Serverless v2
    (for ETL)
    Endpoint
    (custom/read only)
    抽出処理が完了すると、
    最小のワークロードリソースに戻る
    Endpoint
    (custom/for ETL)
    AWS Glueによるデータ抽出を考慮したDBアーキテクチャ
    

    View Slide

57. Instance
    (Master)
    Instance
    (Replica)
    Endpoint
    (default/writer)
    Endpoint
    (default/read only)
    App
    AWS Glue
    Endpoint
    (custom/read only)
    Endpoint
    (custom/for ETL)
    Amazon Aurora
    Serverless v2
    (for ETL)
    実際のリソース消費の様子
    データ抽出処理のタイミング
    AWS Glueによるデータ抽出を考慮したDBアーキテクチャ
    

    View Slide

58. Amazon Aurora
    データ分析プラットフォーム
    DWH
    DWHとして何を利用するか？
    可視化
    AWS Glue
    機微情報はどのように
    処理するか？
    データ抽出時における
    オンライン業務への考慮は？
    ナッジにおけるデータ分析設計の主要な考慮ポイント
    

    View Slide

59. DWHに関するサーバーレスベースのサービス
    DWH
    Amazon Redshift
    Serverless
    Amazon
    Athena
    Amazon S3
    Google Cloud
    BigQuery
    +
    可視化
    データ分析プラットフォーム
    

    View Slide

60. 既存スキームとの親和性、分析体験、データ民主化の醸成、
    コスト最適化の観点からBigQueryを採用
    DWH
    Amazon Redshift
    Serverless
    Amazon
    Athena
    Amazon S3
    Google Cloud
    BigQuery
    +
    可視化
    データ分析プラットフォーム
    

    View Slide

61. 既存スキームとの親和性、分析体験、データ民主化の醸成、
    コスト最適化の観点からBigQueryを採用
    DWH
    Amazon Redshift
    Serverless
    Amazon
    Athena
    Amazon S3
    Google Cloud
    BigQuery
    +
    既存スキームとの親和性
    ・全社的にGoogle Workspaceを利
    用しており、元々Googleアカウント
    を所持。
    ・ダッシュボードのLooker Studio
    想定の利用含めて、Google Cloud利
    用に対する親和性がとても良い。
    ・Google sheetへのエクスポート連
    携が優れている。
    ・バッチ処理に必要なコードやリ
    ソース削減が期待できる。
    可視化
    データ分析プラットフォーム
    

    View Slide

62. 既存スキームとの親和性、分析体験、データ民主化の醸成、
    コスト最適化の観点からBigQueryを採用
    DWH
    Amazon Redshift
    Serverless
    Amazon
    Athena
    Amazon S3
    Google Cloud
    BigQuery
    +
    既存スキームとの親和性
    ・全社的にGoogle Workspaceを利
    用しており、元々Googleアカウント
    を所持。
    ・ダッシュボードのLooker Studio
    想定の利用含めて、Google Cloud利
    用に対する親和性がとても良い。
    ・Google sheetへのエクスポート連
    携が優れている。
    ・バッチ処理に必要なコードやリ
    ソース削減が期待できる。
    分析体験
    • 別SaaSからのデータエクスポー
    トも対応。
    • 別ソースデータやGoogle
    Analytics側と統合したアドホッ
    ク分析がし易くなる。
    • クエリ実行前に予測処理データ
    量がわかるので、メンバーが安
    心してクエリ投入できる。
    可視化
    データ分析プラットフォーム
    

    View Slide

63. 既存スキームとの親和性、分析体験、データ民主化の醸成、
    コスト最適化の観点からBigQueryを採用
    DWH
    Amazon Redshift
    Serverless
    Amazon
    Athena
    Amazon S3
    Google Cloud
    BigQuery
    +
    既存スキームとの親和性
    ・全社的にGoogle Workspaceを利
    用しており、元々Googleアカウント
    を所持。
    ・ダッシュボードのLooker Studio
    想定の利用含めて、Google Cloud利
    用に対する親和性がとても良い。
    ・Google sheetへのエクスポート連
    携が優れている。
    ・バッチ処理に必要なコードやリ
    ソース削減が期待できる。
    分析体験
    • 別SaaSからのデータエクスポー
    トも対応。
    • 別ソースデータやGoogle
    Analytics側と統合したアドホッ
    ク分析がし易くなる。
    • クエリ実行前に予測処理データ
    量がわかるので、メンバーが安
    心してクエリ投入できる。
    前職でBigQueryを触れており、利
    用に慣れているメンバーが在籍し
    ている。
    →スキルセットとしてすでに他の
    メンバへのサポートができる状態
    であり、データ民主化の醸成がよ
    り期待できた。
    データ民主化の醸成
    可視化
    データ分析プラットフォーム
    

    View Slide

64. 既存スキームとの親和性、分析体験、データ民主化の醸成、
    コスト最適化の観点からBigQueryを採用
    DWH
    Amazon Redshift
    Serverless
    Amazon
    Athena
    Amazon S3
    Google Cloud
    BigQuery
    +
    既存スキームとの親和性
    ・全社的にGoogle Workspaceを利
    用しており、元々Googleアカウント
    を所持。
    ・ダッシュボードのLooker Studio
    想定の利用含めて、Google Cloud利
    用に対する親和性がとても良い。
    ・Google sheetへのエクスポート連
    携が優れている。
    ・バッチ処理に必要なコードやリ
    ソース削減が期待できる。
    分析体験
    • 別SaaSからのデータエクスポー
    トも対応。
    • 別ソースデータやGoogle
    Analytics側と統合したアドホッ
    ク分析がし易くなる。
    • クエリ実行前に予測処理データ
    量がわかるので、メンバーが安
    心してクエリ投入できる。
    前職でBigQueryを触れており、利
    用に慣れているメンバーが在籍し
    ている。
    →スキルセットとしてすでに他の
    メンバへのサポートができる状態
    であり、データ民主化の促進がよ
    り期待できた。
    データ民主化の醸成 コスト最適化
    • スキャン料金が毎月1TBスキャン
    まで無料。
    • ストレージ料金はS3と大差なし。
    • データ同期に伴うネットワーク転
    送量も許容範囲だった。
    • AWSとGoogle Cloudで可視化向
    けダッシュボードの料金にも優位
    性あり。
    • Redshift Serverlessはまだ自分た
    ちのフェーズでは比較的高額。
    (※4) 検討当初、Redshift Serverlessは32RPUで時間課金されるため、試算したところ
    自分たちにはとても高額だった(仮に営業日に平均2時間使うと、64%º
    º º )= 632 USD/月となる)
    また、クエリエディタを開く度に、裏で実行されるメタデータ取得クエリも
    課金される仕様が少し辛い。
    可視化
    (※1)
    (※2)
    (※3)
    (※4)
    (※1) Athenaに関しては、処理データごとに5 USD/TB料金が発生。
    (※2) S3標準ストレージでは0.025USD/GB((最初の50TB/月)、
    BigQuery アクティブストレージは0.023 USD/GBかつ毎月10GB無料
    (※3) AWS側サービス選定と合わせてAmazon QuickSightを使うことを想定すると、
    アカウントによるコスト観点でLooker Studio側に軍配が上がる
    ・QuickSight (Enterprise Edition)：作成者 : 24 USD/⽉、閲覧者：最⼤ 5 USD/⽉
    ・Looker Studio：0USD
    データ分析プラットフォーム
    

    View Slide

65. 既存スキームとの親和性、分析体験、データ民主化の醸成、
    コスト最適化の観点からBigQueryを採用
    DWH
    Amazon Redshift
    Serverless
    Amazon
    Athena
    Amazon S3
    Google Cloud
    BigQuery
    +
    既存スキームとの親和性
    ・全社的にGoogle Workspaceを利
    用しており、元々Googleアカウント
    を所持。
    ・ダッシュボードのLooker Studio
    想定の利用含めて、Google Cloud利
    用に対する親和性がとても良い。
    ・Google sheetへのエクスポート連
    携が優れている。
    ・バッチ処理に必要なコードやリ
    ソース削減が期待できる。
    分析体験
    • 別SaaSからのデータエクスポー
    トも対応。
    • 別ソースデータやGoogle
    Analytics側と統合したアドホッ
    ク分析がし易くなる。
    • クエリ実行前に予測処理データ
    量がわかるので、メンバーが安
    心してクエリ投入できる。
    前職でBigQueryを触れており、利
    用に慣れているメンバーが在籍し
    ている。
    →スキルセットとしてすでに他の
    メンバへのサポートができる状態
    であり、データ民主化の促進がよ
    り期待できた。
    データ民主化の醸成 コスト最適化
    • スキャン料金が毎月1TBスキャン
    まで無料。
    • ストレージ料金はS3と大差なし。
    • データ同期に伴うネットワーク転
    送量も許容範囲だった。
    • AWSとGoogle Cloudで可視化向
    けダッシュボードの料金にも優位
    性あり。
    • Redshift Serverlessはまだ自分た
    ちのフェーズでは比較的高額。
    (※4) 検討当初、Redshift Serverlessは32RPUで時間課金されるため、試算したところ
    自分たちにはとても高額だった(仮に営業日に平均2時間使うと、64%º
    º º )= 632 USD/月となる)
    また、クエリエディタを開く度に、裏で実行されるメタデータ取得クエリも
    課金される仕様が少し辛い。
    可視化
    (※1)
    (※2)
    (※3)
    (※4)
    (※1) Athenaに関しては、処理データごとに5 USD/TB料金が発生。
    (※2) S3標準ストレージでは0.025USD/GB((最初の50TB/月)、
    BigQuery アクティブストレージは0.023 USD/GBかつ毎月10GB無料
    (※3) AWS側サービス選定と合わせてAmazon QuickSightを使うことを想定すると、
    アカウントによるコスト観点でLooker Studio側に軍配が上がる
    ・QuickSight (Enterprise Edition)：作成者 : 24 USD/⽉、閲覧者：最⼤ 5 USD/⽉
    ・Looker Studio：0USD
    データ分析プラットフォーム
    

    View Slide

66. 既存スキームとの親和性、分析体験、データ民主化の醸成、
    コスト最適化の観点からBigQueryを採用
    DWH
    Amazon Redshift
    Serverless
    Amazon
    Athena
    Amazon S3
    Google Cloud
    BigQuery
    +
    可視化
    データ分析プラットフォーム
    u 「他のサービスデメリットが大きい」、というよりは、ナッジとして「BigQueryを利用する効用が大きい」
    という結論
    u Google Cloud構築の足回り作業(IAMやアカウント管理、ベースラインとしてのセキュリティ対策)工数に
    投資しても、期待する分析の体験が上回ると判断
    

    View Slide

67. Amazon Aurora
    データの民主化をもとに、データドリブンな文化を根ざすためにも、
    業務DBとは別に分析用の環境を別途設ける
    データ分析プラットフォーム
    DWH
    プロダクト開発担当
    与信＆債権担当
    データサイエンティスト
    マーケティング担当
    ビジネス担当
    可視化
    AWS Glue
    

    View Slide

68. Amazon Aurora
    データの民主化をもとに、データドリブンな文化を根ざすためにも、
    業務DBとは別に分析用の環境を別途設ける
    データ分析プラットフォーム
    プロダクト開発担当
    与信＆債権担当
    データサイエンティスト
    マーケティング担当
    ビジネス担当
    DWH
    (BigQuery)
    可視化
    (Looker Studio)
    AWS Glue
    

    View Slide

69. Amazon Aurora
    データ分析プラットフォーム
    DWHとして何を利用するか？ AWS Glue
    機微情報はどのように
    処理するか？
    データ抽出時における
    オンライン業務への考慮は？
    ナッジにおけるデータ分析設計の主要な考慮ポイント
    DWH
    (BigQuery)
    可視化
    (Looker Studio)
    

    View Slide

70. スマホアプリ
    外部接続システム
    (返済機能)
    管理者Web
    マイクロサービス別
    各API
    Amazon
    API Gateway
    NLB
    API
    NLB
    API
    カード管理API
    返済系API
    申込系API
    通知系API
    外接連携API
    Amazon Aurora
    Amazon ECS
    バッチ用
    AWS Sfn
    Amazon
    API Gateway
    指定信用情報機関
    (CIC)
    会員系API
    決済系API
    管理者API
    コンテンツ用
    S3バケット
    Amazon
    CloudFront
    外部接続システム
    (eKYC機能)
    外部接続システム
    (ペイメント関連)
    外部接続システム
    (カード印刷関連)
    外部接続システム
    (金融機関)
    サービスプラットフォーム
    ナッジにおけるプラットフォームの全体像
    データ分析プラットフォーム
    各担当者
    DWH
    (BigQuery)
    可視化
    (Looker Studio)
    AWS Glue
    API
    ALB
    バッチ用S3
    バケット
    API(非同期)
    

    View Slide

71. クラウドでサーバーレスを利用する
    ＝サーバ部分に纏わるあれこれをクラウド事業者に移譲する
    寄与
    PCI DSSへの準拠
    データ分析業務
    寄与
    差別化を生まない重労働の排除
    

    View Slide

72. まとめ
    

    View Slide

73. まとめ
    • ナッジにおけるサーバーレスファーストの考え方とその背景を紹介
    • PCI DSS準拠の観点からEC2は極力避けている（絶対ではない）
    • サーバーレスのあとの技術選定は自由度を設けている
    • コンピューティング以外のサーバーレスサービスも積極的に活用
    • ただし、選定に関しては極力言語化することで、合理性は持たせる
    • 自分たちの中では、「今の時点で最適だ」少なくとも胸を張ってといえる状態にする
    

    View Slide

74. ご清聴いただき、ありがとうございました。
    

    View Slide