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

■イベント
Google Cloud Next Tokyo '23
https://cloudonair.withgoogle.com/events/next-tokyo

■登壇概要
タイトル：決済事業のアーキテクチャとそれを⽀える AlloyDB
登壇者：技術本部 Bill One Engineering Unit　上司 陽平、佐橋 周作

■Bill One エンジニア 採用情報
https://media.sansan-engineering.com/billone-engineer

Transcript

1. 決済事業のアーキテクチャと それを⽀える AlloyDB
2. 上司 陽平 Site Reliability Engineer 佐橋 周作 Software Engineer
3. 1. 会社、プロダクト概要 2. クレジット決済の前提知識 3. アーキテクチャ 4. データベースの⽐較 5. Cloud SQL と AlloyDB 6. まとめ ⽬次
4. 会社、プロダクト概要
5. 会社概要 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 パラシオ、関⻄⽀店、福岡⽀店、 中部⽀店 サテライトオフィス：徳島、京都、福岡、新潟 拠 点 寺⽥ 親弘 代 表 者
6. Sansan のプロダクト 5
7. 請求書受領から、⽉次決算を加速する インボイス管理サービス「Bill One」 あらゆる請求書をオンラインで受け取り、 企業全体の請求書業務を加速する インボイス管理サービスです。
8. Bill Oneビジネスカード Bill One ビジネスカードは、これまで当社が培ってきたデータ化技術を⽣かして 法⼈カードの課題を解決し、⽉次決算を加速する法⼈カードです。
9. クレジット決済の前提知識
10. クレジット決済の前提知識 9 イシュア アクワイアラ 国際ブランド ユーザ 店舗（加盟店）
11. クレジット決済の前提知識 10 イシュア アクワイアラ 国際ブランド ユーザ 店舗（加盟店） カード発⾏ 申込み カード発⾏
12. クレジット決済の前提知識 11 イシュア アクワイアラ ユーザ 店舗（加盟店） ⽀払可否 チェック カード情報・⽀払情報 カード提⽰・⽀払い 国際ブランド
13. クレジット決済の前提知識 12 イシュア アクワイアラ ユーザ 店舗（加盟店） カード⽀払い ⽀払可否 商品提供 国際ブランド
14. クレジット決済の前提知識 13 イシュア ユーザ 店舗（加盟店） カード⽀払い アクワイアラ 国際ブランド
15. 国際ブランドとのコミュニケーションを 代替することで、⽐較的簡易にイシュアとしての機 能をサービスに組み込むことが可能。 - カード発⾏・管理 API - 決済 API etc… 国際ブランドカード発⾏プラットフォーム
16. アーキテクチャ Bill One ビジネスカードのアーキテクチャ
17. Bill One のアーキテクチャ
18. 設計時の課題 1. 頻繁な機能追加と安定性の両⽴ 2. 決済リクエストのスパイク
19. 設計時の課題 1. 頻繁な機能追加と安定性の両⽴ 2. 決済リクエストのスパイク
20. 頻繁な機能追加と安定性の両⽴ 19 可⽤性（中） 変更頻度（⾼） カード発⾏ カードロック 証憑管理 etc… 可⽤性（⾼） 変更頻度（低） 決済機能 3D セキュア
21. 頻繁な機能追加と安定性 20 Card カード発⾏ カードロック 証憑管理 etc… 決済機能 3D セキュア Payment 可⽤性要件・変更頻度でサービ スを分けた。 頻繁に変更が求められる機能を Card サービス、 24 時間 / 365 ⽇ 安定した レスポンスが求められる機能をPayment サー ビスとした。
22. 設計時の課題 1. 頻繁な機能追加と安定性の両⽴ 2. 決済リクエストのスパイク
23. 決済リクエストのスパイク JVM の関係上、Kotlin ではCloud Run のコールド スタートが遅く、スパイク時のレスポン ス遅延の懸念 Payment サービスは Go を使⽤ Cloud Run のコールドスタート時にも⽴ ち上がりが早い Go を採⽤。
24. 最終的なアーキテクチャ
25. データベースの選定 Bill One ビジネスカードにおけるデータベースの選定
26. Google Cloud のマネージドリレーショナル データベース Cloud SQL MySQL、PostgreSQL、SQL Server 向 けのフルマネージド リレーショナル データベース サービス。 より⾼い性能と可⽤性をEnterprise Plus Edition として提供。 AlloyDB 特に要求の厳しいエンタープライズ ワークロードに対応するフルマネージ ドの PostgreSQL 互換データベース サービス。 Cloud Spanner 実質無制限のスケールで⾼いパフォー マンスと可⽤性を実現するフルマネー ジドのデータベース サービス。
27. マネージド リレーショナル データベース ⽐較(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 とその新機能の使いどころ」 （編集許諾取得済み）
28. マネージド リレーショナル データベース ⽐較(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, 関数、演算⼦ 、データ型など)
29. マネージド リレーショナル データベース ⽐較(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 秒未満 だった
30. マネージド リレーショナル データベース ⽐較(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) リードレプリカ リードプールノード ノード追加により無 停⽌・無制限にス ケール
31. マネージド リレーショナル データベース ⽐較(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 ワー クロード - ⾼可⽤性が求めら れる本番環境 - リードレプリカ 台数が多い場合 - リアルタイム 分析機能(カラム ナエンジン)が必 要 - 性能の柔軟なス ケール性 - メンテナンスダ ウンタイムをゼ ロにしたい - マルチリージョ ン構成
32. 選定対象 Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner Cloud SQL Enterprise Plus Edition は設計当時 （2023 年 07 ⽉リリース）はなかった。
33. 採⽤したデータベース 32 Payment AlloyDB Cloud SQL Card
34. 主な選定のポイント 開発のスピード、品質、可⽤性を特に重視し、 それぞれのバランスを考慮して選定
35. データベースの選定 Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner 開発のスピードと品質を重視し、 Cloud Spanner を断念
36. 短⼯期で⾼い品質を担保 短⼯期での品質担保 Cloud Spanner の特性を踏まえて品質 を担保するための⼗分な時間がないと 判断した。 PostgreSQLの経験者数 既存のマイクロサービスではCloud SQL for PosrgreSQL を利⽤している。 PostgreSQL であれば経験者が多く、 品質を担保しやすかった。 既存資産の活⽤ Bill One ではドメインイベントの発⾏ などマイクロサービスに必要なコア機 能を⾃前で実装している。Cloud SQL や AlloyDB であれば既存資産を変更す ることなく活⽤可能。
37. 特性の例 スキーマ設計で特性を考慮 ホットスポットを避けるプライマリー キーの作成な ど、特性を踏まえたテーブル設計が必要。 性能の安定性 Processing Units を利⽤すると、1000 未満の⼩さい インスタンスかつワークロードの変動が⼤きい場合 にレイテンシが断続的に増える可能性がある。 ShardId LastAccess UserID … … … … … …
38. データベースの選定 Cloud SQL Enterprise Edition Cloud SQL Enterprise Plus Edition AlloyDB Cloud Spanner 決済事業としての⾼い可⽤性を重視し、 Payment サービスでは AlloyDB を採⽤
39. - 決済処理は数秒で完了する必要 がある - インスタンスのサイズ変更とメ ンテナンスによるダウンタイム が短い AlloyDB を採⽤ - Card サービスはコスト⾯も踏ま え Cloud SQL を利⽤中 ⾼い可⽤性の AlloyDB を採⽤ Payment AlloyDB Cloud SQL Card
40. - 性能問題時の対処にスケール アップを選択できる - 既存サービスでは Cloud SQL の ダウンタイムを許容できないこ とがあった - 計画的なサイズ変更時に影響を 抑えることができる ダウンタイムが短いことの利点
41. AlloyDB を実際に使ってみてどうか...
42. 6 ⽉のプレリリース以降AlloyDB 起因の問題は 1 件！！
43. Cloud SQL と AlloyDB Cloud SQL と AlloyDB の機能差分や注意点
44. Cloud SQL に慣れたユーザが AlloyDB を利⽤する際に知ってお くと良い機能差分についてご説明。 機能差分 節約機能 メンテナンス ウィンドウ パブリック IP Cloud Run との接続 ID 管理機能
45. 機能差分 節約機能 メンテナンス ウィンドウ パブリック IP Cloud Run との接続 ID 管理機能
46. 節約機能 インスタンスの停⽌ができない 開発環境とステージングで夜間と休⽇分節約の 余地がある。 「⾼可⽤性」しか選択できなかった 2023 / 09 / 22「基本」構成が GA。 それまで VM 2 台分の料⾦が必須だった 2023 / 09 / 21 に撮影した AlloyDB 作成画⾯
47. 節約機能 2023 / 09 / 21 に撮影した AlloyDB 作成画⾯ 画⾯には表⽰されるが 選択できなかった インスタンスの停⽌ができない 開発環境とステージングで夜間と休⽇分節約の 余地がある。 「⾼可⽤性」しか選択できなかった 2023 / 09 / 22「基本」構成が GA。 それまで VM 2 台分の料⾦が必須だった
48. Payment のみで AlloyDB を活⽤ - 決済処理で特に可⽤性が必要な 部分を分離していた設計が活きた - 途中で予算の変更などもあったた め仕⽅ない側⾯もあった - AlloyDB から Cloud SQL への移⾏ はたぶん世界初！！（個⼈調べ） AlloyDB から Cloud SQL へ移⾏ Card サービスはコスト削減のため に移⾏した。 AlloyDB Cloud SQL
49. ダンプしてリストアするだけじゃない - 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 …
50. ID 管理機能 節約機能 メンテナンス ウィンドウ パブリック IP Cloud Run との接続 ID 管理機能
51. 少しづつ整ってきている - 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 ¥ …
52. メンテナンス ウィンドウ 節約機能 メンテナンス ウィンドウ パブリック IP Cloud Run との接続 ID 管理機能
53. AlloyDB はメンテナンス ウィンドウがない - メンテナンス時間（当時は 10 秒未満） をユーザが少ない深夜に指定できない - 深夜でも決済は発⽣するためダウンタイ ムが⻑い⽅が決済処理への影響が⼤きい - プロダクト マネージャとも議論し、 Cloud SQL ではなくダウンタイムが短い AlloyDB を採⽤ メンテナンス ウィンドウ Down Time
54. パブリック IP 節約機能 メンテナンス ウィンドウ パブリック IP Cloud Run との接続 ID 管理機能
55. パブリック IP が利⽤できない Cloud Run コネクタ インスタンス プライベート IP Identity-Aware Proxy Compute Engine AlloyDB VPC サーバレス アクセス コネクタ Cloud Run を利⽤する場合は サーバーレス VPC アクセス が必要 DB にアクセスする ために踏み台が必要
56. サーバーレス VPC アクセス コネクタが不要 - Cloud Run から VPC ネットワークにトラ フィックを直接送信できる機能 - コネクタ インスタンスが不要となるため、 コスト削減や性能向上が期待できる - Cloud NAT が利⽤できないため Cloud Run の外向き通信でパブリック IP を固定でき ない Direct VPC Egress (Pre-GA) AlloyDB Cloud Run コネクタ インスタンス サーバレス アクセス コネクタ Direct VPC Egress
57. IAP を活⽤した安全な接続 Identity-Aware Proxy Compute Engine AlloyDB プライベート IP 踏み台を経由した SSH の ポートフォワードにより ローカル環境から データベースにアクセス IAP による IAM 認証 VPC External IP を VM に付与することなく インターネット経由で SSH が可能なので安全
58. Cloud Run との接続 節約機能 メンテナンス ウィンドウ パブリック IP Cloud Run との接続 ID 管理機能
59. Cloud SQL と同等の接続機能がない - AlloyDB Auth Proxy を Unix ソケット経由で簡単に利⽤する 仕組みがない - AlloyDB コネクタを活⽤することで IAM 認証や TLS 通信を簡単に 実現できる Cloud Run との接続 AlloyDB Cloud Run パブリック IP Cloud SQL プライベート IP プライベート IP Unix ソケット
60. AlloyDB コネクタの基本機能 IAM 認証 IAM パーミッションを使って AlloyDB インスタンスへの 接続を制御可能 暗号化通信 データベース・プロトコルとは関係な く、コネクタとサーバ側プロキシとの 間で TLS 1.3 暗号化通信を実施 証明書管理が不要 SSL 証明書の設定や配布、ファイア ウォールや送信元/宛先 IP アドレスの 管理が不要
61. 機能差分 節約機能 メンテナンス ウィンドウ パブリック IP Cloud Run との接続 ID 管理機能
62. 機能差分 インデックス アドバイザ 機能差分 [番外編]
63. AlloyDB はデータベースが処理するクエリ を分析し、推奨するインデックスをビュー で提供 インデックス アドバイザ google_db_advisor_recommended_in dexes データベースに推奨される新しいインデックスの⼀ 覧。各インデックスに必要なストレージの⾒積もり や、各インデックスが影響するクエリの数も表⽰ google_db_advisor_workload_report アドバイザーが 1 つ以上の新しいインデックスを推 奨するクエリの⼀覧。各⾏は関連するクエリに対す る推奨を要約
64. 何も表⽰されなければあなたは性能問題にうなされることはな くなるでしょう... インデックス アドバイザ If the index advisor's most recent analysis finds no recommendations, then this query returns a table with no rows.
65. まとめ
66. Sansan の Bill One ビジネスカードは、 企業のクレジットカード利⽤に関する 課題を解決する法⼈カード - 特に⾼い可⽤性が必要とされる決済処理のみ をPayment サービスとして独⽴させ、それ以 外をCard サービスにまとめることで素早い機 能追加や頻繁な変更による影響が及びづらい ようにした - Payment サービスでは⾼可⽤性を実現するた めに AlloyDB を採⽤ - AlloyDB と Cloud SQL では細かい機能差分も あるので注意が必要