【Railway】デプロイのライフサイクルとヘルスチェック
Railway でのデプロイ時のシャットダウンプロセス、ヘルスチェック、再起動ポリシーの設定方法を解説し、ゼロダウンタイムデプロイを実現します。
Railwayはこちら （←このリンクから登録すると20ドル分のクレジットがもらえます）
デプロイのライフサイクルとヘルスチェック
Railway は、新しいデプロイが正常に稼働するまで古いデプロイを維持することで、ゼロダウンタイムデプロイを実現します。本記事では、その仕組みの中心となる正常なシャットダウン、ヘルスチェック、再起動ポリシーについて解説します。
正常なシャットダウン (Graceful Shutdown)
新しいデプロイが正常だと判断されると、Railway は古いデプロイに対して SIGTERM シグナルを送信します。アプリケーション側でこのシグナルを補足し、以下の処理を行うことで、安全にシャットダウンできます。
- 進行中のリクエストを完了させる
- データベース接続を閉じる
- その他クリーンアップ処理
SIGTERMをハンドルしない場合、10秒後にSIGKILLが送信され強制終了します。
シャットダウンタイムアウトの変更
サービス設定でシャットダウンタイムアウトを調整できます（デフォルト: 10秒）。
Service → Settings → Graceful Shutdown Timeout
ヘルスチェック (Healthchecks)
ヘルスチェックは、新しいデプロイが正常にリクエストを受け付けられる状態かを確認する仕組みです。HTTP ベースのサービスの場合、指定したパスに Railway がリクエストを送信し、ステータスコード 200 が返るかで判断します。
設定項目
| 設定 | 説明 | デフォルト値 |
|---|---|---|
| Healthcheck Path | ヘルスチェック用エンドポイントのパス | / |
| Healthcheck Port | ヘルスチェック用ポート | (環境変数 PORT) |
| Healthcheck Hostname | ヘルスチェック時の Host ヘッダ | (自動生成されたドメイン) |
| Initial Delay | デプロイ後、ヘルスチェック開始までの待機時間 | 0秒 |
| Timeout | ヘルスチェックリクエストのタイムアウト | 5秒 |
| Interval | ヘルスチェックの実行間隔 | 5秒 |
| Max Retries | 失敗時のリトライ回数 | 3回 |
再起動ポリシー (Restart Policy)
デプロイされたサービスがクラッシュした場合の挙動を定義します。
| ポリシー | 説明 |
|---|---|
ALWAYS |
常に再起動を試みます。 |
ON_FAILURE |
終了コードが 0 以外の場合に再起動します（最大10回）。 |
NEVER |
再起動しません。 |
デフォルトはON_FAILUREです。10回失敗するとCrashed状態になります。
まとめ
ゼロダウンタイムデプロイを実現するために、以下の3点を正しく設定することが重要です。
- Graceful Shutdown: アプリケーション側で
SIGTERMをハンドルする。 - Healthchecks:
/healthのような専用エンドポイントを用意し、設定する。 - Restart Policy: ユースケースに合わせて再起動ポリシーを選択する。
これらの設定を適切に行うことで、ユーザー影響を最小限に抑えながら、安全かつ迅速にデプロイを繰り返すことが可能になります。
Railwayはこちら （←このリンクから登録すると20ドル分のクレジットがもらえます）
