Summary
この文書の要点
- SSRが必要なページと静的化できるページを分ける。
- Cloud Runでは起動時間、ヘルスチェック、同時実行数を見る。
- SSRサーバーはステートレスにし、セッションやキャッシュの置き場所を明示する。
- Cloud Runの同時実行数、CPU、最小インスタンスをレンダリング特性に合わせて調整する。
どこが設計の難所か
SSRアプリをCloud Runへ載せると、コンテナ起動、Nodeプロセス、外部API呼び出し、レンダリングエラーが利用者の表示に直結します。静的サイトの感覚で運用すると、障害時の切り分けが難しくなります。
Cloud Runはリクエストに応じてスケールするため、コールドスタートや同時実行数を考える必要があります。SSRで外部APIを呼ぶ場合、API遅延がHTML応答全体を遅くします。
SSRは初期表示やメタタグ制御に利点がありますが、サーバー実行になるため運用対象が増えます。Cloud Runではコールドスタート、同時実行、タイムアウト、ヘルスチェックがユーザー体験に直結します。
境界をどう切るか
SSRが必要な理由をページ単位で確認します。認証や動的メタデータが不要なページは静的生成に寄せ、SSRページではデータ取得のタイムアウト、エラー時表示、キャッシュを設計します。
設計では、SSRで必要なデータ取得、静的assets配信、API呼び出し、認証を分けます。Cloud Runのコンテナはステートレスに保ち、リクエストごとの状態はCookie、外部DB、外部キャッシュへ置きます。
実装で効く細部
DockerではNode実行に必要な成果物だけを含め、ヘルスチェック用の軽いエンドポイントを用意します。Cloud Runの同時実行数、最小インスタンス、メモリを実測で調整します。ログにはURL、ステータス、レンダリング時間を残します。
DockerfileではNode.jsサーバーとbuild成果物を明確に分け、health endpointを用意します。ログにはリクエストID、route、レンダリング時間、データ取得時間を出し、遅いページを特定できるようにします。
- SSRで秘密情報をHTMLへ埋め込まないよう、環境変数とpublic configを分ける。
- 静的assetsはCloud Run経由かCDN経由かを決め、キャッシュヘッダーを分ける。
- コールドスタートが問題になるページでは最小インスタンスや軽量化を検討する。
壊れ方を観測する
検証では、直接アクセス、リロード、外部API遅延、SSR例外、コールドスタート、デプロイ直後の旧新リビジョン混在を確認します。Playwrightで主要ページのHTMLメタも見ると安心です。
検証では、初回アクセス、連続アクセス、深いURL、404、認証ページ、API遅延を確認します。Lighthouseだけでなく、Cloud Runログ上のレンダリング時間を見て、どこが遅いかを切り分けます。
捨てた選択肢とトレードオフ
SSRは柔軟ですが、静的配信より運用対象が増えます。SEOや認証前初期表示など明確な理由がないページはSSGやSPAに寄せた方が軽く保てます。
SSRはSEOや初期表示に強い一方、運用の複雑さが増えます。すべてのページをSSRする必要がない場合は、静的生成やクライアント取得と組み合わせる方が合理的です。
現場に残す判断軸
React Router SSRをCloud Runで使うなら、レンダリングをアプリの重要なサーバー処理として扱う必要があります。ページごとにSSRの価値を確認し、監視とキャッシュを設計することが重要です。
React Router SSRをCloud Runで運用するなら、フロントエンド実装だけでなくサーバー運用として設計する必要があります。レンダリング時間をログで見えるようにすると、改善の手がかりが残ります。
