Heroku から Cloud Run / Render への移行｜コンテナ化の最小ステップ

長年、Webアプリケーションのホスティング先としてデファクトスタンダードであったHerokuですが、料金体系の変化やエコシステムの成熟に伴い、より柔軟でコスト効率の高いプラットフォームへの移行を検討するフェーズが来ています。特に、Google Cloudが提供するCloud Runや、Herokuの使い勝手を継承したRenderは、有力な移行先候補です。

本記事では、エンジニアが実務で直面する「Herokuからの脱却」をテーマに、既存のソースコードを最小限の手間でコンテナ化し、新しい環境で安定稼働させるための具体的なステップを解説します。インフラの刷新は単なるコスト削減に留まらず、スケーラビリティの確保やデプロイフローの高速化に直結する重要なプロジェクトです。

Herokuから移行すべきタイミングとプラットフォームの選び方

移行を検討する最大のトリガーは、「コストと柔軟性のバランス」です。Herokuは非常に優れたPaaS（Platform as a Service）ですが、アドオンの料金が割高であったり、インスタンス（Dyno）のスペック選択肢が限定的であったりするという側面があります。

Render：Herokuに最も近い「PaaS的」な選択肢

Renderは、Herokuのシンプルさを好む開発者に最適な移行先です。GitHubと連携するだけで自動ビルド・デプロイが行われる仕組みはHerokuそのものであり、学習コストを極限まで抑えることができます。また、静的サイトのホスティングが無料である点や、マネージドデータベースの料金が比較的安価である点が魅力です。

Cloud Run：GCPのエコシステムを活かす「サーバーレスコンテナ」の決定版

一方、将来的な拡張性や、他のGoogle Cloudサービス（BigQueryやCloud Storageなど）との連携を重視するなら、Cloud Runが第一候補となります。リクエストがない間はインスタンスをゼロにする「完全従量課金」が可能なため、アクセスに波があるサービスでは劇的なコストダウンが期待できます。

【比較表】Heroku vs Render vs Cloud Run

各プラットフォームの主要な特性を以下の表にまとめました。自社のプロジェクト規模や運用体制に合わせて選択してください。

もし、インフラの刷新と同時にバックオフィス業務の最適化も進めているのであれば、SaaSコストとオンプレ負債を断つための現実的なアプローチについての知見も、長期的なアーキテクチャ設計の参考になるはずです。

移行前の準備：アプリケーションのコンテナ化（Docker化）

RenderやCloud Runへ移行するための「共通チケット」が、アプリケーションのコンテナ化です。HerokuではBuildpackが自動で言語を判別してくれましたが、モダンな移行先ではDockerfileを用意するのが一般的です。

Dockerfileの作成：最小構成のテンプレート

例えば、Node.jsアプリケーションの場合、プロジェクトのルートディレクトリに以下のようなDockerfileを作成します。

ベースイメージの指定

FROM node:18-slim

作業ディレクトリの設定

WORKDIR /usr/src/app

依存関係のコピーとインストール

COPY package*.json ./
RUN npm install --production

ソースコードのコピー

COPY . .

環境変数PORTのデフォルト値（移行先から渡される）

ENV PORT=8080

アプリケーションの起動

CMD [ "npm", "start" ]

環境変数（PORT）の動的読み込み設定

ここが最も重要なポイントです。Herokuと同様、RenderやCloud Runは実行時にPORTという環境変数を通じて、アプリケーションがリッスンすべきポート番号を指定します。コード内で3000などのポート番号をハードコードしている場合は、必ず以下のように修正してください。

// JavaScriptでの例
const port = process.env.PORT || 8080;
app.listen(port, () => {
console.log(Server running on port ${port});
});

パターンA：Renderへの移行手順（最小ステップ）

Renderへの移行は、驚くほどスムーズです。以下の手順で進めます。

1. GitHub連携: RenderダッシュボードでGitHubアカウントを紐づけ、対象のリポジトリを選択します。
2. Service Typeの選択: 「Web Service」を選択します。
3. Runtimeの設定: Dockerfileがリポジトリにある場合、Renderは自動的にDocker環境として認識します。
4. 環境変数のインポート: Herokuの管理画面からConfig Varsをコピーし、Renderの「Environment」タブに貼り付けます。
5. データベースの作成: Render上で「New PostgreSQL」を作成し、払い出された内部接続URL（Internal Database URL）をアプリケーションの環境変数に設定します。

