GitHub
IX. Утилізовуваність
Підвищуйте надійність за допомогою швидкого запуску і коректного вимкнення
Процеси застосунку дванадцати факторів є утилізовуваними, тобто вони можуть бути запущені або зупинені в будь-який момент. Це сприяє гнучкому масштабуванню, швидкому розгортанню коду або змінам конфігурації і надійності production-розгортання.
Слід намагатися мінімізувати час запуску процесів. В ідеалі час між моментом виконання команди запуску процесу і моментом, коли процес готовий приймати запити чи задачі, має тривати лише пару секунд. Короткий час запуску забезпечує більшу гнучкість для релізу і масштабування. Крім того, це підвищує стійкість, оскільки менеджер процесів може легко переміщувати процеси на нові фізичні машини у разі необхідності.
Процеси мають коректно завершувати свою роботу, коли вони отримують SIGTERM сигнал від диспетчеру процесів. Для веб-процесу коректне завершення роботи досягається завдяки припиненню прослуховування порту, до якого він прив’язаний (що означає відмову від отримання будь-яких нових запитів), завершенню обробки будь-яких поточних запитів та зупинці самого процесу. В цій моделі передбачається, що HTTP-запити короткі (не більше ніж кілька секунд), а у разі довгих запитів (long polling) клієнт має намагатися відновити з’єднання у разі його втрати.
Для процесу, що виконує фонові задачі (worker), коректне завершення роботи досягається за рахунок повернення поточного завдання назад у чергу задач. Наприклад, в RabbitMQ робочий процес може надіслати команду NACK; в Beanstalkd завдання повертається в чергу автоматично щоразу, коли процес втрачає з’єднання. Системи, що використовують блокування, такі як Delayed Job, мають бути повідомлені, щоб звільнити блокування задачі. В цій моделі передбачається, що всі задачі є повторно вхідними, що зазвичай досягається шляхом обертання результатів їхньої роботи в транзакції або шляхом використання ідемпотентних операцій.
Процеси також мають бути стійкі до раптової зупинки в разі відмови апаратних засобів, на яких вони запущені. Хоча це менш ймовірна подія, ніж коректне завершення роботи за допомогою сигналу SIGTERM, вона все ж таки може статися. Рекомендованим підходом є використання надійних черг завдань, таких як Beanstalkd, які повертають завдання в чергу задач, коли клієнти втрачають з’єднання або від’єднуються по тайм-ауту. У будь-якому випадку, застосунок дванадцяти факторів має проектуватися таким чином, щоб обробляти несподівані та некоректні вимкнення. Прикладом вдалої реалізації архітектури “тільки аварійного вимкнення” (Crash-only design) є СouchDB.