コンテナイメージをビルド・起動できるホスティングでも、実行モデルが常時稼働サーバーとは限らない。リクエスト駆動で増減し、アイドル時に停止するステートレス実行基盤へ移す場合、同じイメージが起動することと、アプリケーションの意味が保たれることは別問題として扱う。

判断基準

移行可否は、まず「HTTP を所定ポートで待ち受けられるか」というイメージ互換性を確認し、その後に次の実行モデル差分を独立に監査する。

• 起動回数: プロセス起動時の migration、seed、外部通知などは、スケールアウトや再起動のたびに多重実行される。起動処理から外し、デプロイ工程の単一実行ジョブへ分離する。
• 状態のスコープ: ローカルファイル、プロセス内キャッシュ、セッション、レート制限カウンターは、インスタンス間で共有されず停止時に消える。正しさやセキュリティに使う状態は外部ストアへ置く。プロセス内状態は失われても正しさが壊れない最適化に限定する。
• DB 接続: インスタンス数と各プロセスの接続プール上限を掛けた値が DB の接続上限を超えないようにする。単一サーバー時代の無制限プールをそのまま持ち込まない。
• 要求の寿命と形: 最大処理時間、要求・応答サイズ、ストリーミング、双方向接続、バックグラウンド処理の制約をエンドポイントごとに照合する。要求より長く生きる仕事はキューや durable workflow へ分離する。
• ネットワーク: 実行リージョンとデータの距離、固定 egress IP、私設ネットワーク、前段 proxy が渡すクライアント IP の信頼境界を確認する。外部 DB へ到達できることだけでなく、TLS、接続元制限、遅延まで含めて判断する。
• デプロイ単位: 複数サービスの一体デプロイ機能は、同一リポジトリなどの前提を持つことがある。既存のリポジトリ境界と preview 環境への秘密・DB 接続先を確認する。

検証方法

アプリの全状態と副作用を列挙し、それぞれに「要求、プロセス、デプロイ、永続」のどの寿命を期待しているかを付ける。次に、想定基盤で複数インスタンス起動、停止後の再起動、同時要求、preview デプロイを試し、起動副作用の多重化、状態消失、DB 接続数、IP 解決、外部サービス疎通を観測する。イメージの起動成功だけを移行完了条件にしない。