2023年は「Cloud Run を触って覚える」をテーマとした ひとりアドベントカレンダー を開催しており、Cloud Run のさまざまな機能や Cloud Run でよく使う構成などをご紹介しています。
最終日、25日目は Cloud Run を中心としたサーバーレス アーキテクチャをいくつか紹介します。2023年にちなんで23個のアーキテクチャを用意しました。
Cloud Run の概要は「gihyo.jp」で解説していますので、こちらもぜひご覧ください。
Web アプリケーション + API の 3-Tier 構成 (SPA)
Web アプリケーション + API の 3-Tier 構成 (SPA)
SPA (Single Page Application) がフロントになり、バックエンドの API サーバーとして Cloud Run を使用するアーキテクチャです。SPA は Next.js や Vue.js、Angular などを想定していただければ良いかと思います。
SPA は静的コンテンツになるので Cloud Storage に置き、Cloud Storage と Cloud Run を Application Load Balaner にひとまとめにします。こうすることでドメインが同一かつパスで切り替えるといった構成が取れ、CORS (Cross Origin Resource Sharing) の必要がありません。
Web アプリケーション + API の 3-Tier 構成 (SSR)
Web アプリケーション + API の 3-Tier 構成 (SSR)
SPA 部分を SSR (Server Side Rendering) に変えたアーキテクチャです。SSR は Next.js や Nuxt.js、Angular、Remix などを想定していただければ良いかと思います。
HTML および JavaScript は Cloud Run でレンダリングしたものが返るようにし、画像などのメディア コンテンツは Cloud Storage から配信します。SSR サーバーからレンダリング時に取得したいデータはバックエンド API サーバーから取得します。
モバイルアプリの 2-Tier 構成
モバイルアプリの 2-Tier 構成
モバイルアプリのデータ読み書きは Firestore を使うことで 2-Tier 構成を取ることができます。レイヤーが少ないのでシンプルでありながら、Firestore のリアルタイム リスナーも使うことができます。
Firestore のデータ書き込みによって発生するロジックは、Firestore イベントリスナーを使って Cloud Run を発火し、Cloud Run 内の処理を実行することができます。
モバイルアプリ向けにはシンプルな構成にしつつも、Cloud Run を併用することでカスタマイズ自由な構成を取ることができます。
API ゲートウェイ
API ゲートウェイ
他のシステムや他の Google Cloud サービスなどの、いわゆるファサードの役割として Cloud Run を使うアーキテクチャです。
BFF も同様の構成を取ることができ、フロントエンドに対してシンプルな API を提供し、バックエンドやマイクロサービスへのリクエスト処理の仲介をします。GraphQL を採用するケースも多いです。
高可用な Web アプリケーション or API
高可用な Web アプリケーション or API
Cloud Run を複数のリージョンにデプロイし、グローバル ロードバランサにぶら下げるアーキテクチャです。この構成を取ることで、片方のリージョン (または Cloud Run サービス) に障害が発生したとしてもサービス提供を維持することができます。
データベースは Spanner を採用することで、アプリケーション側とデータベース側でそれぞれ高可用な構成を取ることができます。
内部向け Web アプリケーション or API
内部向け Web アプリケーション or API
Cloud Run を VPC 内からしか実行できないようなユースケースに適用する場合のアーキテクチャです。手前に内部ロードバランサを配置することで、複数の Cloud Run サービスをルーティングすることが可能です。
Interconnect を使うことで専用線経由でのアクセスも受け入れることができ、オンプレから呼び出すようなユースケースに対応することも可能です。
Identity-Aware Proxy でアクセス制限
Identity-Aware Proxy でアクセス制限
ロードバランサーと組み合わせて使うことができる、アクセス制御のためのプロキシ レイヤーを設けることができる Identity-Aware Proxy を使うアーキテクチャです。Web サービスにアクセス可能な Google アカウントを IAM で制御することができ、すでに Cloud Identity で社内の Google アカウントを管理している場合は非常にスムーズなユーザー体験を提供できます。
次の記事でも解説していますので、ぜひご確認ください。
Identity Platform で認証
Identity Platform で認証
Google Cloud が提供する IDaaS である Identity Platform (Firebase Authentication の Enterprise 版) でエンドユーザーの認証を行うアーキテクチャです。フロントエンドには Identity Platform の SDK を組み込むだけでユーザーの新規登録やログインの機能を導入できます。Firebase Authentication の SDK と使いまわせる点も良いところです。
Identity Platform のログイン画面
Identity Platform のログイン画面
Identity-Aware Proxy の外部 ID を許可する設定を使う場合に必要な設定で、Identity-Aware Proxy の画面から簡単に Identity Platform のログイン画面を Cloud Run にデプロイすることができるようになっています。もちろん自分でフルカスタマイズしたログイン画面を実装し、Cloud Run でホスティングするような使い方も可能です。
コンテンツ配信 (CDN)
コンテンツ配信 (CDN)
Web アプリケーションのコンテンツは一定期間キャッシュ可能なものが多く、CDN を使うことでオリジンへのトラフィックを減らすことができます。
Google Cloud では、アプリケーション ロードバランサのオプションとして Cloud CDN を有効化することができます。Cloud CDN ではキャッシュ コントロールのデフォルト値を設定することができるので、オリジンからキャッシュコントロールを返さない場合でもクライアントに一律でキャッシュ コントロールを返すことができます。
攻撃のブロック (WAF) と reCAPTCHA Enterprise
攻撃のブロック (WAF) と reCAPTCHA Enterprise
Web アプリケーションや API サーバーを一般公開すると、悪意のあるアクセスと付き合わなければいけません。Google Cloud では WAF (Web Application Firewall) の機能を Cloud Armor というサービスで提供しています。アプリケーション ロードバランサのオプションとして有効化できるので、導入もかなり簡単です。
Cloud Armor は Standard と Managed Protection Plus の 2 つのオプションを提供していますが。Managed Protection Plus は Paygo が選べるようになりました。年間契約なく気軽に導入することができるようになりました。
また Cloud Armor は reCAPTCHA Enterprise と組み合わせて使うことができ、攻撃と思われるアクセスが検知されたら reCAPTCHA にリダイレクトするといった構成が組めるようになります。
Eventarc イベント通知
Eventarc イベント通知
Eventarc を使えば、Google Cloud のサービスや 3rd パーティのイベントを通知することもできます。メールや Slack に通知するだけではなく、後続として何らかのシステムの API を呼ぶといった使い方も応用することが出来ます。
アラート通知のカスタマイズ
アラート通知のカスタマイズ
Cloud Monitoring のアラート発生時に Webhook として Cloud Run を呼び出し、通知用のメッセージをカスタマイズした上で各チャネルに通知を送信するアーキテクチャです。Cloud Monitoring では標準で各チャネルへの通知をサポートしていますが、標準で通知される以上の情報を加えたり、通知されるビジュアルをカスタマイズしたい場合は Cloud Run を挟むと良いでしょう。
Cloud Storage イベントトリガー
Cloud Storage イベントトリガー
イベントドリブン アーキテクチャは Eventarc を使うと簡単に構築できます。Eventarc は Google Cloud の各サービスまたは 3rd パーティのイベントを管理し、イベント発生時に Cloud Run を実行する構成を取ることができます。
この例では、画像ファイルが Cloud Storage にアップロードされたら Cloud Run を発火し、リサイズ (加工) した画像を配置するという流れを表しています。
画像メタデータ抽出
画像メタデータ抽出
Cloud Storage イベントトリガーを使った、もう少し多機能なアーキテクチャ例です。全体のパイプラインを Workflows で管理し、Workflows の中で Cloud Run を呼び出しています。Cloud Run の中では Vertex AI Vison を呼び出し、画像からメタデータを抽出し BigQuery に保存しています。
Workflows の中でもある程度のロジックを直接記述することもできますが、ロジックのテストなど管理面を考えると Cloud Run の中でロジックを実行した方が良い場合が多いです。
承認ワークフロー
承認ワークフロー
Workflows を使った承認ワークフローをサーバーレスで構成するアーキテクチャです。申請フォームを Cloud Run でホスティングし、申請があったら Workflows を開始します。Workflows の中では Cloud Run を使ってメッセージをメールで送信し、メールを受け取った承認者が確認後、承認用 API が呼ばれるようにします。Workflows では 承認用 API をポーリングすることができるので、承認されたら Workflows を先に進め、承認が通った後の処理を実行します。
Workflows では 1 つのワークフローのタイムアウトが最大 1 年なので、申請が途中で停滞したとしても長時間待機することもできます。
並列処理
並列処理
Cloud Run ジョブのメインの機能を活用したアーキテクチャです。この例では Cloud Storage にアップロードされた CSV ファイルの数のタスク数でジョブを実行し、ジョブ内の各タスクが対応する CSV ファイルを読み、一次加工した上で BigQuery に書き込むといった流れを表しています。
Cloud Run ジョブではジョブ実行時にタスク数を動的に決めることができるようになったため、たとえば CSV ファイルの数が定まっていないようなユースケースでも柔軟に対応することができます。
非同期処理
非同期処理
Cloud Run の Always on CPU を活用したアーキテクチャです。Always on CPU はリクエスト・レスポンスに依らないタスクを実行するのに最適な機能です。リクエストベースの Cloud Run サービスでは、通常はリクエストがあったタイミングで Cloud Run を起動し、レスポンスを返したらコンテナ インスタンスが終了します。レスポンスを返した後はコンテナ インスタンスは生存しない (15 分でシャットダウンされる) ため長時間の非同期処理には向きませんが、Always on CPU の場合は処理が終わるまで生存するため非同期処理のユースケースに対応することができます。
このアーキテクチャではタスク全体を Workflows で管理し、Workflows の中で Always on CPU の Cloud Run サービスの非同期処理を呼び出しています。
キューイング サービス
キューイング サービス
Pub/Sub でメッセージをキューイングし、Push サブスクリプション (Pub/Sub 側からサブスクライバーを呼び出す方式) を使って順番に Cloud Run を呼び出して処理を行うアーキテクチャです。一般的な FaaS とは違い、コンカレンシーを活用することで 1:N の関係で Cloud Run を実行することができるので、コスト効率よく後続の処理を実行することができます。
メッセージのフィルタを使うと、メッセージにあらかじめタグを付けておき、タグによって後続の Cloud Run を呼び分けるような使い方もできます。
また Pub/Sub のメッセージサイズは最大で 10MB まで入れることができるので、必要な情報をすべてメッセージに詰め込んで処理を行うこともできます。シンプルな構成で柔軟な要件に対応できるのがポイントです。
リアルタイムデータ処理
リアルタイムデータ処理
Pub/Sub でメッセージを受け取り、Pub/Sub の Push Subscription を使って Cloud Run を呼び出し、Cloud Run の中でデータ処理を行った上で BigQuery に保存しています。Pub/Sub から直接 BigQuery に保存することもできますが、ETL 処理を実施したい場合はこのような構成がおすすめです。
Cloud Run のコンカレンシー (コンテナ インスタンスとメッセージが 1:N にできる) やスケール性能 (メッセージ数でスケール) を活かすことができるため、メッセージが大量に来たとしてもコストパフォーマンス良く捌くことができます。
Cloud Storage の Web インターフェース
Cloud Storage の Web インターフェース
Cloud Storage ではコンソールからファイル管理はできますが、非エンジニアのユーザーにアクセスさせることが困難なケースもあります。このアーキテクチャでは Cloud Run でファイルを管理できる GUI を提供し、Cloud Storage は Cloud Storage FUSE を使ってネットワーク ファイル システムとして Cloud Run にマウント、ファイルの読み書きを行うような構成になっています。
機械学習モデルのエンドポイント
機械学習モデルのエンドポイント
Vertex AI の AutoML でトレーニングしたモデルは Vertex AI Endpoints を使うことでホスティングすることが可能です。手軽な反面、ホスティングする場合は常時稼働コストがかかってしまうため「たまにしか実行しない」ようなユースケースでは余剰リソースが発生してしまいます。
Vertex AI Model Registry からモデルをエクスポートし、コンテナ化して Cloud Run でホスティングすることにより、0 から N にスケール可能なホスティングが可能になります。
Dialogflow + Cloud Run (チャットボットの Webhook)
Dialogflow + Cloud Run (チャットボットの Webhook)
Dialogflow はチャットボットを簡単に作ることができるサービスです。受け答えは Dialogflow の中で設計しますが、複雑性をともなう処理を行ったり、チャットの会話の結果としてアクションに繋げる (例 : 会話を通して商品を購入する) 場合は Webhook を使います。Webhook の呼び先として Cloud Run サービスを用意し、Dialogflow を拡張することができます。
会話型の生成 AI アプリケーションを構築できる Vertex AI Conversation もバックエンドは Dialogflow になっていますので、このアーキテクチャをそのまま適用することも可能です。
まとめ
Cloud Run を中心にした、色々なユースケースをアーキテクチャとして紹介しました。これらの多くはお客様からの実際のお問い合わせを元にしています。いずれかのアーキテクチャが、実際のアーキテクチャを考える上での参考になれば幸いです。
23 個も考えられるかな？と思いましたがいざ挙げてみると書ききれませんでした。来年は他にも紹介する機会を持ちつつ、実際の構築方法も紹介できればと思います。
ぎりぎりになりましたが、メリークリスマス！🎄そして良いお年を！🎍
Discussion