Google Cloud上で構築するサーバレスアーキテクチャの設計と運用

株式会社SocialDog

私達は、「あらゆる人がSNSを活用できる世界を創る」というミッションを掲げ、国内アカウント数シェアNo.1のSNSアカウントマネジメントプラットフォームSaaS「SocialDog」を開発・運営するスタートアップ企業です。
SNS運用にまつわるさまざまな課題を解決できるSaaSとして「SocialDog」の企画・開発をしています。
創業から8年、日本国内でSNSツールとしてユーザー数シェアNo.1となった今、「対応SNSの拡大」をしつつ、「海外展開」を目指しています。

私が所属するAnalyticsチームは、主にSocialDogプロダクトのSNSアカウント・投稿の分析機能の開発を行なっています。
分析機能はCloud Run、Cloud SQL、BigQuery、Cloud Pub/Sub、Cloud Tasksなどのアーキテクチャを活用しています。

現在のインフラアーキテクチャについて

導入の背景

SocialDogでは、連携されたXアカウントのフォロー・フォロワー情報を取得し、アカウント管理機能を提供しています。
具体的には、以下のような機能があります。

• アカウントを一覧で表示する機能
• アクティブ※1ではないフォローを一覧で表示する機能
• アクティブなフォロー・フォロワーを検索する機能 ※1: 最短で直近3日以内に投稿をしている場合をアクティブと判定
  

SocialDogで扱うデータでは、フォロー・フォロワーの傾向としてフォロワー数がフォロー数を上回るという特徴がありました。 上記機能の中で最も重視されていたのが「アクティブではないフォローを一覧で表示する機能」でした。
このような背景から、導入前はフォロー・フォロワー情報の保存に関して以下の優先度で実装していました。

• フォローのアカウント情報を優先して保存
  
• フォロワーについてはSocialDogに未保存のアカウント情報のみを優先して保存
  

つまり、SocialDogに保存済みのフォロワー情報に関しては、データを取得してもデータ更新を行わない状態でした。

課題

フォロー・フォロワーのアカウント管理機能において、以下の課題がありました。

• フォロワーデータの更新不備
• Cloud SQLでデッドロック（排他制御の競合状態）が頻発
• 連携されたXアカウントのフォロー・フォロワー情報を全件保存すると1日の更新件数が2億行に達する
• 保存先のテーブルが巨大
• 外部APIの利用制限
• 外部APIの利用制限により、フォロー・フォロワーデータの保存に失敗しても再試行ができない

解決策の検討

フォロワーのデータを更新する方法について検討しました。

1. フォローデータと同様の更新方式

• フォローデータと同じように外部APIからデータ取得時に保存
• しかし、単純にUPDATE文を実行しただけだとデッドロックが頻発
• トランザクションの分離レベル調整、一括更新（Bulk UPDATE）などSQLの変更で解決できないか検討したが、保守性や影響範囲の観点から断念

2. フォロワーデータ保存をマイクロサービス化

• フォロワーデータ保存専用のマイクロサービスを実装
• 利用するクラウドサービスとして以下を比較検討しました
• Cloud Pub/Sub
• Cloud Tasks

採用したソリューション

変更前

変更後

フォロワーデータ保存は最大100ユーザー分のデータ取得が並列実行されています。
Cloud Pub/Subの場合、最大100ユーザー分の更新処理が同時にCloud SQLにアクセスしてしまいます。
そのため、Cloud RunでそのままCloud SQLに保存するのとほぼ同じになってしまい、デッドロックが起きてしまう懸念がありました。

それに対してCloud Tasksは配信先の同時実行数を制御することができるため、デッドロックが起きない程度の並列数に調整することができます。
また、デッドロックが起きてしまっても、Cloud Tasksが自動的にリトライしてくれるので、保存失敗のリスクに対応することができます。

これらの理由からCloud Tasksを使用したマイクロサービス化する方針で実装を行いました。

なお、Cloud Tasksはタスク実行順序を保証しないため、データ取得完了時点でアカウント情報が古い可能性があります。
しかし、1日以内にはデータが更新されるためアクティブ判定には問題ないと判断しました。

導入効果

導入後はフォロワーデータの全量保存が1日以内で完了し、アクティブ判定も正常に動作させることができるようになりました。
SocialDogで扱うプロフィール情報も最新のものとなり、1日2億行のフォロー・フォロワーのデータ更新も行うことができました。
毎日更新されるプロフィール情報を利用して、他のXアカウントをベンチマークする新機能もリリースすることができました。

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

SocialDogでは現在、Compute Engine上で動くPHPを使った処理からCloud Runへの移行を進めています。 バッチ処理についてもcronを利用したスケジューラー管理から、順次Cloud Run + Cloud Schedulerに移行していきたいと考えています。
Cloud Run + Cloud Schedulerに移行することで、スケジュール間隔の調整が容易になることや、デプロイ、サーバー管理の手間が省けるなど運用面でメリットがあります。
Cloud Pub/SubやCloud Tasksに関しては似たようなサービスではありますが、ユースケースが異なります。 Google Cloudのドキュメントも参考に、適したユースケースに応じて利用するサービスを検討するスキルを向上させていきたいと考えています。

