IX. Утилизируемость (Disposability)
Максимизируйте надежность с помощью быстрого запуска и корректного завершение работы
Процессы приложения двенадцати факторов являются утилизируемыми, это означает, что они могут быть запущены и остановлены в любой момент. Это способствует стабильному и гибкому масштабированию, быстрому развёртыванию изменений кода и конфигураций и надежности рабочего развёртывания.
Процессы должны стараться минимизировать время запуска. В идеале процесс должен затратить всего несколько секунд от момента времени, когда выполнена команда запуска, и до того момента, когда процесс запущен и готов принимать запросы или задачи. Короткое время запуска предоставляет большую гибкость для релиза и масштабирования. Кроме того, это более надежно, так как менеджер процессов может свободно перемещать процессы на новые физические машины при необходимости.
Процессы должны завершаться корректно, когда они получают SIGTERM сигнал от диспетчера процессов. Для веб-процесса корректное завершение работы достигается путем прекращения прослушивания порта сервиса (таким образом, отказаться от каких-либо новых запросов), что позволяет завершить текущие запросы и затем завершиться. В этой модели подразумевается, что HTTP-запросы короткие (не более чем на несколько секунд), в случае длинных запросов клиент должен плавно попытаться восстановить подключение при потере соединения.
Для процесса, выполняющего фоновые задачи (worker), корректное завершение работы достигается путем возвращения текущей задачи назад в очередь задач. Например, в RabbitMQ рабочий процесс может отправлять команду NACK; в Beanstalkd задача возвращается в очередь автоматически, когда рабочий процесс отключается. Системы, основанные на блокировках такие, как Delayed Job должны быть уведомлены, чтобы освободить блокировку задачи. В этой модели подразумевается, что все задачи являются повторно входимыми, что обычно достигается путем оборачивания результатов работы в транзакции или путем использования идемпотентных операций.
Процессы также должны быть устойчивыми к внезапной смерти в случае отказа аппаратного обеспечения. Хотя это менее вероятное событие, чем корректное завершение работы сигналом SIGTERM, оно все же может случиться. Рекомендуемым подходом является использование надежных очередей задач, таких как Beanstalkd, которые возвращают задачу в очередь когда клиент отключается или превышает лимит времени. В любом случае приложение двенадцати факторов должно проектироваться так, чтобы обрабатывать неожиданные и неизящные выключения. Архитектура только аварийного выключения (Crash-only design) доводит эту концепцию до её логического завершения.