はじめに
最近、周りの人にアプリを使ってもらうことが増えてきて、Cloud Run を使う機会も多くなってきました。
ただ、自分はインフラの知識があまり強くないので、そこを中心に Cloud Run の仕組みを整理してみようと思います。
まずは一言で
「コンテナをHTTPで起動できるサーバーレス環境」です。
- コンテナ？
- HTTPで起動？
- サーバレス環境？
さて、深堀りしていきましょう。
Cloud Runの特徴
サーバレス
インフラ管理が不要。CPUやメモリなどのリソースを指定するだけで良い。
インフラ管理が不要で何が嬉しいの？
→ 多くの手間と専門知識が必要な作業を省略できる。
- 初期設定
物理サーバーや仮想マシンのセットアップ、OS のインストール、ネットワーク - セキュリティとパッチ管理
OS やミドルウェアのセキュリティパッチの適用、アクセス制御の設定（IAMで簡単に管理） - 監視とロギングの構築
Cloud Monitoring や Cloud Logging と統合されており、アプリケーションの状態やログを容易に確認
スケーラブル
トラフィックに応じて自動スケールする（ゼロにもスケールダウン）
以下であれば、1インスタンスあたり80リクエスト、100までスケールアウトできる。80リクエストを超えたときにはじめてスケールアウトする。
スケールの管理：Kubernetes（クバネティス）
もし、Cloud Runでスケールを自動調整してくれない場合、通常は Kubernetes（特に GKE：Google Kubernetes Engine）を使ってスケーリングを管理するのが一般的です。
次のKubernetesでやることをCloud Runはすべて自動でやってくれるんですね～
- Pod（アプリケーション動作のコンテナ+ログ管理や監視のコンテナのセット）数やスケールルールの設定
- ノード数（Kubernetesを動かすためのコンピュータの数）・バージョン・アップデート・セキュリティパッチなどの運用 など
コンテナベース
任意の言語・ライブラリを含めたコンテナを利用可能
どうしてコンテナベースなのか？
「コンテナでアプリを自由に作れるようにしながら、インフラ運用は自動化する」という理想の中間点を目指したから。
Cloud Runがコンテナであることの強み
- あらゆる言語を選択できる
Cloud Functionsでは特定の言語や環境しか選択できなかった。 - 開発環境と本番が一致する
Cloud Runで動かしたコンテナを、GKE, AWS Fargate, 自社オンプレにも持っていける - Kubernetes を使ってないのに Kubernetes 並に賢い
サーバー構築、スケーリング、セキュリティ、全部自動 - 現代のCI/CD、DevOpsはすでにコンテナ前提であるから
HTTPベース
リクエストが来たときにコンテナが起動、レスポンスを返す
Cloud Run が HTTP ベースである理由
- 汎用性と標準性が高いから
HTTP は、あらゆるプログラミング言語・ツール・サービスからアクセス可能な最も広く使われている通信プロトコル。ブラウザからのアクセス、APIからのアクセス、スマートフォンや IoT デバイスなど、すべて HTTP で簡単に連携可能。 - スケーラビリティに最適
HTTP リクエストは ステートレス（状態を持たない） であるため、Cloud Run はリクエストごとにインスタンス（Podに相当）を起動・終了させることができる。
- 同時リクエスト数に応じてインスタンス数を自動スケール
- トラフィックがゼロになれば、スケールダウンしてコストもゼロ
Cloud Runにデプロイするまでの流れ
私が過去に記載したアプリケーション作成記事を基に簡単に説明します。
1. ローカルにアプリを用意（Python/Nodeなど）
2. Dockerfile 作成
以下記事を参照。
3. GCP プロジェクト準備 ＆ Cloud SDK インストール
以下記事に簡単に記載しています。
4. コンテナをビルドしてpush（コンテナイメージの作成）
以下のコマンドを入力することで、Dockerファイルを基に、Artifact Registoryにイメージがビルドされます。
gcloud builds submit --tag gcr.io/YOUR_PROJECT_ID/your-app-name
5. Cloud Run にデプロイ
gcloud run deploy your-app-name \
--image gcr.io/YOUR_PROJECT_ID/your-app-name \
--platform managed \
--region asia-northeast1 \
--allow-unauthenticated \
--memory 512Mi \
--cpu 1
アプリケーションをデプロイすると
GCPのコンソールからCloud Runのページにアクセス。デプロイしたサービスの詳細を見ると、URLの記載が。このURLにリクエストを送ると、サービスにアクセスできるようになっています。
リビジョンとは
アプリのコードや設定のバージョン履歴のこと。
＜リビジョンによって実現できること＞
トラフィック分割
1つのサービスに対して複数のリビジョンを同時に稼働させ、たとえば「新しいリビジョンには10%、既存の安定版には90%」といったように、トラフィックの割合を指定して分割することができる。これにより、段階的なリリースや A/B テストが簡単に行える。
ロールバック機能
リビジョンは履歴としてすべて保存されるため、もし新しいバージョンで不具合が発生しても、古いリビジョンを選択するだけですぐに前の状態に戻すことができる。
リビジョン単位で構成（設定情報）の保存、ログやモニタリング情報
具体的には、メモリサイズやCPU数、環境変数、同時リクエスト数、サービスアカウントなどが含まれており、いつどんな構成で動いていたかを正確に追跡できる。どのバージョンでエラーが多かったか、リソース使用量に違いがあったかなどを簡単に可視化できる。
参考