はじめに
本記事で言及しないこと
CRM の開発・運用状況
異なるプロジェクト間のDB接続における解決策の検討と実装
- 検討した接続方式
- IAM認証によるセキュアな接続の実現
最後に

はじめに

こんにちは。テクノロジー戦略本部開発3部の今井です。
私は現在、顧客対応・SFA システム（以下、CRM）のバックエンド・インフラ領域の開発に携わっています。
本記事では、システムリプレイスを進めるうえで、アプリケーションサーバーから複数の DB に対してアクセスする際の課題感や対応方針についてご紹介します。

なお、本記事では、インフラストラクチャの課題についてのみ言及します。
既存システムと CRM それぞれで異なる ORM の挙動・仕様についてなど、具体的なアプリケーション開発の課題については、別の記事でご紹介します。

本記事で言及しないこと

システムリプレイスを進める理由や目的
システムリプレイスの具体的な内容や実施方法
アプリケーションの具体的な開発方法

CRM の開発・運用状況

バイセルでは DX の取り組みのひとつとして、さらに多様な買取・販売チャネルに対応し、買取から販売まで一気通貫してデータを管理・活用する「バイセルリユースプラットフォーム Cosmos」（以下、Cosmos）の開発を進めています。

その中で私が携わっているプロジェクトでは、インサイドセールス部門で使用する CRM を開発しています。
主力事業である出張訪問買取の最初の入口となり、将来的にはマーケティング部やセールスコンプライアンス部等顧客対応のハブとなるシステムを目指しています。

また、バイセルでは既に顧客管理システムを運用していますが、様々な課題があり、Cosmos 内の各サービスへ段階的にリプレイスしていくことが決定しています。
その中で CRM は昨年から既存システムの顧客管理ドメインを担う形で開発を進めており、今回システムリプレイスの計画を立て始めました。

異なるプロジェクト間のDB接続における解決策の検討と実装

両システムとも Google Cloud を採用していますが、別々のプロジェクトで運用されています。
具体的なアーキテクチャや技術スタックは以下の通りです。

既存システム

顧客情報、商材情報、アポイント情報など多岐にわたるデータを管理
ドメインごとに複数のマイクロサービスが存在し、それぞれの DB で分散管理

CRM

1st リリース時の方針により、完全な独立運用はせず、既存システムとの連携を前提とした設計
CRM の DB には既存システムに依存しないデータのみを格納
顧客関連情報等の依存データは、既存システムの DB に継続して蓄積

両システムの技術スタック(一部抜粋)

項目	既存システム	CRM
言語	Ruby	Go
フレームワーク	Ruby on Rails	ogen
ORM	Active Record	SQLBoiler
実行基盤	Google Kubernetes Engine	Cloud Run
DB	Cloud SQL for PostgreSQL (PostgreSQL 11)	AlloyDB for PostgreSQL (PostgreSQL 14)

具体的な計画としては、両システムを並行して開発・運用しながら、既存システムの API を徐々に CRM へ移行し、既存システムの顧客管理ドメインにあたるサービスを停止させる方針に決まりました。
「既存システムの API を CRM に移行する」とは、既存システムの API と同等の仕様になる API を CRM で実装し直すことを指しています。
その際、CRM BE から既存システムの顧客管理 DB へ直接アクセスする必要があります。

しかし、両システムで採用しているアーキテクチャや技術スタックに相違があることから、複数の課題が生じました。

検討した接続方式

前述の通り、両システムは別々の Google Cloud プロジェクトで運用されています。
そのため、CRM BE から既存システムの Google Cloud プロジェクトで構築されている顧客管理 DB へアクセスできるようにする必要がありました。

最初に現状把握を進めたところ、顧客管理 DB である Cloud SQL のプライマリーインスタンスにはパブリック IP が設定されており、プライマリーインスタンスは既存システムの顧客管理サービスからのみ参照・登録が可能、リードレプリカは認可済みネットワークからのアクセスが可能な構成でした。

既に外部からアクセスできる構成であったため、当初は CRM BE の IP アドレスを認可済みネットワークに追加することで実現できないかと他のメンバーから意見をもらいました。

しかし、CRM BE の実行基盤である Cloud Run はインターネットへアクセスする際、動的 IP アドレスプールを使用するので、単体では静的 IP アドレスを設定する事ができません。
（実現するには、Cloud Run の前段に Cloud NAT を配置する必要がある）

また、よりセキュアな接続方法を実現したいと考えていたので、この案を見送りました。

続いて、VPC ネットワークピアリングによるプライベート接続を検討しました。
しかし、CRM で作成した VPC から Cloud SQL が配置されている Google 管理下の VPC まで 2 ホップ必要となり、推移的ルーティングができないため、この案も見送りました。

参考: cloud.google.com

他には、Private Service Connect を検討しました。
しかし、Cloud SQL インスタンスを作成する段階で設定が必要であったり、プライベートサービスアクセスとの併用ができないなどの理由で見送りました。

参考: cloud.google.com

その他にもプライベートな接続方法をいくつか検討しましたが、開発・運用コストなどを考慮すると採用するには至らず、結果としてパブリックな接続方法を採用する案に決定しました。

IAM認証によるセキュアな接続の実現

セキュアな接続の実現には、認可済みネットワークの設定ではなく、IAM 認証を採用しました。
具体的な設定は以下の2つです。

IAM ロールの付与: 既存システムと CRM 両方の Google Cloud プロジェクトにおいて、CRM BE を実行している Cloud Run のサービスアカウントに Cloud SQL Client の IAM ロールを付与
Cloud SQL 接続の設定: Cloud Run の Cloud SQL connections に顧客管理 DB の Cloud SQL インスタンスを追加

補足: 内部的にCloud SQL Auth Proxyを使用しているため、両プロジェクトでCloud SQL Admin APIを有効化しています。