Google CloudとAWSのコンテナ実行環境比較

Google CloudとAWSのコンテナ実行環境比較【Google Cloud】GDG Tokyo Monthly Online Tech Talks
2024/2/22 徳田真之介

自己紹介徳田真之介 (とっく - @tokkuu) • 株式会社 Cyber Agent ◦
AI事業本部 • 好きな技術 ◦ TypeScript/Go/App Runner/Cloud Run ◦ Flutter/Firebase • 趣味など ◦ 3歳の娘のパパ ◦ ポーカー(超初心者) 2

はじめに

はじめに • AWS -> Google Cloudへの載せ替えを検討する際に整理した内容 ◦ 比較する単位の合わせ方や観点は主観で選んでます • 開発段階なので、実際運用してみた知見は含まれません
• アプリケーションエンジニア(バックエンドメイン)のみのチームで運用するという観点なので、専属のSREやプラットフォームエンジニアが居る場合は結論が異なると思います • zennの記事「Amazon ECSとApp RunnerとCloud runの比較」 https://zenn.dev/tokku5552/articles/diff-aws-google-cloud

背景 • AWSで構築していた広告配信システム(DSP)をGoogle Cloudで構築している。 • まだリリース前なので運用した所感などはないが、開発段階での気付きなどをシェア。
5 https://speakerdeck.com/tokku5552/gao-surupututodi-reitensiwoshi-xian-suruji-shu

Real Time Biddingの流れ 6 SSP  ユーザー  DSP  ①インプレッション ②リクエスト AD
• ユーザーが広告を表示しようとしていることをSSPが検知。 • SSPはDSP(複数)に対してリクエストを行う。

Real Time Biddingの流れ 7 SSP  ユーザー  広告主  キャンペーン1  キャンペーン2  キャンペーン3 
DSP  ①インプレッション ②リクエスト ③入札(内部) ¥100 ¥120 ¥90 AD AD AD AD • DSPに予め登録しておいた広告の候補を内部で精査して、いくらで入札するかを決定。(インナーオークション)

DSP  ①インプレッション ②リクエスト ③入札(内部) ④入札(外部) ¥100 ¥120 ¥90 ¥120 AD AD AD AD AD • SSPに対して入札額と広告の情報を返却

DSP  ①インプレッション ②リクエスト ③入札(内部) ④入札(外部) ⑤落札 DSP(A社)  ¥100 ¥120 ¥90 ¥120 ¥110 AD AD AD AD AD AD • 他のDSPと比べて一番高い額で落札

DSP  ①インプレッション ②リクエスト ③入札(内部) ④入札(外部) ⑥掲載 ⑤落札 DSP(A社)  ¥100 ¥120 ¥90 ¥120 ¥110 AD AD AD AD AD AD

Real Time Biddingの流れ 11 SSP  秒間数十万リクエストに対して 50ms でレスポンス
  ユーザー  広告主  キャンペーン1  キャンペーン2  キャンペーン3  DSP  ①インプレッション ②リクエスト ③入札(内部) ④入札(外部) ⑥掲載 ⑤落札 DSP(A社)  ¥100 ¥120 ¥90 ¥120 ¥110 AD AD AD AD AD AD

12 AWSでの構成

チーム体制 • プロダクト立ち上げというのもあり実際に手を動かしているエンジニアは3名 • FE・BE・SREなどのポジションはなく、全員全部やるスタイル (一応みんなBEがメイン) •
EKSやGKEなどのKubernetes サービスは除外 13 エンジニア 3名 PM・Biz

比較

Amazon ECS (on Fargate) • Amazon ECSはフルマネージドのコンテナオーケストレーションサービス • 稼働する場所（キャパシティ）をEC2か
Fargateか選べる。 • AWS Fargateはサーバーレスのコンテナ実行環境。 15

App Runner • AWSが提供するフルマネージドのコンテナアプリケーションサービス • ECSよりも管理すべき部分が少なく、GitHubのリポジトリもしくはECRなどのイメージリポジトリと接続して、CD環境が勝手に作られる。 •
カスタムドメインやHTTPSリダイレクト、Secret Manager、WAFもサポート (最近) • DSPシステムに採用できるほどではないが、 Cloud Runに近いので比較 16

Cloud Run • Google Cloudが提供するフルマネージドなコンテナ実行環境 • 対応している言語であればDockerﬁleなしでもデプロイ可能 •
コールドスタートが可能 17

18 サービス最大vCPU 最大メモリスケーリング上限 ECS on Fargate 16vCPU 120GB
5000(サービスあたりのタスク数)  App Runner 4vCPU 12GB 25  Cloud Run 8vCPU 32GB 1000(CPUやメモリによって変動)  設定できるリソースとスケーラビリティ • App RunnerはDSPというワークロードには向いていなさそう • 元のシステムでの稼働実績としてはCloud Runで賄える

19 サービス料金 1ヶ月あたりの料金目安 (1vCPU/1GBと仮定) 備考 AWS Fargate(ECS) Linux/ARM・東京リージョン vCPU当たり0.04045USD/h
メモリ1GBあたり0.00442USD/h 32.3064 USD App RunnerやCloud Runと同じ構成にするには他のリソースが必須(ALBとか) App Runner アジアパシフィック (東京) リージョン料金は 0.009 USD/GB 時および 0.081 USD/vCPU 時 64.8 USD 常時アクティブな場合の料金 Cloud Run $0.00001800 / vCPU 秒 $0.00000200 / GiB 秒 51.84 USD 無料枠あり料金による比較 • 実際の課金額はカタログスペックと逆転することもありそう

その他のポイント • App Runnerはimage uriにlatestタグを指定しておくと、latestのイメージを更新するだけで勝手にデプロイが走ってくれる • Cloud Buildの使い勝手が良い(主観)
• ECS、Cloud Runはサイドカーに対応している (App Runnerだけしてない...) 20

Cloud Runのメリット・デメリット(主観) • App RunnerとCloud Runはインフラ側の管理コストがかなり低く感じる • 管理コストに対して対応できるワークロードの幅が良い(広く対応できる)
• Cloud Build使いやすい ◦ モノレポでも使えそう。 Code Pipeline系はモノレポだと厳しかった。 21 • VPCとの接続が分かりづらい • FireLens的なの欲しいメリットデメリット

Podcastやってます！ https://podcasters.spotify.com/pod/show/5rh9uag8ah エンジニアがもがくラジオエンジニアのキャリアなどについて雑談している Podcastです Spotify/Apple Podcast/Google Podcast/Amazon Musicなど主要スタンドで配信中！

Google CloudとAWSのコンテナ実行環境比較

Google CloudとAWSのコンテナ実行環境比較

tokku5552

Transcript