Ми всі любимо дивитися прямі трансляції матчів, будь то Індійська Прем'єр-Ліга (IPL) або Ліга чемпіонів УЄФА, але чи замислювались ви коли-небудь, як ці організації справляються з такою великою кількістю одночасних користувачів, які можуть раптово збільшуватись або зменшуватись на будь-яку кількість? Але спершу давайте зрозуміємо концепцію графіка цунамі.
Приклад графіка цунамі
Припустимо, ми дивимося крикетний матч, і Вірат виходить на поле о 12:30. Подивіться на пік на вищезгаданому графіку — величезна кількість користувачів підключається до прямої трансляції (перед тим, як він вибуває з гри близько 13:00, і кількість користувачів знову різко знижується). Команди з маркетингу та продажів надсилають сповіщення, залучаючи ще більше користувачів одночасно. Тут, як розробник, ви можете подумати, що ми можемо використовувати авто-масштабування, і це має бути правильний підхід. Але насправді це не зовсім так. Авто-масштабування в AWS може бути не найкращим варіантом для всіх, оскільки:
- Один тип інстанції на групу: Коли система авто-масштабується, і уявімо, що ми використовуємо тип інстанції m5x large, і вона з якоїсь причини дає помилку, ви не зможете масштабувати свій застосунок, що призведе до блокування.
- Експоненціальне зворотне відключення: Через різкий сплеск в черзі запитів ми можемо зіткнутися з каскадним ефектом, що може призвести до великої затримки в нашій прямій трансляції.
- Проблеми з доступністю потужностей: Коли наша система масштабуватиметься в конкретній AZ, ми можемо отримати помилку “Досягнута межа потужності в AZ”, що створить перешкоди під час масштабування.
Тепер постає питання: як же вони масштабуються? Вони роблять це так:
- Окрім базового масштабування, яке здійснюється за допомогою AWS на основі використання CPU та пам'яті, вони масштабуються на основі кількості запитів. Як тільки кількість запитів зростає, система масштабується.
- Крім цього, ми також можемо створювати AI моделі, використовуючи такі інструменти як Splunk, Datadog або інші подібні, що дозволяють системам автоматично масштабуватись на основі шаблонів. Наприклад, пік навантаження на матчі IPL зазвичай припадає на початкові або кінцеві овери, або коли хтось знаходиться на 99, або коли боулер намагається зробити хет-трик.
- Налаштування більше ніж одного типу інстанції, окрім тих, що використовуються конкретною AZ, гарантує, що ми не потрапимо в пастку неможливості масштабування через використання тільки одного типу інстанції в групі.
Отже, коли кількість живих користувачів наближається до 99% від загальної кількості користувачів, вони більше акцентують увагу на критичних послугах (платіжна система, реклама), а не на інших послугах, якими користується лише 1% користувачів у цей момент, наприклад: налаштування моєї пробіли на клавіатурі. Для того, щоб зрозуміти всі ці процеси, розробники повинні спершу добре зрозуміти шлях користувача.
-Рошан
(Навчаючись голосно)
Перекладено з: How Hotstar scales millions of concurrent users