Tweet
Tweet

Slide 1

Slide 1 text

決済事業のアーキテクチャと それを⽀える AlloyDB

Slide 2

Slide 2 text

上司 陽平 Site Reliability Engineer 佐橋 周作 Software Engineer

Slide 3

Slide 3 text

1. 会社、プロダクト概要 2. クレジット決済の前提知識 3. アーキテクチャ 4. データベースの⽐較 5. Cloud SQL と AlloyDB 6. まとめ ⽬次

Slide 4

Slide 4 text

会社、プロダクト概要

Slide 5

Slide 5 text

会社概要 4 社 名 Sansan株式会社 所 在 地 表参道本社 東京都渋⾕区神宮前5-52-2 ⻘⼭オーバルビル13F グ ル ー プ 会 社 Sansan Global Pte. Ltd. （シンガポール） Sansan Global Development Center, Inc. （フィリピン） ログミー株式会社 株式会社ダイヤモンド企業情報編集社 クリエイティブサーベイ株式会社 株式会社⾔語理解研究所 従 業 員 数 1,421名（2023年8⽉31⽇時点） 表参道本社 神⼭ラボ Sansan Innovation Lab 2007年6⽉11⽇ 設 ⽴ ⽀店：表参道本社、Sansan パラシオ、関⻄⽀店、福岡⽀店、 中部⽀店 サテライトオフィス：徳島、京都、福岡、新潟 拠 点 寺⽥ 親弘 代 表 者

Slide 6

Slide 6 text

Sansan のプロダクト 5

Slide 7

Slide 7 text

請求書受領から、⽉次決算を加速する インボイス管理サービス「Bill One」 あらゆる請求書をオンラインで受け取り、 企業全体の請求書業務を加速する インボイス管理サービスです。

Slide 8

Slide 8 text

Bill Oneビジネスカード Bill One ビジネスカードは、これまで当社が培ってきたデータ化技術を⽣かして 法⼈カードの課題を解決し、⽉次決算を加速する法⼈カードです。

Slide 9

Slide 9 text

クレジット決済の前提知識

Slide 10

Slide 10 text

クレジット決済の前提知識 9 イシュア アクワイアラ 国際ブランド ユーザ 店舗（加盟店）

Slide 11

Slide 11 text

クレジット決済の前提知識 10 イシュア アクワイアラ 国際ブランド ユーザ 店舗（加盟店） カード発⾏ 申込み カード発⾏

Slide 12

Slide 12 text

クレジット決済の前提知識 11 イシュア アクワイアラ ユーザ 店舗（加盟店） ⽀払可否 チェック カード情報・⽀払情報 カード提⽰・⽀払い 国際ブランド

Slide 13

Slide 13 text

クレジット決済の前提知識 12 イシュア アクワイアラ ユーザ 店舗（加盟店） カード⽀払い ⽀払可否 商品提供 国際ブランド

Slide 14

Slide 14 text

クレジット決済の前提知識 13 イシュア ユーザ 店舗（加盟店） カード⽀払い アクワイアラ 国際ブランド

Slide 15

Slide 15 text

国際ブランドとのコミュニケーションを 代替することで、⽐較的簡易にイシュアとしての機 能をサービスに組み込むことが可能。 - カード発⾏・管理 API - 決済 API etc… 国際ブランドカード発⾏プラットフォーム

Slide 16

Slide 16 text

アーキテクチャ Bill One ビジネスカードのアーキテクチャ

Slide 17

Slide 17 text

Bill One のアーキテクチャ

Slide 18

Slide 18 text

設計時の課題 1. 頻繁な機能追加と安定性の両⽴ 2. 決済リクエストのスパイク

Slide 19

Slide 19 text

設計時の課題 1. 頻繁な機能追加と安定性の両⽴ 2. 決済リクエストのスパイク

Slide 20

Slide 20 text

頻繁な機能追加と安定性の両⽴ 19 可⽤性（中） 変更頻度（⾼） カード発⾏ カードロック 証憑管理 etc… 可⽤性（⾼） 変更頻度（低） 決済機能 3D セキュア

Slide 21

Slide 21 text

頻繁な機能追加と安定性 20 Card カード発⾏ カードロック 証憑管理 etc… 決済機能 3D セキュア Payment 可⽤性要件・変更頻度でサービ スを分けた。 頻繁に変更が求められる機能を Card サービス、 24 時間 / 365 ⽇ 安定した レスポンスが求められる機能をPayment サー ビスとした。

Slide 22

Slide 22 text

