Heroku アプリのライフサイクル

最終更新日 2025年04月16日(水)

Heroku は開発者がアプリケーションを簡単にデプロイ、管理、拡張できるクラウドプラットフォームです。インフラ管理に伴う複雑さの多くを抽象化します。Heroku を効果的に使用するには、アプリのライフサイクルを理解することが重要です。ライフサイクルは開発からデプロイおよびそれ以降まで、アプリがたどるいくつかの異なる段階で構成されます。

1. アプリを開発する

開発フェーズではコードを記述し、それをデプロイする空のアプリを Heroku に作成します。

アプリをデプロイするための準備​も行う必要があります。Heroku でアプリを実行するために多くの変更を加える必要はありませんが、アプリのどの部分が実行可能であるかをプラットフォームに伝える必要があります。

一般的な言語の慣用表現やフレームワークを使用すれば、Heroku によって実行可能部分が認識されます。たとえば、Node.js の場合は、package.json​ 内の main​ フィールドです。その他のアプリの場合、または実行する複数のプロセスタイプを宣言する場合は、Procfile​ と呼ばれるテキストファイルで宣言する必要があります。

開発フェーズにおけるその他の一般的な実務としては、依存関係の統合​、データベースなどのバッキングサービスのアドオン​のインストール、ローカルでのアプリの実行​などがあります。

2. Heroku にコードをプッシュする

完全なデプロイプロセスは、コードをプッシュし、それがビルドをトリガーして、その後リリースという形でデプロイされ、Heroku プラットフォームで実行されるという流れで構成されます。

Heroku は Git ベースのデプロイと CI/CD 統合を通じてデプロイプロセスを簡素化します。コードのプッシュ方法は、デプロイ方法​によって異なりますが、git push heroku main​ と GitHub 統合​が最も一般的です。

3. アプリをビルドする

Heroku プラットフォームにソースコードが渡されると、ソースアプリのビルドが開始されます。

Heroku は Node.js、Python、Ruby、Java など、さまざまな言語の環境と依存関係を構成するのに役立つ複数のbuildpack ​をサポートしています。ほとんどのアプリでは、使用する buildpack が自動的に検出されます。

通常、ビルドの仕組みは言語ごとに異なりますが、基本的なパターンは同じです。通常は、指定された依存関係を取得し、スタイルシートの処理やコードのコンパイルなど、必要なアセットを作成します。結果として得られるビルドアーティファクトには、実行可能な状態にコンパイルされて組み立てられたアプリと、実行内容の指示 (Procfile​) が含まれています。

Fir 世代のアプリのビルドを実行する場合、Heroku はユーザーのデプロイを支援する目的のみにおいて、アプリのソースコードのコピーを保持します。このコピーはビルドごとに更新され、最新バージョンが反映されます。

4. リリースをデプロイする

アプリのビルドが成功すると、新しいリリース​の作成がトリガーされます。新しいリリースを作成する前に、Heroku はリリースフェーズ​で指定されたタスクを実行します (該当する場合)。

アプリのビルドが成功し、該当するリリースフェーズのタスクがすべて正常に実行されると、Heroku によってリリースがデプロイされます。Heroku CI​ またはその他の CI/CD 統合ツールを使用する場合は、テスト実行に合格することをデプロイの要件とすることができます。 コードをプッシュする以外にも、Heroku は環境設定​を変更したり、アプリのアドオンリソースを変更​したりした場合にも、新しいリリースを作成し、アプリを再移動します。

リリースはすべてのアプリ dyno にデプロイされ、Heroku の Preboot​ および Rolling Deploys​ 機能により、ダウンタイムなしでデプロイされます。本番環境に変更を加える前にアプリを十分にテストするには、代わりに Review Apps​ やパイプライン​の機能を使用してビルドを昇格​させることを検討してください。

5. アプリを実行する

デフォルトでアプリは Heroku ドメイン​からアクセスできます。

デプロイ後、アプリはランタイムフェーズに入り、リクエストにアクティブに対応する dyno​ と呼ばれるコンピューティングリソース上で実行されます。Dyno formation に応じて、dyno の一部は web​ プロセスタイプに関連付けられたコマンドを実行し、また一部は Procfile​ で宣言されているほかのコマンドを実行します。

HTTP トラフィックを受信するのは web​ dyno のみです。Heroku の HTTP ルーター​は、アプリへの受信リクエストを、稼働中の Web dyno に分散して振り分けます。このルーティングは、HTTP トラフィックと HTTPS トラフィックの両方を処理し、複数の同時接続とタイムアウト処理をサポートします。

Dyno Manager は、dyno の実行を担当するプラットフォームの一部です。そのジョブには、実行中のアプリで障害が発生したり、基盤となるハードウェアに問題が生じたりした場合に、dyno を再起動することが含まれます。また特段ほかの設定がない限り、アプリの健全性を維持するために、毎日 dyno を再起動します。

6. リソースを拡張する

一般的に、Web トラフィックを処理するためにアプリの処理能力を拡張するには、web​ dyno の数を拡大します。バックグラウンドジョブ​を処理する worker​ dyno など、ほかのプロセスタイプも拡張できます。

Heroku は複数の dyno サイズ​を備えた堅牢なスケーリングモデルを提供しているため、必要に応じてリソースを調整できます。

7. アプリを監視する

アプリがスムーズに実行されるよう、パフォーマンスを監視し、必要に応じて問題をデバッグします。Heroku は、ログ​、メトリクス​、OpenTelemetry​ (Fir 世代​のアプリのみ) などのさまざまな監視ツールと、監視用のアドオン​のサポートを提供します。

8. アプリの更新とメンテナンスを実施する

アプリは、バグ修正、セキュリティパッチ、新機能の追加のために定期的に更新する必要があります。Heroku はアプリを管理および実行するため、プラットフォームの更新とメンテナンス​だけでなく、Heroku Postgres​ などの Heroku 独自のアドオンのメンテナンスもプラットフォームが担当します。

Heroku が提供するアップデートとメンテナンス以外にも、自分でコードベースに必要な変更を加えたり、アプリへのアクセスを一時的に無効にする必要がある場合はメンテナンスモード​に切り替えたりすることもできます。管理タスクを実行するために、One-off dyno​ を実行することもできます。

9. リソースを最適化する

アプリを拡張、監視、更新しながら、コードとリソースの使用量を最適化する方法を見つけます。使用量を最適化する方法のヒントについては、こちらのガイド​を参照してください。

10. アプリを廃止する

アプリが不要になったら、スケールダウン​し、アドオンを削除​して、Heroku から削除​します。アプリの削除は永久的な操作であり、構成、コード、ビルド、リリースなど、関連するすべてのデータも削除されます。

次のステップ

開発者は Heroku のアプリのライフサイクルを理解することにより、プラットフォームの機能を最大限に活用し、効率的なデプロイ、スケーリング、管理を行うことができます。Heroku の合理化されたワークフローを活用することで、チームは複雑なインフラ管理に煩わされることなく、アプリの構築と改善に集中できます。以下のトピックを掘り下げて、さらに学習を進めましょう。