Cloud Load Balancing: Cloud Run サービスへの安全なプライベート アクセスを実現する包括的なソリューション
Google Cloud Japan Team
※この投稿は米国時間 2023 年 4 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。
このたび、内部 HTTP(S) ロードバランサのバックエンドとして Cloud Run サービスの一般提供を開始しましたことをお知らせいたします。この新機能によって、Google Cloud 上、オンプレミス、または他のクラウド上のサービスやクライアントと Cloud Run サービスの間でプライベート接続を確立できます。Cloud Run で内部ロードバランサを使用すると、カスタム ドメイン名を使用できる、レガシー サービスからのトラフィックを移行できる、ID とコンテキストに基づいてアクセスを保護できる、複数のサービスに対応する単一の内部レイヤ 7 ロードバランサを構成できるなどの利点があります。
今回のリリースの一環として、Cloud Run サービスがリージョン外部 HTTP(S) ロードバランサのバックエンドとしても一般提供されました。
Cloud Run について
Cloud Run は、コンテナを実行するフルマネージド型のサーバーレス コンピューティング環境です。Kubernetes クラスタや VM のプロビジョニング、構成、管理といったインフラストラクチャ管理をユーザーが行う必要は一切ありません。デベロッパーはインフラストラクチャを気にすることなく、業務上最も重要なタスクである、アプリケーションの作成に専念できます。デベロッパー エクスペリエンスが向上する以外にも、Cloud Run にはサーバーレス環境として企業に好まれる主なメリットが多数あります。
内部 HTTP(S) ロード バランシングについて
Google Cloud Load Balancing は、ワークロードのデプロイ環境がクラウドかオンプレミスかにかかわらず、アプリケーションの大規模展開に役立つフルマネージド サービスです。高可用性やセキュリティの要件にも対応できます。
内部 HTTP(S) ロードバランサは Google Cloud のプロキシベースのレイヤ 7 ロードバランサです。内部 IP アドレスの背後でサービスを実行してスケールできます。このロードバランサは Google の次世代ロードバランサの一つで、すぐに使用できる高度なトラフィック管理機能（トラフィックのミラーリング、重み付けに基づくトラフィック分割、リクエスト / レスポンスに基づくヘッダー変換など）に対応しているため、トラフィックの処理方法をきめ細かく制御できます。Google のロードバランサはオープンソースの Envoy Proxy を基盤としており、Google Cloud だけでなく、他のクラウドやオンプレミスにもトラフィック管理を拡張できます。
Cloud Run サービスで内部 HTTP(S) ロード バランシングを使用するメリット
内部ロードバランサ経由でプライバシーを保護しながら安全に Cloud Run サービスにアクセスする
Cloud Run は VPC で動作しませんが、内部 HTTP(S) ロードバランサを使用して、VPC ネットワーク内のクライアントから Cloud Run サービスへの（プライベート IP アドレスを使った）プライベート アクセスを許可できます。ロードバランサのネットワークにピアリングされた他のネットワークのクライアントでも可能です。つまり、Google Cloud VM で実行されている他のサービスが Cloud Run サービスに非公開でアクセスできます。同様に、VPN トンネルまたは相互接続のアタッチメントを使用して、オンプレミス サービスまたは他のクラウド サービスによる Cloud Run デプロイメントへのアクセスを許可できます。
カスタム ドメイン名を構成する
内部 HTTP(S) ロードバランサを使用してカスタム ドメインを設定できます。プライベート クライアントは、デプロイされたサービスに Cloud Run が提供するデフォルトの URL アドレスではなく、このドメインを使って Cloud Run サービスにアクセスできます。内部 HTTP(S) ロードバランサのルーティング ルールを構成するときに、Cloud Run サービスのカスタム ドメイン名または URL を指定し、サービスにアクセスする必要がある他のサービス オーナーやユーザーと共有できます。ロードバランサがドメイン名や URL パスなどに基づいてトラフィックをルーティングする仕組みについては、こちらをご覧ください。
Identity-Aware Proxy を使用してアクセスできるユーザーを制御する
Identity-Aware Proxy（IAP）を使用してユーザー ID を確認し、コンテキストを使ってユーザーに Cloud Run サービスへのアクセス権を付与すべきかどうかを判断できます。IAP を内部ロードバランサのバックエンド サービスで有効化すると、すべてのアクセス制御構成を一元管理できます。さらに、制限付きの上り（内向き）設定と VPC Service Controls 境界を使用して、内部ロードバランサ経由と、安全な VPC 境界内のリソース経由でのみ Cloud Run サービスにアクセスできるようにすることが可能です。
レガシー サービスからのトラフィックを移行する
内部 HTTP(S) ロード バランシングでは、複数のバックエンド間での割合に基づいたトラフィック分割を可能にする重み付けによるトラフィック分割がサポートされます。たとえば、まずは本番環境トラフィックのごく一部（1% など）を Cloud Run 上のサービスの新しいバージョンに送信し、残りのトラフィックを引き続き以前のバージョンに送信します。Cloud Run サービスが想定どおりに動作することを確認したら、シフトするトラフィックを徐々に増やし、安心して新しいバージョンに 100% のトラフィックを移行できます。重み付けによるトラフィック分割を使用してオンプレミス サービスからトラフィックをシフトし、クラウドへの移行を加速させることもできます。
内部 HTTP(S) ロード バランシングでは、重み付けによるトラフィック分割だけでなく、その他の高度なトラフィック管理機能もサポートされるため、HTTP リクエスト パラメータを使って特定のサービスにトラフィックをルーティングしたり、障害を注入してエラーをシミュレートしたりすることが可能です。これらの機能の詳細については、こちらをご覧ください。
同じロードバランサを使用して複数のサービスタイプにトラフィックを分散する
内部 HTTP(S) ロード バランシングのレイヤ 7 ルーティング機能を使用して、複数のサービスを同じロードバランサのバックエンドとして構成できます。これらのサービスは Cloud Run だけでなく、Compute Engine、Google Kubernetes Engine、さらにはオンプレミスでも実行できます。このアプローチにより、すべてのルーティング ルール ポリシーを 1 か所にまとめることができます。ホスト名、IP アドレス、SSL 証明書の単一セットを複数のサービスに関連付けることでネットワーク管理が簡素化されます。
さらに、プロジェクト間のサービス参照を使用すれば、1 つの一元的なロードバランサによって、複数の異なる Google Cloud プロジェクトに分散された何百ものサービスにトラフィックをルーティングできます。これにより、部門ごとの役割分担が実現するため、下図のようにネットワーク チームがその他のプロジェクトのロードバランサをプロビジョニングおよび維持する間に、サービス オーナーは自分のプロジェクトのサービス構築に専念できます。
Cloud Run サービスのリージョン外部 HTTP(S) ロード バランシング
これまでも、グローバル外部 HTTP(S) ロード バランシングによって Cloud Run をデプロイし、外部クライアントの接続を可能にすることはできましたが、リージョン外部ロードバランサも使用できるようになりました。リージョン外部ロードバランサは、その名前が示すように、1 つのリージョンに存在して同じリージョンのワークロードにのみ接続するように設計されています。したがって、リージョン指定の要件（ローカライズ コンプライアンス基準への準拠など）を満たすのに役立ちます。また、リージョン外部ロードバランサはスタンダード Network Service Tier をサポートしているため、ネットワーク パフォーマンスのトレードオフは存在しますが、コスト重視のワークロードを最適化できます。
ご利用方法
Cloud Run サービスをロードバランサのバックエンドとして指定するには、サーバーレス ネットワーク エンドポイント グループを使用します。
Cloud Run サービスのロードバランサをデプロイする際は、設定ガイドをご確認ください。
- Google Cloud、プロダクト マネージャー Anusheel Pareek
