サーバーレスファーストで考える クレジットカードビジネスの最適化 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万円も、返済すれば即時に利用枠は復活 利用者にとって安心で便利なクレジットカード

No content

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

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

サーバーレスファーストで考える クレジットカードビジネスの最適化 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準拠

No content

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

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との連携は 利用者側の責務 ランタイムの ライフサイクル管理は 利用者側の責務

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への準拠の検討が求められる

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への準拠の検討が求められる

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

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を採用 これらのサービス選定 を主軸にシステム構築

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

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への準拠 データ分析業務 寄与 差別化を生まない重労働の排除 次は こちら

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

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

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

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

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

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

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

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

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

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

既存スキームとの親和性、分析体験、データ民主化の醸成、 コスト最適化の観点から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 データ分析プラットフォーム

既存スキームとの親和性、分析体験、データ民主化の醸成、 コスト最適化の観点から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 データ分析プラットフォーム

既存スキームとの親和性、分析体験、データ民主化の醸成、 コスト最適化の観点からBigQueryを採用 DWH Amazon Redshift Serverless Amazon Athena Amazon S3 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)

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

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

まとめ

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

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