The Twelve-Factor App

IX. Einweggebrauch

Robuster mit schnellem Start und problemlosen Stopp

Die Prozesse einer Zwölf-Faktor-App können weggeworfen werden, sie können also schnell gestartet und gestoppt werden. Dies erleichtert schnelles elastisches Skalieren, schnelles Deployment von Code oder Konfigurationsänderungen und macht Produktionsdeployments robuster.

Prozesse sollten möglichst geringe Startup-Zeiten haben. Idealerweise braucht ein Prozess wenige Sekunden vom Startkommando bis der Prozess läuft und Requests oder Jobs entgegennehmen kann. Eine kurze Startup-Zeit gibt dem Release-Prozess und der Skalierung mehr Agilität; sie hilft der Robustheit, weil ein Prozessmanager bei Bedarf einfacher Prozesse auf neue physikalische Maschinen verschieben kann.

Prozesse fahren ohne Schwierigkeiten herunter, wenn sie ein SIGTERM-Signal vom Prozessmanager bekommen. Für einen Web-Prozess kann ein problemloses Herunterfahren erreicht werden, indem er aufhört an seinem Service-Port zu lauschen (und damit alle neuen Requests ablehnt), die laufenden Requests zuende bearbeitet und sich dann beendet. Diesem Modell eigen ist, dass HTTP-Requests kurz sind (höchstens ein paar Sekunden) oder im Falle von Long-Polling, der Client sich nahtlos neu verbindet, wenn die Verbindung verloren geht.

Für einen Worker-Prozess wird ein problemloser Stopp erreicht, indem er seinen laufenden Job an die Workqueue zurück gibt. Zum Beispiel kann bei RabbitMQ ein Worker einen NACK; bei Beanstalkd wird der Job automatisch an die Queue zurückgegeben, wenn ein Worker die Verbindung beendet. Lock-basierte Systeme wie Delayed Job sollten sicherstellen, dass ihr Lock im Job-Record freigegeben wird. Diesem Modell eigen ist, dass alle Jobs reentrant sind, was üblicherweise erreicht wird indem man die Ergebnisse in eine Transaktion einpackt oder den Vorgang idempotent gestaltet.

Prozesse sollte auch robust gegen plötzlichen Tod sein - falls die zugrundeliegende Hardware versagt. Auch wenn dies viel seltener ist als ein reguläres Herunterfahren mit SIGTERM, so kommt es dennoch vor. Wir empfehlen ein robustes Queue-Backend wie Beanstalkd, das Jobs an die Queue zurückgibt falls Clients die Verbindung beenden oder nicht mehr antworten. Wie auch immer ist eine Zwölf-Faktor-App darauf ausgelegt mit unerwarteten, irregulären Stopps umgehen zu können. Crash-only design führt dieses Konzept zu seinem logischen Schluss.