Как мы пересобирали интеграционную платформу в мире, где всё меняется быстрее, чем Kubernetes успевает масштабировать pod’ы
Есть проекты, где всё идёт спокойно.
А есть высоконагруженные интеграционные системы.
Это уже отдельный жанр.
Особенно когда:
бизнес растёт;
количество запросов увеличивается каждый месяц;
требования регуляторов обновляются быстрее документации;
часть привычных зарубежных решений внезапно начинает жить своей жизнью;
а инфраструктура, собранная из множества отдельных VM и сервисов, всё чаще начинает вести себя нервно и непредсказуемо.
Именно в такой момент к нам пришёл заказчик.
Инфраструктура, которая устала
Снаружи всё выглядело вполне рабочим:
данные передавались, интеграции функционировали, бизнес-процессы не останавливались.
Но внутри система уже представляла собой набор отдельных VM и сервисов, которые со временем превратились в сложную и плохо управляемую экосистему.
Внутри команды эту инфраструктуру даже называли «ульями» — таких VM было около десяти, каждая отвечала за свою часть процессов, а понимание полной картины постепенно становилось отдельной инженерной задачей.
Главная проблема была не в одном «сломавшемся» компоненте, а в сложности всей системы.
Любой рост нагрузки запускал знакомую цепочку событий:
увеличивались очереди;
росло время отклика;
появлялись задержки;
команда открывала Grafana;
Grafana открывала портал в тревожность.
А дальше классика enterprise-разработки:
— «Почему всё тормозит?»
— «Потому что запросов много».
— «А почему система снова упирается в ресурсы?»
— «Потому что сервисы распределены хаотично и масштабируются неравномерно».
— «Понятно. Очень воодушевляет».
Вишенка на торте — обновления
Обновлять такую инфраструктуру было отдельным приключением.
Любой релиз требовал:
ручной координации между сервисами;
проверок зависимостей;
контроля VM;
молитв;
и моральной готовности провести вечер не дома.
Потому что если что-то пойдёт не так — проблемы начинали каскадно распространяться по всей системе.
А когда речь идёт о критичных бизнес-процессах и постоянном обмене данными между сервисами, фраза:
«Система недоступна, попробуйте позже»
звучит примерно как:
«Мы решили немного пожить в стрессе».
А потом подключилась реальность 2020-х
Но основной вызов был в другом:
регулятор жёстко определял требования по времени отклика системы — условно, n секунд.
Превышение этого порога уже вело к риску санкций и финансовых потерь.
Это означало, что архитектуру нужно было строить сразу с расчётом на стабильную и предсказуемую работу под высокой нагрузкой.
Однако реальность 2020-х только усложняла задачу:
инфраструктурные решения становились менее предсказуемыми;
отдельные сервисы периодически работали нестабильно;
требования к безопасности и лицензированию могли меняться буквально на ходу.
В какой-то момент обсуждение архитектуры нередко сводилось к простому вопросу:
— «Эта система выдержит нужный отклик?»
— «На данный момент — да».
— «Значит, берём».
Поэтому ключевыми принципами для нас стали:
отказ от зависимости от отдельных VM;
гибкость архитектуры;
использование open-source стеков;
возможность быстрой миграции сервисов;
минимизация зависимости от внешних платформ;
централизованное управление инфраструктурой.
Решили пересобрать систему — но без боли для бизнеса
Полностью останавливать систему было нельзя.
Вообще.
Бизнес должен работать.
Данные должны передаваться.
Пользователи не должны даже заметить, что внутри инфраструктуры идёт капитальный ремонт.
Поэтому пошли через параллельный запуск:
существующая система продолжала работать, пока рядом постепенно разворачивалась новая платформа.
Мы построили централизованную микросервисную архитектуру на:
FastAPI;
Celery;
Redis Sentinel;
PostgreSQL;
Kubernetes;
Prometheus и Grafana.
Фактически это был переход не от «монолита», а от разрозненной VM-инфраструктуры к управляемой контейнерной платформе с нормальной оркестрацией и автомасштабированием.
И, конечно же, Kubernetes почти сразу решил показать характер.
Когда autoscaling слишком старается
На нагрузочном тестировании всё выглядело прекрасно.
До определённого момента.
Потом Celery-воркеры начали масштабироваться так активно, будто Kubernetes решил открыть собственный дата-центр.
Причина оказалась в очередях Redis:
под высокой нагрузкой некоторые процессы создавали всплески задач быстрее, чем worker’ы успевали их разбирать.
Визуально Grafana выглядела как кардиограмма человека после энергетика и дедлайна одновременно.
Пришлось:
переработать распределение очередей;
ограничить burst scaling;
разделить типы worker’ов;
оптимизировать обработку задач;
перенастроить HPA;
отдельно стабилизировать Redis Streams.
После этого система наконец перестала паниковать при росте нагрузки и начала масштабироваться спокойно и предсказуемо.
Как взрослый production-сервис, а не как junior-инженер в первый день релиза.
Самая нервная ночь проекта
Финальное переключение делали через blue-green deployment.
Звучит красиво.
На практике это выглядит так:
вся команда сидит ночью перед дашбордами;
кофе заканчивается быстрее RAM;
DevOps смотрит на latency как трейдер на курс валют;
а любой spike на графике вызывает коллективное:
«Так. А это сейчас нормально было?»
Но переключение прошло идеально.
Без простоя.
Без потери данных.
Без падений.
Без традиционного «срочно откатываемся».
И это, пожалуй, лучший комплимент любой инфраструктурной команде:
когда бизнес вообще не замечает, насколько сложная работа была проделана внутри.
Что получили в итоге
После запуска заказчик получил:
отказоустойчивую микросервисную платформу;
99,9% uptime;
автоматическое масштабирование;
полноценный мониторинг;
прозрачную observability-инфраструктуру;
стабильные релизы без ночных ритуалов;
систему, которая спокойно выдерживает дальнейший рост нагрузки.
А главное — исчезло ощущение, что инфраструктура живёт собственной жизнью и в любой момент может устроить сюрприз.
Теперь сюрпризы остались только у мировой IT-индустрии.