Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

iselegant
August 31, 2023

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

iselegant

August 31, 2023
Tweet

More Decks by iselegant

Other Decks in Technology

Transcript

  1. 新井 雅也 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
  2. 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を前提に記載
  3. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目に対する方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法

    の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 ファイアウォールと適切なパラメータ設計 データの暗号化とネットワーク保護 ウィルス対策と脆弱性管理、セキュアコーディング データへのアクセス制御、アクセスの識別、物理セキュリティ セキュリティ監視、監査証跡、セキュリティテスト セキュリティポリシー ※PCIDSS v3.2.1を前提に記載 要約すると
  4. 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におけるコンピューティングサービスと責任共有モデル サーバーレスサービス
  5. 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との連携は 利用者側の責務 ランタイムの ライフサイクル管理は 利用者側の責務
  6. 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への準拠の検討が求められる
  7. 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への準拠の検討が求められる
  8. 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… スタートアップにとって、継続的な運用負荷が解消されないことは死活問題 →強力システム要件やサービス制約の理由がない限り、サーバーレス以外の選択肢は合理的ではない
  9. 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を採用 これらのサービス選定 を主軸にシステム構築
  10. AWS Lambda AWS Fargate サービス毎の利用目的と照らし合わせて、選定基準する方向性は持ちつつも、 柔軟な選定ができるように、幅を持たせている ある程度のドメイン規模(API 5本以上など)の バックエンドAPI群 例)

    モバイル向けBFF 決済ドメイン向けAPI (API約30本) イベント発火による小規模なApp処理 例) 与信後ファイルUP契機によるカード発行 カード印刷ファイル連携後の他システム連携 銀行からの返済電文受け取り後のAPI連携
  11. 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に集約する等)ぐらいの思考の余裕を設ける 技術選定に関する考え方
  12. スマホアプリ 外部接続システム (返済機能) サービスプラットフォーム 管理者Web 外部接続システム (eKYC機能) 外部接続システム (ペイメント関連) 外部接続システム

    (カード印刷関連) スマホアプリ用 フロントAPI 管理者Web用 フロントAPI 外接システム用 フロントAPI マイクロサービス別 各API 腐敗防止層 外接向けAPI カード 返済 申込 通知 指定信用情報機関 (CIC) バッチ連携 決済 会員 管理者 外部接続システム (金融機関) データ ベース ナッジにおけるサービスプラットフォームは サーバーレスを前提としたAWSサービスで構成 コンテンツ
  13. スマホアプリ 外部接続システム (返済機能) 管理者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(非同期)
  14. スマホアプリ 外部接続システム (返済機能) 管理者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(非同期)
  15. 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にログインしてアドホック分析を実施
  16. 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
  17. Google Sheets 組織規模やビジネス規模が大きくなるにつれて、 業務DBに対する直接的なアクセスは様々な課題を生む プロダクト開発担当 与信&債権担当 データサイエンティスト マーケティング担当 ユーザ離脱の傾向を押さえて、 プロダクト改善に繋げたい...

    ビジネス担当 未返済の利用者傾向を分析し、 与信モデル改善に役立てたい... GMV等のビジネスKPIを可視化し、日々のビジネスの成長を ステークホルダーと共有しつつ、次の打ち手を考えたい... クレカ新規デザインの反応を見て、 ファンへの施策を検討したい... 決済金額と返済率の相関や 与信通過時の特性との相関を分析したい... バッチ処理にて 一部データを出力
  18. プロダクト開発担当 与信&債権担当 データサイエンティスト マーケティング担当 ユーザ離脱の傾向を押さえて、 プロダクト改善に繋げたい... ビジネス担当 未返済の利用者傾向を分析し、 与信モデル改善に役立てたい... GMV等のビジネスKPIを可視化し、日々のビジネスの成長を

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

    データ抽出時における オンライン業務への考慮は? ナッジにおけるデータ分析設計の主要な考慮ポイント
  20. Amazon Aurora AWS Glueによるデータ抽出を考慮したDBアーキテクチャ Instance (Master) Instance (Replica) Endpoint (default/writer)

    Endpoint (default/read only) App AWS Glue 日次で決まった時刻に DBからデータを抽出開始
  21. Amazon Aurora Instance (Master) Instance (Replica) Endpoint (default/writer) Endpoint (default/read

    only) App AWS Glue データ抽出時にオンライン業 務と同じエンドポイントを利 用すると、App側通信処理に 影響が出る可能性 キャッシュ汚染、スロークエ リが発生する可能性 AWS Glueによるデータ抽出を考慮したDBアーキテクチャ
  22. 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アーキテクチャ
  23. 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アーキテクチャ
  24. 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アーキテクチャ
  25. 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アーキテクチャ
  26. 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アーキテクチャ
  27. Amazon Aurora データ分析プラットフォーム DWH DWHとして何を利用するか? 可視化 AWS Glue 機微情報はどのように 処理するか?

    データ抽出時における オンライン業務への考慮は? ナッジにおけるデータ分析設計の主要な考慮ポイント
  28. 既存スキームとの親和性、分析体験、データ民主化の醸成、 コスト最適化の観点からBigQueryを採用 DWH Amazon Redshift Serverless Amazon Athena Amazon S3

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

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

    Google Cloud BigQuery + 可視化 データ分析プラットフォーム u 「他のサービスデメリットが大きい」、というよりは、ナッジとして「BigQueryを利用する効用が大きい」 という結論 u Google Cloud構築の足回り作業(IAMやアカウント管理、ベースラインとしてのセキュリティ対策)工数に 投資しても、期待する分析の体験が上回ると判断
  34. スマホアプリ 外部接続システム (返済機能) 管理者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(非同期)