AZON.моби
  • Новости
  • Обзоры
  • Смартфоны
  • Игры
  • Криптовалюты
No Result
View All Result
AZON.моби
No Result
View All Result
AZON.моби
Home Новости

Стабильные версии на бэкапе, кастомные метрики и не только: лучшие практики для highload от FAVBET Tech

28.08.2024
Share on FacebookShare on Twitter

В преддверии боя Усика и Фьюри тысячи болельщиков делали ставки, кто выиграет. Их запросы – миллионы в секунду – получала и обрабатывала платформа, которую обслуживает FAVBET Tech. Артем Скрипник, CEO FAVBET Tech, ставит команде за этот вызов твердую пятерку: платформа ни разу не легла.

Этоинтересно

Apple TV+ продлила Sci-Fi сериал «Киллербот» на второй сезон

Apple TV+ продлила Sci-Fi сериал «Киллербот» на второй сезон

11.07.2025
Петиция Stop Killing Games против отключения игр набрала 1,3 млн подписей

Петиция Stop Killing Games против отключения игр набрала 1,3 млн подписей

11.07.2025

Достичь этого удалось благодаря подготовке системы к нагрузке. Какие лучшие практики используют для этого в 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, мы обнаружили, что это будет стоить очень дорого. Надо было бы менять инфраструктуру и код и идти на рынок за новыми специалистами. А в результате мы бы получили улучшение всего на несколько процентов.

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

  1. Архитектура

Мы перешли от монолита к микросервисам. Это позволило масштабировать систему и иметь сотни независимых маленьких сервисов, каждый из которых можно масштабировать в зависимости от бизнеса. Чем меньше сервис, тем легче обеспечить его отказоустойчивость и правильную работу.

Нагрузка на каждый микросервис неравномерна. Один может обрабатывать сотни миллионов транзакций, другой – десятки. Важно правильно построить распределенные системы, когда используются кластеры серверов для распределения нагрузки, масштабирования, обработки и хранения данных между несколькими узлами.

Также важно использовать сервисы кеширования, что уменьшает нагрузку на систему. Кеширование – это прослойка между клиентом и сервером, которая позволяет выдавать определенные статические данные без привлечения основного сервиса.

Еще один важный аспект – балансировка нагрузки, то есть правильная настройка балансировщиков для корректного и равномерного распределения запросов между сервисами.

Представим, что у нас есть веб-сайт, который обслуживает онлайн-заказы в интернет-магазине техники. И вот вышел новый айфон – и все хотят сделать предзаказ. В такие моменты количество запросов на сайт резко увеличивается в единицу времени. Чтобы избежать перегрузки одного сервера, который может замедлить работу сайта или даже привести к его сбою, используется балансировщик нагрузки.

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

Очень хорошо работает автоскейлинг – возможность сервисов автоматически масштабироваться в зависимости от нагрузки. К примеру, вечером в пятницу или субботу пользователей на платформе больше, чем в понедельник. Держать одинаковое количество серверов в эти дни бессмысленно. Система автоматически отслеживает нагрузку на серверы. Если она приближается к пиковой, сама добавляет экземпляры, а если спадает – уменьшает их количество.

  1. Технологические подходы

Оптимизация баз данных критически важна, потому что они часто становятся узким местом системы. Это включает оптимизацию запросов в базу данных, распределение данных между несколькими базами (шардирование) и масштабирование баз данных как горизонтально, так и вертикально.

Вернемся к примеру с новенькими «яблочными» гаджетами. Предположим, есть проблема – база данных не была оптимизирована для такого количества одновременных запросов (предзаказов). Запросы становятся медленными, время отклика растет, и система начинает «тупить».

Последствия:

  • Сбои в функционировании сайта. Из-за перегрузки базы данных веб-сайт может периодически выходить из строя, приводя к потере потенциальных продаж и недовольству клиентов.
  • Ошибки при обработке заказов. Система может неправильно обрабатывать заказы, например, позволяя нескольким клиентам «купить» последний товар в запасе, что приводит к конфликтам и потребности в отмене заказов.
  • Утрата данных. Из-за высокой нагрузки возможны ситуации, когда данные не сохраняются должным образом, что приводит к потере важной информации о клиентах и ​​заказах.
  • Ухудшение репутации бренда. Частые сбои и медленная реакция сайта могут повлиять на впечатления клиентов от бренда, снижая лояльность и потенциально отпугивая новых клиентов.

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

