Высоконагруженная система для финансовых структур

В наше время повсеместной цифровизации многие компании сталкиваются с большими потоками данных. Эти системы должны выдерживать большие нагрузки. Возникает вопрос: как системам оставаться работоспособными и укладываться в требуемые SLA?

Рассмотрим пример из нашей практики — создание высоконагруженной системы по приему и обработке 2 млрд сообщений в сутки.

О подходах в работе и технологиях

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

Для реализации этого проекта мы использовали распространенную в мировой практике технологию Hadoop, базу данных HBase, ClickHouse, а также брокер сообщений Kafka. Выбор данных технологий позволил нам реализовать на приеме несколько этапов проверок с последующим отсеиванием тех сообщений, которые не соответствовали критериям заказчика с SLA менее 100 мс.

Один из ключевых параметров системы — способность обрабатывать большой объем данных. Поэтому во время разработки, помимо обычного тестирования, командой проводились сессии нагрузочного тестирования. Результаты показали, что максимальная нагрузка составляет около 23 000 сообщений в секунду. А это на 20% выше требований заказчика. За более чем два года промышленной эксплуатации доступность нашей системы значительно превысила международные стандарты для подобного рода систем. И это несмотря на 80 релизов во время ее эксплуатации.

Результативное построение команд

Нам удалось значительно ускорить процесс разработки: подобные системы обычно разрабатываются около года командами не менее 10-12 человек. Мы сократили этот срок до 7 месяцев и реализовали весь проект командой, состоящей всего из 6 человек. Подобного результата удалось достичь благодаря:

• использованию всех возможностей гибких методологий как основного элемента планирования и ведения разработки;
• использованию принципа непрерывной интеграции;
• сокращению влияния управляющих менеджеров на команду разработки — Техлид, он же Скраммастер;
• ежедневному взаимодействию с заказчиком;
• отдельному тестовому стенду, который являлся полной копией промышленного;
• оперативному отклику на периодические челленджи в выходные и в ночное время.

Особенности. Вызовы. Решения.

Одна из типовых трудностей, с которой мы столкнулись — это использование персональных данных. Прямого доступа к базам данных заказчика мы не имели. Вся разработка велась на отдельном контуре с дальнейшими релизами самим заказчиком. Поэтому нашим тестировщикам, помимо стандартного тестирования функционала, приходилось готовить максимально подробные инструкции.

Еще одним вызовом стало решение со стороны заказчика в середине разработки изменить формат приема данных без изменения срока релиза. В текущих реалиях это довольно распространенная ситуация, поскольку внешние обстоятельства постоянно меняются и компаниям необходимо под них подстраиваться. Нам же, как разработчикам, важно было им в этом помочь.

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

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