インフラ

    2025.07.28

    HerokuからAWS Fargateへの移行事例|2段階ビルドとCI/CD自動化でアプリ運用を最適化

    プロジェクト概要

    Heroku 上で稼働しているアプリケーションをAWS の ECS(Elastic Container Service)に移行するプロジェクトです。

    アーキテクチャやアプリの大幅な改修は行わず、既存の構成を可能な限り維持する「リフトアンドシフト」方式を採用しました。

    プロジェクト概要フロー

    課題

    以下のように課題を3つに整理しました。

    1. アプリケーション構成の把握とFargate対応 既存Herokuアプリの依存関係・設定・稼働条件を洗い出し、Fargate上で動作するようにアーキテクチャを作成する必要があります。

    2. デプロイパイプラインの構築 GitHub Actionsを活用し、ビルド~デプロイまで自動化されたパイプラインを構築する必要ががあります。

    3. コンテナイメージのビルド Dockerfile作成やビルド手順の整備といった作業が必要となります。

    アプリケーション構成の把握とFargate対応

    Herokuが提供する抽象化された環境に強く依存していたため、アーキテクチャをシンプルに構成しました。

    システム全体の設計として、データベース(RDS)へのアクセスはコンテナ経由に限定されており、アプリケーション本体やマイグレーションもすべてコンテナを通して行う設計となっています。そのため、初期構築時やアップデート時には、専用のDBマイグレーション用コンテナを都度立ち上げて処理を実行する必要がありました。 イメージ図は以下となります

    システム構成概略図

    デプロイパイプラインの構築

    今回は、Herokuからの環境移行(リフトアンドシフト)にあたり、新たにデプロイパイプラインを構築する必要がありました。

    移行後の環境では、Gitの操作をトリガーにデプロイが自動で行われる仕組みを構築したいと考え、GitHub Actions を採用しました。

    パイプライン全体の流れは以下の通りです:

    1. 対象ブランチへのマージをトリガー

    2. GitHub Actions が起動

    3. Docker イメージをビルド

    4. Amazon ECR(Elastic Container Registry)にイメージをプッシュ

    5. AWS Fargate 上のタスクを更新してアプリケーションをデプロイ

    GitHub Actionsを利用したCI/CDパイプラインの詳細なフロー

    コンテナイメージのビルド

    もともとHeroku上で動作していたアプリケーションのため、クラウド環境(Fargateなど)での運用を前提としたDockerfileは存在していませんでした。

    今回のリフト&シフトにあたり、環境をコンテナベースに移行する必要がありましたが、アプリ本体とフロントエンドビルドを分離する構成となっていたため、2段階ビルド(multi-stage build)を採用しました。

    最初のステージでは、Node.js 環境でフロントエンドの依存解決およびビルド(yarn build)を実施。

    次のステージでは、Ruby環境でRailsの依存をインストールし、先ほどのビルド成果物を取り込んで本番環境用のイメージを作成。

    この構成により、不要なビルドツールや開発用の依存を含まない、軽量かつ安全な本番イメージを作成することができました。

    最終的に、このイメージを用いてFargate上での実行にも成功いたしました。

    2段階ビルド(Multi-stage Build)の詳細フロー

    ボトルネックとなった箇所

    ボトルネックとなった箇所はコンテナイメージの2段階ビルドの設計です。

    もともとHeroku上で動作していたアプリケーションのため、クラウド環境(Fargate)での運用を前提とした Dockerfile は存在していませんでした。 そのため、Dockerベースの構成を一から設計し直す必要がありました。

    特に時間を要したのは、アプリ本体とフロントエンドのビルド工程が分かれていたことです。 これにより単純なイメージビルドでは対応できず、2段階ビルドの導入が必須となりました。

    最初のステージでは Node.js 環境を用いて、フロントエンドの依存解決およびビルドを実行。

    次のステージでは Ruby 環境で Rails の依存をインストールし、前段で生成されたフロントエンドのビルド成果物を取り込んで、本番用の軽量なイメージを構築。

    この構成にたどり着くまでに、環境の切り分けやアセットの受け渡し、依存の関係の整理など、調整作業に多くの時間を要しました。

    最終的には、本番イメージの作成に成功し、Fargate 上で安定して動作させることができました。

    成果

    今回のリフトアンドシフトにより、Herokuに依存した運用から脱却し、AWS上での柔軟かつ拡張性のある運用基盤へと移行することができました。

    1. Herokuのビルドパック依存から脱却し、Dockerベースの標準化された環境構築に成功

    2. GitHub Actions による自動デプロイパイプラインを整備し、CI/CD の効率化を実現

    3. 2段階ビルドによる軽量で本番向けのコンテナイメージ作成により、セキュリティと保守性を向上

    4. Fargate + RDS という構成により、サーバーレスかつスケーラブルな実行基盤を構築

    アプリケーション自体はモノリシックな構成のままですが、インフラと運用面をモダナイズすることで、今後のスケールやマイクロサービス化にも対応しやすい土台を整えることができました。

    お問い合わせはこちら
    ホーム

    |

    システム開発事業

    |

    開発事例

    |

    HerokuからAWS Fargateへの移行事例|2段階ビルドとCI/CD自動化でアプリ運用を最適化

    お問い合わせ

    サービスに関するご質問や、取材・パートナーシップのご相談などはこちらからお気軽にご連絡ください。

    trending_flat

    お問い合わせはこちら

    採用について

    チームのビジョンに共感し、共に前進できる仲間を探しています。一緒に働いてみませんか?

    launch

    採用情報はこちら