Кроме того, технологические особенности охватывают разные мониторинги и метрики. Есть общедоступные метрики, такие как потребление сервисом RAM и CPU, а есть более кастомные, например, использование памяти внутренними процессами сервиса. Они и дают понять, что происходит внутри сервиса.

Долгое время в момент проблем мы не понимали, что идет не так. Пытались переделать код вслепую. И только когда по каждому ключевому сервису мы прописали кастомные метрики, то наконец-то увидели, где именно проблема, и пофиксили ее. Она могла быть даже не в нашем коде, а в используемой им библиотеке.

На некоторые метрики мы настраиваем алерты. К примеру, когда использование оперативной памяти достигает 75%, это сигнал задуматься об оптимизации сервиса. Это не значит, что он уже не работает, но сигнализирует о необходимости проверки.

  1. Организационные подходы

В FAVBET Tech есть отдельная команда, которая занимается нагрузочным тестированием. Она создает скрипты, которые моделируют поведение пользователей и нагрузку на систему. Это особенно важно для подготовки к большим событиям, когда мы ожидаем условные 100 тыс. клиентов и 500 млн ставок.

Мы можем смоделировать такую ​​нагрузку, прогнать сервисы в тестовой среде и проверить, как они ее выдержат. Это позволяет определить потенциальные проблемы и оптимизировать услуги без влияния на пользователей.

У компани есть пул performance-тестов для каждого направления, где самая большая нагрузка. Хорошей практикой является нагрузочное тестирование системы в нерабочие часы, например в 4-5 утра в понедельник, когда на платформе минимум клиентов.

Как спрогнозировать нагрузку

Каждый бизнес с амбициями ставит цель – расти любой ценой. И тогда некоторые нагрузки на сервисы можно спрогнозировать. Но самые большие технологические вызовы возникают именно в ситуациях, которые невозможно предположить.

Как технологическая компания FAVBET Tech не управляет бизнесом, а поставляет программное обеспечение. Например, один из наших клиентов – «Favbet Україна». Мы понимаем динамику и тенденции их бизнеса, знаем некоторые характеристики и метрики, которые можем собрать исторически и спрогнозировать.

Бизнес ожидает определенное количество новых клиентов и строит стратегию удержания существующих. Рост в таком случае органичен. Не бывает так, что за один день количество клиентов удваивается, но такое может постепенно произойти за год. И мы анализируем, как растет нагрузка на сервисы, где достигаются определенные пределы ресурсов и возможностей и что нужно подготовить заранее, чтобы за квартал быть готовыми к увеличению трафика.

Второй аспект – это сезонность событий, характерная для нашего бизнеса. К примеру, в ставках на спорт есть высокий и низкий сезоны. Высокий сезон – это топовые спортивные события, например, матчи сборной Украины, Евро и чемпионаты мира. Большие ивенты также вызывают интерес у игроков и являются прогнозируемыми событиями, на которые приходят многие пользователи.

К примеру, бои Кличко и Усика всегда вызывают большой интерес. Последний поединок Усика с Тайсоном Фьюри побил все рекорды нагрузки на платформу. Но мы ни разу не упали, потому что подготовились к этому заранее. Ставлю команде за это твердую пятерку.

Что делать, если нагрузки непредсказуемые

Сейчас мы уже знаем свои пиковые нагрузки. Команда к ним готова, так как у нас есть стабильные версии каждого сервиса. То есть, если мы проводим тестирование и видим, что какая-то новая версия сервиса не вывозит нагрузку и исправить ее не успеваем, мы откатимся к стабильной версии.

Но раньше так не было. Были определенные проблемы с нагрузкой, и мы не всегда успевали понять, почему они возникли. Были и кейсы, где нельзя было спрогнозировать нагрузку. К примеру, когда в прошлом году в Украине закрылся один из крупнейших операторов и огромное количество его клиентов перешли к другим игрокам рынка.

