01/ 02アーキテクチャ
Cloudflare中心アーキ
同じ SSR アプリを Cloud Run と Cloudflare Containers の両方で無改修で動かした実例 — 違いは課金の出方・固定IP・環境の器
同じ Node の SSR コンテナは、Cloud Run と Cloudflare Containers のどちらでも無改修で動きました。違いはアプリ本体ではなく、その周りに集まります。
- 課金は『待機に払う』か『使った分だけ・寝たらゼロ』か
- 固定IPの出口は Cloud Run の得意・Cloudflare の苦手
- 環境の器は GCP=プロジェクト、Cloudflare=Worker
今回の実験は「同じアプリを、2つのクラウドで同時に動かす」ものです。React Router の SSR サーバを詰めた Node のコンテナを、これまでの Google Cloud Run に加えて Cloudflare Containers でも動かしました。アプリ本体は1行も変えていません。
各ブロックや矢印をクリックすると、その仕組みの説明がここに表示されます。
入口を挟まず HTTP を直接コンテナへ — 部品が少ない
この図をテキストで読む
構成図「同じコンテナ、届け方が2通り」。ブロック6個、つながり4本。 枠: Cloud Run（HTTP を直接コンテナへ）（ブロック3個）、Cloudflare（Worker が受けてコンテナへ）（ブロック3個）。 【ブロック】 - 利用者: ブラウザ - Cloud Run: HTTP を直接受ける - コンテナ（SSR）: Node のアプリ本体 - 利用者: ブラウザ - Worker: 入口（エッジ） - コンテナ（SSR）: Node のアプリ本体 【図の符号】緑の枠=関門・経由点 / 赤紫の枠=データの置き場 / 青の囲み枠=境界の囲み 【流れ】 - Cloud Run：HTTP を直接: 利用者 → Cloud Run → コンテナ（SSR） - Cloudflare：Worker 経由: 利用者 → Worker → コンテナ（SSR）
同じイメージが両方で動くのは、Cloudflare Containers が普通の Node コンテナをそのまま動かせるからです。だから DB（Neon）への接続も、リアルタイム通信も、無改修で動きました。変わるのは中身ではなく、その周り ── 入口・課金・出口のIP・環境の分け方です。