Cloud Runを試してみる

当社はしばらくの間、ワークロードの一部をサーバーレスインフラへ移行することを検討してきました。当初は AWS Lambdaを本命のソリューションとして考えていましたが、Cloud Runが 標準でコンテナをサポートしていることは、既存コンテナの移行コストを下げるため魅力的な選択肢でした。

当初はまず、静的でないWebサイトを移行することを検討しました。以下は、それを使って学んだことと、なぜまだ本格運用には 適していないと判断したのかです。

ワークロードの移行

コンテナがすでにGCRに保存されている場合、Cloud Runの設定は非常に簡単です。Cloud Runが設定する$PORTで待ち受けるよう、 コードを適応させる必要がありました。これは予想より複雑であることが判明しました。当社はNginxを使っており、その設定は 設定ファイル内での環境変数をサポートしていないためです。

選択肢は、LUAやPERLのようなスクリプト言語を使って環境変数からNginxの変数を作成するか、あるいはenvsubstを使って 設定テンプレートを変換し環境変数の値を置換するかのいずれかでした。

暗号化されたトラフィック

Cloud Runの明確な利点の一つは、TLS/SSLエンドポイントの設定をCloud Runが引き受けてくれるため、もはや自分で設定する 必要がなくなることです。

これは、TLS設定のベストプラクティスやサポートすべきプロトコルなどに関して最新の状態を保ち続ける必要がなくなるため、 セキュリティの向上をもたらします。ただしこれは、厳格なポリシーを持ちたい、あるいは古いブラウザーをサポートしたいと 考える場合に、裁量の余地を狭めることにもなります。

こうした場合、設定する手段のないマネージドなTLS設定は大きな問題となります。

外部サービスへの接続

サービスが起動して稼働し始めると、SQLデータベースへの接続について不満を述べ続けました。驚いたことに、Cloud Runは 内部のGoogleサービスへの接続のみをサポートしています。GCP上で動いていないデータベースはサポートされていません。

これはまた、外向きの接続を必要とするいくつかのユースケースにおいて、Cloud Runの有用性を制限します。どうしてもそれが 必要な場合は、専用のGKE上でCloud Runを動かすことも可能ですが、その設定が非常に複雑でドキュメントも明確でなかったため、 当社は単に断念しました。

テストを続けるため、最終的にCloud SQLを使ってGCP上にデータベースを構築しました。ただしSQL接続は、/cloudsql/で コンテナにマウントされるソケットファイルを使って行われます。

これの設定にもコードの変更が必要でしたが、非常に簡単でした。本当に面白かったのは、IAMポリシーのエラーと欠落している APIに対処しなければならなかったときです。経験するのは楽しくありませんが、いったん動くようになれば、同じサービス アカウントを再利用してデータベースに接続するのは造作もなく、明らかにより安全です。

スケーリング

Cloud Runのセットアップが済みDB接続も動くようになると、真価が問われる瞬間、すなわちどれほどうまくスケールし性能を 発揮するかが訪れました。

数千もの接続をサービスに解き放ったところ、見事に機能し、1k QPSに達し、1.6k QPSまでスパイクしました。

スケーリングは嬉しい驚きで、標準でそのまま機能しました。プロビジョニングが不足している場合は、データベースが ボトルネックになる可能性があります。

レイテンシー

残念ながら、決め手となったのはレイテンシーでした。当社のWebサイトで良いユーザー体験を提供するには、比較的低い レイテンシーを維持することが重要でした。

現在のレイテンシーは平均で40 msから2000msの間で変動し、95パーセンタイルでは3000 msでした。

Cloud Runのレイテンシーは4000msから8000msとひどいものでした。コールドスタートのあとにレイテンシーが下がるのは 確認できましたが、それでも達成される値は600msから4000msと高く、頻繁に8000msまでスパイクして戻っていました。

結論

Cloud Runは非常に有望に見え、標準でコンテナをサポートしているため明らかに大きな可能性を秘めています。Cloud Buildとの 連携も、デプロイを自動化するうえで大きなプラスのように思えます。

外向きの接続をサポートしていないことが、その有用性と連携のシナリオを制限しています。これは、DDoS攻撃を実行するために サービスが悪用されるのを避けるために行われているのだと推測しています。

スケーリングの数値は印象的ですが、レイテンシーが非常に問題であり、これがWebサイトやAPIすら運用するうえでの有用性を 制限しています。

外向きの接続を必要としない限り、レイテンシーに敏感でない作業にこのサービスを使うことは、依然として選択肢の一つです。