設計時の課題 1. 頻繁な機能追加と安定性の両⽴ 2. 決済リクエストのスパイク

Slide 23

Slide 23 text

決済リクエストのスパイク JVM の関係上、Kotlin ではCloud Run のコールド スタートが遅く、スパイク時のレスポン ス遅延の懸念 Payment サービスは Go を使⽤ Cloud Run のコールドスタート時にも⽴ ち上がりが早い Go を採⽤。

Slide 24

Slide 24 text

最終的なアーキテクチャ

Slide 25

Slide 25 text

データベースの選定 Bill One ビジネスカードにおけるデータベースの選定

Slide 26

Slide 26 text

Google Cloud のマネージドリレーショナル データベース Cloud SQL MySQL、PostgreSQL、SQL Server 向 けのフルマネージド リレーショナル データベース サービス。 より⾼い性能と可⽤性をEnterprise Plus Edition として提供。 AlloyDB 特に要求の厳しいエンタープライズ ワークロードに対応するフルマネージ ドの PostgreSQL 互換データベース サービス。 Cloud Spanner 実質無制限のスケールで⾼いパフォー マンスと可⽤性を実現するフルマネー ジドのデータベース サービス。

Slide 27

Slide 27 text

マネージド リレーショナル データベース ⽐較(2023 / 9 / 26 時点) Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner 互換性 PostgreSQL, MySQL SQL Server PostgreSQL, MySQL PostgreSQL PostgreSQL (⼀部の SQL, 関数 、演算⼦、データ型など) 可⽤性 99.95 % (HA 構成)、 メンテナンス ダウンタイム 30 秒未満 メンテナンス含めて 99.99 % (HA 構成)、メンテナンス ダウンタイ ム 10 秒未満 メンテナンス含めて 99.99 % (HA 構成)、多くのワークロードで メンテナンス ダウンタイム 1 秒 未満 最⼤ 99.999 % メンテナンス ダウンタイム なし Write 性能 ‒ 書き込みスループットが 最⼤ 2 倍 OLTP ワークロードにおいて、 4x のスループット ノード追加により無停⽌・ 無制限にスケール Read 性能 リードレプリカ スループット最⼤ 3 倍 向上 (Data Cache) リードレプリカ リードプールノード ノード追加により無停⽌・ 無制限にスケール 選定例 - ⼩規模構成 - 柔軟な CPU / Memory 構成 - 開発環境 - ⾼い性能が要求される MySQL/PostgreSQL ワークロード - ⾼可⽤性が求められる本番環境 - Cloud SQL Enterprise Edition から変更なく、より⾼い性能・ 可⽤性を実現したい - より⾼い性能が要求される PostgreSQL ワークロード - ⾼可⽤性が求められる本番環境 - リードレプリカ台数が多い場合 - リアルタイム分析機能(カラムナ エンジン)が必要 - 性能の柔軟なスケール性 - メンテナンスダウンタイム をゼロにしたい - マルチリージョン構成 出典：Google Cloud AlloyDB Case Study Meetup 「試してみませんか？AlloyDB とその新機能の使いどころ」 （編集許諾取得済み）

Slide 28

Slide 28 text

マネージド リレーショナル データベース ⽐較(2023 / 9 / 26 時点) Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner 互換性 PostgreSQL, MySQL SQL Server PostgreSQL, MySQL PostgreSQL PostgreSQL (⼀部の SQL, 関数 、演算⼦、データ型など) 可⽤性 99.95 % (HA 構成)、 メンテナンス ダウンタイム 30 秒未満 メンテナンス含めて 99.99 % (HA 構 成)、メンテナンス ダウンタイム 10 秒未満 メンテナンス含めて 99.99 % (HA 構成)、多くのワークロードで メンテナンス ダウンタイム 1 秒未 満 最⼤ 99.999 % メンテナンス ダウンタイム なし Write 性能 ‒ 書き込みスループットが 最⼤ 2 倍 OLTP ワークロードにおいて、 4x のスループット ノード追加により無停⽌・ 無制限にスケール Read 性能 リードレプリカ スループット最⼤ 3 倍 向上 (Data Cache) リードレプリカ リードプールノード ノード追加により無停⽌・ 無制限にスケール 選定例 - ⼩規模構成 - 柔軟な CPU / Memory 構成 - 開発環境 - ⾼い性能が要求される MySQL/PostgreSQL ワークロード - ⾼可⽤性が求められる本番環境 - Cloud SQL Enterprise Edition から変更なく、より⾼い性能・ 可⽤性を実現したい - より⾼い性能が要求される PostgreSQL ワークロード - ⾼可⽤性が求められる本番環境 - リードレプリカ台数が多い場合 - リアルタイム分析機能(カラムナ エンジン)が必要 - 性能の柔軟なスケール性 - メンテナンスダウンタイムを ゼロにしたい - マルチリージョン構成 Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner 互換性 PostgreSQL, MySQL SQL Server PostgreSQL, MySQL PostgreSQL PostgreSQL (⼀部の SQL, 関数、演算⼦ 、データ型など)