◆執筆：株式会社SocialDog Analyticsチーム 中村友耶
テックブログはこちら

ユアマイスター株式会社

ユアマイスターはサービス産業のIT化プラットフォームです。「大事な人と過ごす場所」や「愛着のあるもの」を大切にする文化を創り、人々の大事なものがより大切にされる社会を目指しています。
プロダクトはプロによるハウスクリーニングや修理など80以上のサービスを依頼することができる「ユアマイスター」と、サービスを提供するパートナーさんが受注管理等をすることができる「ユアマイスターパートナー」の主に2つを開発しています。ユアマイスターのエンジニアチームでは横断的にプロダクトを開発し、一人ひとりがフロントエンドからインフラまで幅広く担当しています。

現在のインフラアーキテクチャについて

ユアマイスターでは現在、各種プロダクトを主にGoogle Cloud の Cloud Run 上で稼働させております。

AWSからの移行

以前は AWS 上で、オートスケーリング機能をもたないサーバベースのシステムを運用していましたが、この構成には当時2つの課題がありました。
1つ目はデプロイとロールバックの手間です。サーバベースの構成ではソースコードのデプロイをサーバごとに行う必要があり、手間がかかっていました。また、インスタンス構成のバージョン管理も難しく、不具合発生時に元の状態へ迅速にロールバックすることも困難でした。
2つ目はスケーラビリティの問題です。当社のプロダクトは季節変動によってトラフィックが大きく変動するため、需要に応じてリソースを自動で最適化する仕組みの導入が求められていました。

これらの課題を解消する手段として、コンテナを活用したサーバレスアーキテクチャが適切だと判断しました。そして、サーバレス関連のプロダクトが充実している Google Cloud へ、AWS 上のインフラを全面的に移行しました。

技術選定と運用のコツ

現在のアーキテクチャでは、フロントエンドとバックエンド API をそれぞれ別の Cloud Run サービスとして構築しています。VPC への接続には Direct VPC Egress または Serverless VPC Access Connector を利用し、VPC 内からは Private Service Access または Private Service Connect を介して AlloyDB、Cloud SQL、Memorystore、Elastic Cloud といった各種サービスに接続しています。

また、Google Cloud 上のインフラは Terraform によってコードで管理しています。これにより、エンジニアは誰でもインフラ構成をコードとして確認・改修・レビューできます。GUI による手動設定を無くすことで人為的なミスを防ぎ、環境毎の構成差異が発生しないようにしています。

初めてサーバレスを導入する場合、Cloud Run のオートスケーリングは強力ですが、「導入すれば自動で最適化される」とは限らない点に注意が必要です。私たちも経験しましたが、移行直後からオートスケーリングが期待通りに機能しないケースは珍しくありません。

成功の鍵は、継続的なモニタリングと地道なチューニングにあります。
まずは Cloud Monitoring などでリクエスト数や CPU 使用率を監視し、ボトルネックを1つずつ特定することが第一歩です。原因は Cloud Run だけでなく、アプリケーション内の Web サーバ設定やデータベースの接続数といった周辺コンポーネントにあることも多いため、システム全体を俯瞰して調整することが不可欠です。最適なパラメータを見つけ出すためには試行錯誤が欠かせず、数ヶ月単位の期間を見込んでおくと良いと思います。

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

ユアマイスターが目指すプロダクトアーキテクチャの理想像は、変化に柔軟であることです。
変更に伴うリスクが局所化され、機能ごとに疎結合なサービスとして分割され、それらがサーバレス環境で効率的に実行される姿が望ましいと考えます。この指針に基づき、システム全体の信頼性と開発俊敏性を向上させるため、インフラだけでなくアプリケーション機能の再構築も進めています。

たとえば、現在多くのバッチ処理で Cloud Run ジョブを利用していますが、集計などの処理とトランザクションメールの送信といった非同期処理を同じ仕組みで扱っており、非効率な状態です。今後はこれらの非同期処理を Cloud Pub/Sub や Cloud Tasks をトリガーとするイベント駆動型へ移行し、バックエンドに Cloud Run 関数を連携させることで、大幅なコスト削減と応答性の向上を見込んでいます。各機能の実行環境が独立するため、特定の機能に対する改修の影響がサービス全体に波及するリスクを抑えることができ、より高速なプロダクト開発が可能になります。

一方で、機能分割はデプロイフローの複雑化というトレードオフを伴います。この新たな課題に対し、IaC (Infrastructure as Code) による構成管理の徹底や、CI/CD パイプラインの高度化を通じてどのように対応していくかが、今後の重要な検討事項となります。

◆執筆：増井　広樹　プロダクト部プロダクトグループ
@masyus_work
テックブログはこちら

株式会社ゼスト

私達、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 森本真一
テックブログはこちら