ゼストのサーバレスアーキテクチャ

私達、ZEST は「護りたい。その想いを護る。」を Mission に、在宅医療介護業界向けスケジュール最適化ソリューションを中心とした SaaS を提供している会社です。
2024 年 3 月にプロダクトをフルリニューアルし、リニューアルを機に完全内製化するとともに、Cloud Run/Cloud Run Jobs をメインとした、Google Cloud のサーバレスアーキテクチャを全面採用しました。

メインのインフラ構成

メインとなる Web アプリケーションはマイクロサービス構成としており、Cloud Run 上で稼働しています。
各マイクロサービス間の連携は Google Cloud のマネージド・サービスである Cloud Pub/Sub と Cloud Tasks を利用して疎結合/非同期な連携を実現しています。
Cloud Pub/Sub と Cloud Tasks の使い分けとしては、メッセージ種別で使い分けており、Cloud Pub/Sub はイベントドリブンな非同期処理に利用し、Cloud Tasks は明示的なコマンドを伴う非同期処理に利用しています。
また Cloud Tasks は外部のサービスとの連携等、rate limit が必要なものにも利用しています。

バッチ実行基盤

バッチ実行基盤についても、Cloud Run Jobs を採用しています。スケジューリングされた定期的な処理については、Cloud Scheduler 等を利用し、Cloud Run Jobs を実行することで実現しています。

リニューアル以前はインスタンスをベースとしたアーキテクチャだったため、柔軟なスケーリングやコスト適正化について課題を抱えていましたが、サーバレスな Cloud Run/Cloud Run Jobs を採用することにより、スケーラビリティとコスト効率を最大化することができ、以前までの課題を解消することができました。

CI/CD

CI/CD については、CI として GitHub Actions を、CD として Cloud Build を組み合わせて利用しています。
リニューアル以前はデプロイについては、完全自動化されておらず、一部手動でのデプロイが必要で、時間と神経を使うものでしたが、現在は GitHub の PR をトリガーとして、完全に自動化された CI/CD パイプラインを構築しています。
CDとしてCloud Build を採用した理由としては、Google Cloud のサービスとの親和性が高いこと、またデータベースのマイグレーションのために Private VPC 上の AlloyDB にアクセスする必要があったためです。

モニタリング

モニタリングツールとしては、Datadog を採用しています。マイクロサービスを採用しているため、障害時やパフォーマンスの問題が発生した際には分散トレーシングが必須になります。
そのため各マイクロサービス間の分散トレーシングには、Datadog APM、フロントエンドのモニタリングには Datadog RUM を利用しています。

今後の展望や取り組み予定について

Cloud Pub/Sub については、Pull 形式ではなく、Push 形式を利用しています。当初は、Pull 形式での利用を検討していましたが、Cloud Run のスケーリングと相性が悪く、また Always on CPU も試したものの、私達のユースケースでは適切にスケーリングさせる方法が見つかりませんでした。
今年の Google Cloud Next'25 において、Cloud Run の Service、Jobs に続く、第 3 のデプロイ方式として Worker Pools が発表されました。こちらを利用することで Pull 形式でのスケーリングの問題を解決できそうなため、再度検証したいと思っています。

また Security Command Center では Cloud Run Threat Detection がプレビューとして発表されたので、こちらも GA になり次第、導入を検討したいと考えています。これにより、よりセキュアに Cloud Run を利用できるようになると期待しています。

◆執筆：株式会社ゼスト 開発本部 SRE 森本真一