アプリケーション開発に注力するためのCloud Run導入(株式会社エモーションテック)

参考になった

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

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

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

株式会社エモーションテック / 岡崎知也

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

最終更新日2024/10/31投稿日2024/10/31

ツールの利用規模	ツールの利用開始時期	事業形態
11名〜50名	2022年6月	B to B

ツールの利用規模	11名〜50名
ツールの利用開始時期	2022年6月
事業形態	B to B

アーキテクチャ

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

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

同期処理

Google Cloud Load Balancing、Cloud RunでAPIサーバーを構成

バッチ処理：要件に応じて以下のような構成を選定

Cloud Pub/Sub + Cloud Run
- 1件1件の処理時間は短いが、多数のリクエストが発生する処理をできるだけ高速に行うために選定
Cloud Tasks + Cloud Workflows + Cloud Run
- 複数の処理の実行管理を効率よく実装するために選定
Cloud Run Jobs
- 実行時間が1時間を超える可能性があるものや、実行上限時間を厳密に制御したい処理のために選定

デプロイは、GitHub ActionsのWorkflowで実施します。 Cloud Runの設定ファイル(YAML形式)をアプリケーションとは異なる専用リポジトリで管理し、Kustomizeを用いてテンプレートから設定ファイルの生成をしています。

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

導入背景

2022年に新規プロダクトを立ち上げるにあたり、アプリケーションの実行基盤としてGoogle Cloud の Cloud Run を採用しました。既存プロダクトでは AWS とGoogle Cloud (一部機能) を利用していましたが、新規プロダクトでは双方の製品を比較して選定することとなりました。

ツール導入前の課題

少人数チームであったことから、インフラ構築と運用における設定項目をできるだけ少なくし、アプリケーション開発に注力できるようにすること
既存プロダクトの顧客を収容することを見越して、ある程度のスケーラビリティを確保すること
将来的にアプリケーションの実行基盤の見直しが必要になった際にできるだけ刷新がしやすいこと

比較検討したサービス

AWS ECS Fargate
AWS EKS
AWS Lambda
Google Cloud GKE
Google Cloud Functions

比較した軸

普段インフラの設計・運用を行わないメンバーでも、できるだけ容易に構築・運用できること
Rust などの言語を含むアプリケーション動作環境のカスタマイズ性
将来的な技術変更に伴うアプリケーションの移植の容易さ

選定理由

初期構築の容易さと運用時のシンプルさが、他製品と比較して優れていると考えた点
- FaaS製品と比較して、実行時間制限や利用可能言語の制約が緩く要件とも合致している点
- Kubernetes 関連製品と比較して設定やCI/CD製品等の選択肢が限られているものの、製品選定や設計における迷いが生じにくく、かつ必要な機能を満たしている点
- 台数0台からのスケールアウトが可能で、利用者が少ない場合に費用を節約しやすい点

新規プロダクトの迅速な立ち上げには Cloud Run のシンプルさが適していると判断しました。 Cloud Armor などのセキュリティ連携機能も要件に見合うものが用意されており、BigQuery をはじめとする Google Cloud 製品との連携も容易である点が決め手となりました。

導入の成果

スケールアウト/スケールイン、スペック変更、デプロイといった運用作業をより速く、簡単に行えるようになり、運用負荷を低減できたと考えます。

インフラ構築を普段行わないメンバーでも、マイクロサービスの追加構築時の環境セットアップを容易に行えるようになり、プロトタイピングを短期間で行いやすくなりました。

導入時の苦労・悩み

1. ネットワーク設定の検討

Cloud Run自体というよりも、ネットワーク設定の検討に時間を要しました。例えば、マイクロサービスによっては、アウトバウンド通信時にNAT経由が必須のものと、NATのリソース制限を避けるためにNATを通したくないもの、他のCloud Runサービス向けアウトバウンド通信をプライベートネットワーク経由にする必要があるものがありました。そのような要件を満たすため一般的なネットワークの知識に加えてGoogle Cloudのプライベートネットワーキングについての学習が必要でした。

2. バッチ処理の実装

2023年4月にCloud Run Jobs が GA する前は、バッチ処理を Cloud Run とCloud Tasksを用いて実装していました。その構成の場合、処理の最大実行時間をCloud Tasks のクライアント側のタイムアウトを意識する必要があったり、 Cloud Runがタイムアウトした後もしばらくコンテナインスタンス自体は稼働し続ける(任意のタイミングで停止される)ような挙動があり厳密な実行制御のためには工夫が必要でした。現在は Cloud Run Jobs で、24時間までの実行だったり、処理ごとの実行制御を行いやすくなったため、使い勝手がより良くなった印象です。

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

上長・チームへの説明

AWS 関連製品や Kubernetes 関連製品については、既存プロダクトでの利用経験やプロトタイピングの結果を基に、各製品のメリット・デメリットを整理して説明しました。「ツール導入前の課題」の解決を見込める旨を説明しました。

活用方法

常時稼働の商用サービスとして、API とバッチ処理に利用しています。

よく使う機能

開発環境にて0台からのスケールを有効にして、コスト低減

ツールの良い点

起動速度に満足している点
- Dockerイメージサイズ160MB程度のRust製のアプリケーションで1秒未満
- Rust 製アプリケーションで性能検証したところ、0台から突発的な高負荷アクセス（1000 RPS〜の規模）にも対応可能であることを確認
- デプロイ速度も速いためリリース作業のストレスが少ないと感じる
自動スケーリングの設定が単純明快である点
Cloud Run Jobs のリリースによりバッチ処理の開発が容易になった点

ツールの課題点

現状、メモリ使用量のような一部メトリクスの値が統計値でしか見れないため、実際の値(最大値等)を確認することが困難である点
- (メモリ使用量についてはOut of Memmoryとなった場合はエラーログが出力されるので100%使用されたことの確認は可能ではあります。)
Cloud Runのサービス間の親子関係を確認したい際に、Google Cloud Traceであれば問題が発生しないが、Span IDがCloud Runで書き換えられることで、3rd PartyのObservability製品でサービス間の親子関係が上手く表現できない事象を確認している点