Главное правило в таких случаях: когда не удается оптимизировать код, нужно по крайней мере иметь возможность «засыпать все железом». Использовать не пять серверов, а 25. Это обойдется дорого, но сервис не ляжет. Вы выиграете время на необходимые технические изменения, а даунтаймы будут минимальными только на миграции сервисов на новые, более мощные, серверы.

Визуальное оформление статьи осуществлено командой ITC.UA

Другие новости

Apple TV+ продлила Sci-Fi сериал «Киллербот» на второй сезон

Apple TV+ продлила Sci-Fi сериал «Киллербот» на второй сезон

11.07.2025
Петиция Stop Killing Games против отключения игр набрала 1,3 млн подписей

Петиция Stop Killing Games против отключения игр набрала 1,3 млн подписей

11.07.2025
Звезду «Игры в кальмара» посадили на жесткую 14-месячную диету — он сбросил 10 кг, чтобы выглядеть «мучеником» в финале

Звезду «Игры в кальмара» посадили на жесткую 14-месячную диету — он сбросил 10 кг, чтобы выглядеть «мучеником» в финале

11.07.2025
Новые процессоры Ryzen впервые со времён Ryzen 3000 нарастят количество ядер. CPU на архитектуре Zen 6 уже поставляются партнёрам AMD

Новые процессоры Ryzen впервые со времён Ryzen 3000 нарастят количество ядер. CPU на архитектуре Zen 6 уже поставляются партнёрам AMD

11.07.2025
Google дарит год ИИ-сервиса AI Pro стоимостью $200 на Pixel 9 и запускает Gemini на Wear OS

Google дарит год ИИ-сервиса AI Pro стоимостью $200 на Pixel 9 и запускает Gemini на Wear OS

11.07.2025
Глобальный сбой Steam: серверы не работают по всему миру

Глобальный сбой Steam: серверы не работают по всему миру

11.07.2025
Next Post
Xiaomi отвергла слух о крутой фишке Redmi K80 из первых моделей серии

Xiaomi отвергла слух о крутой фишке Redmi K80 из первых моделей серии

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest
guest
0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

Популярные новости

  • Посольство РФ требует от США информацию о главе WEX

    Посольство РФ требует от США информацию о главе WEX

    1 shares
    Share 0 Tweet 0
  • Крипта криптой, но Tether держит 80 тонн золота на $8 млрд в тайном хранилище

    1 shares
    Share 0 Tweet 0
  • Обзор монитора MSI MAG 271QP QD-OLED X24: когда цена не портит качество

    1 shares
    Share 0 Tweet 0
  • Rockstar перенесла релиз GTA VI на май 2026 года

    1 shares
    Share 0 Tweet 0
  • Тест-драйв Land Rover Defender: легенда нашего времени

    14 shares
    Share 6 Tweet 4

Подписка на новости


Информация

Использование любых материалов сайта разрешается при условии ссылки на AZON.mobi
Интернет-СМИ должны использовать прямую открытую для поисковых систем гиперссылку. Ссылка должна размещаться в подзаголовке или в первом абзаце материала.
Редакция сайта может не разделять точку зрения авторов статей и ответственности за содержание републицируемых материалов не несет.

Мы в соцсетях

ТОП новости

Apple TV+ продлила Sci-Fi сериал «Киллербот» на второй сезон

Apple TV+ продлила Sci-Fi сериал «Киллербот» на второй сезон

11.07.2025
OPPO K13 Turbo получил первый тизер и официальную дату анонса

OPPO K13 Turbo получил первый тизер и официальную дату анонса

11.07.2025
  • Разместить новости

© 2006-2024 AZON.mobi
Новости высоких технологий. All rights reserved.

No Result
View All Result
  • Новости
  • Игры
  • Криптовалюты
  • Обзоры
  • Смартфоны

© 2006-2024 AZON.mobi
Новости высоких технологий. All rights reserved.

wpDiscuz
0
0
Оставьте комментарий! Напишите, что думаете по поводу статьи.x
()
x
| Ответить