Cloud Run とは何かをご存知でしょうか？ Google が提供するパブリッククラウド「 Google Cloud 」に内包されており、コンテナ運用を効率化できるサービスです。
本記事では、 Cloud Run の仕組みや活用事例、料金体系など、あらゆる観点から一挙に解説します。コンテナを効率的に運用したいと考えている方は、ぜひ最後までご覧ください。
目次
Cloud Run とは？
Cloud Run は Google のパブリッククラウド「 Google Cloud 」に内包されているサービスであり、フルマネージドで提供されているコンテナの実行環境です。なお、コンテナとはアプリケーションや設定用ファイル、ライブラリなどを OS 上にまとめたものを意味します。
通常、コンテナを使用する際は Kubernetes （コンテナのオーケストレーションツール）の知識を求められることが一般的です。しかし、 Kubernetes を使うには一定のスキルが必要となるため、学習にかける費用・時間を確保しなければならない点が大きな課題だと言えます。
もちろん、 Kubernetes を使わずにコンテナを扱うことも可能ですが、オーケストレーション（設定・管理などの作業を自動化すること）を実現するためには、 Kubernetes を避けて通ることはできません。そして、このような課題を解決するうえで Cloud Run が有効な選択肢になります。
構築したコンテナイメージを Cloud Run の環境に乗せることで、 Kubernetes によって処理できる様々な機能を手間なく実現できます。このように、 Cloud Run の活用により、開発者は煩雑なインフラ管理から解放され、コードの書き込みやデプロイメントに集中できるようになります。
また、 Cloud Run には 「 Cloud Run for Anthos 」というサービスが用意されており、これを活用することで、コンテナの環境をサーバーレス環境として使えるため、よりシンプルに Kubernetes のコンテナ環境を利用できます。なお、 Anthos とは Google Cloud に搭載されているプラットフォームであり、アプリケーションを手間なくモダナイズできるサービスです。
Cloud Run for Anthos を活用することで
- マルチクラウド環境での Cloud Run の利用
- オンプレミス環境での Cloud Run の利用
- 既存の Kubernetes クラスタで Cloud Run の利用
- 複数リージョンの Cloud Run クラスタの管理
が可能となります。
コンテナ技術とサーバーレスアーキテクチャの重要性
Cloud Run について理解する前に、コンテナ技術やサーバーレスアーキテクチャの重要性を把握しておくことが大切です。なぜなら、 Cloud Run の導入・活用を検討するうえで、これらが重要なポイントになるためです。
以下、それぞれについて詳しく解説します。
コンテナ技術
アプリケーションを動かすためには実行環境が必要になりますが、その環境を構築するために「コンテナ」を作り、コンテナによってアプリケーションを動作させる仕組みをコンテナ技術と呼びます。コンテナ技術はゲスト OS を使用せずにアプリケーションの実行環境を構築することが可能なため、一般的な仮想化技術と比較して、 CPU やメモリの使用リソースを抑えられるというメリットがあります。
また、コンテナの起動プロセスはシンプルに設計されているため、起動時間の短縮や処理スピードの向上、サーバー負荷の低減などを実現できる点も嬉しいポイントです。さらに、コンテナは試験環境で動かしていたものを本番環境でも使えるため、環境に依存したトラブルを事前に回避することが可能です。
このように、コンテナ技術は自社の生産性向上やリスク回避に大きく貢献します。アプリケーションを効率的に運用したい場合には、コンテナの利用が有効な選択肢になると言えるでしょう。
サーバーレスアーキテクチャ
サーバーレスアーキテクチャとは、自社で物理サーバーを用意する必要がなく、外部ベンダーがサーバー管理を代行してくれる仕組みのことです。昨今、身近な存在になったクラウドサービスに関しても、このサーバーレスアーキテクチャを採用しているものが数多く存在します。
従来、システムを構築するためには自社で物理サーバーを用意する必要があり、多額の初期費用が発生するケースが一般的でした。しかし、サーバーレスアーキテクチャは外部ベンダーが管理しているサーバーを利用するため、初期コストをかけずにシステムを構築できます。ただし、サーバーレスアーキテクチャを利用する場合、従量課金（使用量に応じて金額が変動する仕組み）で月々のサービス利用料金が発生することは覚えておきましょう。
また、サーバーの管理・運用は外部ベンダーが巻き取ってくれるため、自社の作業工数を大幅に削減することが可能です。さらに、契約内容を変更するだけで柔軟にスケーリング（使用リソースを増減すること）ができるため、柔軟なシステム運用の実現に繋がります。
Cloud Run の特徴
Cloud Run は様々な特徴・強みを持つサービスです。具体的にどのような特徴があるのか、代表的なものをいくつかご紹介します。
フルマネージドなサーバーレスプラットフォーム
フルマネージドとは、ほぼ全てのサーバー管理をベンダーが代行してくれることを意味します。 Cloud Run はフルマネージドサービスとして提供されているため、自社の工数をかけずに管理・運用できる点が大きな特徴となっています。これにより、社員は利益に直結する業務にリソースを集中させることができ、自社の生産性向上やビジネス成長に繋がります。
コンテナベースのアプリケーション実行
本来、アプリケーションを実行するためには、アプリケーション本体や設定ファイル、ライブラリなど、様々なものを組み合わせて使う必要があります。しかし、 Cloud Run はこれらをコンテナ上に集約し、ひとまとめにしてコンテナベースでアプリケーションを動かせるため、アプリケーションの実行にかかる作業負荷を大幅に低減できます。
高速なスケーリングと低レイテンシー
Cloud Run は外部からのアクセスがない状態ではコンテナのインスタンスが 0 になり、アクセスの発生に伴って必要量までスケールする仕組みを採用しています。そのため、手動でリソースを調整する必要がなく、高速なスケーリングを実現できます。また、他の Google Cloud サービスと同様、強固なインフラをベースとして設計されているため、低レイテンシーな環境でコンテナを扱える点も大きなメリットです。
シンプルなデプロイとバージョン管理
Cloud Run のデプロイはとてもシンプルな仕組みを採用しており、「 gcloud run deploy 」などの単一コマンドを実行するだけで簡単にデプロイできます。コマンドでデプロイを行った後は固有の URL が自動発行されるため、それを使えば外部へのアプリケーション公開を容易に行うことが可能です。
また、 Cloud Run はそれぞれのデプロイが新しいリビジョンを生成し、これにより以前のバージョンへ簡単にロールバックできるため、状況に応じて過去のバージョンへ戻すことも可能です。このように、バージョン管理を効率的に行える点も Cloud Run の大きな特徴となっています。
柔軟な言語とフレームワークのサポート
Cloud Run は言語・ライブラリの制約が少なく、自社の状況に合わせて様々な言語を使用可能なため、柔軟なコンテナ運用を実現できます。
また、フレームワークに関するサポートも充実しており、 Spring Boot などの有名なフレームワークについては、 Google の公式サイト上に説明用のドキュメントが用意されています。このように、初心者でも安心して扱える点が Cloud Run の魅力の一つだと言えるでしょう。
以下、参考までに Google Cloud がサポートしている言語・フレームワークの一例を表にまとめます。
| カテゴリ | 種類 | 対応言語・フレームワークの詳細 |
|---|---|---|
| 言語 | Java | Spring Boot 、 Jakarta EE など |
| Python | Flask 、 Django など | |
| Node.js | Express 、 Koa など | |
| Go | Echo 、 Gin など | |
| C# | .NET Core など | |
| Ruby | Rails など | |
| PHP | Laravel など | |
| フレームワーク | Django | 高機能な Python フレームワーク |
| Node.js | サーバーサイド開発用の JavaScript ランタイム環境 | |
| Go | 高速かつ効率的なコンテナ開発に適した言語 | |
| C# | ウェブ、モバイル、デスクトップアプリケーションを構築するための汎用プログラミング言語 | |
| Ruby | 豊富なライブラリとツール群を備えた Ruby フレームワーク |
従量課金モデルによるコスト最適化
詳しい料金体系は後述しますが、 Cloud Run は使用量に応じて料金が変動する従量課金モデルを採用しています。そのため、予算の範囲内でおさまるように計画的に使えば、コストを最適化しながらコンテナを運用することが可能になります。また、 Google 公式サイトには料金計算ツールが用意されており、使用するプロダクトやリソース量などを入力することで、コストを事前にシミュレーションできるため、不安な方は料金計算ツールを活用することをおすすめします。
なお、料金計算ツールの使い方について解説した記事もあるので、合わせてご覧ください。
関連記事
Cloud Run の仕組み
Cloud Run でコードを実行する際には、
- Cloud Run サービス
- Cloud Run ジョブ
という 2 種類から好きなものを選択して利用できる仕組みとなっています。以下、それぞれについて詳しく解説します。なお、文中で使用している画像に関しては、 Google 公式サイトの「 Cloud Run とは」を参照元としています。
Cloud Run サービス
Cloud Run サービスは、 Web のリクエストやイベントに応答するためのコードを実行する際に使用されるケースが一般的です。 Cloud Run サービスの特徴としては、すべてのサービスに利用できる一意の HTTPS エンドポイントや、迅速な自動スケーリングなどが挙げられます。
Cloud Run には「 *.run.app 」ドメインの一意のサブドメインに HTTPS エンドポイントが用意されており、状況に応じてカスタムドメインを構成することも可能なため、 TLS （ Transport Layer Security ： Web ブラウザと Web サーバー間のデータ通信を暗号化し、送受信を行うための仕組み）を Cloud Run で管理することができます。また、 WebSocket や HTTP / 2 、 gRPC などをサポートしている点も大きな特徴です。
加えて、 Cloud Run サービスはすべての受信リクエストを処理するため、迅速にスケールアウトするように設計されています。最大 1,000 個のインスタンスをスケールアウトできますが、事前にリクエストを送信し、 Google の承認を取得することで、 1,000 個以上のインスタンスへスケールアウトできます。また、リクエストが少なくなった場合、 Cloud Run サービスはアイドル状態のコンテナを削除するため、使用リソースの最適化にも繋がります。
以下、 Cloud Run サービスの構成イメージを図で示します。
Cloud Run ジョブ
Cloud Run ジョブは、コードが動作後に停止する場合に使用されるケースが一般的です。例えば、データベースの移行のように、作業完了後に終了するコードを実行する際は、 Cloud Run ジョブが適切な選択肢になると言えるでしょう。
また、 Cloud Run ジョブはコマンドラインから「 gcloud CLI 」を使用してジョブを実行したり、定期的なジョブをスケジュールしたりすることで実行できます。通常、スクリプトやツールを実行するためには、コード実行のための 1 つのインスタンスを開始しますが、配列ジョブ（独立した同一のインスタンスを複数並行）を用いて開始することも可能です。
以下、配列ジョブのイメージを図で示します。
このように、 Cloud Run でコードを実行する際には、「 Cloud Run サービス」と「 Cloud Run ジョブ」という 2 つの選択肢が用意されています。それぞれ特徴が異なるため、自社の状況に合わせて、適切なものを選択することが大切です。
なお、今回の記事では説明を割愛しますが、 Cloud Run ジョブでは Workflows （複数のジョブを連携させて事前に定義した順に実行できるサービス）を活用することで、ワークフローの一部として Cloud Run ジョブを実行できます。当社センティリオンシステム 大阪事業所でもサポートが可能なため、気になる方や自社で導入したい方は問い合わせフォームよりお気軽にお問い合わせください。
Cloud Run と Google Cloud の他コンピュ―トサービスとの違い
Google Cloud には、 Cloud Run 以外にも様々なコンピュートサービスが用意されています。本章では、 Google Cloud の代表的なコンピュートサービスと Cloud Run との違いをご説明します。
Cloud Run と Google Kubernetes Engine （ GKE ）との違い
Google Kubernetes Engine （以下 GKE と記載）とは、 Kubernetes の運用を効率化できるツールです。コンテナ運用を効率化できる点は Cloud Run と共通していますが、両者には様々な違いが存在します。
例えば、リクエストがない時に Cloud Run は 0 までスケールインできますが、 GKE は 0 までのスケールインは不可能です。また、 Cloud Run は VPC 内のリソースと通信を行うには設定が必要ですが、 GKE は設定なしで VPC 内のリソースと直接接続することができます。
このように、 Cloud Run と GKE は異なる特徴を有したサービスであり、それぞれメリット・デメリットが存在します。 Cloud Run はコンテナをサーバーレス環境で簡単に実行可能なサービス、 GKE は高度なコンテナオーケストレーションを行えるサービスとイメージするのが理解しやすいと思います。
なお、 GKE については以下の記事で詳しく解説していますので、関心のある方はあわせてご覧ください。
関連記事
Cloud Run と App Engine との違い
App Engine とは、アプリケーションを手間なく実行できるサービスです。構成ファイルやコードをデプロイするだけで簡単に実行可能なため、自社の業務効率化に大きく貢献します。
Cloud Run の場合、柔軟な実行環境を構築できる点が大きな特徴ですが、 App Engine のように構成ファイルとコードのみでデプロイを行うことはできません。また、 App Engine は Identity Aware Proxy の認証がサポートされていますが、 Cloud Run で同様の認証を行うためには Serverless NEG に紐付ける必要があります。
ただし、フレキシブル環境の App Engine は VM ベースの実行環境であるため、 Cloud Run と比較してスケーリングの速度が遅く、 0 までスケールインすることもできません。このように、 Cloud Run と App Engine は異なるメリット・デメリットを持っているため、簡単にデプロイしたい場合は App Engine 、柔軟な環境を求める場合は Cloud Run など、状況に合わせて使い分けることを意識してください。
Cloud Run と Container Registry との違い
Container Registry とは、 Docker イメージを保存・管理するためのサービスです。なお、 Docker は「 Docker コンテナ」と呼ばれるコンテナを作成し、効率的にアプリケーションを実行するための代表的なソフトウェアであるため、コンテナに関する基礎知識として覚えておきましょう。
一方、 Cloud Run はコンテナアプリケーションを実行するためのサービスであるため、両者は明確に異なるサービスとなっています。ただし、 Cloud Run でコンテナを実行するためには Docker イメージが必要ではありますが、仮に Docker を使わないとしても、 Container Registry でイメージを保存することが可能です。
Cloud Run のセキュリティ対策
Cloud Run には、コンテナを安全な環境で利用するための様々なセキュリティ対策が施されています。本章では、 Cloud Run のセキュリティ対策について、いくつか内容を抜粋して解説します。
各種認証
Cloud Run は簡単にデプロイを行うことが可能ですが、アクセス制限をしなかった場合、不特定多数が自由にアクセスできるようになってしまい、情報漏洩などのリスクが増加します。そこで、 Cloud Run には、サービスを安全な環境で利用するための各種認証が備わっています。
Cloud Run に搭載されている認証機能としては、
- サービス間通信の認証
- Google Cloud 間の認証
- エンドユーザーの認証
などが挙げられます。
これらの認証を活用することで、様々なシーンにおけるセキュリティを高めることが可能です。 Cloud Run を安全に使いたいのであれば、認証は必要不可欠な機能であると言えるでしょう。
アクセス制限
Cloud Run はオープンな URL を発行するため、そのままの状態ではセキュリティが担保されているとは言えません。しかし、 Cloud Run 単体でファイアウォールの制御などを行うことは不可能であり、アクセス制限を実現するためには「 Google Cloud ロードバランサ（以下 GCLB と記載）」と「ネットワークエンドポイントグループ（以下 NEG と記載）」を連携する必要があります。
Cloud Run に登録した NEG と GCLB のバックエンドサービスを連携させれば、バックエンドサービスに複数の NEG を設定できるようになります。これにより、リージョン単位で Cloud Run サービスを稼働させ、 GCLB を使って近いリージョンの Cloud Run にリクエストをルーティングさせることが可能になるため、外部からのトラフィックを柔軟に制御することができます。
VPC 連携
特定のユーザーのみがアクセスできる状態を作るためには、 Virtual Private Cloud （以下 VPC と記載）と Cloud Run を連携させる必要があります。例えば、サーバーレス VPC アクセスを経由して Cloud Run に接続すれば、 VPC 内のリソースへアクセスすることが可能になります。
また、 Cloud Run 発信で通信を行う際に IP アドレスを固定したい場合は、 Cloud NAT とサーバーレス VPC アクセスを連携させることで実現できます。これにより、 IP アドレスを固定化し、通信先のファイアウォールを用いてアクセスを制御できるようになります。
Cloud Run の活用事例
主に時計事業を展開するセイコーホールディングスのシステムソリューション事業を担っている「セイコーソリューションズ」では、 Cloud Run を活用してクラウド辞書サービスの開発に Cloud Run を活用しています。
同社のマーケティングの結果、サービスの潜在顧客は 300 万人にも上ることが判明し、利用者が爆発的な増加に耐えうるだけのインフラ整備が大きな課題となっていました。そこで、サービス規模の拡大にも柔軟に対応できるよう、サーバーレスで運用できる Cloud Run の導入を決めたのです。
同社は Cloud Run でコンテナ運用を効率化しつつ、 Cloud Datastore や Cloud SQL をはじめとした、他の Google Cloud サービスも組み合わせて利用しています。表示部分を担うフロントエンドと機能部分を担うバックエンドを分割し、マイクロサービス化の工夫を施すことで、サービス拡大後のコスト低減や信頼性の向上、メンテナンス工数の削減などを担保する狙いです。
また、同社はクラウド辞書サービスにおける検索のレスポンスを重視しており、高速レスポンスを実現できる点も Google Cloud の導入を決めた一因となっています。このように、 Cloud Run や Google Cloud の各種サービスを活用し、自社のビジネス成長に繋げている好事例だと言えるでしょう。
Cloud Run の料金体系
最後に、 Cloud Run の料金体系について解説します。
Cloud Run は使用した分だけ料金が発生する従量課金制を採用していますが、次の 2 パターンのどちらに該当するのかによって、異なる料金体系が採用されます。
- CPU を常に割り当てる
- CPU をリクエスト処理中のみ割り当てる
ここからは、一例として東京リージョンの料金体系を表にまとめます。なお、 Cloud Run には一定量まで無料でサービスを利用できる「無料枠」と、一定量の利用を約束することで割引を受けられる「確約利用割引」が用意されていますので、これらについてもあわせて表に記載しています。
まずは、 CPU を常に割り当てる場合の料金です。
| CPU | メモリ | リクエスト | |
|---|---|---|---|
| 無料枠 | 毎月 240,000 vCPU 秒まで | 毎月 450,000 GiB 秒まで | - |
| 通常料金 | 0.00001800 米ドル / vCPU 秒 | 0.00000200 米ドル / GiB 秒 | - |
| 確約利用割引適用の料金 | 0.00001494 米ドル / vCPU 秒 | 0.00000166 米ドル / GiB 秒 | - |
※参照元： Google 公式サイト「 Cloud Run の料金」（ 2024 年 4 月時点）
次に、 CPU をリクエスト処理中のみ割り当てる場合の料金です。
| CPU | メモリ | リクエスト | |
|---|---|---|---|
| 無料枠 | 毎月 180,000 vCPU 秒まで | 毎月 360,000 GiB 秒まで | 1 ヶ月あたり 200 万件まで |
| 通常料金 | 0.00002400 米ドル / vCPU 秒 | 0.000002500 米ドル / GiB 秒 | 100 万件あたり 0.400 米ドル |
| 確約利用割引適用の料金 | 0.00001992 米ドル / vCPU 秒 | 0.000002075 米ドル / GiB 秒 | 100 万件あたり 0.332米ドル |
※参照元： Google 公式サイト「 Cloud Run の料金」（ 2024 年 4 月時点）
このように、 Cloud Run の料金体系は 2 つのパターンに分かれており、 CPU の割り当て方法によって算出方法が異なります。それぞれの違いを理解し、自社にとって最適なものを選択するように意識してください。
なお、 Cloud Run はオンデマンド容量を提供しており、インスタンスを自動的にスケーリングします。予想されるピークの使用量に対応するため、インフラストラクチャを事前にプロビジョニングする必要はありませんが、 Cloud Run で課金されるコンテナインスタンスは「使用されているコンテナインスタンス」となるため、この点には注意が必要です。
まとめ
Cloud Run の仕組みや活用事例、料金体系など、あらゆる観点から一挙に解説しました。
企業が Cloud Run を活用することで、コンテナ運用の効率化や高速スケーリングなど、様々なメリットを享受できます。この記事を読み返して、サービスの特徴や料金体系などを理解しておきましょう。
当社では、これまでの多くのクラウド開発を支援してきた知見を活かし、クラウドを活用した内製化に取り組まれるお客様を全力でサポートします。
以下のような課題をお持ちの方は、ぜひお気軽にご相談ください。
- SRE を実現したい
- クラウド活用を推進するための開発体制作りが進まない
- 既存資産をどのようにクラウド移行するか検討する知見が不足している
- 内製化するためのクラウド開発スキルを持った人材が不足している
- コスト削減の実現方法に悩んでいる
貴社の状況に合わせて、体制づくり支援や開発計画支援、クラウド開発スキルアップ支援など、様々な支援メニューを提供しています。
また、今回ご紹介した「 Google Cloud 」に特化したメニューも提供しています。 Google Cloud に関するスキルの底上げや平坦化を検討されている方は、ベストプラクティスセミナーやテクニカル・アドバイザリーサービス、テクニカルコンサルティングなどをご検討ください。
無料で相談できるため、まずは問い合わせフォームからご連絡いただければと思います。本記事を参考にして、 Google Cloud の導入および Cloud Run の活用を検討してみてはいかがでしょうか？
当社センティリオンシステム 大阪事業所がお送りするメールマガジン「 Ignition for Google Cloud 」が大好評配信中！
- Google Cloud 関連の最新情報
- お役立ち情報
- SRE
- 内製化のポイント
など
当社の知見を一部公開しております！
メルマガ登録はこちら
