PaaSサービス(Heroku, Vercel)からのCloud Run移行

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

レビュー投稿日の情報になります

PharmaX株式会社 / Koichi Ozaki

チームリーダー / EM / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名

最終更新日2024/12/16投稿日2024/12/16

ツールの利用規模	ツールの利用開始時期	事業形態
10名以下	2022年7月	B to C

ツールの利用規模	10名以下
ツールの利用開始時期	2022年7月
事業形態	B to C

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャの意図・工夫

スケジュールジョブ

Cloud SchedulerからCloud Run Jobsをトリガー実行することで実現しています。導入当時(2022年)時点ではCloud Run JobsがGAしていなかったため、別の機構で実現していましたが現在はCloud Run JobsとCloud Schedulerを利用すれば簡単にスケジュールジョブ実行機構は構築可能です。 2023年にCloud Run JobsはGAとなりましたが、GA後も処理上限時間が24時間まで延長されたり、実行制御を行いやすくなるアップデートが入っており、日々使いやすくなっている印象です。

Cloud Runのデプロイ

Cloud BuildのGitHub連携機能を利用し、リリースブランチへのマージをトリガーにデプロイ実行しています。Cloud Build上でDockerイメージをビルドし、Atifact ResistoryでDockerイメージをホスティング。Cloud Build上でgcloudコマンドを実行し、Cloud Runへデプロイをしています。

導入の背景・解決したかった問題

導入背景

当時の状況

導入以前（PoC検証期、サービス立ち上げ期）はHeroku、VercelなどのPaaSサービスを利用してサーバホスティングしていました。チームに専任インフラエンジニアもまだいない状況で、アプリケーションエンジニアがインフラメンテナンスを兼務していました。

ツール導入前の課題

利用していたPaaSサービスの制約が多く、Enterprise向けプランに加入しなければ国内リージョンにデータを置けないなど、コストパフォーマンス面での課題が出てきました。フロントエンドとバックエンドで異なるPaaSサービスを利用していたため、ログ調査がしづらいなどの問題も上がっていました。

どのような状態を目指していたか

少人数チームで開発を進めたいため、インフラ運用コストは極力低くしたい
今後のサービス拡大を見越してある程度のスケーラビリティを確保したい
インフラコストパフォーマンスを最適化したい

比較検討したサービス

AWS ECS Fargate
AWS EKS
Google Cloud GKE

比較した軸

インフラ構築・運用コスト。アプリケーションエンジニアがインフラ運用を兼務する体制を継続可能なこと
コストバランスを意識したインフラ運用が実施できること。トラフィックに応じて柔軟にスケールアップ/ダウン、スケールアウト/インを実施できること
簡単にデプロイパイプラインを構築できること
IaC化ができること

選定理由

BigQuery、Firestoreなどデータ基盤を既にGoogle Cloud上に既に構築していたため、他のパブリッククラウドはあまり選択肢には入りませんでした。

ビルド/デプロイが簡便で構築コストが低かった
- コンテナイメージさへ準備すればgcloudコマンドでデプロイ可能
- Google Cloud Buildなど、Cloud Runと連携したビルドパイプラインサービスが充実しており、構築も簡便
サーバレスのコンテナサービスのため運用コストが低かった
スタートアップ向けプログラムに採択いただき、Google Cloud無料枠を数百万円規模で付与してもらえたこと

導入の成果

KubernetesやVMサービスと比べると総じて構築・運用コストは低いため、現在も複数サービスでCloud Runをフル活用しています。 TerraformによるIaC化をしていることもあり、インフラ専門外のアプリケーションエンジニアでも簡単なサービス構築・運用であれば実施できています。トラフィックに応じたスケーリングが可能なため、サービス規模に応じたサーバコストの最適化も容易です。

導入時の苦労・悩み

スケジューリングジョブ/バッチ処理など、スポットでのタスク実行する選択肢が当時は乏しく構築に苦労しました。当時はHTTPリクエストベースでCloud Runへタスク実行リクエストを飛ばす仕組みを構築して回避しましたが、現在はCloud Run Jobsを利用すればCloud Run上でのスポットタスク実行が可能になっています。

導入に向けた社内への説明

上長・チームへの説明

リプレース前の課題、リプレース前後の構成図などを元にリプレースの必要性と効果を説明しました。また、リプレースに必要なエンジニアリソースや工期見積を元にリプレース開発期間中はアプリケーション開発スピードを緩めてもらえるよう経営陣と調整しました。

活用方法

よく使う機能

Cloud SchedulerとCloud Run Jobsによるスケジューリングジョブ実行
Cloud Buildを利用したデプロイパイプライン（GithubブランチマージトリガーによるDockerコンテナビルドとCloud Runデプロイ）
Cloud MonitoringによるCloud Runメトリクスの可視化と監視アラート設定

ツールの良い点

最小インスタンス数を0にすることでトラフィックがない時間帯のコストをほぼゼロに抑えれること
サーバーレスのコンテナサービスのため、構築・運用コストが非常に低い

ツールの課題点

Cloud Run特性に合わせたスケーリング計画・設定が必要な点
- 現時点(2024年末)ではCPU使用率と最大同時リクエスト数でのオートスケーリングハンドリングとなります。スパイク型のトラフィック増には対応でやすいですが、細やかなスケーリングを実施したい場合はGoogle Cloud APIなどを活用して別途スケーリング機構を構築する必要ができます
サーバのSSH操作など、対話型でのサーバ操作ができない点
- 例：Ruby on Railsサーバの対話式Railsコンソール操作など
- 弊社はCompute Engineで構築したBastionサーバにてCloud Runと同様のコンテナ環境をビルドして回避しています

PharmaX株式会社 / Koichi Ozaki

チームリーダー / EM / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名