Проектируйте ПО для cloud native среды

Определите необходимое поведение

Практики cloud native поддерживают воспроизводимую разработку и эксплуатацию в публичных, частных и гибридных средах. CNCF выделяет системы, которые при изменениях остаются управляемыми, наблюдаемыми и устойчивыми к сбоям. Контейнеры и оркестрация могут поддерживать этот подход. Сами по себе они не обеспечивают все эти свойства.

Начнём с вымышленного сервиса отчётов. ИИ-инструмент создаёт endpoint, worker и образ контейнера. На демонстрации получается правильный PDF. До production команде нужно ответить на другой вопрос: что произойдёт, если платформа заменит worker во время выполнения задания?

Это вопрос проектирования и приложения, и инфраструктуры. Перезапуск может восстановить процесс, но потерять его незавершённую работу.

Отделяйте процесс от устойчиво сохраняемого состояния

Прототип хранит задания в очереди и готовые отчёты на диске контейнера. Замена контейнера может удалить и то и другое. Добавление workers также может привести к разным ответам в зависимости от того, какой worker получил запрос.

В пересмотренной архитектуре используются устойчивое хранилище заданий и одобренное объектное хранилище. Запрос фиксирует идентификатор задания. Worker берёт задание в работу, создаёт результат и записывает его расположение. При скачивании отчёта пользователем по-прежнему выполняются проверки доступа.

Храните секреты вне образа. Передавайте их через одобренную систему управления секретами. Зафиксируйте, какие изменения конфигурации требуют нового релиза или перезапуска процесса.

Продумайте повторные попытки до добавления workers

Предположим, worker сохраняет PDF, а затем останавливается до подтверждения задания. Очередь доставляет задание повторно. Вторая попытка не должна приводить к повторному списанию с клиента или противоречивым сообщениям о завершении.

При необходимости используйте идемпотентную операцию. Повтор одного логического запроса должен сохранять предусмотренный эффект. Определите стабильный идентификатор запроса, надёжно сохраняйте результат и проверьте поведение в каждой точке возможного сбоя. AWS описывает этот подход в руководстве по безопасным повторным попыткам.

Повторным попыткам тоже нужны ограничения. Задайте timeout, предел числа попыток и задержку, которая предотвращает одновременные повторные запросы. Сохраняйте неудавшиеся задания для проверки, а не повторяйте их бесконечно.

Сделайте желаемое состояние доступным для review

Декларативная конфигурация описывает желаемое развёртывание. Контроллер поддерживает это состояние. Например, Kubernetes Deployment управляет репликами приложения и контролируемыми обновлениями. Само приложение всё равно должно правильно обрабатывать замену.

Версионируйте конфигурацию инфраструктуры и приложения. Проверяйте изменения в обычном процессе поставки. Наблюдайте за фактическим завершением заданий, временем ожидания в очереди, сбоями и ограничениями зависимостей. Запущенный процесс всё ещё может быть неспособен сформировать отчёт.

Выберите платформу, которую команда сможет эксплуатировать

Cloud native не требует превращать каждое приложение в микросервисы. Модульное приложение в управляемой среде выполнения может соответствовать своим требованиям. Дополнительные сервисы добавляют интерфейсы, решения о развёртывании и эксплуатационную работу.

Предоставьте агенту разработки реальный контракт платформы: поддерживаемую среду выполнения, способ идентификации, сервисы данных, правила развёртывания и необходимые подтверждения. Наряду с успешными запросами тестируйте прерывание и замену процессов. Продолжите с урока о доступности и границах отказов.