「その言語、 Cloud Run で実装してみない？」というテーマで喋りました #devio2021

こんにちは

CX事業本部 MAD事業部 の 田中 孝明 です。

DevelopersIO 2021 Decade という弊社オンラインイベントにて、「その言語、 Cloud Run で実装してみない？」というテーマでお話させていただきましたので、ご紹介します。

セッション概要

MAD事業部では以前から一部使われていた Google Cloud を本格的に利用しようという動きがあります。個人的に好きなサービスである Cloud Run を使った内容をお話しします。

動画

スライド

Cloud Run を一言で

Cloud Run は 2019年 にデビューした コンピュート に属するサービスです。

主な機能

Cloud Run は、マシンのプロビジョニング、クラスタの構成、自動スケーリングについて心配することがない、フルマネージドコンピューティング環境です。

更に、任意のプログラミング言語、OSのライブラリを使用でき、Google Cloud の提供するコンテナのエコシステムと高い親和性があります。

また、コードが実行されている間のみ料金が発生する従量課金となっています。

Cloud Run : サーバーレスコンテナ

ベンダー ロックインしない

Cloud Run は標準の OCI コンテナに対応し、標準の Knative Serving API を実装しているため、アプリケーションをオンプレミスや、その他のクラウド環境に移行可能です。

高速自動スケーリング

Cloud Run にデプロイされたマイクロサービスは、本格的な Kubernetes クラスタを構成、または管理しなくても、リクエストの数に基づいて自動的にスケールされます。 また、Cloud Run はゼロへのスケーリングを行いますので、リクエストがない場合はリソースをまったく使用しません。

トラフィックの分割

Cloud Run はトラフィックを複数のリビジョン間で分割できるため、カナリアデプロイや Blue/Green デプロイなど、段階的なデプロイを行うことができます。

カスタム ドメイン

Cloud Run でカスタムドメインマッピングが利用できます。設定すると、ドメインのTLS証明書がプロビジョニングされます。

自動冗長化

Cloud Run には自動冗長性が備わっているため、高可用性のために複数のインスタンスを作成する必要がありません。

各種サービスとの統合

コンテナは、コードやその依存関係をパッケージ化してデプロイする手法の標準となっています。

Cloud Run は、Cloud Build、Cloud Code、Artifact Registry、Docker などのコンテナエコシステムと親和性の高いサービスであることがわかります。

Cloud Code

Cloud Code for VS Code は、Visual Studio Code を簡単に拡張でき、Gloud Run のビルド、実行、デバッグのサイクルが短縮されます。

Cloud Build

Cloud Build では Cloud Run のアプリケーションコンテナを作成することはもちろん、既存の Cloud Build トリガーを Cloud Run サービスに関連付けることも可能です。

Container Registry / Artifact Registry

Container Registry からコンテナイメージのデプロイはもちろん、2020年の11月より提供が開始された Artifact Registry を利用することもできます。Artifact Registry でホストされているイメージを Cloud Run にデプロイすることができます。

Cloud Monitoring / Cloud Logging

また、Cloud Monitoring、Cloud Logging と完全に統合されているため、運用面でも開発者の助けになるでしょう。

Cloud Debugger

特定の言語にはなりますが、Cloud Debugger にも対応しています。これにより本番環境でしか再現しないような、原因が追いづらい不具合の調査も可能です。

呼び出し方

HTTPS

すべての Cloud Run サービスには、永続的な HTTPS の URL があります。 ユースケースには、RESTful Web API、限定公開のマイクロサービス、Webアプリケーション用のHTTP ミドルウェア、リバースプロキシ、パッケージ化されたWebアプリケーションなどがあります。

gRPC

内部のマイクロサービス間で通信する場合、高負荷のデータを扱う場合、gRPC サーバーで gRPC ストリーミングを使用して、より応答性の高いアプリケーションと API を構築する場合に gRPC は良い選択肢となります。

WebSockets

追加の構成が不要で Cloud Run で WebSockets を利用することができます。 チャットアプリケーションなど、ストリーミングサービスを必要とする、すべてのアプリケーションなどで活用できます。

Pub/Sub からのトリガー

Pub/Sub を使用してメッセージを Cloud Run サービスのエンドポイントに push できます。

そこではメッセージが HTTP リクエストとしてコンテナに配信されます。

• ユースケース
  • Cloud Storage バケットへのイベントを受信した後、データに対して変換処理を行う
  • Google Cloud のログを Pub/Sub にエクスポートして Cloud Run で処理する
  • Cloud Run サービスから独自のカスタムイベントを Publish して処理する

スケジュールに沿ってサービスを実行

Cloud Scheduler を使用して、スケジュールに沿って Cloud Run サービスを安全にトリガーできます。

