ユアマイスターのサーバレスアーキテクチャ

ユアマイスターはサービス産業の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
テックブログはこちら