Сезонність — головний ворог фіксованої інфраструктури. Одинадцять місяців на рік сервер простоює на 20% завантаження, а в один тиждень не витримує трафіку.
Купувати ресурси під пік означає переплачувати весь рік; не купувати — втрачати гроші саме тоді, коли їх найлегше заробити. Хмарна модель існує саме для цієї задачі.
Вихідна ситуація
Український магазин товарів для активного відпочинку. Звичайна відвідуваність — близько 1 200 осіб на добу. Два виражені піки на рік: передноворічний період і весняний старт сезону. У піки трафік зростає у 5–7 разів, причому основний удар припадає на кілька годин після старту розсилки.
Попередній рік магазин пройшов болісно: сайт витримав, але час відповіді виріс до чотирьох секунд, а кількість завершених замовлень виявилася нижчою за очікувану приблизно на третину при рекордному трафіку.
Що зробили в підготовці
- Перенесли проєкт на хмарну конфігурацію з можливістю змінювати ресурси без перезавантаження сервісу.
- Винесли статику й зображення на окремий канал доставки контенту.
- Налаштували повносторінкове кешування для каталогу з коротким часом життя, залишивши динамічними лише кошик і оформлення.
- Провели навантажувальне тестування за два тижні до старту, змоделювавши очікуваний пік із подвійним запасом.
- Підготували план відкату на випадок, якщо щось піде не так під час розпродажу.
Що показало тестування
Найцікавіше знайшлося не там, де очікували. Вузьким місцем виявився не веб-сервер, а один запит до бази на сторінці фільтрації, який працював без індексу. На звичайному трафіку він додавав непомітні 80 мілісекунд, під навантаженням у сім разів вищим — блокував решту запитів і клав усю систему. Додавання індексу коштувало п’ять хвилин роботи і зняло проблему повністю.
Це типова історія: масштабування ресурсів маскує проблеми коду до певної межі, після якої масштабувати вже нема куди. Тому навантажувальне тестування має передувати збільшенню тарифу, а не навпаки.
Як пройшов сам пік
За дві години до старту розсилки конфігурацію збільшили вдвічі. У момент піку час відповіді тримався в межах 400 мілісекунд, помилок не було. Через три доби ресурси повернули до звичайного рівня. Загальна переплата за підвищену конфігурацію склала суму, яку магазин заробляє за перші пів години розпродажу.
Саме в цьому й полягає економічна логіка: хмарний хостинг для сайту дозволяє платити за пікову потужність рівно стільки днів, скільки вона потрібна, а не цілий рік.
Чекліст підготовки до сезону
Що робити після піку
Найкорисніша частина роботи починається наступного дня. Зафіксуйте фактичні цифри: пікову кількість одночасних користувачів, максимальний час відповіді, використання пам’яті й процесора, кількість помилок. Ці дані стануть основою для планування наступного сезону і врятують від вгадування.
Окремо перегляньте, які сторінки виявилися найповільнішими під навантаженням. Зазвичай це не головна, а сторінки фільтрації каталогу й кошик. Оптимізація саме цих двох вузлів дає більший ефект, ніж будь-яке подальше нарощування ресурсів.
Коли хмара не потрібна
Чесне застереження: якщо ваш трафік рівний протягом року, гнучкість хмарної моделі ви не використаєте, а надбавку за неї платитимете щомісяця. У такому випадку фіксована конфігурація на віртуальному чи виділеному сервері обійдеться дешевше за той самий обсяг ресурсів. Хмара — інструмент під конкретну задачу нерівномірного навантаження, а не універсально краще рішення.
За місяць: аудит повільних запитів до бази, перевірка актуальності версій, тестове відновлення з резервної копії. За два тижні: навантажувальне тестування з реалістичним сценарієм — не просто головна сторінка, а шлях від каталогу до оформлення замовлення. За тиждень: узгодження з провайдером плану масштабування і контактів для термінового зв’язку. За добу: заморозка будь-яких змін у коді. Під час піку: моніторинг у реальному часі й людина, яка на нього дивиться, а не лише автоматичні сповіщення.