Scrap Book

Insights and updates

TailscaleをCloud Runで使ってはいけない?初回アクセスが120秒→2秒に改善したVPN構成の見直し

TailscaleをCloud Runで使ってはいけない?初回アクセスが120秒→2秒に改善したVPN構成の見直し

2025年6月27日 | Tool

Google CloudのCloud Runと、軽量VPNとして人気のTailscale。この組み合わせで社内向けWebアプリを構築したところ、初回アクセスがなんと120秒かかるという予想外の問題に直面しました。

今回はその経緯と、最終的にGoogle Compute Engine(GCE)に移行して初回アクセス時間を2秒以下にまで改善した実例をご紹介します。

背景:Cloud Run × Tailscale で社内向けアプリを構築

私たちは社内利用のための軽量なWebアプリケーションをGoogle Cloud Run上にデプロイしていました。Cloud Runはスケーラブルで手軽に利用できるため、特に小規模なアプリケーションのホスティング先として非常に便利です。

ただし今回のアプリは社内向けで外部公開したくないため、VPNを使って社内ネットワーク経由でのみアクセスできるようにする必要がありました。そこで選んだのが、安全な接続が可能な「Tailscale」です。

構成の概要

  • フロントエンド:Next.js(静的/動的混在)
  • ホスティング:Google Cloud Run
  • VPN:Tailscale

Cloud Run上のコンテナに、Tailscaleのサービスを同居させ、自動的にVPN接続を開始する構成です。こちらを参考に作成しました。

問題:初回アクセスに120秒もかかる…

アプリケーションは正しく動作しましたが、VPN越しにWebアプリへアクセスすると、初回アクセスが非常に遅いという致命的な問題が発生します。

どれほど遅いのか?

実際の計測では、アプリケーション自体は軽量にもかかわらず、初回アクセスに120秒前後かかっていました。再アクセスすれば数秒で表示されるのですが、インスタンスがスリープ状態の時は常に大幅な遅延が発生しました。

遅延の原因はどこにあったのか?

問題の原因は複数ありました。主な要因は以下の通りです。

1. TailscaleのUser-mode VPN

Cloud Runではカーネルモードが利用できないため、Tailscaleはuser-modeで動作します。これにより、パフォーマンスが大幅に低下し、VPNの確立にも時間がかかりました。

2. MTU(最大転送単位)の問題

VPNを使うと、パケットの分割(フラグメンテーション)が発生しやすくなります。MTUサイズが最適でないと通信が不安定になる場合もあります。
このGithubのIssueにもあるようにMTUを1024に設定しなければ、私の環境でも動作しませんでした。

解決策:Compute Engineへ移行して60倍の高速化

このようにCloud Runではさまざまな制約があり、VPN構成としては実用的ではないと判断。そこで、より自由度の高いGoogle Compute Engine へ移行することにしました。

GCEのメリット

  • カーネルモード が利用可能
  • UDP通信が可能
  • OSレベルでMTUなどネットワーク設定が自由に調整可能

結果として、初回アクセスは120秒から2秒以下に改善。VPN越しでも、待ち時間を意識せずに利用できる快適な環境になりました。

結論:VPN用途ではCloud Runは適さない場合もある

Cloud Runは便利なサービスですが、VPNや低遅延が求められる構成には向いていないことが今回の事例から明らかになりました。Tailscaleのような強力なVPNソリューションも、動作環境に応じてパフォーマンスが大きく変わることに注意が必要です。

まとめ

Tailscaleは優れたVPNサービスですが、Cloud Runのような制約の多い実行環境ではパフォーマンスを十分に引き出せませんでした。Compute Engineに移行することで、通信速度・安定性の両方が大きく改善されました。

「便利なはずの構成がうまくいかない」そんなときは、実行環境との相性をもう一度見直してみることをおすすめします。