Масштабирование бизнес-критичных приложений для миллионов пользователей: личный опыт достижения высокой производительности
Бизнес-критичные (Business Critical) ИТ-системы - это системы, которые наряду с Mission Critical системами обладают высокой степенью влияния не только на финансовый результат компании, но и могут повлечь репутационные издержки в случае выхода такой системы из строя даже на непродолжительное время. При этом, бизнес-критичная система может считаться Mission Critical, если от неё зависит основной бизнес компании. Примером бизнес-критичных систем являются приложения из B2C сегмента, формирующие цифровую экосистему организации и обслуживающие существующую клиентскую базу основной ветви бизнеса, например, бронирование гостиничных билетов в банковских приложениях, мессенджеры у маркетплейсов, и прочие сопутствующие сервисы. Для поддержания высокого уровня клиентского опыта, такие решения должны уметь стабильно обрабатывать сотни тысяч или миллионы запросов одновременно, что с точки зрения глобальных корпораций, является нетривиальной задачей, особенно в случае необходимости обработки большого количества данных. По оценкам исследовательской компании IDC (Global DataSphere Forecast, 2021-2025), мировой объем сгенерированных данных к 2025 году составит около 181 зеттабайт.
Для удовлетворения требований, которые предъявляются к business-critical системам, архитекторам программного обеспечения приходится решать задачи, заключающиеся не только в обеспечении бесперебойной работы сервисов, но и сохранении положительного пользовательского опыта, который стал важнейшей метрикой ввиду наличия многочисленных решений от конкурентов.
Требования, предъявляемые к архитектуре программного обеспечения
Требования к программному обеспечению - одна из ключевых составляющих проектирования, определяющая поведение системы в соответствии с бизнес-целями заказчика. По своей природе все требования можно классифицировать по двум осям: функциональные и нефункциональные, а также качественные и количественные. Ниже приведён неполный список так называемых способностей системы ('-ilities'), которые необходимо учитывать при разработке архитектуры решения.
Auditability – способность системы быть прозрачной в плане записи в лог различных пользовательских действий и попытках его совершить, а также сквозного отслеживания транзакций и прочих активностей. Является базовым требованием для обеспечения безопасности.
Availability — это отношение времени, в течение которого система способна оставаться доступной для пользователей (uptime, сек) ко всему времени наблюдения, включая время недоступности системы (downtime + uptime). Наиболее частыми градациями доступности выступают значения от 99,9% до 99,999%, где система недоступна 8,77 часов и 5,26 минут в год соответственно. Это неотъемлемый компонент соглашения об уровне сервиса (Service Level Agreement).
Configurability – способность системы быть настраиваемой пользователем или администратором без модификации исходного кода. Часто требуется модификация без перезапуска, on-the-fly. Конфигурируемость может значительно увеличить пользовательскую аудиторию, что является критической метрикой с точки зрения бизнеса. Extensibility – способность системы к расширению своей функциональности без изменения исходного кода. Сюда относится поддержка плагинов и вспомогательных компонентов. Для обеспечения расширяемости, на стадии проектирования уделяется особое внимание на разбиение системы на модули.
Interoperability – способность системы интегрироваться с другими системами или модулями. Поддержка базовых протоколов и форматов, например, как REST, gRPC, SOAP, JSON, XML, Protocol Buffers и стандартов безопасности является необходимым условием для обеспечения данной характеристики.
Maintainability – способность системы к быстрому проведению обновления, ремонта и прочих обслуживающих действий. Эта метрика напрямую влияет на доступность системы, ее производительность.
Performance – способность системы обрабатывать входящие запросы при наличии нагрузки. Ключевыми аспектами производительности являются пропускная способность throughput, количество запросов в секунду и время ответа, latency. Данная метрика особенно важна для систем реального времени.
Portability – способность системы работать на разных платформах, операционных системах, разном окружении при её минимальной модификации. Большинство корпоративных решений создается с использованием виртуальной машины JVM, которая, выступая отдельным слоем, позволяет абстрагироваться от различий в оборудовании. Сюда же относится и Docker, позволяющий запускать приложения в разных средах.
Scalability - способность системы эффективно справляться с растущими рабочими нагрузками за счет расширения ее ресурсов без существенного снижения производительности. Масштабируемая система может обслуживать больше пользователей, данных или транзакций, сохраняя при этом отзывчивость и надежность. Security – способность системы быть защищенной от несанкционированного доступа, нарушений и киберугроз. Она обеспечивает конфиденциальность, целостность и доступность информации, предотвращая несанкционированные изменения, сбои или утечки данных.
Usability – способность системы быть лёгкой в эксплуатация с точки зрения пользовательского опыта. В контексте технологий это часто относится к дизайну приложений, веб-сайтов или устройств, обеспечивая их интуитивность, удобство для пользователя и доступность. Тестирование удобства использования часто проводится для оценки метрики и внесения улучшений на основе отзывов и наблюдений пользователей. Данная метрика является одной из ключевых среди представленных.
Системным и бизнес-аналитикам, вместе с разработчиками, архитекторами приходится не только выявлять требования, но и разрешать многочисленные противоречия. Такие требования как Maintainability, Extensibility не относятся к бизнес-функциональности напрямую и часто помещаются в технический долг, который может разрастись к релизу продукта, и значительно увеличить итоговый бюджет проекта. Обеспечение конфигурируемости негативно сказывается на поддерживаемости, безопасность может негативно сказаться на клиентском опыте. Для визуализации приоритетов, данные требования можно представить в виде розы ветров. Очерченная область будет смещаться в сторону Security, Auditability для систем, с особыми требованиями к безопасности, и/или в сторону Performance, Scalability для высоконагруженных решений.
Решение для миллионов автовладельцев
Владение автомобилем подразумевает множество действий, включая регистрацию транспортного средства, оформление страховки, оплату парковки, платных дорог, помощь на дороге, оплату штрафов ГИБДД и прочих платежей. Создание решения по автоматизации таких операций для одного из крупнейших национальных банков России - ВТБ, являлось для меня, как для главного ответственного разработчика, критически важной задачей, учитывая реализацию национальной программы цифровой трансформации (одна из пяти национальных целей развития России до 2030 года в соответствии с Указом Президента Российской Федерации от 21.07.2020 № 474).
Автоматизация процессов, связанных с владением автомобилем, повышает экономическую эффективность как государственных, так и банковских сервисов, снижает затраты граждан на выполнение обязательных процедур, обеспечивает своевременное поступление платежей в бюджет, сокращает бюрократию и делает взаимодействие с госорганами более прозрачным. Кроме того, благодаря возможности решить многие вопросы без необходимости посещения офисов, тратится меньше бумаги и топлива, что соответствует целям ESG-стратегии. И, что особенно важно, такая автоматизация дисциплинирует водителей и повышает уровень безопасности на дорогах.
Основные технические вызовы и мои решения при создании цифровой платформы для владельцев автомобилей
Обеспечение эластичности сервиса и устойчивости к пиковым нагрузкам.
Одной из особенностей поведения пользовательской аудитории, для которой создавался продукт, является резкое повышение её активности в определённые периоды - в дни выплаты заработной платы, завершения льготного периода оплаты штрафов или в предпраздничные дни. Если в обычные дни, в пределах 12 часового окна, при общем количестве пользователей 10 млн, количестве уникальных пользователей за сутки (DAU) 10% и средней пользовательской сессии, содержащей порядка 50 запросов, нагрузка составляет около 1200 RPS, то в пиковые периоды нагрузка возрастает в 3 раза и более, достигая 3600 RPS и выше. Для оперативной адаптации ресурсов сервиса под изменяющуюся рабочую нагрузку была выбрана микросервисная архитектура с использованием Docker контейнеризации и Kubernetes оркестрации с Horizontal Pod Autoscaling функцией. Такой подход позволил оперативно масштабировать ресурсы в зависимости от притока пользователей, сохраняя стабильность и доступность сервиса.
Обеспечение быстрого ответа от системы
Ещё в 2006 году компания Google зафиксировала, что задержка в отклике всего на 0,5 секунды может привести к снижению повторного трафика на 20%. Задержка ответа (latency) системы критична с точки зрения пользовательского опыта (UX), особенно в настоящее время, и для повышения производительности мне пришлось внедрить ряд инженерных решений, таких как кэширование с использованием Redis в узлах с высоким cache hit ratio. Это потребовало предварительного анализа паттернов запросов и настройки TTL для наиболее часто запрашиваемых данных. Для оптимизации асинхронного взаимодействия и сокращения времени отклика примерно на 20%, был внедрён реактивный стек WebFlux, который позволил более эффективно обрабатывать потоки данных. Кроме того, была применена умышленная денормализация базы данных - это позволило снизить количество ресурсоёмких операций join примерно на 30%. В совокупности эти меры обеспечили практически двукратное ускорение работы сервиса, что стало ощутимым улучшением как для пользователей, так и для бизнеса.
Обеспечение высокой доступности приложения
Ещё одной особенностью создаваемого решения являлось интенсивное взаимодействие с множеством внешних государственных сервисов - таких как Государственная информационная система о государственных и муниципальных платежах (ГИС ГМП), базы ГИБДД, системы оплаты парковок и другие. Высокая вероятность сбоев или задержек в этих интеграциях может привести к каскадному отказу всей системы (cascading failure). Чтобы минимизировать риски, я создал конфигурацию и осуществил настройку таймаутов и политику повторных попыток (retry policy), внедрил паттерн Circuit Breaker, который позволил временно приостанавливать обращение к недоступным сервисам и тем самым разгружать их. Кроме того, были реализованы fallback-механизмы и мониторинг состояния внешних систем, что дало возможность оперативно переключаться на альтернативные источники данных. В совокупности эти меры обеспечили устойчивость системы и высокую доступность сервиса даже при сбоях внешних компонентов.
Обеспечение мониторинга и трассировки в системе
Распределённое приложение, состоящее из множества микросервисов, постоянно взаимодействующих между собой, представляет сложность с точки зрения поддержки и диагностики. Для своевременного выявления и устранения неисправностей крайне важно иметь возможность отслеживать путь каждого запроса и контролировать поведение системы в режиме реального времени. С этой целью были внедрены инструменты централизованного логирования и мониторинга: стек ELK (Elasticsearch, Logstash, Kibana) для агрегации и сквозного анализа логов всех микросервисов, а также Prometheus для снятия метрик. Это решение позволило реализовать сквозную трассировку запросов, выявлять аномалии, такие как рост числа ошибок или увеличение времени отклика, и оперативно принимать корректирующие меры - например, масштабировать ресурсы или пересмотреть конфигурацию.
Обеспечение сохранности пользовательских данных
Платформа обрабатывает чувствительные пользовательские данные, которые должны сохраняться даже при сбоях, включая полное отключение электроэнергии. Для минимизации риска потери данных был использован Postgres кластер с настроенной репликацией данных. Снижение нагрузки на базу данных и распределение запросов были обеспечены введением кэширующих слоев и балансировкой нагрузки с помощью HAProxy. Также были заранее рассчитаны необходимые ресурсы (CPU, память, размер дискового хранилища) с учётом объёмов и сроков хранения данных, что позволило обеспечить стабильную и безопасную работу платформы.
Заключение
Благодаря перечисленным техническим решениям и эффективному использованию облачных вычислений удалось ускорить приложение примерно в два раза, снизить время отклика на 30% в пиковые моменты и сохранить его доступность даже при троекратной нагрузке. Это позволило автовладельцам - клиентам крупнейшего национального банка, где было внедрено данное решение, получить удобный и надежный сервис, а самому банку, имеющему офисы в разных странах, существенно поднять выручку. Кроме того, архитектура решения может быть адаптирована и для экосистем других крупных компаний, что делает её универсальной и масштабируемой с точки зрения бизнеса. Разработка высоконагруженных приложений, которые используются миллионами пользователей по всей стране, требует комплексного подхода и нестандартных решений. У разработчика есть широкий инструментарий для построения распределённых систем: микросервисная архитектура, асинхронная обработка данных, технологии кэширования и мониторинга. Однако всё это должно быть подчинено улучшению пользовательского опыта - система должна работать быстро, без сбоев и надёжно хранить данные пользователей. Кроме того, необходимо помнить, что каждое архитектурное решение имеет свою цену. Например, денормализация может стать проблемой при расширении доменной модели, а разбиение системы на микросервисы может значительно усложнить мониторинг, трассировку и управление API. Архитектурные решения требуют тщательного баланса между стоимостью, производительностью, масштабируемостью, безопасностью и удобством обслуживания. Нахождение оптимального решения зависит от бизнес-целей, требований пользователей и эксплуатационных ограничений.
Опубликовано 18.04.2025
