ローリングデプロイ
最終更新日 2025年04月08日(火)
Table of Contents
この機能は Private Space 内のアプリでのみ使用できます。
アプリが初めて Private Space にデプロイされるときは、基盤となる専用インフラストラクチャの設定のため、アプリが使用可能になるまでに数分かかることがあります。
それ以降のリリース (コードのデプロイや環境設定の変更) では遅延はずっと短くなり、ダウンタイムはほとんどまたはまったく発生しません。アプリの dyno が 1 つしかない場合は、短時間のダウンタイムが発生する可能性があります。複数の dyno の場合、ローリングデプロイ機能によりダウンタイムをゼロにできます。ローリングデプロイは、Private Space の両方の世代で利用できます。
ローリングデプロイの動作
ローリングデプロイは、Common Runtime での Preboot に似ています。どちらも、新しいリリースの間のゼロダウンタイムを実現します。Preboot のメソッドは、既存の Web dyno が終了する前に、新しい Web dyno が起動してトラフィックを受信するようにすることです。ローリングデプロイでは、既存の dyno の 25% までしか停止および変更せず、残りの dyno はリクエストとタスクを処理します。その効果として、すべてのリクエストはユーザーのダウンタイムなしで処理され、新しいリリースは徐々にformation 全体にプッシュされます。
より正確に言うと、次の条件が当てはまる場合、Private Space アプリの新しいリリースの間にダウンタイムは発生しません。
- アプリが 1 回でもデプロイされたことがあり、現在実行されている。
- アプリには少なくとも 2 つの dyno があり、現在はフル業務量ではない。
フル業務量ではないということは、最大 25% の dyno が不足していても、リクエストを処理するのに十分な dyno がアプリにあることを意味します。アプリに 2 つまたは 3 つの dyno しかない場合、リリースがロールアウトされている間は、残りの 1 つまたは 2 つの dyno で既存の負荷を処理できる必要があります。
Private Space 内の既存のアプリをスケーリングしても、(既存の負荷を処理するのに十分な容量がある限り) ダウンタイムは発生しません。dyno サイズを変更すると、状況によっては、新しい dyno を作成してトラフィックを切り替える間に短いダウンタイムが発生します。
アプリにアタッチされているどのデータベースもスキーマの変更を伴わず、アプリの古いリリースと新しいリリースの両方と互換性があります (前方および後方互換)。
Fir 世代のアプリ
Fir 世代のアプリケーションが新しいリリースに応じて再起動すると、dyno 数が設定されたスケールを一時的に超過することがあります。この動作は可用性の低下を防ぐために存在します。古いリリースを実行している dyno が終了する前に新しい dyno を作成し、準備ができていることを確認します。これにより、リリースがロールアウトされている間に利用可能な dyno の数が増えます。
最新のリリースの結果として起動できない dyno は、以前のリリースを実行している dyno に加えて引き続き存在します。この場合、最新の dyno が正常に実行されるまで、dyno 数は設定されたスケールを超えます。