dyno の再起動

最終更新日 2025年04月08日(火)

この記事では、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 の公式ドキュメント​をお読みください。

その他の資料