Renderは、無料枠や安価なプランでもSSLが自動更新されるため、証明書の管理に悩まされることはありません。

パターンB：Cloud Runへの移行手順（本格運用向け）

エンタープライズ用途や、将来的なトラフィック増が見込まれる場合は、Cloud Runへの移行を推奨します。Google Cloudの堅牢なネットワーク基盤を利用できるメリットは計り知れません。

Cloud Buildによるコンテナイメージのビルド

Google Cloudでは、ローカルでイメージをビルドしてアップロードするよりも、Cloud Buildを利用するのが効率的です。以下のコマンドで、ソースコードからコンテナイメージを作成し、Artifact Registryに保存できます。

gcloud builds submit --tag gcr.io/[PROJECT-ID]/my-app

Cloud Runへのデプロイと最小インスタンスの設定

Cloud Runへのデプロイ時には、メモリやCPUの割り当て、最大・最小インスタンス数を指定します。特に「コールドスタート（初動の遅れ）」を避けたい場合は、--min-instances 1を設定することで、常に1つ以上のインスタンスを待機状態にできます。

大量のデータを扱うアプリケーションであれば、Cloud RunからBigQueryへシームレスにデータを流し込む設計も可能です。例えば、BigQueryとリバースETLを用いたアーキテクチャを構築することで、インフラ移行を機にデータ活用を加速させることができます。

データベースと静的ファイルの移行

アプリケーションの「脳」であるデータの移行には、細心の注意を払う必要があります。

Heroku Postgresからデータをエクスポート・インポートする

Heroku Postgresのデータを移行する際は、pg_dumpコマンドを使用します。Heroku側でメンテナンスモードを有効にし、データの整合性を担保してから作業を行ってください。

Herokuからバックアップを作成

heroku pg:backups:capture --app [YOUR-HEROKU-APP]
heroku pg:backups:download --app [YOUR-HEROKU-APP]

移行先（例：Cloud SQL）へインポート

pg_restore -h [DB_HOST] -U [DB_USER] -d [DB_NAME] latest.dump

画像・動画ファイルをCloud Storage / S3へ逃がす

Herokuの「エフェメラル・ファイルシステム」と同様、移行先でもコンテナ内のファイル保存は永続化されません。アップロードされた画像等は、必ずGoogle Cloud StorageやAWS S3などの外部ストレージに保存するようコードを修正してください。

移行後によくあるトラブルと対処法

無事にデプロイが終わっても、本番環境特有の挙動でエラーが発生することがあります。

• 504 Gateway Timeout: Cloud Runのデフォルトのタイムアウト設定（通常60秒）を超えている可能性があります。重い処理はCloud Tasksなどのキューイングサービスに逃がすか、タイムアウト設定を延長してください。
• Memory Limit Exceeded: コンテナに割り当てたメモリが不足すると、インスタンスが強制終了します。HerokuのDynoよりもメモリ効率が変わる場合があるため、移行直後はメトリクスを注視し、必要に応じてスペックを調整してください。
• DB接続エラー: 移行先のDBのファイアウォール（IP制限）が原因であることが多いです。Renderなら「Allow connections from any IP」の設定（セキュリティに注意）、Cloud Runなら「Cloud SQL Proxy」の利用を確認してください。

こうしたインフラ側での自動化が進むと、副次的に他の業務プロセスも自動化したくなるものです。例えば、経理業務の完全自動化のように、APIを活用して手作業を排除する思想は、インフラエンジニアの「自動化マインド」と非常に親和性が高いと言えます。

まとめ：インフラ刷新がもたらす開発効率の向上

HerokuからCloud RunやRenderへの移行は、単なるサーバーの引っ越しではありません。コンテナ化という標準的な技術スタックを手に入れることで、特定のプラットフォームへのロックインを防ぎ、開発チームに高度な柔軟性をもたらします。

「とりあえず動く」状態から、スケーラビリティとコストパフォーマンスを両立した「強いインフラ」へ。本ガイドのステップを参考に、一つずつ確実に移行を進めてみてください。公式サイトのドキュメント（Heroku Dev Center, Render Docs, Google Cloud Run Docs）には、最新の仕様変更が反映されているため、実作業の前には必ず目を通すことをお勧めします。