Google cloud day ’21

1. 新規事業「Bill One」による
Google Cloud 活用術
大西 真央
Sansan株式会社 Bill One 事業部
プロダクト開発責任者

2. 自己紹介
● 大西 真央（@mmmmao0530）
● Bill One 事業部 プロダクト開発責任者
● Sansan でのキャリア
○ Sansan 事業部
■ Web アプリケーションエンジニア
■ 関西支店立ち上げ
■ エンジニアリングマネージャー
○ 新規事業開発室
■ 新規事業のエンジニア組織立ち上げ
■ Bill One 事業立ち上げ

3. 1. Bill One とは
2. アーキテクチャ
3. 活用術
アジェンダ

4. Bill One とは
01

6. あらゆる請求書をオンラインで受け取る

7. アーキテクチャ
02

8. 使用言語
● フロントエンド：TypeScript、React
● バックエンド：Kotlin、Ktor
● データベース：PostgresSQL

9. 利用している Google Cloud サービス群
コンピューティング
- Cloud Run
- App Engine
- Cloud Functions
ストレージ・データベース
- Cloud Storage
- Cloud SQL
その他
- Cloud Tasks
- Cloud Build
- Cloud Scheduler
- Cloud Logging
- Error Reporting
- Secret Manager

10. 利用している Google Cloud サービス群
コンピューティング
- Cloud Run
- App Engine
- Cloud Functions
ストレージ・データベース
- Cloud Storage
- Cloud SQL
その他
- Cloud Tasks
- Cloud Build
- Cloud Scheduler
- Cloud Logging
- Error Reporting
- Secret Manager

11. 利用している Google Cloud サービス群
コンピューティング
- Cloud Run vs App Engine
- App Engine
- Cloud Functions
ストレージ・データベース
- Cloud Storage
- Cloud SQL
その他
- Cloud Tasks vs Pub/Sub
- Cloud Build
- Cloud Scheduler
- Cloud Logging
- Error Reporting
- Secret Manager

12. 利用している Google Cloud サービス群
コンピューティング
- Cloud Run vs App Engine
- App Engine
- Cloud Functions
ストレージ・データベース
- Cloud Storage
- Cloud SQL
その他
- Cloud Tasks
- Cloud Build
- Cloud Scheduler
- Cloud Logging
- Cloud Error Reporting
- Secret Manager
App Engine ではなく、Cloud Run を採用している理由
- 料金が安い。
- 全体的にモダンな設計になっている。
- Google Cloud 内（Cloud Run ⇔ Cloud Funtions など）での認証が標準で提供されている。
- ランタイムが自由に選べる（任意の Docker イメージを選択可能） 。

13. 利用している Google Cloud サービス群
コンピューティング
- Cloud Run
- App Engine
- Cloud Functions
ストレージ・データベース
- Cloud Storage
- Cloud SQL
その他
- Cloud Tasks vs Pub/Sub
- Cloud Build
- Cloud Scheduler
- Cloud Logging
- Cloud Error Reporting
- Secret Manager
Pub/Sub ではなく、Cloud Tasks を採用している理由
- 実運用を考えた時に、Google Cloud の画面からエラーになった
Task の情報（メッセージの中身やリトライ回数）を確認できる。

14. アーキテクチャ

15. アーキテクチャのポイント
● サーバーレスサービスを活用することで、インフラに関わる人的コストの削減できる。
○ デプロイ周りのコア部分は Google Cloud で用意済。
○ サーバー構築不要。スケールアップは容易、スケールアウトは自動。
○ 各種ログはロギングやエラーレポートに自動連携。
○ ビジネス拡大フェーズでも、インフラ周りに時間を取られずアプリ開発に注力可能。

16. アーキテクチャのポイント
ビジネスの本質に注力できる環境で開発する。

17. Proprietary + Confidential
活用術
03

18. 1. 非同期処理
2. CI / CD
3. B2B マルチテナントにおけるストレージのバケット設計
4. ログの閲覧をシンプルに
5. ログの検索を容易に

19. 1. 非同期処理
● 関連サービス
○ Cloud Tasks
○ Cloud Run
● やりたいこと
○ システムの密結合を排除したい。
● 実現時のポイント
○ ドメインイベントによる非同期メッセージングを導入。
○ ドメインイベントと関連処理を分離するために、ブローカーを導入。
○ ドメインイベントを確実に送信するために、トランザクショナルメッセージングを導入。

20. 1. 非同期処理
ドメインイベントによる非同期メッセージングを導入
● メイン処理と関連処理を同一のリクエストで処理せず、別々の
リクエストで処理。
● メイン処理が終わると、メイン処理が終わったというドメインイ
ベントを発行して、リクエストを終了。
● ドメインイベントが発行されると、関連処理のリクエストを処
理。
<ドメインイベント>
請求書を受領した
<関連処理>
受領メールを送る
<メイン処理>
請求書を受領する

21. 1. 非同期処理
ドメインイベントと関連処理を分離するために、ブローカーの
考え方を導入
● ドメインイベントは、どの関連処理が処理されるか把
握しない。
● ドメインイベントと関連処理のマッピングはブローカー
という役割が担う。
<ドメインイベント>
請求書を受領した
<関連処理>
受領メールを送る
ブローカー
関連処理を知る必要がない
ブローカーのコード例（独自実装）

