最終更新日 2024年10月21日(月)

Preboot では、Web dyno での Standard dyno の起動動作​が変更されます。Preboot は、既存の一連の Web dyno を停止してから新しい Web dyno を起動するのではなく、既存の Web dyno が終了される前に新しい Web dyno が確実に起動される (かつトラフィックを受信する) ようにします。これは、ダウンタイムなしのデプロイに貢献できます。

この機能は、コードベースの 2 つのバージョンが並行して実行されている状況を引き起こす可能性があるため、慎重に使用してください。たとえば、Web dyno が古いリリースを実行している一方で、ワーカーが新しいリリースを実行している可能性があります。コードとデータベースの設定がこの動作をサポートしていることを確認してください。

Preboot の有効化と無効化

Preboot は、アプリごとに明示的に有効にする必要があります。Preboot を有効にするには、次のようにします。

$ heroku features:enable preboot -a <myapp>
Enabling preboot for myapp... done

Preboot を無効にするには、次のようにします。

$ heroku features:disable preboot -a <myapp>
Disabling preboot for myapp... done

Preboot が有効になっているかどうかを確認するには、次のようにします。

$ heroku features -a <myapp>
=== App Features (myapp)
[+] preboot  Provide seamless web dyno deploys [general]

Preboot でのデプロイ

Preboot が有効になったら、通常どおりに (コードをデプロイするか、または環境設定を変更することによって) 新しいリリース​を作成できますが、次のような異なる動作が確認されます。

• ログには、slug のコンパイルが完了するとすぐに新しい dyno が起動したことが示されます。heroku ps​の出力には、新しい dyno の状態 (starting​ や up​ など) が即座に表示されます。古い dyno は引き続き実行されますが、heroku ps​ には表示されません。
• デプロイが完了してから約 3 分後 (または、デフォルト値が 1 分であるアプリの起動タイムアウト制限の 2 分後) に、HTTP リクエストが新しい dyno へのルーティングを開始し、同時に古い dyno へのルーティングを停止します。
• 新しい dyno が完全に稼働し、ユーザーリクエストを処理した直後に、古い dyno がシャットダウンされます。これらのシャットダウンは、通常どおりにログで確認できます。

この動作の変更は、web​ プロセスタイプにのみ適用されます。その他の dyno (Worker など) は引き続き、通常どおりにシャットダウンおよび再起動されます。

手動または自動による dyno の再起動での Preboot

Preboot の動作は、リリースによって発生した再起動と、dyno の手動または自動による再起動​とでは若干異なります。dyno が手動または自動で再起動されると、次の動作が確認されます。

• ログには、slug のコンパイルが完了するとすぐに新しい dyno が起動したことが示されます。heroku ps​の出力には、新しい dyno の状態 (starting​ や up​ など) が即座に表示されます。古い dyno は引き続き実行されますが、heroku ps​ には表示されません。
• 新しい dyno は、割り当てられたポートにバインドするとすぐにリクエストの受信を開始します。この時点では、古い dyno と新しい dyno の両方がリクエストを受信しています。
• 再起動が実行されてから約 4 ～ 6 分後に、古い dyno がシャットダウンされます。これらのシャットダウンは、通常どおりにログで確認できます。

注意

• だれがデプロイを実行していたとしても、新しいコードがユーザーリクエストの処理を開始するまでに数分待つ必要があります。これは Preboot を使用しない場合より長時間かかります (ただし、その間、ユーザーリクエストは引き続き古い dyno によって処理される)。
• heroku ps​ で新しい dyno のステータスが表示されるまでに短時間 (1 ～ 2 分) かかりますが、ユーザーリクエストは引き続き古い dyno によって処理されています。
• 不適切な状態の dyno がある場合は、heroku restart​ によって新しい dyno が起動されますが、再起動の送信を3 分以上停止するまで古い dyno は強制終了されません。heroku ps:stop​により、この問題を即座に解決できます。
• Preboot でリリースを作成すると、同時に実行される (最大 3 分間重複する) コードのバージョンが 2 つ存在することになりますが、ユーザーリクエストを処理するのは 1 つのバージョンだけです。これらが正常にやり取りできるように注意してください。一部のアドオンやその他のサービスでは同時接続の数が制限されているため、2 倍の数の dyno を実行すると、このような制限に達する可能性が高くなります。特に、Heroku Postgres の場合、推奨される回避法は​接続プール​の使用です。
• Preboot でリリースを作成すると、Heroku により、ルーティングが古い dyno から新しい dyno にある時点で切り替えられます。切り替え中に、リクエストが両方の dyno に転送される非常に短時間のオーバーラップが発生する可能性があります。
• Preboot で dyno の手動または自動による再起動を行うと、新しい dyno は、割り当てられたポートにバインドするとすぐにリクエストの受信を開始するため、完全に準備ができる前にリクエストの処理を開始する可能性があります。これはまた、dyno をスケーリングしたり、dyno タイプを切り替えたりする場合にも当てはまります。
• リリース中に、スケーリングやその他の dyno formation の変更は許可されません。Preboot が完了するまで待機する必要があります。
• 環境設定の変更によってトリガーされたリリース中に、古い dyno は古い環境設定値で実行します。新しいデータベースのプロモートなど、アプリの接続先のデータベース接続文字列を変更するデータベースの変更を実行する場合は特に、環境設定の変更は慎重に行う必要があります。これらの接続文字列を変更する目的で、Mini Heroku Key-Value Store プランまたは Essential Heroku Postgres プランのアプリケーションで Preboot を使用することはお勧めしません。Premium プランにはより安定したアドレスがあるほか、メンテナンスやフェイルオーバーのためにホストを切り替えるときのダウンタイムを最小限に抑えるリダイレクト機能が含まれています。