こんにちは。クラウド研究会に所属している しげぞう です。
私が所属しているクラウド研究会では、日々進化するクラウドサービスを実際に利用し、実際の開発現場やプロダクトとして活用していけるのか調べていく活動を行っています。
クラウド研究会についての活動はこちら
いきなりですがみなさん、コンテナは使用してますか？
コンテナイメージ(定義)をあらかじめ作成しておくことで、実行環境の構築を誰でも簡単にスピーディーに行える点がいいな〜と思っているコンテナ。
ローカル開発環境として利用したり、プロダクトのメンテツールをコンテナで稼働させたりと、弊社でもさまざまな場面で活用しています。
個人としてはAWSのコンテナマネージドサービスであるECSを利用する機会が多いのですが、研究会の活動の中でGCPが提供しているコンテナのマネージドサービスである CloudRunを触ることになり、へーっと思うことがいくつかありましたのでECSと比較したり実際にCloudRunを利用してみました。
ECSとCloudRunを比較
AWSのECS（ElasticContainerService）、GCPのCloudRunでできることに違いがあるのか、私の個人的な観点で比較してみました。
| 観点 | ECS | CloudRun |
|---|---|---|
| ベンダー | AWS | GCP |
| イメージ(定義)の管理 | ECRで管理 | Artifact Registryで管理 |
| 実行方法 | タスク/サービス | タスク(ジョブ)/サービス |
| サービスへのHTTPアクセス | IPアドレスでアクセス ※HTTPSでアクセスする場合は別途ALBが必要 |
デプロイ時に発行されたドメインでアクセス ※HTTPSでのアクセスにも標準で対応 |
| 水平スケーリング | ◯ (最小台数：1台) | ◯ (最小台数：0台) |
| ロードバランシング | △ (追加でALBの設定が必要) | ◯ |
| コストの計算方法 | コンテナのスペック(vcpu・mem)×稼働時間(h) | コンテナのスペック(vcpu・mem)×稼働時間(h) |
| 費用例 ※1vCPUx2GBメモリのコンテナタスクを1ヶ月稼働させた場合 |
$45/月 | $57/月 |
基本的なサービス仕様はほとんど差はないかな〜というところでした。ランニングコストの面でCloudRunの方が若干割高でしたが、「CloudRunやるやん」と思う点がいくつかありました。
CloudRun単体で、サービス(Webアプリケーション)へのアクセス&暗号化通信が完結する
CloudRunは、コンテナでデプロイしたWebアプリケーションに対して標準で カスタムドメインの取得 と TLSによる暗号化通信 をサポートしています。
AWSのコンテナ系サービスで同様のことを実現しようとすると、
Route53でドメイン取得して、次にALBを作成して、暗号化通信のためにACMでSSL証明書作成して、、、
とECS以外に別サービスを準備してそれぞれを連携させる必要があります。
慣れている人にとっては低いハードルですが、開発作業に多くのリソースを割きたい方にとっては非常に億劫です。
また、デフォルトでHTTPS通信に対応している点は、開発者に心のゆとりをもたらします。
一時的にホストした環境だとしても、盗聴の可能性はゼロではないので。。
デプロイしたアプリケーションの水平スケーリング（最小0台）に対応している
CloudRunは、リクエスト状況に応じて 0台 から自動的にスケールする水平スケーリングに対応しています。
CloudRunの課金形式は、 コンテナのスペック×稼働時間 のため、
アプリケーションへのアクセスがない時間帯でのリソースの無駄遣いを抑え、コストの最適化を狙うことができます。
ECSの場合、コンテナ稼働の最小台数が1台のため、常時1台は稼働させておく必要があります。
そのためCloudRunは、実行頻度の低いバッチ処理やイベントドリブン(Pub/Sub)なアプリケーションの実行環境に向いているサービスなのかなと感じました。
CloudRunを使ってみる
実際にアプリケーション(SpringBoot)をCloudRunでデプロイしてみました。
GCP環境で構築するため、CloudRun以外のGCPサービスもいくつか採用しています。
コンテナの元となるDockerイメージはDockerfileで準備します。
イメージビルドは、GCPの提供するマネージドなビルドサービスCloudBuildで行い、イメージの管理はArtifactRegistryで行います。
SpringBootアプリケーションは./app配下にソースを配備し、イメージに内包しています。
# Dockerfile
FROM gradle:jdk11-focal AS build
COPY --chown=gradle:gradle ./app /home/gradle/src
WORKDIR /home/gradle/src
RUN gradle build --no-daemon
FROM openjdk:11
RUN mkdir /app
COPY --from=build /home/gradle/src/build/libs/*.jar /app/
ENTRYPOINT ["java", "-Djava.security.egd=file:/dev/./urandom","-jar","/app/demoapp-0.0.1-SNAPSHOT.jar"]CloudBuildを利用したイメージのビルドはgcloud cliで行いますが、ビルドの条件は別ファイルに定義しておきました。
gcloud builds submit --config cloudbuild.yaml .# cloudbuild.yaml
timeout: 3600s
steps:
- name: 'gcr.io/cloud-builders/docker'
script: |
docker build -t $_DOMAIN/$_PROJECT_ID/$_IMAGE_NAME/image:latest .
automapSubstitutions: true
images:
- '$_DOMAIN/$_PROJECT_ID/$_IMAGE_NAME/image:latest'
substitutions:
#Domain name
_DOMAIN: asia-northeast1-docker.pkg.dev
#Project ID
_PROJECT_ID: {プロジェクトID}
#Image name
_IMAGE_NAME: {イメージ名}
コンテナイメージがビルドできたら、実際にCloudRunでコンテナアプリケーションを起動させてみます。
gcloud run deploy sumservice --image=asia-northeast1-docker.pkg.dev/{プロジェクトID}/{イメージ名}/image:latest --allow-unauthenticated上記コマンドでデプロイが完了すると、SpringBootアプリケーションにアクセスするためのエンドポイントURLが確認できます。
~ gcloud run deployコマンド実行中 ~
Deploying container to Cloud Run service [*****] in project [*****] region [asia-northeast1]
✓ Deploying new service... Done.
✓ Creating Revision...
✓ Routing traffic...
✓ Setting IAM Policy...
Done.
Service [*****] revision [*****-00001-2mv] has been deployed and is serving 100 percent of traffic.
Service URL: https://*****-nixrtsas3q-an.a.run.app ←これ！このURLへリクエストを投げることでSpringBootで構築したAPIにアクセスできます。
curl -s -D - -X POST -H "Content-Type:application/json" -d "{\"email\":\"testuser01@example.com\",\"password\":\"testuser01\"}" https://*****-nixrtsas3q-an.a.run.app/api/v1/auth/login最後に
今回はAWSとGCPのコンテナ実行サービスの仕様を比較してみました。
比較結果から、開発者側でインフラ管理を考えたくない、開発要員が足りてないのでお任せできるところはlaaSベンダーにお任せしたい ような場合は、GCPのCloudRunの一択になるのかなと思いました。
しかし調べていると、AWSでもAppRunnerというカスタムドメインとロードバランシングをお任せして、CloudRunと同じようなことができるサービスがあるみたいですね。参考に費用を計算してみると、同一スペック同一条件での試算が $71/月 となったので、GCP（$57/月）の方が若干お安いようです。
今回の投稿が誰かにとってNice！な記事になってくれれば、幸いです。