こんにちは。テクノロジー戦略本部 開発三部の今井です。
私は現在、顧客対応・SFAシステム（以下、CRM）の開発に携わっています。
本記事では、CRMのアーキテクチャ設計時の課題とAlloyDBを採用した理由、実際に運用してみての所感をご紹介します。
背景
弊社ではDXの取り組みのひとつとして、さらに多様な買取・販売チャネルに対応し、買取から販売まで一気通貫してデータを管理・活用する「バイセルリユースプラットフォーム Cosmos」（以下、Cosmos）の開発を進めています。
その中で私が携わっているプロジェクトでは、インサイドセールス部門で使用するCRMを開発しています。
主力事業である出張訪問買取の最初の入口となり、将来的にはマーケティング部やセールスコンプライアンス部等顧客対応のハブとなるシステムを目指しています。
CRMプロジェクトは2023年1月にキックオフされ、2023年10月にリリースしました。
アーキテクチャ設計
2023年4月よりアーキテクチャ設計を開始しました。
その際、Tech Acceleration Program（以下、TAP）へ参加し、Googleに在籍するエンジニアの皆さんと設計やプロトタイピングをさせていただきました。
具体的にはユースケースやドメインモデルの確認から、プロジェクトを進める上での課題を解決するためのワークショップを行いました。
アーキテクチャ全体の話から、DBの選定やデータ基盤への集約方法等、様々な観点からアドバイスをいただきました。
アーキテクチャ設計時の課題
アーキテクチャ設計時には、以下のような課題がありました。
将来的に既存システムからデータを移行する必要がある
弊社では既にお客様の情報を管理するシステムを運用しています。
既存システムはCRMと同様Google Cloud Platformを利用しており、マイクロサービスアーキテクチャで構築されています。
お客様の情報は多岐にわたり、複数のドメインごとにマイクロサービスが存在し、それぞれのDBで分散して管理しています。
こういった状況と1stリリース時のスケジュールやコストを考慮し、既存システムのDBからデータを移行し、CRMを独立したシステムとして運用することは難しいと判断しました。
そのためCRMのDBへは既存システムに依存しないデータを、お客様に関する情報等依存するデータは既存システムのDBに蓄積する方針で進めました。
しかし将来的にはCRMへ乗り換えていくことから、CRMへデータを移行し独立したシステムとして運用できる必要があります。
既存システムのDBにはCloud SQL for PostgreSQL（以下、Cloud SQL）が採用されていることから、CRMのDBもPostgreSQLに互換性のあるDBを採用する方針で進めました。
業務向けの機能の互換性を担保する必要がある
弊社ではデータ基盤を運用しており、蓄積されたデータを元に、様々な業務向けの機能を提供しています。
※データ基盤の詳細はこちらをご覧ください。
既存システムでは、要件に応じてBigQueryへデータを集約したり、Redashから参照できるように構築されています。
CRMでもこういった要件を満たすため、業務向けの機能の互換性を担保する必要がありました。
DBにはAlloyDBを採用
そのような課題がある中で、DBの候補としてあがったのは以下3つでした。
- Cloud SQL
- AlloyDB for PostgreSQL（以下、AlloyDB）
- Cloud Spanner
これらの中からAlloyDBを採用しました。
主な理由としては、社内での技術スタック・人材視点やAlloyDBのパフォーマンス・高可用性の理由が挙げられます。
社内ではCloud SQLを採用しているシステムが大半であり、開発や運用に慣れているエンジニアが多くいます。
Cloud SQLとAlloyDBの利用方法に大きな差はなく、AlloyDBを採用しても開発の習熟面等を懸念する必要がなくなりました。
一方でCloud SpannerはアーキテクチャやIFが異なるため、開発の習熟面等を懸念し、採用しませんでした。
こういった背景から、PostgreSQL完全互換でパフォーマンスが向上するならCloud SQLではなくAlloyDBを採用しようという結論に至りました。
また将来的なデータ移行時に、PostgreSQLの機能をフルにサポートしているDBを採用することで、移行時のリスクを軽減できると考えました。
※「業務向けの機能の互換性を担保する必要がある」の解決策については後日記事にします。
実際に運用してみて
使い勝手はそのままに、より高性能なパフォーマンス・高可用性を享受できる
私が以前開発していたプロダクトでは、アプリケーションをデプロイするサービスにCloud Runを、DBにCloud SQLを採用していました。
またCloud RunからServerless VPC Accessを利用して、プライベートIPによる接続を行っていました。
CRMでもCloud Runを採用しており、AlloyDBへの接続プロセスがCloud SQLとほぼ同様なことから、新しい操作方法を学ぶ必要がありませんでした。
その結果、使い勝手を維持しつつ、Cloud SQLよりもダウンタイムが短いことや無停止のインスタンスサイズ変更等をサポートするAlloyDBの高性能なパフォーマンス・高可用性を享受できることは大きなメリットだと感じています。
継続的バックアップにより、データを損失するリスクを大幅に軽減できる
2023年6月に継続的バックアップ機能がGAになりました。
AlloyDBではマイクロ秒単位での履歴からクラスターを復元でき、デフォルトでは14日前まで遡ることができます。
この期間は最長35日、最短1日に設定可能です。
データ削除後の復元や災害復旧に有効で、RPOがゼロになることから、事実上「データを損失しない」状態になります。
CRMでは、お客様に関するデータを管理しているため、データ損失のリスクを大幅に軽減できることは非常に心強いです。
また2023年11月時点では、Cloud SQLでは継続的バックアップ機能がサポートされていないため、AlloyDBを採用する大きなメリットになると考えています。
cloud.google.com cloud.google.com
単一リージョンでの運用が可能になったことで、ランニングコストの最適化を図れるようになった
従来のAlloyDBでは、HA構成のみサポートされていました。
CRMでは、非本番環境でのHA構成を不要と考えていたため、ランニングコストの増加を懸念していました。
しかし2023年9月に単一リージョンでの使用がGAになり、ランニングコストの最適化を図れるようになりました。
当初CRMでもコスト面を懸念していましたが、非本番環境では単一リージョンを使用することで、ランニングコストを抑えることができました。
今後の開発で検討していること
余談にはなりますが、今後の開発で検討していることをご紹介します。
Cloud Run sidecarを利用した接続
先に申し上げた通り、CRMではCloud Runを利用しています。
現状Cloud RunからAlloyDBへは、直接接続していますが、今後はCloud Run sidecarを利用した接続を検討しています。
sidecarで起動したAlloyDB Auth Proxyを経由して、AlloyDBへ接続することで、より安全性の高い、セキュアな接続を実現できます。
Direct VPC Egressを利用した接続
AlloyDBではパブリックIPを利用した接続がサポートされていません。
そのためCloud RunからAlloyDBへ接続する際には、Serverless VPC Accessを利用する必要があります。
しかしDirect VPC Egressを利用することで、Serverless VPC Accessを利用する必要がなくなるため、これまでよりアーキテクチャがシンプルになり、コストも削減できます。
Direct VPC Egressは現在Pre-GAであり、いくつか制約がありますが、CRMの要件を満たすことができれば採用を検討したいと考えています。
最後に
AlloyDBに興味を持っているエンジニアや、アーキテクチャ設計・DBまわりの技術選定に関わるエンジニアの参考になればと思います。
BuySell Technologiesではエンジニアを募集しています。