Slide 29

Slide 29 text

マネージド リレーショナル データベース ⽐較(2023 / 9 / 26 時点) Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner 互換性 PostgreSQL, MySQL SQL Server PostgreSQL, MySQL PostgreSQL PostgreSQL (⼀部の SQL, 関数 、演算⼦、データ型など) 可⽤性 99.95 % (HA 構成)、 メンテナンス ダウンタイム 30 秒未満 メンテナンス含めて 99.99 % (HA 構 成)、メンテナンス ダウンタイム 10 秒未満 メンテナンス含めて 99.99 % (HA 構成)、多くのワークロードで メンテナンス ダウンタイム 1 秒未 満 最⼤ 99.999 % メンテナンス ダウンタイム なし Write 性能 ‒ 書き込みスループットが 最⼤ 2 倍 OLTP ワークロードにおいて、 4x のスループット ノード追加により無停⽌・ 無制限にスケール Read 性能 リードレプリカ スループット最⼤ 3 倍 向上 (Data Cache) リードレプリカ リードプールノード ノード追加により無停⽌・ 無制限にスケール 選定例 - ⼩規模構成 - 柔軟な CPU / Memory 構成 - 開発環境 - ⾼い性能が要求される MySQL/PostgreSQL ワークロード - ⾼可⽤性が求められる本番環境 - Cloud SQL Enterprise Edition から変更なく、より⾼い性能・ 可⽤性を実現したい - より⾼い性能が要求される PostgreSQL ワークロード - ⾼可⽤性が求められる本番環境 - リードレプリカ台数が多い場合 - リアルタイム分析機能(カラムナ エンジン)が必要 - 性能の柔軟なスケール性 - メンテナンスダウンタイムを ゼロにしたい - マルチリージョン構成 Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner 可⽤性 99.95 % (HA 構成)、 メンテナンス ダウンタイム 30 秒未満 メンテナンス含めて 99.99 % (HA 構成)、メ ンテナンス ダウンタイ ム 10 秒未満 メンテナンス含めて 99.99 % (HA 構成)、 多くのワークロードで メンテナンス ダウン タイム 1 秒未満 最⼤ 99.999 % メンテナンス ダウ ンタイム なし Bill One ビジネスカード の構築当時は 10 秒未満 だった

Slide 30

Slide 30 text

マネージド リレーショナル データベース ⽐較(2023 / 9 / 26 時点) Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner 互換性 PostgreSQL, MySQL SQL Server PostgreSQL, MySQL PostgreSQL PostgreSQL (⼀部の SQL, 関数 、演算⼦、データ型など) 可⽤性 99.95 % (HA 構成)、 メンテナンス ダウンタイム 30 秒未満 メンテナンス含めて 99.99 % (HA 構 成)、メンテナンス ダウンタイム 10 秒未満 メンテナンス含めて 99.99 % (HA 構成)、多くのワークロードで メンテナンス ダウンタイム 1 秒未 満 最⼤ 99.999 % メンテナンス ダウンタイム なし Write 性能 ‒ 書き込みスループットが 最⼤ 2 倍 OLTP ワークロードにおいて、 4x のスループット ノード追加により無停⽌・ 無制限にスケール Read 性能 リードレプリカ スループット最⼤ 3 倍 向上 (Data Cache) リードレプリカ リードプールノード ノード追加により無停⽌・ 無制限にスケール 選定例 - ⼩規模構成 - 柔軟な CPU / Memory 構成 - 開発環境 - ⾼い性能が要求される MySQL/PostgreSQL ワークロード - ⾼可⽤性が求められる本番環境 - Cloud SQL Enterprise Edition から変更なく、より⾼い性能・ 可⽤性を実現したい - より⾼い性能が要求される PostgreSQL ワークロード - ⾼可⽤性が求められる本番環境 - リードレプリカ台数が多い場合 - リアルタイム分析機能(カラムナ エンジン)が必要 - 性能の柔軟なスケール性 - メンテナンスダウンタイムを ゼロにしたい - マルチリージョン構成 Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner Write 性能 – 書き込みスループット が最⼤ 2 倍 OLTP ワーク ロードにおいて、 4x のスループット ノード追加により無 停⽌・無制限にス ケール Read 性能 リードレプリカ スループット最⼤ 3 倍 向上 (Data Cache) リードレプリカ リードプールノード ノード追加により無 停⽌・無制限にス ケール

