🐧
Cloud Run で Web アプリケーションをデプロイしてみた

2024/09/24に公開
Cloud Run
Google Cloud
初心者
tech
 はじめにこんにちは、新卒 1 年目の SRE 部に所属している家野です。
最近は猛暑が続いていますね。今夏は、全然蚊に刺されないなと思い調べたところ、35 度以上だと蚊も活動できないことを知りました。人間もそうですが、蚊にとっても生きづらい世の中になったのだなと思いました。
今回は、簡単に Cloud Run とはどんなプロダクトなのか説明し、最終的には Cloud Run を用いた Web アプリケーションのデプロイの方法を紹介します。
私自身も新卒研修で Cloud Run について知る機会があり、概要を調べた時、「コンテナって何だろう？ サーバーレス？ マネージドなインスタンス？」などの横文字ばかりで正直戸惑ったのを覚えています。
本記事では、そんな専門用語の疑問を解消し、Cloud Run の魅力を感じていただけるように、以下の 2 つのポイントに焦点を当てて紹介します。
Cloud Run はどのようなプロダクトなのか
Cloud Run で簡単な Web アプリケーションをデプロイする方法

 対象読者Google Cloud 初学者の方
Web アプリケーションを簡単にデプロイしたい方
サーバーレスに興味のある方

 Cloud Run の概要
 Cloud Run とはCloud Run とは、Google Cloud が提供するサーバーレスなコンテナ実行環境です。

とはいえ、上記のような説明だとイメージしづらいと思うので言い換えると、私たちが作成したアプリケーションを、簡単にインターネット上に公開して、誰でもアクセスできるようにしてくれるサービスです。

コンテナ

コンテナとは、アプリケーションを動かすのに必要なプログラムや設定ファイル、ライブラリなどの必要なもの全てを箱（コンテナ）にパッケージ化し、異なる OS やクラウド環境でも同じように作成したアプリケーションを実行できる技術です。
サーバーレス

サーバーレスとは、開発者がサーバーの存在を意識せずにアプリケーションを開発できる環境のことです。
通常のサーバーでは、OS やソフトウェアの導入や各種システムの設定などのサーバーの準備（プロビジョニング）や利用者に応じたリソースの増減（スケーリング）、メンテナンスなど様々な管理が必要です。しかし、サーバーレスでは、これらのサーバーの管理が不要になります。
要するに、クラウドプロバイダである Google Cloud がサーバーの管理してくれるため、開発者はアプリケーション開発に集中できます。
つまり、Cloud Run を使うと、コンテナ技術のおかげで Web アプリケーションを簡単にデプロイでき、さらにサーバーレスのおかげで開発者は開発だけに集中できます。
https://cloud.google.com/run/docs/overview/what-is-cloud-run?hl=ja

 Cloud Run の主な機能自動スケーリング

スケーリングとは、負荷状況に応じて、動的にCPUやメモリーといったリソース量やサーバーの数を増減する技術のことです。

Cloud Run における自動スケーリングは、主にコンテナインスタンスの数を増減することで、負荷状況に合わせてシステムのパフォーマンスを最適化します。
従量課金制

従量課金制とは、Cloud Run を利用した分だけの料金を支払うイメージです。

また Cloud Run には、2 つの料金モデルがあります。
リクエストベース: リクエストごとの料金が発生します。つまりユーザーからのアクセスが無い間は料金が発生しません。

使用例: アクセス数が少ないアプリや、たまにしか使わないアプリの場合
インスタンスベース: コンテナインスタンスが起動している間、常に料金が発生します。リクエストの有無に関わらず費用が発生します。

使用例: 起動に時間がかかるアプリや、常にアクセスがあり、起動しておきたいアプリの場合
上記の使用例のように用途にあった料金モデルを選ぶことができます。
HTTPS エンドポイント

作成したアプリケーションを Cloud Run でデプロイすると、自動的に HTTPS という安全な通信方法が使われます。HTTPS とは、ネット上のやり取りを誰にも覗かれないようにしてくれる機能です。要するに Cloud Run を用いれば、安全に Web サービスを自動的にインターネット上に公開できます。
トラフィック分割

トラフィック分割とは、アプリケーションへのトラフィックを複数のバージョンに振り分ける機能です。

例えば、インスタンス A とインスタンス B に、それぞれ 50 % ずつ指定した場合、以下の画像のようにトラフィックは半々に分散されます。




このトラフィック分割の機能を利用することで、カナリアリリースというリリース戦略に役に立ちます。
カナリアリリースとは、新しいバージョンのアプリケーションをリリースする際に、一部のユーザーだけ新しいバージョンに誘導し、問題がないか確認しながら徐々に古いバージョンから新しいバージョンへ切り替えていく手法です。
Cloud Run サービスについて

