В преддверии боя Усика и Фьюри тысячи болельщиков делали ставки, кто выиграет. Их запросы – миллионы в секунду – получала и обрабатывала платформа, которую обслуживает FAVBET Tech. Артем Скрипник, CEO FAVBET Tech, ставит команде за этот вызов твердую пятерку: платформа ни разу не легла.
Достичь этого удалось благодаря подготовке системы к нагрузке. Какие лучшие практики используют для этого в FAVBET Tech и что делать, если спрогнозировать нагрузку невозможно, Артем Скрипник рассказывает в партнерском материале для ITC.
Содержание
- 1 Какие системы считают высоконагруженными
- 2 Как подготовить систему к высоким нагрузкам
- 3 Как спрогнозировать нагрузку
- 4 Что делать, если нагрузки непредсказуемые
Какие системы считают высоконагруженными
Когда я начал работать в компании, в IT-направлении было около 80 человек. Сейчас их 450. Они разрабатывают и поддерживают более 20 проектов, чуть менее половины из которых проекты с высокой нагрузкой.
Высокая нагрузка (highload) – термин, который описывает системы, обрабатывающие большой объем данных, клиентов и запросов за короткий промежуток времени.
Ключевые характеристики таких систем:
- большое количество пользователей одновременно;
- высокая скорость обработки данных;
- возможность масштабирования (скейлинга): увеличение технических ресурсов под нужды бизнеса;
- высокий уровень непрерывной работы платформы (аптайма).
Проекты, где есть сотни тысяч клиентов и сотни миллионов транзакций в сутки, считаются highload-проектами.
Наш ключевой продукт – платформа для игорной индустрии, которая охватывает в том числе онлайн-казино и ставки на спорт. Она работает в Украине, Хорватии и Румынии и является примером проекта с высокой нагрузкой. Когда пользователь играет в слоты, он может делать ставки ежесекундно. Если подсчитать количество пользователей в пиковые часы, количество транзакций возрастает до десятков миллионов.
Артем Скрипник
CEO FAVBET Tech
Не все проекты предназначены для больших нагрузок: например, сайты-визитки или внутренние корпоративные порталы компаний. Но у большинства продуктов есть потенциал роста. Обычно в начале стартапы не нацелены строить отказоустойчивую систему, потому что это могло бы замедлить запуск. На старте создается базовый прототип, который просто работает. Только когда количество транзакций и пользователей растет, нужно усовершенствовать продукт, чтобы обеспечить его стабильную работу.
Для FAVBET Tech этот вопрос остро встал из-за COVID-19, когда массово начали использовать онлайн-сервисы. Особенно это повлияло на онлайн-казино: за день здесь делается до десятков и сотен миллионов ставок.
Как подготовить систему к высоким нагрузкам
Я не сторонник того, что какая-то технология больше подходит для highload-продуктов. На любом языке можно написать сервис, который выдержит высокие нагрузки. Но для этого нужно обладать глубокими знаниями и умениями в сфере архитектурного анализа и понимать, как сервис будет взаимодействовать с другими системами в разных условиях.
Но специальные технологии для высоконагруженных систем есть.
К примеру, несколько лет назад мы переписали наши core-сервисы на Erlang, потому что этот язык эффективно обрабатывает большое количество транзакций и использует при этом минимум ресурсов.
В то же время Erlang-специалистов мало на рынке, поэтому для клиентских сервисов мы используем Python, PHP и Node.js. Иногда это означает, что нам приходится обрабатывать данные на 20 серверах вместо пяти, но это классные технологии.
Также мы выбрали RabbitMQ вместо Kafka: хотя именно вторая считается лучшей для высоконагруженных систем. Впрочем, когда встал вопрос о миграциях на Kafka, мы обнаружили, что это будет стоить очень дорого. Надо было бы менять инфраструктуру и код и идти на рынок за новыми специалистами. А в результате мы бы получили улучшение всего на несколько процентов.
В общем, мы активно работаем над перестройкой нашей платформы и изменением подходов в последние годы. Лучшие решения можно разделить на три направления.
- Архитектура
Мы перешли от монолита к микросервисам. Это позволило масштабировать систему и иметь сотни независимых маленьких сервисов, каждый из которых можно масштабировать в зависимости от бизнеса. Чем меньше сервис, тем легче обеспечить его отказоустойчивость и правильную работу.
Нагрузка на каждый микросервис неравномерна. Один может обрабатывать сотни миллионов транзакций, другой – десятки. Важно правильно построить распределенные системы, когда используются кластеры серверов для распределения нагрузки, масштабирования, обработки и хранения данных между несколькими узлами.
Также важно использовать сервисы кеширования, что уменьшает нагрузку на систему. Кеширование – это прослойка между клиентом и сервером, которая позволяет выдавать определенные статические данные без привлечения основного сервиса.
Еще один важный аспект – балансировка нагрузки, то есть правильная настройка балансировщиков для корректного и равномерного распределения запросов между сервисами.
Представим, что у нас есть веб-сайт, который обслуживает онлайн-заказы в интернет-магазине техники. И вот вышел новый айфон – и все хотят сделать предзаказ. В такие моменты количество запросов на сайт резко увеличивается в единицу времени. Чтобы избежать перегрузки одного сервера, который может замедлить работу сайта или даже привести к его сбою, используется балансировщик нагрузки.
Балансировщик нагрузки работает как регулятор, который распределяет входящие запросы на заказ между несколькими серверами. Например, у нас есть три сервера, и когда запрос от клиента поступает в нашу систему, балансировщик решает, на какой сервер направить этот запрос исходя из текущей нагрузки на каждый сервер. Это означает, что ни один сервер не будет перегружен, поскольку нагрузка равномерно распределена, и все клиенты получат быстрый ответ на свои запросы.
Очень хорошо работает автоскейлинг – возможность сервисов автоматически масштабироваться в зависимости от нагрузки. К примеру, вечером в пятницу или субботу пользователей на платформе больше, чем в понедельник. Держать одинаковое количество серверов в эти дни бессмысленно. Система автоматически отслеживает нагрузку на серверы. Если она приближается к пиковой, сама добавляет экземпляры, а если спадает – уменьшает их количество.
- Технологические подходы
Оптимизация баз данных критически важна, потому что они часто становятся узким местом системы. Это включает оптимизацию запросов в базу данных, распределение данных между несколькими базами (шардирование) и масштабирование баз данных как горизонтально, так и вертикально.
Вернемся к примеру с новенькими «яблочными» гаджетами. Предположим, есть проблема – база данных не была оптимизирована для такого количества одновременных запросов (предзаказов). Запросы становятся медленными, время отклика растет, и система начинает «тупить».
Последствия:
- Сбои в функционировании сайта. Из-за перегрузки базы данных веб-сайт может периодически выходить из строя, приводя к потере потенциальных продаж и недовольству клиентов.
- Ошибки при обработке заказов. Система может неправильно обрабатывать заказы, например, позволяя нескольким клиентам «купить» последний товар в запасе, что приводит к конфликтам и потребности в отмене заказов.
- Утрата данных. Из-за высокой нагрузки возможны ситуации, когда данные не сохраняются должным образом, что приводит к потере важной информации о клиентах и заказах.
- Ухудшение репутации бренда. Частые сбои и медленная реакция сайта могут повлиять на впечатления клиентов от бренда, снижая лояльность и потенциально отпугивая новых клиентов.
Оптимизация кода, алгоритмов, методов использования памяти и процессора, асинхронная обработка данных, использование очередей сообщений – это также помогает обеспечить стабильную работу сервисов под большой нагрузкой.
Кроме того, технологические особенности охватывают разные мониторинги и метрики. Есть общедоступные метрики, такие как потребление сервисом RAM и CPU, а есть более кастомные, например, использование памяти внутренними процессами сервиса. Они и дают понять, что происходит внутри сервиса.
Долгое время в момент проблем мы не понимали, что идет не так. Пытались переделать код вслепую. И только когда по каждому ключевому сервису мы прописали кастомные метрики, то наконец-то увидели, где именно проблема, и пофиксили ее. Она могла быть даже не в нашем коде, а в используемой им библиотеке.
На некоторые метрики мы настраиваем алерты. К примеру, когда использование оперативной памяти достигает 75%, это сигнал задуматься об оптимизации сервиса. Это не значит, что он уже не работает, но сигнализирует о необходимости проверки.
- Организационные подходы
В FAVBET Tech есть отдельная команда, которая занимается нагрузочным тестированием. Она создает скрипты, которые моделируют поведение пользователей и нагрузку на систему. Это особенно важно для подготовки к большим событиям, когда мы ожидаем условные 100 тыс. клиентов и 500 млн ставок.
Мы можем смоделировать такую нагрузку, прогнать сервисы в тестовой среде и проверить, как они ее выдержат. Это позволяет определить потенциальные проблемы и оптимизировать услуги без влияния на пользователей.
У компани есть пул performance-тестов для каждого направления, где самая большая нагрузка. Хорошей практикой является нагрузочное тестирование системы в нерабочие часы, например в 4-5 утра в понедельник, когда на платформе минимум клиентов.
Как спрогнозировать нагрузку
Каждый бизнес с амбициями ставит цель – расти любой ценой. И тогда некоторые нагрузки на сервисы можно спрогнозировать. Но самые большие технологические вызовы возникают именно в ситуациях, которые невозможно предположить.
Как технологическая компания FAVBET Tech не управляет бизнесом, а поставляет программное обеспечение. Например, один из наших клиентов – «Favbet Україна». Мы понимаем динамику и тенденции их бизнеса, знаем некоторые характеристики и метрики, которые можем собрать исторически и спрогнозировать.
Бизнес ожидает определенное количество новых клиентов и строит стратегию удержания существующих. Рост в таком случае органичен. Не бывает так, что за один день количество клиентов удваивается, но такое может постепенно произойти за год. И мы анализируем, как растет нагрузка на сервисы, где достигаются определенные пределы ресурсов и возможностей и что нужно подготовить заранее, чтобы за квартал быть готовыми к увеличению трафика.
Второй аспект – это сезонность событий, характерная для нашего бизнеса. К примеру, в ставках на спорт есть высокий и низкий сезоны. Высокий сезон – это топовые спортивные события, например, матчи сборной Украины, Евро и чемпионаты мира. Большие ивенты также вызывают интерес у игроков и являются прогнозируемыми событиями, на которые приходят многие пользователи.
К примеру, бои Кличко и Усика всегда вызывают большой интерес. Последний поединок Усика с Тайсоном Фьюри побил все рекорды нагрузки на платформу. Но мы ни разу не упали, потому что подготовились к этому заранее. Ставлю команде за это твердую пятерку.
Что делать, если нагрузки непредсказуемые
Сейчас мы уже знаем свои пиковые нагрузки. Команда к ним готова, так как у нас есть стабильные версии каждого сервиса. То есть, если мы проводим тестирование и видим, что какая-то новая версия сервиса не вывозит нагрузку и исправить ее не успеваем, мы откатимся к стабильной версии.
Но раньше так не было. Были определенные проблемы с нагрузкой, и мы не всегда успевали понять, почему они возникли. Были и кейсы, где нельзя было спрогнозировать нагрузку. К примеру, когда в прошлом году в Украине закрылся один из крупнейших операторов и огромное количество его клиентов перешли к другим игрокам рынка.
Главное правило в таких случаях: когда не удается оптимизировать код, нужно по крайней мере иметь возможность «засыпать все железом». Использовать не пять серверов, а 25. Это обойдется дорого, но сервис не ляжет. Вы выиграете время на необходимые технические изменения, а даунтаймы будут минимальными только на миграции сервисов на новые, более мощные, серверы.
Визуальное оформление статьи осуществлено командой ITC.UA
