Cloud Run

• 必要な設定をサービスで集約している分、利用できるようになるまで (デプロイ)の作業工程が少ない
• 利用無料枠が存在する
• 自動コールドスタンバイ機能あり
  ※アクセスが無い場合に自動でサーバ(タスク)を停止し、スタンバイ状態となる。
  スタンバイ状態は初回のアクセスで起動およびレスポンスに時間が掛かる。
• デフォルトエンドポイントが備わっている (ロードバランサーがなくても直接のアクセスが可能)
  ※可用性や性能・拡張性、セキュリティを考慮してロードバランサーや WAF の導入は別途検討した方が良い。

 Fargate

• 各設定項目がリソースとして分かれており、細かな設定が可能
• 1台(タスク)あたりのスペックやタスク数の上限値が高い

※ ランニングコストの算出は2024/6/1時点を参考にしている。
※ グローバルIPアドレスなどのランニングコストは見積対象外としている。
※ Fargateについては最小構成で利用するために別途ロードバランサーが必要となる。(＋$22.27～ ランニングコストの上乗せが発生。)

参考

Cloud Run

https://cloud.google.com/run/pricing?hl=ja

Fargate

https://aws.amazon.com/jp/fargate/pricing/

Cloud Run

1. コンテナイメージをデプロイ ( Artifact Registry サービスにイメージ作成のビルド＆プッシュを行う)
2. サービスを作成

補足

• スペック変更を含むサービスの設定変更は、新しいリビジョンの編集とデプロイで行う必要がある。
• デフォルトで自動コールドスタンバイ設定となっている。
  常時起動にしたい場合は、最小インスタンスを1とし、 CPU ブーストを有効にしておく必要がある。

Fargate

1. コンテナイメージをデプロイ ( ECR サービスにイメージの作成＆プッシュを行う)
2. タスク定義を作成
3. クラスタを作成
4. サービスを作成

補足

• タスクを起動して利用可能になるまでの流れは以下のとおりとなる。
  
  • クラスタ作成 (サービスを載せる基盤)
  • タスク定義作成 (コンテナタスクの設定情報)
  • サービス作成 (タスクのデプロイ設定)
• サービスのタスクは、設定したタスク数分常時起動となる。
• スペック変更などの設定変更はタスク定義で変更を行い、サービスで新しいタスク定義のリビジョンをデプロイする必要がある。 (設定変更とデプロイが分かれている。)

各クラウドサービスで比較をしてみて感じた所見をまとめます。

Cloud Run

• デプロイまでの工程が少なく、機能が複雑ではないため入りやすいと感じた
• Cloud Run のほうは起動に必要な設定をサービスで集約している分、 Fargate と比べて構築工程が少なくなっている。(設定の為のリソースがサービスに集約されている。)
• 社内システムや小～中規模のような、クリティカルなサービスを展開しない場合には、以下の特徴がコスト削減に繋がり、コストパフォーマンスが良いと感じた。
  
  • 利用無料枠が存在する
  • 最小構成でロードバランサーが不要
  • 自動コールドスタンバイ機能が存在する

• ミニマム構成であればサービスにエンドポイントが付与されるため、ロードバランサー無しですぐサービスにアクセス可能。

Fargate

• 高負荷が掛かるような大規模なサービスを展開する場合には、1台あたりのサーバ(タスク)のスペックを高性能にすることができるため、より安定した機能を提供できそうだと感じた。
• タスクの設定変更とデプロイの機能が分離されており、設定変更時のデプロイ運用が少し複雑になると感じた。
• ロードバランサーや WAF を必要とするサービスを展開する場合には、 Cloud Run と比べてランニングコストが少し安くなりそうだと感じた。

いかがでしたでしょうか？

本記事を見て少しでも各クラウドでの違いや特徴を理解し、お役に立てれば光栄です。それでは！