自動スケーリングについて

従量課金制について

トラフィック分割について

カナリアリリースについて

 Cloud Run のメリット
高可用性
自動スケーリング機能により、アクセス数に応じて自動でコンテナ数を調整するため、急なアクセス増加にも対応可能
サーバーレスのため、アプリケーションを動かすための土台（インフラストラクチャ）の運用や管理の手間を削減可能


高いコストパフォーマンス
従量課金制のため、使用した分だけの支払いで済む
2つの料金モデル(リクエスト数もしくはインスタンス数ベース)から、用途にあったモデルを選ぶことでコストの削減
アイドル状態のコンテナには課金されないため、開発環境や利用頻度の低いアプリケーションに最適


柔軟で信頼性の高い環境
アプリケーション公開時に自動で HTTPS が適用されるため、安全な通信を実現可能
トラフィック分割の機能を利用することにより、新しいバージョンの段階的な移行や問題が発見された場合に即座に以前のバージョンへ移行が可能。
また、A/B テスト（新旧 ２ つのバージョンを比較するテスト手法）のように、新機能実装前に beta 版として一部のユーザーにテスターになってもらうことが可能



素早い開発と簡単なデプロイ
さまざまなプログラミング言語やフレームワークに対応しているため開発環境を変更する必要はない
Docker イメージを使用しアプリケーションを簡単にデプロイ可能
Buildpacks を用いれば、アプリケーションのコードから自動的にコンテナを構築してくれるため、Docker の知識が浅い初学者でも簡単に Cloud Run に Web アプリケーションをデプロイ可能

Cloud Run とは

buildpacks を使用したコンテナ化について

buildpacks を使用してビルド

Dockerfile を使用してビルド

 Cloud Run で簡単な Web アプリケーションのデプロイCloud Run を利用して「Hello, World!」を表示する簡単な Web アプリケーションをデプロイします。
Cloud Run のデプロイの流れは次のようなステップを踏みます。
コンテナイメージのビルド
コンテナレジストリ（Artifact Registry）へのコンテナの送信
送信されたコンテナを参照した Cloud Run インスタンスの生成
このうち、Buildpacks を使用することで、コンテナイメージのビルドが簡単になります。
Buildpacks とは、アプリケーションコードから自動的にコンテナを構築するツールで、Dockerfile に関する知識が少なくても利用できます。
!今回は、Python の Web アプリケーションフレームワークである Flask を使用したサンプルアプリをデプロイします。

本記事では、Cloud Run の体験を優先するため、Flask について詳しく知りたい方は、公式ドキュメント を参照してください。

 前提条件（準備）始める前に、以下のものが揃っていることを確認してください。
Google Cloud プロジェクト
gcloud CLI のインストール
お好きなテキストエディタ（ここでは例として VS Code を使用します。）
Python のインストール

 プロジェクトディレクトリの作成ターミナル（またはコマンドプロンプト）で、以下のコマンドを実行して、hello というディレクトリを作成します。
mkdir hello
作成したディレクトリに移動します。
cd hello

 アプリケーションコードの作成hello ディレクトリ内に main.py という名前のファイルを作成して、以下のコードを記述します。

main.py
from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello():
    return 'Hello, World!'

if __name__ == '__main__':
    app.run()
同様に、hello ディレクトリ内に requirements.txt という名前のファイルを作成して、以下のコードを記述します。
requirements.txt
flask
このファイルは、プロジェクトで必要なライブラリをリスト化したファイルです。

Cloud Run はデプロイ時に requirements.txt を参照し、そこに書かれたライブラリをインストールするため、このファイルがないとアプリケーションが動作するための必要なライブラリをインストールできず、結果として動作しなくなります。

 Artifact Registry リポジトリの作成Buildpacks で作成されるコンテナイメージを保存する場所を作成します。
Google Cloud コンソールで [Artifact Registry] に移動します。
Artifact Registry の API を有効にします。


Artifact Registry の画面に移動したら、[リポジトリを作成] をクリックします。
[リポジトリの作成] ページで、[名前]、 [リージョン] を以下のように設定します。

[リージョン] は、Cloud Run をデプロイするリージョンと同じ場所を選びます。

（例: asia-northeast1）。


!作成にあたり、多くの設定項目がありますが、手順に記載されていない項目はすべて初期設定のままで進めます。
必要な項目の設定ができましたら、[作成] をクリックし、リポジトリを作成します。

 コンテナイメージのビルドとアップロードプロジェクトの設定

gcloud CLI で使用するプロジェクトを設定します。

これにより、以降のコマンドがどのプロジェクトに対して実行されるかを指定します。

