The Twelve-Factor App

IX. 廃棄容易性

高速な起動とグレースフルシャットダウンで堅牢性を最大化する

Twelve-Factor Appの プロセス廃棄容易 である、すなわち即座に起動・終了することができる。 この性質が、素早く柔軟なスケールと、コード設定 に対する変更の素早いデプロイを容易にし、本番デプロイの堅牢性を高める。

プロセスは、 起動時間を最小化する よう努力するべきである。理想的には、1つのプロセスは、起動コマンドが実行されてから数秒間でリクエストやジョブを受け取れるようになるべきである。起動時間が短いと、リリース作業やスケールアップのアジリティが高くなる。さらに、プロセスマネージャーが必要に応じてプロセスを新しい物理マシンに簡単に移動できるようになるため、堅牢性も高くなる。

プロセスは、プロセスマネージャーから SIGTERMシグナルを受け取ったときに、グレースフルにシャットダウンする。 Webプロセスの場合、グレースフルシャットダウンは、サービスポートのリッスンを中止し(従って新しいリクエストを拒み)、処理中のリクエストが終了するまで待ち、シャットダウンすることで実現される。このモデルでは暗黙的にHTTPリクエストが短い(せいぜい数秒)ことを仮定している。ロングポーリングの場合、クライアントはコネクションが失われたときに途切れなく再接続を試みるべきである。

ワーカープロセスの場合、グレースフルシャットダウンは、処理中のジョブをワーカーキューに戻すことで実現される。例えば、RabbitMQではワーカーはNACKを送ることができる。Beanstalkdでは、ワーカーの接続が失われるとジョブは自動的にキューに戻る。Delayed Jobなどのロックをベースにしたシステムでは、ジョブレコードのロックを確実に解放する必要がある。このモデルでは、暗黙的にすべてのジョブが再入可能であることを仮定している。再入可能性は一般的に、結果をトランザクションで包んだり、処理をべき等にすることで実現される。

また、下層のハードウェアの障害に関して言えば、プロセスは 突然の死に対して堅牢 であるべきである。このような事態が起こることは、SIGTERMによるグレースフルシャットダウンに比べればずっと少ないが、それでも起こりうる。この対策として推奨される方法は、Beanstalkdなどの堅牢なキューイングバックエンドを使い、クライアントの接続が切断されたり、タイムアウトしたときにジョブをキューに戻せるようにすることである。どちらにしても、Twelve-Factor Appは予期しないグレースフルでない停止をうまく処理できるよう設計される。「クラッシュオンリー」設計はこのコンセプトをその論理的帰結に導く。