22. 1. 非同期処理
ドメインイベントを確実に送信するために、トランザクショナルメッセージ
ングの考え方を導入
● Cloud Tasks への Task 登録と DB トランザクションの相性が悪
い。
● Task 登録は成功、DB トランザクションは失敗など、
どちらかだけ成功した場合を考慮すると複雑になる。
● Task に登録する内容を DB に保存して、保存された内容
から Task 登録を行うという考え方
アプリケーション
請求書受領
サービス
データベース
請求書
テーブル
insert insert
ドメインイ
ベント
テーブル
Cloud Tasks
キュー

23. アプリケーション
1. 非同期処理
請求書受領
サービス
データベース
請求書
テーブル
ドメインイ
ベント
テーブル
insert insert
Cloud Tasks
キュー ブローカー
Cloud Tasks
キュー
請求書受領
メール送付サー
ビス
https
https
1. 請求書受領サービスが請求書テーブルとドメインイベ
ントテーブルにデータを保存。
2. 保存されたドメインイベントをアプリケーションが取得
して Task を作成。
3. ブローカーがドメインイベントに紐づく Task を作成。
1
2 3
https

24. 2. CI / CD
● 関連サービス
○ Cloud Build
○ Secret Manager
○ Cloud Run etc
● やりたいこと
○ 機密データを簡易に管理しつつ、CI / CD を実施を自動化したい。
● 実現時のポイント
○ master マージ後、本番環境に自動デプロイ。B2B サービスのため、トラフィック以降は任意の
タイミングで実施。
○ DB パスワードや API キーなどの機密データを管理するために、Google Cloud の Secret Manager
を導入。

25. 本番環境
開発環境
Cloud Build
Cloud Run
Cloud SQL
Secret
Maneger
Cloud Build
1. push をトリガーに
ビルド開始
2.ビルド・テスト（テ
スト DB にアクセス）
3.master のみ
デプロイ実施
5.コンテナレジストリの
イメージをデプロイ（ト
ラフィック移行なし）
6.トラフィック移行用コ
マンドを通知
起動時に
機密データを
取得
Cloud Build
4.イメージを
push
7.エンジニアがリリー
ス（トラフィック移行）
2. CI / CD
コンテナ
レジストリ

26. 3. B2B マルチテナントにおけるストレージのバケット設計
● 関連サービス
○ Cloud Storage
● やりたいこと
○ 他テナントに間違ってアクセスしてしまうミスを可能な限り 0 にしたい。
○ 契約の解約時に委託データを全て削除したい。
● 実現時のポイント
○ テナント毎にバケットを作成。
○ バケットのユニーク性を担保するために、バケット名にドメイン名を保持。
■ バケット名の例 : [tenant-id].bill-one.com

27. B テナント
請求書登録
B テナント
契約開始
Cloud Storage
A テナント
バケット
B テナント
バケット
A テナント
契約開始 create
create
アプリケーション
請求書登録
サービス
Cloud Storage
Util クラス
B テナントのバケットにア
クセス可能とする
B テナント
解約
delete
3. B2B マルチテナントにおけるストレージのバケット設計

28. 4. ログの閲覧をシンプルに
● 関連サービス
○ Cloud Logging
○ Cloud Run
● やりたいこと
○ ログをわかりやすく表示したい
● 実現時のポイント
○ Json フォーマットでログを出力する
1 つのログ出力が複数ログエントリで表示される
1 つのログ出力が 1 つのログエントリで表示する

29. 5. ログの検索を容易に
● 関連サービス
○ Cloud Logging
○ Cloud Run
● やりたいこと
○ https リクエストや非同期処理などで異なるログエントリを横断で閲覧したい。
● 実現時のポイント
○ X-Cloud-Trace-Context ヘッダーから trace_id を取得して、 ログ出力時に trace フィールドに trace_id を出力す
る（厳密には projects/[project_id]/traces/[trace_id] のフォーマットで出力）。
○ 最初の https リクエスト処理時は、自動付与された X-Cloud-Trace-Context を利用。非同期処理する場合は、最
初の trace_id から X-Cloud-Trace-Context ヘッダー値を作成して Cloud Tasks の Task を作成する。

30. 5. ログの検索を容易に
フロントエンド A サービス B サービス Cloud Tasks
X-Cloud-Trace-Context =
xxxxxx/0;o=1
X-Cloud-Trace-Context =
xxxxxx/xyz;o=1
X-Cloud-Trace-Context =
xxxxxx/xyz;o=1
xxxxxx が trace_id になり、Cloud Logging で xxxxxx を検索すると、 リク
エスト横断でログを閲覧出来る。

31. 本日のまとめ
● アーキテクチャ
○ ビジネスの本質に注力できる環境で開発する
● 実運用を通して改善してきた活用術
○ 非同期処理
○ CI / CD
○ B2B マルチテナントにおけるストレージのバケット設計
○ ログの検索を容易に
○ ログの閲覧をシンプルに

33. セッション アンケートへのご回答を
ぜひお願いいたします。
デスクトップでご覧の場合
セッション配信ページ右側に表示されているフォー
ムよりご回答ください。
スマートフォンでご覧の場合
セッション配信ページのセッション概要の下にある
フォームよりご回答ください。

34. Thank you.