Slide 31

Slide 31 text

マネージド リレーショナル データベース ⽐較(2023 / 9 / 26 時点) Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner 互換性 PostgreSQL, MySQL SQL Server PostgreSQL, MySQL PostgreSQL PostgreSQL (⼀部の SQL, 関数 、演算⼦、データ型など) 可⽤性 99.95 % (HA 構成)、 メンテナンス ダウンタイム 30 秒未満 メンテナンス含めて 99.99 % (HA 構 成)、メンテナンス ダウンタイム 10 秒未満 メンテナンス含めて 99.99 % (HA 構成)、多くのワークロードで メンテナンス ダウンタイム 1 秒未 満 最⼤ 99.999 % メンテナンス ダウンタイム なし Write 性能 ‒ 書き込みスループットが 最⼤ 2 倍 OLTP ワークロードにおいて、 4x のスループット ノード追加により無停⽌・ 無制限にスケール Read 性能 リードレプリカ スループット最⼤ 3 倍 向上 (Data Cache) リードレプリカ リードプールノード ノード追加により無停⽌・ 無制限にスケール 選定例 - ⼩規模構成 - 柔軟な CPU / Memory 構成 - 開発環境 - ⾼い性能が要求される MySQL/PostgreSQL ワークロード - ⾼可⽤性が求められる本番環境 - Cloud SQL Enterprise Edition から変更なく、より⾼い性能・ 可⽤性を実現したい - より⾼い性能が要求される PostgreSQL ワークロード - ⾼可⽤性が求められる本番環境 - リードレプリカ台数が多い場合 - リアルタイム分析機能(カラムナ エンジン)が必要 - 性能の柔軟なスケール性 - メンテナンスダウンタイムを ゼロにしたい - マルチリージョン構成 Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner 選定例 - ⼩規模構成 - 柔軟な CPU / Memory 構成 - 開発環境 - ⾼い性能が要求さ れる MySQL/PostgreS QL ワークロード - ⾼可⽤性が求めら れる本番環境 - Cloud SQL Enterprise Edition から変更なく、よ り⾼い性能・可⽤ 性を実現したい - より⾼い性能が要 求される PostgreSQL ワー クロード - ⾼可⽤性が求めら れる本番環境 - リードレプリカ 台数が多い場合 - リアルタイム 分析機能(カラム ナエンジン)が必 要 - 性能の柔軟なス ケール性 - メンテナンスダ ウンタイムをゼ ロにしたい - マルチリージョ ン構成

Slide 32

Slide 32 text

選定対象 Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner Cloud SQL Enterprise Plus Edition は設計当時 （2023 年 07 ⽉リリース）はなかった。

Slide 33

Slide 33 text

採⽤したデータベース 32 Payment AlloyDB Cloud SQL Card

Slide 34

Slide 34 text

主な選定のポイント 開発のスピード、品質、可⽤性を特に重視し、 それぞれのバランスを考慮して選定

Slide 35

Slide 35 text

データベースの選定 Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner 開発のスピードと品質を重視し、 Cloud Spanner を断念

Slide 36

Slide 36 text

短⼯期で⾼い品質を担保 短⼯期での品質担保 Cloud Spanner の特性を踏まえて品質 を担保するための⼗分な時間がないと 判断した。 PostgreSQLの経験者数 既存のマイクロサービスではCloud SQL for PosrgreSQL を利⽤している。 PostgreSQL であれば経験者が多く、 品質を担保しやすかった。 既存資産の活⽤ Bill One ではドメインイベントの発⾏ などマイクロサービスに必要なコア機 能を⾃前で実装している。Cloud SQL や AlloyDB であれば既存資産を変更す ることなく活⽤可能。

Slide 37

Slide 37 text

特性の例 スキーマ設計で特性を考慮 ホットスポットを避けるプライマリー キーの作成な ど、特性を踏まえたテーブル設計が必要。 性能の安定性 Processing Units を利⽤すると、1000 未満の⼩さい インスタンスかつワークロードの変動が⼤きい場合 にレイテンシが断続的に増える可能性がある。 ShardId LastAccess UserID … … … … … …

