Облачные ВМ и облачные браузеры оплачиваются по времени, поэтому пакетные задачи легко упираются в квоты. Оцените расход, определите практический предел параллельности и соблюдайте правильный порядок действий при превышении.
Для ресурсов с повременной оплатой логика расчета проста: время работы умножается на число экземпляров. Квота — это жесткий верхний предел. После его достижения задачи не просто замедляются, а сразу начинают завершаться с ошибкой: новые экземпляры не создаются, работающие экземпляры могут быть отозваны, а API начинают возвращать ошибки ограничения частоты. Понимать, насколько близко вы подошли к пределу, полезнее, чем просто увеличивать бюджет уже после проблемы.
Сначала отделите необходимый расход от необязательного
Одна и та же квота может давать очень разную отдачу в зависимости от того, на какие задачи она тратится. Сначала проведите инвентаризацию и разделите задачи по тому, действительно ли им нужно выполняться в реальном времени.
Постоянно работающие задачи особенно легко съедают квоту. Они могут быть включены весь день, хотя реальная работа занимает всего несколько минут. Замена постоянного мониторинга на запуск по расписанию часто позволяет заметно сократить расход практически без влияния на бизнес. Пиковые задачи, сосредоточенные в определенные часы, можно переносить, а разовые запускать только по необходимости.
Затем задайте себе вопрос: пострадает ли бизнес, если эта задача будет выполнена на шесть часов позже? Если да, оставьте ее на критическом пути и выполняйте в реальном времени. Если нет, переведите ее в низкоприоритетную пакетную обработку и запланируйте на время, когда квота менее загружена. Если проверять цены конкурентов не каждый час, а дважды в день, в большинстве сценариев информационная ценность существенно не снизится.
Как оценивать расход и выбирать параллельность
При оплате по времени работы экземпляров общий расход пакета примерно равен средней длительности одной задачи, умноженной на число задач. Он не зависит от величины параллельности; параллельность лишь определяет, как быстро пакет завершится. Зато от нее зависит мгновенная нагрузка: чем больше экземпляров запускается одновременно, тем выше вероятность упереться в предел параллельности пула ресурсов или в ограничения платформы.
Поэтому начинайте с минимальной параллельности. Сначала запустите одну задачу и измерьте ее среднюю длительность и долю успешных выполнений. Затем постепенно увеличивайте число одновременных задач до нескольких, потом примерно до десятка, фиксируя долю ошибок и количество повторных попыток. Если после определенного уровня доля ошибок заметно растет, это и есть практический предел. Дальнейшее увеличение параллельности лишь вернет сэкономленное время в виде дополнительных повторов.
Не забывайте о скрытом времени: ожидании входа, загрузке страниц, шагах проверки и повторных попытках после сбоев. Часто они занимают больше времени, чем основной сценарий. Полезнее оставить запас на одну задачу, чем пытаться считать все с точностью до минуты.
Как выглядит исчерпание квоты
Исчерпание квоты бывает трудно распознать, потому что оно часто похоже на другие проблемы.
Один из признаков — задача застревает на запуске, поскольку запрос на создание среды или экземпляра отклоняется, а в журнале остается лишь расплывчатая ошибка. Другой вариант — экземпляр отзывается в середине работы и весь предыдущий прогресс теряется. Также могут появляться ошибки ограничения частоты, смесь успешных и неуспешных запусков или очередь, которая растет, но не обрабатывается.
Легче всего ошибиться с ложным зависанием: экземпляр все еще существует, задача выглядит выполняющейся, но на самом деле постоянно ждет, а квота продолжает расходоваться по времени. В такой ситуации сначала посмотрите панель использования квоты, затем отдельно запустите небольшую задачу. Если и она не стартует, проблема, скорее всего, в квоте или разрешениях. Если небольшая задача работает нормально, вероятнее всего дело в параллельности или повторном использовании среды.
Порядок действий для восстановления
Начинайте с бесплатных мер.
Сначала остановите малоценные постоянные расходы и переведите задачи мониторинга на запуск по расписанию. Затем перенесите задачи, допускающие задержку, на периоды с большим запасом квоты, чтобы сгладить кривую потребления. Третьим шагом уменьшите предел параллельности и добавьте очередь, чтобы задачи запускались в соответствии с доступной емкостью, а не все одновременно. Четвертым шагом сокращайте бесполезный расход: кэшируйте общие ресурсы вместо повторной загрузки, по возможности получайте больше данных за один запрос, быстро завершайте заведомо неуспешные запросы и не повторяйте их бесконечно.
Только после этих четырех шагов решайте, нужен ли больший бюджет или более высокий тариф. Часто оказывается, что реально необходимая квота ниже, чем казалось изначально. Если сначала увеличить бюджет, вместе с ним вы оплатите и неэффективные привычки.
Не сжимайте слой среды вместе с вычислительным слоем
Распространенная ошибка при экономии квоты — заставлять несколько задач использовать одну браузерную среду, исходя из того, что достаточно запустить ее один раз.
Цена проявляется сразу: сеансы перезаписывают друг друга, состояния входа сбиваются, кэши смешиваются, а сбой одной задачи может затронуть остальные. Небольшая экономия времени экземпляров затем многократно теряется на диагностике и повторных запусках.
Эти два слоя нужно рассматривать отдельно. Вычислительный слой выполняет логику задач, планирует работу по требованию и оптимизирует затраты. Слой среды отвечает за идентичность и изоляцию, используя отдельную среду для каждой задачи и оптимизируя стабильность. Сжимать слой среды из-за нехватки вычислительных ресурсов — значит смешивать два разных вида затрат. Массовое создание и освобождение сред должно централизованно управляться инструментами слоя среды. Когда PurpleMark изолирует сеансы и кэши по средам, задачи и исполнители верхнего слоя можно планировать гораздо свободнее.
И последнее: не сокращайте расходы за счет нарушения правил. Не используйте неофициальные сервисы только ради экономии квоты и не пытайтесь продавить больший поток увеличением частоты запросов. После срабатывания ограничений повторные попытки обычно расходуют больше квоты, чем работа в контролируемом темпе.
