Cloud Service Mesh for Cloud Runに夢を託してみた
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
Cloud Runで解決したい課題をCloud Service Mesh for Cloud Runで解決できないか検討したり試してみたりしました。
このブログ内の情報は2024/12/01時点のものです。
Cloud Service Mesh for Cloud Run とは解決したい課題課題A gRPCを利用したアプリケーションにおける複数のDev環境の増え続けるBackend Service課題B gRPCを利用したアプリケーションにおける即座にすべてのトラフィックが切り替わる Blue / Green デプロイ夢見た理想の解決案。そして、結論できない課題Aに対する理想Aと検討結果課題Bに対する理想B理想Bの検討 with Bookinfo構成説明Terraformサンプル検討結果 NEGでCloud Runのtag指定出来れば…その他 Cloud Service Mesh for Cloud Runに夢見ていること終わりに
Cloud Service Mesh for Cloud Run とは
記事執筆時点でプレビュー段階の機能です。
Cloud Service Meshによる高度なトラフィック管理機能をCloud Runでも利用できるようになりました。
詳細については下記公式ドキュメントをご参照ください。
解決したい課題
課題A gRPCを利用したアプリケーションにおける複数のDev環境の増え続けるBackend Service
Dev環境において、dev01 dev02などの環境ごとに異なるバージョンのアプリケーションをCloud Runにデプロイしています。Cloud Runごとに図1のようにBackend Serviceを作成する必要があります。
この構成の課題として、Cloud Armor Enterprise Paygo/Annual※1を有効化するとpolicyを設定していなくてもBackend Serviceの数だけ課金される点があります。Prod環境と同様のCloud Armor Enterprise設定をDev環境(またはStg環境)で試したい場合にこの点がネックとなります。
※1 Cloud Armor Enterprise Annualの課金体系について
保護対象リソース100件までは$3,000/月の固定料金で、100件を超えると1保護対象リソースごとに$30/月となります。(図2参照)
保護対象リソースはBackend ServiceとBackend Bucketが対象で、Cloud ArmorのPolicyを適用していなくてもカウント対象となります。詳細はドキュメントをご参照ください。
課題B gRPCを利用したアプリケーションにおける即座にすべてのトラフィックが切り替わる Blue / Green デプロイ
トラフィックの移行を使ったリビジョンの切り替えでは、100%Greenリビジョンにトラフィックが変わるように設定したとしても、変更適用後にトラフィックが切り替わるまでの間に、Blueリビジョンにリクエストが行く場合があります。※2
後方互換性の無いリリースの場合は、この挙動は許容出来ません。
夢見た理想の解決案。そして、結論できない
課題Aに対する理想Aと検討結果
Backend Serviceを減らすために、NEGの集約をCloud Service Meshで出来ないかと思いを馳せてみました。(図4)
図4はCloud Service Mesh for Cloud Runについて調べる前に思い描いた理想図です。
Istioが提供しているサンプルアプリケーションBookinfoを例に検討しました。
(本来使いたいDev環境ではgRPCで通信するため、gRPCRouteを使います。)
図5がCloud Service Mesh for Cloud Runについて調べた結果です。Cloud Service Meshは、Backend Serviceに至るまでの経路を制御するものであって、NEGやBackend Serviceをまとめる機能は持っていませんでした。
課題Bに対する理想B
課題Bと同様に思いを馳せてみた構成が図6になります。この構成でHTTPRouteを変更し、reviews-v3がレスポンスを返し始めたタイミングでreviews-v2がレスポンスを一切返さなくなることが理想です。
(本来使いたいAPIではgRPCで通信するため、gRPCRouteを使いますが、BookinfoでテストするためHTTPRouteを使用しています。)
実際に構築できたものが図7です。Cloud Service Meshの場合はリビジョン tag指定のNEGをBackend Serviceに登録できないため、リリースバージョンごとにCloud Run サービスを別で作成する必要がありました。運用を考えるとこの構成は許容出来ないと結論付けました。
理想通りにすべてのトラフィックが切り替わるのかを確認する性能試験は実施していません。
理想Bの検討 with Bookinfo
実際に構築できるのかIstioのサンプルアプリケーションBookinfoで試した際に使用したTerraformを示します。
構成説明
今回はBookinfoを利用しているため、HTTPRouteを使っていますが、gRPCRouteでも今回使用している設定と同等の設定が可能です。
HTTPRouteに指定するBackend Serviceを切り替えることでバージョンの切り替えを行います。
Terraformサンプル
Bookinfoを構築するterraformコードのサンプルを示します。
exampleの部分は適宜修正してご利用ください。
検討結果 NEGでCloud Runのtag指定出来れば…
Cloud Service Meshでは、backend Serviceは を使用する必要がありますが、この場合Cloud Runのtagを指定したNEGを使うことができませんでした。(図8参照)
この制約により、リリースバージョンごとにCloud Runサービスを作成する必要がありました。
その他 Cloud Service Mesh for Cloud Runに夢見ていること
LBから直接Cloud Service Mesh 経由でCloud Runにアクセスできるようになると嬉しいなと思います。Cloud Runサービス間のトラフィックをより良くする役割として登場したようですので、この機能は役割からズレていますが。
終わりに
本記事では、以下の課題をCloud Service Mesh for Cloud Runで解決できるか試し、解決できないと結論付けました。
- gRPCを利用したアプリケーションにおける複数のdev環境のBackendServiceを統一
- gRPCを利用したアプリケーションにおけるトラフィックが即座に切り替わるBlue / Green デプロイ
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。
