アイレット株式会社 クラウドインテグレーション事業部所属の森 柾也です。
Google Cloud Next において、「The Ultimate Cloud Run Platform Guide: From Zero to Production」というセッションに参加しました。
このセッションでは、Cloud Run を活用し、アプリケーションを迅速かつ効率的にプロダクション環境へデプロイするためのステップが、具体的なデモンストレーションを交えながら紹介されました。
この記事では、セッション内で解説された Cloud Run の主要な機能と、本番運用でも利用される重要な機能をセッションの流れに沿ってご紹介します。
Cloud Run をこれから使い始める初心者から、既に Cloud Run を利用していて、機能を復習したいと考えているエンジニアの助けになれば幸いです。
Cloud Run とは？インフラ管理からの解放
セッションはまず、Cloud Run がインフラストラクチャの管理を一切行うことなく、任意のコンテナ化されたアプリケーションを実行できるサービスであるという基本的な説明から始まりました。
仮想マシン（VM）やクラスタの管理が不要である点が強調され、開発者はアプリケーションコードに集中できる環境が提供されることが示されました。
アプリケーションを Cloud Run へデプロイする 4 つの方法
次に、Cloud Run へアプリケーションをデプロイするための 4 つの主要なオプションが紹介されました。
- コンテナイメージを直接デプロイ: 既に Docker などでコンテナ化されたアプリケーションがある場合、そのコンテナイメージを Cloud Run へ直接デプロイできます。
- GitHub からの継続的デプロイ (CD): アプリケーションのソースコードが GitHub で管理されている場合、継続的デプロイメント (CD) を設定し、コードの変更を自動的に Cloud Run へ反映させることが可能です。
- ソースコードからの自動ビルド (Buildpack): Dockerfile を持たないソースコードのみの場合でも、Cloud Run は Buildpack を利用して自動的にコンテナイメージを構築し、デプロイすることができます。
- Cloud Run Functions: Cloud Functions は現在 Cloud Run Functions となっており、関数をデプロイすることができます。また、バックグラウンドで Google Cloud の Buildpack と Cloud Build が使用されています。
Cloud Run の主要リソース：Service と Job
Cloud Run の、Service と Job という 2 種類のタイプについて解説がありました。
- Service: HTTP リクエストなどのイベントに応じて自動的にスケールする、リクエスト駆動型のアプリケーションに適しています。
- 組み込みの URL と HTTPS が提供され、トラフィック分割 や 段階的なロールアウト 機能により、ダウンタイムなしで新しいバージョンをデプロイできる点が強調されました。 Service は、HTTP/2、gRPC、WebSocket など、多様なトリガーソースをサポートし、 リクエストベースの課金 または インスタンスベースの課金 といった複数の料金オプションが用意されています。
- Job: バッチ処理やタスク処理など、完了まで実行されるコンテナ化された処理に適しています。
- HTTP リクエストによるトリガーではなく、大規模な Job は複数のコンテナで並行実行でき、手動またはスケジュールに基づいて実行可能です。 料金は Job の実行時間に対してのみ発生します。
文章だけでは Job のユースケースを想像しづらいかと思いますが、自分の経験では定期的に gcloud コマンドを実行したいときなど簡単な Cloud Run Job を利用していました。
Functions でも良かったのですが、慣れていた gcloud コマンドをそのまま実行したかったため Job を利用することにしました。また、Cloud Run Job は Cloud Scheduler との連携も充実しているのでちょっとしたツールとして利用するのに適しています。
Cloud Run の高度な機能
セッションでは、Cloud Run をより深く活用するための高度な機能も紹介されました。
- Revision とトラフィック管理:
- アプリケーションの変更時に作成される Revision はイミュータブル（読み取り専用）であり、Cloud Run は トラフィックの移行 を柔軟に制御する機能を提供します。 これにより、ロールバック やカナリアリリースなどの高度なデプロイ戦略を容易に実現できます。 新しい Revision が公開されると、デフォルトでは 100% のトラフィックが自動的に移行 しますが、起動プローブ (startup probe) を設定することで、新しい Revision がトラフィックを受け付ける準備が完了しているかどうかを検証することも可能です。
- Google Cloud サービスとの連携:
- Client Libraries を利用することで、Application Default Credentials (ADC) による認証が自動的に行われ、API キーを管理することなく、Cloud SQL、Memorystore、Cloud Storage など、他の Google Cloud サービス へ安全にアクセスできます。
- VPC 内のサービスへの接続には VPC Connector が利用できます。また、 Cloud Storage に格納されたデータへのアクセスには Volume Mount も利用できます。
- Secret Manager:
- API キー、パスワード、証明書などの機密データを安全に保管および管理するための Secret Manager が紹介されました。 Secret Manager に保管されたシークレットは、環境変数またはファイルとして Cloud Run Service に公開できます。
本番環境での Cloud Run の考慮事項
プロダクション環境で Cloud Run を利用する上で重要な考慮事項も解説されました。
- パブリックドメイン: デフォルトで 2 つのドメイン名 が提供されます。
- カスタムドメイン のマッピングや、Global External Application Load Balancer を利用することで、マルチリージョンロードバランシング、マネージド SSL 証明書、Cloud Armor、CDN などの高度な機能を利用する方法が紹介されました。
- traffic tag によって、トラフィックの処理前に新しいリビジョンをテストして確認する機能も紹介されました。
- オートスケーリング: Cloud Run は、受信したリクエストに応じてコンテナインスタンスを自動的に起動し、トラフィックの増減に合わせてインスタンス数を調整します。
- 一定期間トラフィックがないインスタンスは自動的に停止する スケール To Zero が行われます。 スケール To Zero を防ぎたい場合は 最小インスタンス数 を設定でき、コストを制限するために 最大インスタンス数 を設定することも可能です。
- 料金体系: リクエストベースの課金 と インスタンスベースの課金 の 2 つのモードがあります。
- リクエストベースの課金では、コンテナインスタンスがアイドル状態の場合には課金されません。
- インスタンスベースの課金では、インスタンスがアクティブな時間に対して課金され、リクエストごとの料金はかかりません。
- 料金体系の選択に迷う場合は、料金に関する推奨事項 を確認できる機能も紹介されました。
料金体系について、推奨事項が表示される点は便利だと感じました。はじめはリクエストベースで、トラフィック量やパターンなど全体像が判明した段階で、推奨事項に従って料金体系を切り替えたりすることができそうです。
また、一般的には、トラフィックが散発的 or 急増する場合はリクエストベースの課金、トラフィックが安定的であればインスタンスベースの課金が良いそうです。
まとめ
このセッションを通じて、Cloud Run の多様な機能と可能性を改めて認識することができました。
特に印象に残ったのはデプロイ機能です。プロダクション環境でも利用できるレベルで、トラフィックの振り分けや traffic tag などの機能が充実しているため非常に使いやすいサービスだと思います。
本セッションでは軽くしか触れられませんでしたが、Cloud Run で GPU の割当もできるようになったとのことで、これまでよりも多様なアプリケーションで利用されるインフラストラクチャになると思います。本セッションを通じて、Cloud Run の今後の機能の拡充がさらに楽しみになりました。
簡単30秒