Slide 38

Slide 38 text

データベースの選定 Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner 決済事業としての⾼い可⽤性を重視し、 Payment サービスでは AlloyDB を採⽤

Slide 39

Slide 39 text

- 決済処理は数秒で完了する必要 がある - インスタンスのサイズ変更とメ ンテナンスによるダウンタイム が短い AlloyDB を採⽤ - Card サービスはコスト⾯も踏ま え Cloud SQL を利⽤中 ⾼い可⽤性の AlloyDB を採⽤ Payment AlloyDB Cloud SQL Card

Slide 40

Slide 40 text

- 性能問題時の対処にスケール アップを選択できる - 既存サービスでは Cloud SQL の ダウンタイムを許容できないこ とがあった - 計画的なサイズ変更時に影響を 抑えることができる ダウンタイムが短いことの利点

Slide 41

Slide 41 text

AlloyDB を実際に使ってみてどうか...

Slide 42

Slide 42 text

6 ⽉のプレリリース以降AlloyDB 起因の問題は 1 件！！

Slide 43

Slide 43 text

Cloud SQL と AlloyDB Cloud SQL と AlloyDB の機能差分や注意点

Slide 44

Slide 44 text

Cloud SQL に慣れたユーザが AlloyDB を利⽤する際に知ってお くと良い機能差分についてご説明。 機能差分 節約機能 メンテナンス ウィンドウ パブリック IP Cloud Run との接続 ID 管理機能

Slide 45

Slide 45 text

機能差分 節約機能 メンテナンス ウィンドウ パブリック IP Cloud Run との接続 ID 管理機能

Slide 46

Slide 46 text

節約機能 インスタンスの停⽌ができない 開発環境とステージングで夜間と休⽇分節約の 余地がある。 「⾼可⽤性」しか選択できなかった 2023 / 09 / 22「基本」構成が GA。 それまで VM 2 台分の料⾦が必須だった 2023 / 09 / 21 に撮影した AlloyDB 作成画⾯

Slide 47

Slide 47 text

節約機能 2023 / 09 / 21 に撮影した AlloyDB 作成画⾯ 画⾯には表⽰されるが 選択できなかった インスタンスの停⽌ができない 開発環境とステージングで夜間と休⽇分節約の 余地がある。 「⾼可⽤性」しか選択できなかった 2023 / 09 / 22「基本」構成が GA。 それまで VM 2 台分の料⾦が必須だった

Slide 48

Slide 48 text

Payment のみで AlloyDB を活⽤ - 決済処理で特に可⽤性が必要な 部分を分離していた設計が活きた - 途中で予算の変更などもあったた め仕⽅ない側⾯もあった - AlloyDB から Cloud SQL への移⾏ はたぶん世界初！！（個⼈調べ） AlloyDB から Cloud SQL へ移⾏ Card サービスはコスト削減のため に移⾏した。 AlloyDB Cloud SQL

Slide 49

Slide 49 text

ダンプしてリストアするだけじゃない - Database Migration Service は AlloyDB > Cloud SQL をサポートしていない - pg_dumpall では AlloyDB の管理⽤ユー ザ（ロール）などもダンプされてしまう - 最終的には以下の⽅法で移⾏した > 移⾏先で必要なユーザを再度構築 > マイグレーションを実施 > pg_dump の --data-only オプションを 活⽤し、必要なデータのみを移⾏ AlloyDB から Cloud SQL へ移⾏ AlloyDB Cloud SQL ユ ー ザ ー 作 成 ユーザ作成 Migration 整形済みデータ Database Migration Service $ pg_dumpall … $ pg_dump --data-only …

Slide 50

Slide 50 text

ID 管理機能 節約機能 メンテナンス ウィンドウ パブリック IP Cloud Run との接続 ID 管理機能

Slide 51

Slide 51 text

少しづつ整ってきている - AlloyDB API による ID 管理は可能 > Terraform では未対応 > Cloud SQL では ID 管理や権限付与を Terraform で管理している - 接続時の IAM 認証機能は Pre-GA ID 管理機能 # Create a database user $ gcloud alloydb users create USERNAME ¥ --password=PASSWORD ¥ … # Grant roles to a database user gcloud alloydb users set-roles USERNAME ¥ --db-roles=ROLES ¥ …

Slide 52

Slide 52 text

メンテナンス ウィンドウ 節約機能 メンテナンス ウィンドウ パブリック IP Cloud Run との接続 ID 管理機能

Slide 53

Slide 53 text