これは cron ジョブを使用するのと同様です。

• ユースケース
  • 定期的にバックアップを実行する
  • サイトマップの再生成や古いデータ、コンテンツ、構成、同期、リビジョンの削除などの定期的な管理タスクを実行する
  • 請求書またはその他のドキュメントを生成する

非同期タスクとして実行

Cloud Tasks を使用して、Cloud Run サービスによって非同期に処理されるタスクを安全にキューに入れることができます。

• ユースケース
  • 本番環境で予期しないインシデントが発生した場合にリクエストを処理する
  • ユーザーが操作していない作業を遅らせてトラフィックの急増を緩和する
  • データベースの更新やバッチ処理などの遅いバックグラウンドオペレーションを委任し、別のサービスで処理することでユーザーの応答時間を改善する
  • データベースやサードパーティAPI などのバックエンドサービスに対するコールレートを制限する

Eventarc で 60 以上の Google Cloud サービスと連携

Eventarc は、60 以上の Google Cloud ソースから Cloud Audit Logs 経由でイベントを受信すること、Pub/Sub にメッセージを Publish してカスタムソースからイベントを受信することなどができます。

• ユースケース
  • Cloud Storage イベントから Cloud Audit Logs 経由でデータ処理パイプラインをトリガーする
  • Cloud Audit Logs 経由の BigQuery イベントを使用して、ジョブが完了するたびに Cloud Run でダウンストリーム処理を開始する
  • Pub/Sub への Publish によるカスタムソースからのイベントを使用して、マイクロサービス間でシグナルをやりとりすることで、標準化された同一のインフラストラクチャであらゆるサービス間の非同期処理に対応する

Cloud Run から Cloud SQL への接続

パブリック IP パスの場合

Cloud Run によって暗号化が行われ、Cloud SQL Auth Proxy を使用して Unix ソケット経由で接続します。これらの接続は、追加構成なしで自動的に暗号化されます。

プライベート IP パスの場合

アプリケーションはサーバーレスVPCアクセスを介してインスタンスに直接接続します。この方法では、Cloud SQL Auth Proxy を使用せずに、TCP を使用して インスタンスの プライベートIPアドレス と ポート3306 を使用して、Cloud SQL インスタンスに直接接続します。

また、アプリケーションをローカルでテストする場合は、Cloud SQL Auth Proxy を使用できます。また、Dockerコンテナ経由で Cloud SQL Proxy を使用してテストできます。

Cloud Functions との棲み分け

Cloud Functions では、限られたプログラミング言語のセットで記述されたコードをデプロイできます。

• Node.js
• Python
• Java
• .NET
• Ruby
• PHP

Cloud Run では、開発者が選択したプログラミング言語を使用してコンテナイメージをデプロイ可能ですので、事実上好きな言語で開発することが可能です。

Cloud Run は、最大 60 分の長い リクエストタイムアウト を提供します。一方で Cloud Functions の リクエストタイムアウト は最大で 9 分です。

この制限を踏まえて、処理時間が長いアプリケーションは Cloud Run が候補になるでしょう。

Cloud Functions は、各関数インスタンスに一度に 1 つのリクエストのみを処理しますが、 Cloud Run は、デフォルトで、各コンテナインスタンスで複数の同時リクエストを処理するように構成されています。これは大量のリクエストが予想される場合に、レイテンシを改善しコストを削減するのに役立ちます。

CPU が割り当てられる機能が プレビュー に

応答を返した後に バックグラウンドタスク とその他の非同期処理作業を実行したり、Go の Goroutine または Node.js の async、Java のスレッド、Kotlin のコルーチンを使用することもできます。

この機能により、これまで Cloud Run では対応できなかった多くのユースケースに可能性が広がります。

他の言語で サービス を ビルド して デプロイ する

Kotlin や Swift などの モバイルエンジニア が得意な言語や、Rust や Elixir など、コンテナでビルドできるものは公式のドキュメントでサンプルのアプリケーションが提供されています。

まとめ

Cloud Functions で制限にかかる処理も実行可能です。また、Dockerコンテナ にパッケージ化できれば、過去のアプリケーションの資産を利用や任意の言語での実装が可能です。

リンク集

• Cloud Run: サーバーレス コンテナの話
• 60 を超える Google Cloud ソースのイベントで Cloud Run をトリガーする
• Eventarc の概要
• 新しい CPU 割り当てコントロールにより Cloud Run 上でさらに多様なワークロードを実行
• 他の言語でサービスをビルドしてデプロイする

おわりに

DevelopersIO 2021 Decade では、他にも多数の ビデオセッション が順次公開されています。 また、10/5 〜 10/14 の期間中に ライブセッション も開催されますので、そちらもチェックしていただけると幸いです。