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

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

新井雅也 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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を前提に記載

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

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

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におけるコンピューティングサービスと責任共有モデルサーバーレスサービス

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

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

ネットワーク設定アプリケーションカスタマーデータ 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… スタートアップにとって、継続的な運用負荷が解消されないことは死活問題 →強力システム要件やサービス制約の理由がない限り、サーバーレス以外の選択肢は合理的ではない

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

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

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

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に集約する等)ぐらいの思考の余裕を設ける技術選定に関する考え方

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

スマホアプリ外部接続システム (返済機能) 管理者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(非同期)

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

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

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

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(非同期)

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にログインしてアドホック分析を実施

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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アーキテクチャ

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

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

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

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

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

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

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 データ分析プラットフォーム

Google Cloud BigQuery + 可視化データ分析プラットフォーム u 「他のサービスデメリットが大きい」、というよりは、ナッジとして「BigQueryを利用する効用が大きい」という結論 u Google Cloud構築の足回り作業(IAMやアカウント管理、ベースラインとしてのセキュリティ対策)工数に投資しても、期待する分析の体験が上回ると判断

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

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

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

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(非同期)

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

まとめ

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

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

サーバーレスファーストで考えるクレジットカードビジネスの最適化 / Business Opti...

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

More Decks by iselegant

Other Decks in Technology

Featured

Transcript