AlloyDB はメンテナンス ウィンドウがない - メンテナンス時間（当時は 10 秒未満） をユーザが少ない深夜に指定できない - 深夜でも決済は発⽣するためダウンタイ ムが⻑い⽅が決済処理への影響が⼤きい - プロダクト マネージャとも議論し、 Cloud SQL ではなくダウンタイムが短い AlloyDB を採⽤ メンテナンス ウィンドウ Down Time

Slide 54

Slide 54 text

パブリック IP 節約機能 メンテナンス ウィンドウ パブリック IP Cloud Run との接続 ID 管理機能

Slide 55

Slide 55 text

パブリック IP が利⽤できない Cloud Run コネクタ インスタンス プライベート IP Identity-Aware Proxy Compute Engine AlloyDB VPC サーバレス アクセス コネクタ Cloud Run を利⽤する場合は サーバーレス VPC アクセス が必要 DB にアクセスする ために踏み台が必要

Slide 56

Slide 56 text

サーバーレス VPC アクセス コネクタが不要 - Cloud Run から VPC ネットワークにトラ フィックを直接送信できる機能 - コネクタ インスタンスが不要となるため、 コスト削減や性能向上が期待できる - Cloud NAT が利⽤できないため Cloud Run の外向き通信でパブリック IP を固定でき ない Direct VPC Egress (Pre-GA) AlloyDB Cloud Run コネクタ インスタンス サーバレス アクセス コネクタ Direct VPC Egress

Slide 57

Slide 57 text

IAP を活⽤した安全な接続 Identity-Aware Proxy Compute Engine AlloyDB プライベート IP 踏み台を経由した SSH の ポートフォワードにより ローカル環境から データベースにアクセス IAP による IAM 認証 VPC External IP を VM に付与することなく インターネット経由で SSH が可能なので安全

Slide 58

Slide 58 text

Cloud Run との接続 節約機能 メンテナンス ウィンドウ パブリック IP Cloud Run との接続 ID 管理機能

Slide 59

Slide 59 text

Cloud SQL と同等の接続機能がない - AlloyDB Auth Proxy を Unix ソケット経由で簡単に利⽤する 仕組みがない - AlloyDB コネクタを活⽤することで IAM 認証や TLS 通信を簡単に 実現できる Cloud Run との接続 AlloyDB Cloud Run パブリック IP Cloud SQL プライベート IP プライベート IP Unix ソケット

Slide 60

Slide 60 text

AlloyDB コネクタの基本機能 IAM 認証 IAM パーミッションを使って AlloyDB インスタンスへの 接続を制御可能 暗号化通信 データベース・プロトコルとは関係な く、コネクタとサーバ側プロキシとの 間で TLS 1.3 暗号化通信を実施 証明書管理が不要 SSL 証明書の設定や配布、ファイア ウォールや送信元/宛先 IP アドレスの 管理が不要

Slide 61

Slide 61 text

機能差分 節約機能 メンテナンス ウィンドウ パブリック IP Cloud Run との接続 ID 管理機能

Slide 62

Slide 62 text

機能差分 インデックス アドバイザ 機能差分 [番外編]

Slide 63

Slide 63 text

AlloyDB はデータベースが処理するクエリ を分析し、推奨するインデックスをビュー で提供 インデックス アドバイザ google_db_advisor_recommended_in dexes データベースに推奨される新しいインデックスの⼀ 覧。各インデックスに必要なストレージの⾒積もり や、各インデックスが影響するクエリの数も表⽰ google_db_advisor_workload_report アドバイザーが 1 つ以上の新しいインデックスを推 奨するクエリの⼀覧。各⾏は関連するクエリに対す る推奨を要約

Slide 64

Slide 64 text

何も表⽰されなければあなたは性能問題にうなされることはな くなるでしょう... インデックス アドバイザ If the index advisor's most recent analysis finds no recommendations, then this query returns a table with no rows.

Slide 65

Slide 65 text

まとめ

Slide 66

Slide 66 text

Sansan の Bill One ビジネスカードは、 企業のクレジットカード利⽤に関する 課題を解決する法⼈カード - 特に⾼い可⽤性が必要とされる決済処理のみ をPayment サービスとして独⽴させ、それ以 外をCard サービスにまとめることで素早い機 能追加や頻繁な変更による影響が及びづらい ようにした - Payment サービスでは⾼可⽤性を実現するた めに AlloyDB を採⽤ - AlloyDB と Cloud SQL では細かい機能差分も あるので注意が必要

Slide 67

Slide 67 text

No content