Экономика масштабирования трафика · 18 июля 2026 г.
Egress, изображения, CDN и очереди: дорогая форма растущего трафика
Трафик не превращается в стоимость инфраструктуры по одной фиксированной ставке. Размер ответа, cache hit ratio, варианты изображений, всплески загрузок, пропускная способность workers и операции storage решают, будет запуск стоить несколько долларов или создаст очередь и четырёхзначный счёт за передачу.
Методика
Что именно сравнивается
- Моделируем публичную передачу отдельно от storage, операций запросов, преобразований изображений и compute приложения.
- Используем четыре явные точки трафика и средний некэшированный ответ 3 МБ; для критики результата можно заменить любое из этих допущений.
- Используем опубликованные цены Supabase и Cloudflare, проверенные 18 июля 2026 года; налоги, региональные исключения и enterprise-скидки исключены.
- Считаем графики очередей детерминированными capacity-моделями, а не измерениями конкретного клиентского приложения.
Размер ответа умножает трафик
Миллион просмотров страниц по 3 МБ передаёт примерно 3 ТБ ещё до накладных расходов протокола и повторных загрузок. Сокращение среднего ответа до 1 МБ убирает около 2 ТБ без изменения CPU, базы или числа пользователей. Для контентных продуктов бюджет байтов может быть важнее настройки сервера.
Supabase сейчас документирует $0,09 за ГБ некэшированного egress и $0,03 за ГБ кэшированного сверх отдельных включённых 250 ГБ Pro. Cloudflare R2 не берёт плату за egress в интернет, но storage и операции Class A/B тарифицируются, а подключённый соседний сервис может добавить собственную плату.[1][2]
График изолирует только передачу. Он предполагает 3 МБ на посещение, платную организацию Supabase и неизменное сжатие при росте трафика. Нулевая линия R2 не означает нулевой счёт всей системы хранения.
Конвейер изображений — это capacity-система
Адаптивная разметка не даёт телефону загружать desktop hero. Современные форматы и настройки качества дополнительно сокращают байты. Результат зависит от визуального контента, поддержки браузеров и требуемого качества, поэтому измеряйте production-изображения вместо одного коэффициента сжатия на все случаи.[4][5]
Cloudflare Images по-разному считает уникальные преобразования, сохранённые и доставленные изображения. В бесплатный план сейчас входят 5 000 уникальных преобразований; после лимита новые преобразования возвращают ошибку, а кэшированные варианты продолжают работать. В платной доставке считается каждое изображение, запрошенное браузером.[3]
График использует одну иллюстративную исходную фотографию на 2,4 МБ. Это не benchmark кодеков. Его задача — показать, почему изменение размера до реальных размеров отображения обычно даёт больший первый выигрыш, чем смена формата при сохранении чрезмерно большого полотна.
Загрузка файла не должна держать веб-запрос в заложниках
Сервер, проксирующий загрузку 500 МБ, расходует входящую полосу, соединение приложения, буферы памяти и часто исходящую полосу до объектного хранилища. Ограниченный по времени presigned URL позволяет клиенту загрузить данные прямо в конкретный объект без общих секретов storage.[6]
Декодирование изображений, проверка на вирусы, транскрипция и создание производных — ограниченные задачи workers. Веб-запрос должен проверить намерение и поставить работу в очередь; workers забирают её с контролируемой скоростью. Это не рекомендация только про Sharp: Sharp — один из возможных image workers, а admission и concurrency очереди — свойства системы.
Очередь поглощает всплеск, только если скорость обработки в итоге выше скорости поступления. Если приходит 5 000 задач в минуту, а workers выполняют 1 000, очередь растёт на 4 000 каждую минуту. Очередь без политики вместимости и срока жизни лишь откладывает аварию.
Измеряйте кэш и очередь как поведение продукта
Высокий cache hit ratio может убрать трафик с origin, но устаревшие или персонализированные ответы без кэширования всё равно доходят до compute. Записывайте вместе байты ответа, статус кэша, байты origin, число преобразований, операции объектов и видимую пользователю свежесть.
Для асинхронной работы публикуйте числа принятых, начатых, завершённых, упавших, повторённых, истёкших и отправленных в dead-letter задач. Быстрый HTTP 202 с двенадцатичасовой очередью — не быстрый продукт.
Amazon Builders’ Library рекомендует вводить admission control до того, как очередь станет невозможно обработать. Приоритизация, load shedding и ограниченные повторы тоже входят в план запуска.[7][8]
- Задавайте бюджет байтов для каждой страницы и API-операции вместе с целью запросов в секунду.
- Измеряйте cache hit ratio по классам объектов и считайте байты origin после CDN-кэширования.
- Заранее создавайте распространённые варианты изображений; ограничивайте произвольные размеры преобразований.
- Загружайте большие объекты прямо в storage с короткоживущими и узкими правами.
- Задавайте SLA возраста очереди и времени завершения вместе с HTTP latency.
- Нагрузочно проверяйте burst-поступление, устойчивую обработку, повторы и poison jobs в изолированном контуре.
Реестр источников
Спецификации и цены меняются. Ссылки делают снимок проверяемым.
Источники и коммерческие данные проверены 2026-07-18. Если источник не говорит обратного, цены указаны без налогов.
- Manage Egress usage ↗Supabase · биллинг
- Cloudflare R2 pricing ↗Cloudflare · цены
- Cloudflare Images pricing ↗Cloudflare · цены
- Image performance ↗web.dev · продукт
- Responsive images ↗web.dev · продукт
- Uploading objects with presigned URLs ↗Amazon Web Services · продукт
- Avoiding insurmountable queue backlogs ↗Amazon Web Services · продукт
- Avoiding overload in distributed systems ↗Amazon Web Services · продукт