dyno の再起動
最終更新日 2025年04月08日(火)
Table of Contents
この記事では、Heroku Dyno の再起動動作と再起動する方法について説明します。
再起動に関するイベントと一部の Heroku エラーコードは、Fir アプリではまだ利用できません。Fir のオブザーバビリティに関連する変更について通知を受け取るには、Changelog の受信登録を行ってください。
手動での再起動
heroku restart を実行すると、Dyno Manager がアプリの dyno をすべて再起動します。特定の dyno、または特定のプロセスタイプの dyno を再起動することもできます。
Cedar 世代のアプリ
Cedar アプリの場合、Common Runtime では拡張されたプロセスの一部である dyno で ps:stop を実行すると、Dyno Manager はそれらを自動的に停止して再起動します。Private Space では ps:stop が終了し、dyno を実行している専用インスタンスに置き換えられます。
Fir 世代のアプリ
Fir 世代のアプリの場合、dyno は Kubernetes ポッドによって実行されます。ps:stop への呼び出しがトリガーされるたびに、対応する dyno が終了して置き換えられます。
自動再起動
アプリの dyno は次の場合に自動的に再起動します。
- 新しいコードのデプロイによる新しいリリースの作成時
- 環境設定の変更時
- アドオンの変更時
- dyno の起動に使用されたコマンドの終了時
- 少なくとも 1 日 1 回 (
fir-bypass-daily-dyno-restarts を有効にした場合を除く) - 必要に応じて (Dyno Manager が基礎となるハードウェアの障害を検出した場合など)
このような処理は定期的に透過的かつ自動で行われ、アプリケーションログに表示されます。dyno を再起動するとローカルファイルシステムへのすべての変更が削除されます。
毎日の再起動
Dyno Manager は、Heroku で実行されているアプリケーションのヘルスを維持するために、すべてのアプリの dyno を 1 日に 1 回以上再起動します。再起動は 24 時間ごとに行われます (同一アプリケーションのすべての dyno が同時に再起動するのを避けるため、追加で最大 216 分のランダムな間隔でも行われます)。デプロイまたは環境設定の変更など、手動での再起動およびリリースはこの 24 時間の周期でリセットされます。再起動は One-off dyno を含むすべての dyno で行われるため、dyno は最大で 24 時間 + 216 分間実行されます。複数の dyno がある場合、0 から 216 分の間でランダムに異なるタイミングで再起動されます。24 時間経過する前にアプリケーションに変更を行うと、再起動は行われません。dyno が再起動されると、以下のようなログエントリが表示されます。
2015-08-18T06:20:13+00:00 heroku[web.1]: Cycling
Fir 世代のアプリには、毎日の自動 dyno 再起動動作を無効にするオプションがあります。詳細は、Heroku Labs の記事を参照してください。
dyno コマンドの終了
dyno の起動に使用されたコマンドが終了した場合にも dyno は再起動します。dyno の起動に使用されるコマンドが終了するケースには、以下のようなものがあります。
- 起動コードの欠陥 - アプリに不可欠の依存関係がない場合、または起動時にその他の問題がある場合は、コマンドがただちに終了し、スタック追跡が出力されます。
- 起動時に使用されたリソースでの一時的なエラー - 起動時にアプリが何らかのリソースにアクセスし、そのリソースがオフラインの場合、コマンドが終了することがあります。たとえば、データベースとして Amazon RDS を使用し、Heroku アプリにセキュリティグループの ingress を作成しない場合、エラーが生成されるか、起動の試行がタイムアウトになります。
- バイナリライブラリのセグメンテーション違反 - アプリでバイナリライブラリ (例: XML parser) が使用され、クラッシュした場合、アプリケーション全体もクラッシュする可能性があります。例外処理はこれを捕捉できないため、プロセスが停止します。
- インタープリターまたはコンパイラーのバグ - まれなケースとして、インタープリター (Ruby、Python) またはコンパイル (Java、Scala) のバグによってプロセスが停止することがあります。
dyno のクラッシュ再起動ポリシー
dyno のクラッシュとは、dyno で実行中のプロセスから発生し、dyno が停止する原因となるすべてのイベントを指します。これには 0 の終了コード (またはその他のあらゆる終了コード) で終了するプロセスが含まれます。
Common Runtime 再起動ポリシー
Common Runtime により、クラッシュする dyno についての増分バックオフポリシーが実装されます。
- dyno が初めてクラッシュした場合、ただちに再起動します。
- dyno が再びクラッシュすると、再起動が次に試行される前にクールオフの時間が設けられます。
- 最初のクールオフ時間は最大 20 分、次は最大 40 分、その後は最大 60 分、最大 180 分となり、最終的に最大 320 分となります。
- 320 分のクールオフ時間の後、再起動は 320 分おきに試行されます。
クールオフ時間は次の場合にリセットされます。
- dyno が正常に起動した場合
- 新しいリリースをアプリにプッシュした場合
- アプリを再起動した場合
- dyno を 0 に縮小してから再び拡張した場合
Cedar Private Space 再起動ポリシー
Cedar 世代の Private Space に増分バックオフポリシーはありません。dyno がクラッシュした場合、クールオフ時間はなく、繰り返し再起動されます。
Fir Private Space 再起動ポリシー
dyno がクラッシュすると、Fir は Kubernetes によるビルトイン増分バックオフポリシーを使用します。ポッドが問題を処理する方法については、Kubernetes の公式ドキュメントをお読みください。