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