Хмарні ВМ і хмарні браузери оплачуються за часом, тому пакетні завдання легко впираються у квоти. Оцініть споживання, визначте практичну межу паралельності та дотримуйтеся правильного порядку відновлення.
Для ресурсів із погодинною оплатою логіка рахунку проста: тривалість роботи, помножена на кількість інстансів. Квота — це жорстка верхня межа. Після її досягнення завдання не просто сповільнюються, а одразу завершуються помилкою: нові інстанси не створюються, активні можуть бути відкликані, а API починають повертати помилки обмеження частоти. Розуміти, наскільки близько ви до межі, корисніше, ніж просто збільшувати бюджет уже після проблеми.
Спочатку відокремте необхідне споживання від зайвого
Одна й та сама квота може давати дуже різну віддачу залежно від завдань, які її споживають. Спершу проведіть інвентаризацію та розділіть завдання за тим, чи справді їм потрібне виконання в реальному часі.
Постійно активні завдання належать до тих, що найшвидше з'їдають квоту. Вони можуть працювати весь день, хоча реальна корисна робота триває лише кілька хвилин. Перехід від безперервного моніторингу до запуску за розкладом часто суттєво скорочує споживання майже без помітного впливу на бізнес. Пікові завдання, зосереджені в певні години, можна переносити, а одноразові запускати тільки за потреби.
Потім поставте собі запитання: чи постраждає бізнес, якщо це завдання виконається на шість годин пізніше? Якщо так, залиште його на критичному шляху та запускайте в реальному часі. Якщо ні, переведіть у низькопріоритетну пакетну обробку й заплануйте на період, коли квота менш завантажена. Перехід від щогодинного моніторингу цін конкурентів до двох перевірок на день у більшості випадків не зменшує інформаційну цінність суттєво.
Як оцінювати споживання та визначати паралельність
Коли оплата залежить від часу роботи інстансів, загальне споживання пакета приблизно дорівнює середній тривалості одного завдання, помноженій на кількість завдань. Воно не залежить від рівня паралельності; паралельність лише визначає, як швидко завершиться пакет. Натомість від неї залежить миттєве навантаження: що більше інстансів запускаються одночасно, то вища ймовірність упертися в межу паралельності пулу ресурсів або обмеження платформи.
Тому починайте з мінімальної паралельності. Спершу запустіть одне завдання й перевірте його середню тривалість та рівень успішності. Потім поступово збільшуйте до кількох, а далі приблизно до десятка одночасних завдань, записуючи частку помилок і кількість повторних спроб. Якщо після певної точки частка помилок помітно зростає, це і є практично доступна межа. Подальше підвищення паралельності лише поверне зекономлений час через додаткові повтори.
Не пропускайте прихований час: очікування входу, завантаження сторінок, кроки перевірки та повторні спроби після невдач. Часто вони тривають довше за основний процес. Корисніше залишити запас на кожне завдання, ніж намагатися все порахувати до хвилини.
Як виглядає вичерпання квоти
Вичерпання квоти важко розпізнати, бо воно часто схоже на інші проблеми.
Одна ознака — завдання зависає на старті, оскільки запит на створення середовища або інстансу відхиляється, а в журналі залишається лише нечітка помилка. Інша — інстанс відкликають посеред виконання, і весь попередній прогрес втрачається. Також можуть з'являтися помилки обмеження частоти, часткові успіхи впереміш із невдачами або черга, що постійно зростає, але не обробляється.
Найлегше помилково діагностувати удаване зависання: інстанс ще існує, завдання виглядає активним, але насправді постійно чекає, а квота продовжує витрачатися з часом. У такій ситуації спершу перевірте панель використання квоти, а потім окремо запустіть невелике завдання. Якщо й воно не стартує, причина, ймовірно, у квоті або дозволах. Якщо працює нормально, проблема швидше за все в паралельності або повторному використанні середовища.
Порядок дій для відновлення
Починайте з дій, які нічого не коштують.
По-перше, зупиніть малоцінне постійне споживання й переведіть завдання моніторингу на запуск за розкладом. По-друге, перенесіть завдання, які можуть чекати, на періоди з більшим запасом квоти, щоб вирівняти криву споживання. По-третє, знизьте межу паралельності та додайте чергу, щоб завдання виконувалися відповідно до доступної місткості, а не стартували всі разом. По-четверте, скоротіть марне споживання: кешуйте спільні ресурси замість повторного завантаження, за можливості отримуйте більше даних одним запитом, швидко завершуйте запити, приречені на помилку, і не повторюйте їх без кінця.
Лише після цих чотирьох кроків вирішуйте, чи потрібен більший бюджет або вищий рівень сервісу. Часто виявляється, що реально потрібна квота менша, ніж здавалося спочатку. Якщо спершу збільшити бюджет, разом із ним ви профінансуєте й неефективні звички.
Не стискайте шар середовища разом з обчислювальним шаром
Поширена помилка під час економії квоти — змушувати кілька завдань використовувати одне браузерне середовище, виходячи з того, що достатньо запустити його лише один раз.
Наслідки з'являються одразу: сесії перезаписують одна одну, стани входу збиваються, кеші змішуються, а збій одного завдання може потягнути за собою інші. Невелика економія часу інстансів потім багаторазово втрачається на діагностику та повторні запуски.
Ці два шари треба розглядати окремо. Обчислювальний шар виконує логіку завдань, планує роботу на вимогу та оптимізує витрати. Шар середовища відповідає за ідентичність та ізоляцію, використовуючи окреме незалежне середовище для кожного завдання й оптимізуючи стабільність. Стискати шар середовища через дефіцит обчислювальних ресурсів означає змішувати два різні типи витрат. Масове створення та вивільнення середовищ має централізовано керуватися інструментами цього шару. Коли PurpleMark ізолює сесії та кеші за середовищами, завдання й виконавці верхнього шару можна планувати значно вільніше.
І наостанок: не скорочуйте витрати через порушення правил. Не використовуйте неофіційні сервіси лише заради економії квоти й не намагайтеся продавити більший потік підвищенням частоти запитів. Після спрацювання обмежень повторні спроби зазвичай витрачають більше квоти, ніж робота в контрольованому темпі.