以下のコマンドをローカルのターミナルで実行します。
gcloud config set project YOUR_PROJECT_ID
!プロジェクトの設定のコマンドを実行した際に、以下のような警告メッセージが表示された場合は、注意が必要です。

この問題は、複数の Google Cloud プロジェクトを使い分けている人に起こりやすいです。
WARNING: Your active project does not match the quota project in your local Application Default Credentials file. This might result in unexpected quota issues.
Application Default Credentials（ADC）との不一致を回避するために、割り当てプロジェクトを自分が操作するプロジェクト ID に設定します。
gcloud auth application-default set-quota-project YOUR_PROJECT_ID
このコマンドを実行することで、ADC に設定されている割り当てプロジェクトを現在のローカル環境で作業しているプロジェクトに一致させることができます。これにより、設定不一致による問題を回避できます。

詳しくは、Google Cloud 公式ドキュメントまたは下記の記事を参照してください

https://zenn.dev/cloud_ace/articles/f46fb1868249d7
サービスアカウントに IAM 権限の追加
!今回は、Cloud Run を体験することを優先するため、サービスアカウントは、デフォルトサービスアカウントを使用します。

サービスアカウントについての詳しくは、Google Cloud 公式ドキュメントを参照してください
[IAM]のページに移動して、デフォルトサービスアカウントに「Storage オブジェクト閲覧者」の権限を付与します。

コンテナイメージのビルドとアップロード

main.py があるディレクトリ（hello）で、Buildpacks を用いて自動的にコンテナイメージを構築し、作成した Artifact Registry にアップロードします。

gcloud builds submit コマンドは、Cloud Build を操作するコマンドです。Cloud Build は、Buildpacks を利用して、Dockerfile が存在しないアプリケーションのコードのあるディレクトリから、自動的に Dockerfile を生成し、コンテナイメージを構築します。

以下のコマンドを実行します。
gcloud builds submit --pack image=YOUR_REGION-docker.pkg.dev/YOUR_PROJECT_ID/hello-repo/hello
YOUR_REGION を、Artifact Registry のリポジトリ作成の時に設定したリージョンに置き換えてください。
YOUR_PROJECT_ID をあなたのプロジェクト ID に置き換えてください。
パスの末尾（/hello）は、アップロードするコンテナイメージの名前を表しています。 この名前で Artifact Registry に保存されます。
!実行する時に、Cloud Build の API を有効化してない方は、以下のよう有効化するかの旨を聞かれますので、「y」と入力し、有効化します。
API [cloudbuild.googleapis.com] not enabled on project [プロジェクト名]. Would you like to enable and retry （this will take a few minute）?（y/N）?
「SUCCESS」と返ってきたら、コンテナイメージを Artifact Registry にプッシュ完了です。


 Cloud Run にデプロイ[Cloud Run] に移動します
Cloud Run のページに移動したら、[サービスの作成] をクリックします。
[サービスの作成] ページで、[コンテナイメージの URL]、 [サービス名]、 [リージョン]、 [認証] を以下の通り設定します。
[コンテナイメージの URL] は、先ほど Artifact Registry にプッシュしたイメージを選択します。
[リージョン] は、作成したArtifact Registry のリポジトリと同じリージョンに設定します。



必要な設定ができたら、[作成] をクリックします。
[作成] をクリックすると、デプロイが開始されます。完了までには少し時間がかかり、画面にはぐるぐる回るアイコンが表示されます。

デプロイが完了すると、以下のように緑色のチェックマークが表示され、デプロイ完了の目印となります。
デプロイが完了したら、[サービスの詳細] ページに移動し、URL をクリックします。


Hello, World!

URL をクリック後、ブラウザ上に「Hello, World!」と表示されれば、Cloud Run で Web アプリケーションの公開に成功しています。



 まとめ本記事では、Google Cloud のサーバーレスコンテナ実行環境である Cloud Run の概要と、簡単な Web アプリケーションをデプロイする方法を紹介しました。
開発者は、コンテナ技術とサーバーレス技術を活用することにより、サーバの管理を意識せずにアプリケーション開発に集中でき、自動スケーリングや従量課金制など、様々なメリットを享受できます。
本記事では、Buildpacks を利用して Python の Flask フレームワークで作成した Web アプリケーションを Cloud Run にデプロイする手順を解説しました。これにより、Docker の知識がなくても、簡単に Cloud Run にアプリケーションをデプロイできることを示しました。
Cloud Run は、開発者がより簡単に、そしてより効率的に Web アプリケーションを開発・公開できる環境を提供します。ぜひ、今回の記事を参考に、Cloud Run を活用して Web アプリケーションを開発してみてください。