Высоконагруженная система 2 млрд сообщений в сутки за 7 месяцев
В наше время повсеместной цифровизации многие компании сталкиваются с большими потоками данных. Эти системы должны выдерживать большие нагрузки.
Возникает вопрос: как системам оставаться работоспособными и укладываться в требуемые SLA?
Наша компания имеет большой опыт работы с High End системами, основными критериями которых являются высокая нагрузка, высокая доступность, отказоустойчивость и низкий уровень задержки. Рассмотрим пример из нашей практики — создание высоконагруженной системы по приему и обработке 2 млрд сообщений в сутки.
О подходах в работе и технологиях
Помимо основных стандартных характеристик к системе, командой были реализованы функциональные требования: доступность 24/7, горизонтальная масштабируемость и аналитика в режиме реального времени.
Для реализации этого проекта мы использовали распространенную в мировой практике технологию Hadoop, базу данных HBase, ClickHouse, а также брокер сообщений Kafka. Выбор данных технологий позволил нам реализовать на приеме несколько этапов проверок с последующим отсеиванием тех сообщений, которые не соответствовали критериям заказчика с SLA менее 100 мс.
Один из ключевых параметров системы — способность обрабатывать большой объем данных. Поэтому во время разработки, помимо обычного тестирования, командой проводились сессии нагрузочного тестирования. Результаты показали, что максимальная нагрузка составляет около 23 000 сообщений в секунду. А это на 20% выше требований заказчика. За более чем два года промышленной эксплуатации доступность нашей системы значительно превысила международные стандарты для подобного рода систем. И это несмотря на 80 релизов во время ее эксплуатации.
Результативное построение команд
Нам удалось значительно ускорить процесс разработки: подобные системы обычно разрабатываются около года командами не менее 10-12 человек. Мы сократили этот срок до 7 месяцев и реализовали весь проект командой, состоящей всего из 6 человек.
Подобного результата удалось достичь благодаря:
- использованию всех возможностей гибких методологий как основного элемента планирования и ведения разработки;
- использованию принципа непрерывной интеграции;
- сокращению влияния управляющих менеджеров на команду разработки — Техлид, он же Скраммастер;
- ежедневному взаимодействию с заказчиком;
- отдельному тестовому стенду, который являлся полной копией промышленного;
- оперативному отклику на периодические челленджи в выходные и в ночное время.
Особенности. Вызовы. Решения
Несколько слов хочу сказать и о сложных задачах на проекте. Одна из типовых трудностей, с которой мы столкнулись – это использование персональных данных. Прямого доступа к базам данных заказчика мы не имели. Вся разработка велась на отдельном контуре с дальнейшими релизами самим заказчиком. Поэтому нашим тестировщикам, помимо стандартного тестирования функционала, приходилось готовить максимально подробные инструкции.
Еще одним вызовом стало решение со стороны заказчика в середине разработки изменить формат приема данных без изменения срока релиза. В текущих реалиях это довольно распространенная ситуация, поскольку внешние обстоятельства постоянно меняются и компаниям необходимо под них подстраиваться. Нам же, как разработчикам, важно было им в этом помочь.
Теперь расскажу о решениях. Нам удалось договориться с заказчиком об одном финальном релизе без проведения промежуточных - это позволило достаточно сильно выиграть время, которое не пришлось тратить на составление планов, сборок и т.д. Также благодаря продуманной микросервисной архитектуре мы достаточно быстро и точечно заменили исходные модули системы, добавили новые правила без влияния на общий функционал. В настоящий момент наша система насчитывает уже больше трехсот модулей.
Важный фактор работоспособности системы, который требует особого внимания – тонкая настройка оборудования, которая напрямую влияет на скорость работы в целом. Зачастую рекомендуемые параметры оборудования не соответствуют тем критериям к системе, которые мы предъявляем при разработке, поэтому мы также оказываем необходимую поддержку по конфигурации оборудования.
Как выбрать исполнителя
При выборе исполнителя для схожих задач я рекомендую обращать внимание на следующие моменты. Во-первых, в портфолио компании должны быть успешно завершенные проекты по высоконагруженным системам. Во-вторых, подтвержденный опыт гибких методологий, а также опыт работы с закрытыми контурами заказчика без прямого доступа к базам данных.
Не стоит бояться сложных задач – для каждой из них найдется оптимальное решение.