Напередодні бою Усика і Ф’юрі тисячі вболівальників робили ставки, хто виграє. Їхні запити – мільйони на секунду – отримувала й обробляла платформа, яку обслуговує FAVBET Tech. Артем Скрипник, CEO FAVBET Tech, ставить команді за цей виклик тверду п’ятірку: платформа жодного разу не лягла.
Досягти цього вдалося завдяки підготовці системи до навантаження. Які найкращі практики використовують для цього у FAVBET Tech і що робити, якщо спрогнозувати навантаження неможливо, Артем Скрипник розповідає в партнерському матеріалі для ITC.
Зміст
Які системи вважають високонавантаженими
Коли я почав працювати в компанії, в ІТ-напрямі було близько 80 людей. Зараз їх 450. Вони розробляють і підтримують понад 20 проєктів, трохи менше половини з яких проєкти з високим навантаженням.
Ключові характеристики таких систем:
- велика кількість користувачів одночасно;
- висока швидкість оброблення даних;
- можливість масштабування (скейлингу): збільшення технічних ресурсів під потреби бізнесу;
- високий рівень безперервної роботи платформи (аптайму).
Проєкти, де є сотні тисяч клієнтів і сотні мільйонів транзакцій за добу, вважаються highload-проєктами.
Наш ключовий продукт – платформа для ігорної індустрії, яка охоплює в тому числі онлайн-казино і ставки на спорт. Вона працює зокрема в Україні, Хорватії та Румунії та є прикладом проєкту з високим навантаженням. Коли користувач грає у слоти, він може робити ставки щосекунди. Якщо підрахувати кількість користувачів у пікові години, кількість транзакцій зростає до десятків мільйонів.
Наш ключовий продукт – платформа для ігорної індустрії, яка охоплює в тому числі онлайн-казино і ставки на спорт. Вона працює зокрема в Україні, Хорватії та Румунії та є прикладом проєкту з високим навантаженням. Коли користувач грає у слоти, він може робити ставки щосекунди. Якщо підрахувати кількість користувачів у пікові години, кількість транзакцій зростає до десятків мільйонів.
Не всі проєкти призначені для великих навантажень: наприклад, сайти-візитівки чи внутрішні корпоративні портали компаній. Але в більшості продуктів є потенціал зростання. Зазвичай на початку стартапи не націлені будувати відмовостійку систему, бо це могло б уповільнити запуск. На старті створюється базовий прототип, який просто працює. Тільки коли кількість транзакцій і користувачів зростає, потрібно вдосконалювати продукт, щоб забезпечити його стабільну роботу.
Для FAVBET Tech це питання гостро постало через COVID-19, коли масово почали використовувати онлайн-сервіси. Особливо це вплинуло на онлайн-казино: за день тут робиться до десятків і сотень млн ставок.
Як підготувати систему до високих навантажень
Я не прихильник того, що якась технологія більше підходить для highload-продуктів. Будь-якою мовою можна написати сервіс, який витримає високі навантаження. Але для цього потрібно мати глибокі знання і вміння у сфері архітектурного аналізу та розуміти, як сервіс взаємодіятиме з іншими системами в різних умовах.
Але специфічні технології для високонавантажених систем є.
Наприклад, декілька років тому ми переписали наші core-сервіси на Erlang, бо ця мова ефективно обробляє велику кількість транзакцій і використовує при цьому мінімум ресурсів.
Водночас Erlang-фахівців мало на ринку, тому для клієнтських сервісів ми використовуємо Python, PHP та Node.js. Інколи це означає, що нам доводиться обробляти дані на 20 серверах замість п’яти, але це по-своєму класні технології.
Також ми вибрали RabbitMQ замість Kafka: хоча саме друга вважається кращою для високонавантажених систем. Втім, коли постало питання про міграції на Kafka, ми виявили, що це коштуватиме надзвичайно дорого. Треба було б змінювати інфраструктуру та код і йти на ринок за новими фахівцями. А в результаті ми б отримали покращення лише на кілька відсотків.
Загалом ми активно працюємо над перебудовою нашої платформи і зміною підходів останніми роками. Найкращі рішення можна поділити на три напрями.
- Архітектура
Ми перейшли від моноліту до мікросервісів. Це дозволило масштабувати систему та мати сотні незалежних маленьких сервісів, кожен з яких можна масштабувати залежно від потреб бізнесу. Чим менше сервіс, тим легше забезпечити його відмовостійкість і правильну роботу.
Також важливо використовувати сервіси кешування, що зменшує навантаження на систему. Кешування – це прошарок між клієнтом і сервером, який дозволяє видавати певні статичні дані без залучення основного сервісу.
Ще один важливий аспект – балансування навантаження, тобто правильне налаштування балансувальників для коректного та рівномірного розподілення запитів між сервісами.
Уявімо, що в нас є вебсайт, який обслуговує онлайн-замовлення в інтернет-магазині техніки. Ось вийшов новий айфон – і всі хочуть зробити передзамовлення. У такі моменти кількість запитів на сайт різко збільшується на одиницю часу. Щоб уникнути перевантаження одного сервера, який може сповільнити роботу сайту або навіть призвести до його збою, використовується балансувальник навантаження.
Балансувальник навантаження працює як регулятор, який розподіляє вхідні запити на замовлення між кількома серверами. Наприклад, у нас є три сервери, і коли запит від клієнта надходить до нашої системи, балансувальник вирішує, на який сервер спрямувати цей запит, виходячи з поточного навантаження на кожен сервер. Це означає, що жоден сервер не буде перевантажений, оскільки навантаження рівномірно розподілене, і всі клієнти отримають швидку відповідь на свої запити.
Дуже добре працює автоскейлинг – можливість сервісів автоматично масштабуватися залежно від навантаження. Наприклад, ввечері у п’ятницю чи суботу користувачів на платформі більше, ніж у понеділок. Тримати однакову кількість серверів у ці дні немає сенсу. Тож система автоматично відстежує навантаження на сервери. Якщо воно наближається до пікового, сама додає екземпляри, а якщо спадає – зменшує їх кількість.
- Технологічні підходи
Оптимізація баз даних критично важлива, адже вони часто стають вузьким місцем системи. Це включає оптимізацію запитів до бази даних, розподіл даних між кількома базами (шардування) та масштабування баз даних як горизонтально, так і вертикально.
Повернемося до прикладу з новенькими «яблучними» гаджетами. Припустимо, є проблема – база даних не була оптимізована для такої кількості одночасних запитів (передзамовлень). Запити стають повільними, час відгуку зростає, і система починає «тупити».
Наслідки:
- Збої у функціонуванні вебсайту. Через перевантаження бази даних вебсайт може періодично виходити з ладу, призводячи до втрати потенційних продажів і невдоволення клієнтів.
- Помилки в обробленні замовлень. Система може неправильно обробляти замовлення, наприклад, дозволяючи кільком клієнтам «купити» останній товар у запасі, що призводить до конфліктів і потреби у скасуванні замовлень.
- Втрата даних. Через високе навантаження можливі ситуації, коли дані не зберігаються належним чином, що призводить до втрати важливої інформації про клієнтів і замовлення.
- Погіршення репутації бренду. Часті збої та повільна реакція сайту можуть негативно вплинути на враження клієнтів від бренду, знижуючи лояльність і потенційно відлякуючи нових клієнтів.
Оптимізація коду, алгоритмів, методів використання пам’яті і процесора, асинхронне оброблення даних, використання черг повідомлень – усе це також допомагає забезпечити стабільну роботу сервісів під великим навантаженням.
Крім того, технологічні особливості охоплюють різні моніторинги та метрики. Є загально доступні метрики, як-от споживання сервісом RAM і CPU, а є більш кастомні, наприклад, використання пам’яті внутрішніми процесами сервісу. Вони й дають зрозуміти, що відбувається всередині сервісу.
Довгий час у момент проблем ми не розуміли, що саме відбувається не так. Намагалися переробити код наосліп. І тільки коли за кожним ключовим сервісом ми прописали кастомні метрики, то нарешті побачили, де саме є проблема, і пофіксили її. Вона могла бути навіть не в нашому коді, а в бібліотеці, яку він використовує.
- Організаційні підходи
У FAVBET Tech є окрема команда, яка займається навантажувальним тестуванням. Вона створює скрипти, які моделюють поведінку користувачів і навантаження на систему. Це особливо важливо для підготовки до великих подій, коли ми очікуємо умовні 100 тис. клієнтів та 500 млн ставок.
Ми можемо змоделювати таке навантаження, прогнати сервіси в тестовому середовищі та перевірити, як вони його витримають. Це дозволяє визначити потенційні проблеми й оптимізувати сервіси без впливу на користувачів.
Компанія має пул performance-тестів для кожного напряму, де є найбільше навантаження. Гарною практикою є навантажувальне тестування системи в неробочі години, наприклад, о 4-5 ранку в понеділок, коли на платформі мінімум клієнтів.
Як спрогнозувати навантаження
Кожен бізнес з амбіціями ставить мету – зростати за будь-яку ціну. І тоді деякі навантаження на сервіси можна спрогнозувати. Проте найбільші технологічні виклики виникають саме в ситуаціях, які неможливо передбачити.
Бізнес очікує певну кількість нових клієнтів і будує стратегії утримання чинних. Зростання в такому випадку є органічним. Не буває так, що за один день кількість клієнтів подвоюється, але так може поступово статися за рік. І ми аналізуємо, як зростає навантаження на сервіси, де досягаються певні межі ресурсів і можливостей і що потрібно підготувати заздалегідь, щоб за квартал бути готовими до збільшення трафіку.
Другий аспект – це сезонність подій, характерна для нашого бізнесу. Наприклад, у ставках на спорт є високий і низький сезони. Високий сезон – це топові спортивні події, наприклад, матчі збірної України, Євро та чемпіонати світу. Великі івенти також викликають інтерес у гравців і є прогнозованими подіями, на які приходить багато користувачів.
Наприклад, бої Кличка й Усика завжди викликають великий інтерес. Останній поєдинок Усика з Тайсоном Ф’юрі побив усі рекорди навантаження на платформу. Але ми жодного разу не впали, бо підготувались до цього завчасно. Ставлю команді за це тверду п’ятірку.
Що робити, якщо навантаження непередбачувані
Зараз ми вже знаємо свої пікові навантаження. Команда до них готова, оскільки в нас є стабільні версії кожного сервісу. Тобто, якщо ми проводимо тестування і бачимо, що якась нова версія сервісу не вивозить навантаження і виправити її не встигаємо, ми відкотимося до стабільної версії.
Але раніше так не було. Були певні проблеми із триманням навантаження, і ми не завжди встигали зрозуміти, чому вони виникли. Були й кейси, де не можна було спрогнозувати навантаження. Наприклад, коли минулого року в Україні закрився один з найбільших операторів і величезна кількість його клієнтів перейшли до інших гравців ринку.
Головне правило в таких випадках: коли не вдається оптимізувати код, потрібно принаймні мати можливість «засипати все залізом». Використати не п’ять серверів, а 25. Це коштуватиме дорого, але сервіс не ляже. Натомість ви виграєте час на необхідні технічні зміни, а даунтайми будуть мінімальними тільки на міграції сервісів на нові, потужніші, сервери.
Візуальне оформлення статті здійснено командою ITC.UA
Повідомити про помилку
Текст, який буде надіслано нашим редакторам: