Előző fejezet: 8. Párhuzamos folyamatok

Következő fejezet: 10. Egyensúly a fejlesztés és az üzemeltetés között

Maximális hibatűrés gyors üzembehelyezéssel és egyszerű, gördülékeny leállítással.

A tizenkét tényezős alkalmazás folyamatai eldobhatóak (disposable), ami azt jelenti, hogy nagyjából a parancs észlelésének pillanatában elindul vagy leáll. Ez megkönnyíti a rugalmas méretezést (elastic scaling), a kód vagy a konfiguráció gyors telepítését és a produkciós telepítések hibatűrését.

A folyamatoknak törekedniük kell az üzembehelyezésükhöz szükséges idő minimalizálására. Ideális esetben egy folyamatnak néhány másodpercig tart az indulási parancstól eljutni egészen addig, hogy a folyamat fut és kész a kérések vagy a feladatok fogadására. A gyors üzembehelyezési idő több teret biztosít a folyamat üzembehelyezéséhez és a felskálázódáshoz (scaling up); segíti a hibatűrést, ugyanis ha indokolt, a folyamatkezelő (process manager) könnyebben át tudja mozgatni a folyamatot egy új fizikai eszközre.

A folyamat álljon le egyszerűen és gördülékenyen, ha megkapja a leállító parancsot (SIGTERM) a folyamatkezelőtől. Webes folyamatoknál ez elérhető, ha megszüntetjük a szolgáltatás portján a rendelkezésre állást (listening - ezzel minden további kérést visszautasítva), engedélyezzük viszont a folyamatban lévő kérések teljesítését és csak ezután állítjuk le a folyamatot. Ebből következik, hogy ebben a modellben a HTTP kérések kiszolgálása rövid (nem több néhány másodpercnél), a hosszú ideig tartó hívásokkal történő folyamatos lekérdezés (long polling) esetén pedig a kliens zökkenőmentesen újrakapcsolódik, ha a kapcsolat megszakad.

Munkavégző folyamatok esetén az egyszerű és gördülékeny leállás elérhető az aktuális végrehajtás alatt lévő feladat visszahelyezésével a várakozósorba (work queue). Például a RabbitMQ üzenetsor esetén a munkavégző folyamat küldhet egy NACK jelet; míg Beanstalkd esetén a feladat automatikusan visszakerül a várakozósorba, ha a munkavégző felé megszakad a kapcsolat. A Delayed Job-hoz hasonló zárolás alapú rendszereknél fontos, hogy a zárolást ilyenkor a feladat adatrekordján feloldjuk. A modellünknek a következménye, hogy minden feladat ismételhető kell, hogy legyen, ami tipikusan a feladatok tranzakcióba burkolásával, vagy a műveletek idempotenssé tételével (az első feladatvégzés után a további ismétlések nem változtatják az eredményt) érhető el.

A folyamatoknak ezen kívül jól kell tűrniük a hirtelen halált is, a futtató hardver eszköz meghibásodásának az esetét is. Bár ez a leállási parancs (SIGTERM) hatására történő egyszerű és gördülékeny leállásnál sokkal ritkábban előforduló lehetőség, azért meg szokott történni. Az javasolt megközelítés egy hibatűrő üzenetsor használata, mint például a Beanstalkd, ami egyszerűen visszahelyezi a feladatot a várakozósorba, ha kapcsolat megszakad az ügyfélprogram felé vagy a kliens időtúllépésbe kerül. Akárhogy is, a tizenkét tényezős alkalmazás a nem várt és/vagy nem gördülékeny leállások kezelésére megfelelő felépítést alkalmaz. A kizárólag-összeomlás (crash-only) elleni tervezési mód ezt a koncepciót vonja le logikus végkövetkeztetésként.

The Twelve-Factor App: IX. Disposability