Расходы egress в облаке после экспортов аналитики: что команды упускают

Почему запросы на экспорт создают неожиданные счета

Клиент нажимает "Export CSV", и команда ожидает небольшой счёт за запрос и несколько секунд работы. Счёт говорит иначе. Одно скачивание часто пропускает данные через несколько систем, прежде чем файл попадает к клиенту.

Типичный маршрут на бумаге прост: хранилище выполняет задачу экспорта, пишет результат в объектное хранилище, воркер или приложение готовит скачивание, а CDN или файловый шлюз отправляет его клиенту. Если скачивание падает, возобновляется или запрашивается дважды, тот же файл перемещается снова.

Ничто из этого само по себе не выглядит дорогим. Вместе они создают egress‑затраты, которые остаются невидимыми, пока клиенты не попросят большие диапазоны дат или всю историю.

Команды обычно замечают сначала вычисления, потому что они «шумные». Время запросов видно в дашбордах. Кредиты хранилища легко отслеживать. Инженеры оптимизируют SQL, добавляют партиции и забывают о проблеме. Сетевые расходы тише. Они лежат на отдельных строках счёта у провайдеров хранения, хранилища данных и CDN, поэтому никто не видит весь маршрут целиком.

Проблема усугубляется, когда один экспорт пересекает несколько продуктов. Хранилище может взимать плату за создание файла. Объектное хранилище — за выход из региона. CDN — снова при скачивании клиентом, особенно если файл большой или его получают несколько раз. Если приложение копирует файл между регионами перед доставкой, это ещё один счёт до того, как клиент увидит экспорт.

Экспорт 2 ГБ редко ограничивается только 2 ГБ события. После стаджинга, копий, кэша и повторных попыток это может превратиться в 6–8 ГБ платного трафика. Команды пропускают это, потому что оценивают стоимость задачи, создавшей файл, а не маршрут, по которому файл пошёл.

Когда расходы на экспорт растут, не спрашивайте «Сколько стоил запрос?». Спросите: «Куда путешествовали байты и сколько раз?"

Где обычно начинаются списания

Большинство команд думают сначала о времени вычислений. Счёт чаще растёт в другом месте.

Эгресс начинается, когда данные покидают место, где они обычно живут, и один экспорт клиента может задеть несколько сервисов до тех пор, пока не дойдет до браузера. Первый удар часто приходит от объектного хранилища. Если файл лежит в бакете, каждое скачивание может вызвать исходящую передачу. Маленький CSV недорого обрабатывать. Повторяющийся экспорт в 40 ГБ — нет, особенно когда клиенты скачивают его несколько раз или функция возобновления просит недостающие части.

Хранилища данных добавляют ещё один уровень. Выполнение запроса — это одна стоимость. Экспорт результата может добавить ещё, когда хранилище пишет файлы в хранилище объектов, копирует данные между регионами или отправляет результаты в другой аккаунт. Команды часто не замечают этого, когда хранилище в одном регионе, сервер приложения — в другом, а доставка идёт через третий сервис.

CDN может помочь, но экспорты часто плохо работают с кэшем. Большие одноразовые файлы не попадают в кэш, поэтому CDN подтягивает их с origin. Эта операция перемещает данные из хранилища или сервера приложения, а затем CDN снова отправляет их клиенту.

Повторы делают всё хуже. Если скачивание падает на 92%, некоторые клиенты запрашивают недостающую часть. Плохо написанные начинают заново с байта ноль. Частичные загрузки, просроченные подписанные URL, тесты поддержки и автоматические повторы могут превратить один запрошенный экспорт в три или четыре передачи.

Вот почему экспорты аналитики кажутся дешёвыми в разработке и дорогими в продакшне. Запрос заканчивается быстро, но данные продолжают двигаться.

Как картировать полный путь экспорта

Начните с простой схемы. Нарисуйте все системы, которые коснутся экспорта до того, как файл попадёт клиенту. Это обычно означает хранилище или базу данных, раннер задач, временное хранилище, приложение, которое создаёт ссылку для скачивания, и место, где файл в итоге лежит.

Команды часто считают только последнее скачивание, но счёт начинается раньше. Один экспорт может переместиться из хранилища данных в объектное хранилище, затем в другой регион, затем через CDN и только потом к клиенту.

Для каждого перемещения запишите пять вещей:

• откуда данные начинают путь
• куда они идут далее
• пересекает ли это границу региона или провайдера
• какого размера файл после форматирования и сжатия
• кто или что инициирует передачу

Последний пункт важнее, чем кажется. Файл, отправленный в бакет, принадлежащий клиенту, имеет иную модель затрат, чем скачивание в браузере. Ручной экспорт, отправленный поддержкой, отличается от ночной автоматической задачи.

Формат файла быстро меняет арифметику. CSV легко обрабатывать, но он может быть намного больше Parquet или zip‑JSON. Сырой экспорт 2 ГБ, который сжимается до 300 МБ, имеет совсем другой профиль затрат, особенно если клиенты скачивают его несколько раз.

Частота должна быть на той же карте. Отметьте, запускается ли экспорт по запросу, каждую ночь, после каждого отчёта или раз в месяц. Затем укажите, куда он попадает: в браузер клиента, их облачное хранилище, SFTP или внутренний inbox. Эти пути стоят по‑разному.

Ещё одна проверка ловит много пропущенных списаний: что происходит после первого скачивания. Некоторые команды держат файл за CDN семь дней. Если клиент скачает его один раз, стоимость может остаться низкой. Если десять человек у клиента скачивают один и тот же файл 800 МБ, вы платите за повторные передачи, а не за один экспорт.

Хорошая карта намеренно скучная. Если кто‑то может проследить файл от источника до финального скачивания за минуту, вы сможете оценить цену экспорта из хранилища и сборы за передачу до запуска, а не после прихода счёта.

Простой пример с экспортом для клиента

Клиент просит ежемесячный CSV с аналитикой. Команда делает его за день и предполагает, что затраты будут малы. Эта догадка часто неверна.

Начните с малого случая. У клиента 200 000 строк за месяц. Если экспорт включает только дату, кампанию, источник, сессии и доход, CSV может быть около 180 МБ. Запрос хранилища читает несколько гигабайт, чтобы собрать его, затем приложение пишет файл в объектное хранилище, чтобы клиент мог скачать позже.

Списания разбросаны. Хранилище начисляет за вычисления или прочитанные байты. Объектное хранилище — за запись и хранение файла. Скачивание вызывает плату за передачу, когда файл выходит из хранилища или CDN. Если файл пересекает регионы или аккаунты, это добавляет ещё одну строку.

Файл становится дорогим, как только кто‑то просит сырые колонки. Добавьте данные по устройствам, UTM‑поля, URL страниц, рефереров, свойства событий и JSON‑блок для кастомных атрибутов — и тот 180 МБ CSV может вырасти до 1.4 ГБ или больше. CSV удобно открывать, но он не всегда компактный.

Посмотрите затем на поведение загрузок. Поддержка тестирует файл один раз. Клиент скачивает его дважды, потому что первая копия попала в неверную папку. Их аналитик подтягивает его в BI‑инструмент. Автоматическая задача повторяет две попытки после таймаута. Один ежемесячный экспорт превратился в шесть‑семь скачиваний.

При 1.4 ГБ на скачивание семь загрузок превращаются в ~9.8 ГБ для одного клиента. Это не кажется ужасным само по себе. Сюрприз наступает, когда экспорт становится стандартной функцией.

Если 300 клиентов получают одинаковый ежемесячный экспорт, вы уже не имеете дело с единичным случаем. Вы запускаете 300 задач хранилища, пишете 300 больших файлов, храните 300 файлов и, возможно, перемещаете почти 3 ТБ при скачиваниях до учёта повторов и копий между регионами.

Вот почему эти счета появляются поздно. Команды сосредоточены на генерации файла. Стоимость часто растёт на выходе.

Как оценить цену до запуска

Команды обычно недооценивают egress, потому что смотрят только на финальный файл, который скачивает клиент. Счёт начинается раньше. Если один экспорт начинается как 40 ГБ в хранилище, превращается в 12 ГБ CSV, копируется через два сервиса и скачивается дважды, вы платите за куда больше перемещений, чем видит клиент.

Начните с размера сырых данных, а не готового экспорта. Проверьте, сколько данных читает запрос, сколько он возвращает и пишет ли система промежуточный файл перед созданием финального. Отфильтрованный экспорт может быть намного меньше исходной таблицы, но некоторые системы всё равно перемещают большой объём во время работы.

Формат имеет значение. CSV часто растёт, потому что это plain text. JSON может быть ещё больше. Parquet или сжатые архивы сильно уменьшают размер. Если клиенты могут выбирать формат, оцените каждый отдельно.

Затем считайте каждый хоп. Обычный путь: хранилище → временное хранилище → воркер экспорта → обратно в хранилище или CDN → финальное скачивание клиентом. Это четыре события передачи, а не одно. Если воркер работает в другом регионе или CDN подтягивает с origin‑бакета в другом регионе, цифры быстро растут.

Повторы тоже должны попасть в оценку. Задачи падают, браузеры таймаутят, поддержка перезапускает экспорты, клиенты скачивают файл повторно, потому что потеряли его. Для аналитических экспортов реалистичнее удваивать ожидаемое число скачиваний, чем надеяться на один чистый перенос.

Простая формула работает хорошо:

оценочная ежемесячная стоимость = размер одного экспорта x количество переходов x ожидаемое число экспортов x коэффициент повторов x ставка за ГБ

Добавьте запас перед запуском. 25% — разумный минимум. 50% — безопаснее, если функция новая, файлы большие или клиенты будут просить кастомные выгрузки. Этот буфер дешевле, чем учиться на первом счёте.

Ошибки, которые увеличивают счёт

Большинство команд оценивают стоимость SQL‑запроса, может быть временного хранилища, и считают, что на этом всё. Это пропускает часть, которая чаще всего бьёт сильнее: само скачивание. Перемещение большого экспорта из хранилища данных, бакета или CDN может стоить больше, чем его генерация.

Ошибки с регионами накапливаются быстро. Данные могут храниться в одном регионе, экспорт генерироваться в другом, а клиент скачивать из третьего — клиент видит один экспорт, облачный счёт считает несколько перемещений.

Сырые экспорты — ещё одна распространённая проблема. Если клиенту нужны ежемесячные итоги, отправлять каждую строку события — пустая трата. 200 МБ сводки может заменить 40 ГБ дампа. Команды часто по умолчанию отдают всё, потому что это проще один раз собрать, но платят за это каждый раз при скачивании.

Повторные загрузки наносят тихий вред. Клиенты повторяют попытки после таймаута, делятся файлом внутри компании или подтягивают его в несколько инструментов. Поддержка может усугубить ситуацию, перезапуская старые экспорты вместо повторного использования уже готового файла. Один запрос может превратиться в шесть передач без чьего‑то внимания.

Шаблон знаком: команда смотрит стоимость запроса и игнорирует сетевые сборы. Задача экспорта запускается не в том регионе. Система записывает полный сырой файл вместо меньшего отчёта. Затем клиенты и поддержка скачивают или регенерируют тот же экспорт снова.

Небольшой пример всё проясняет. Клиент просит годовой экспорт активности. Команда генерирует 25 ГБ CSV, хранит его день и получает тикет поддержки, когда первое скачивание падает в конце. Поддержка перезапускает задачу дважды. Клиент пробует снова из двух офисов. Компания заплатила не за один экспорт. Она заплатила за запрос, несколько передач, дополнительное хранение и время поддержки.

Лучшее исправление простое: решите, какой файл действительно нужен клиенту, прежде чем строить фичу. Это решение одновременно снизит и передачу, и нагрузку поддержки.

Как уменьшить передачу, не усложняя экспорты

Большинство команд тратят полосу, отправляя слишком много данных слишком часто. Самые лёгкие экономии обычно приходят от более строгих правил экспорта, а не от блокировки клиентов.

Начните с самого файла. Если вы отправляете CSV или JSON, сжимайте перед доставкой. Gzip часто сокращает большие экспорты настолько, что это заметно снижает egress‑затраты, особенно на медленных соединениях, где повторы часты.

Следующий фикс ещё проще: экспортируйте только то, что просил клиент. Если нужен только пять колонок за последние 30 дней, не пакуйте 18 месяцев истории со всеми полями. Широкие таблицы и дампы всей истории быстро растут.

Меньшие временные окна помогают больше, чем многие команды ожидают. Вместо одного огромного экспорта предложите селектор дат с разумными лимитами или дайте возможность подтягивать инкрементальные файлы по дням, неделям или месяцам. Если нужен полный архив, его всегда можно собрать из меньших частей, и повторы остаются дешёвыми при падении загрузки.

Держите маршрут экспорта локальным, когда можете. Если хранилище в одном регионе, а воркер экспорта в другом, вы платите за перемещение ещё до клика клиента. Размещайте воркер и бакет рядом с исходными данными, а доставляйте финальный файл оттуда.

Кэширование готовых экспортов — ещё один простой выигрыш. Если клиент скачивает тот же отчёт дважды или поддержка просит копию, отдавайте уже готовый файл вместо регенерации. Короткое время истечения обычно сохраняет актуальность без необходимости нового переноса при каждом запросе.

Практическая схема выглядит так:

• позволяйте клиентам выбирать колонки и диапазон дат
• генерируйте файл рядом с исходными данными
• сжимайте перед сохранением
• повторно используйте готовый файл для повторных скачиваний

Это сохраняет удобство экспорта и предотвращает тихие всплески счёта, которые проявляются через недели.

Быстрые проверки перед включением экспорта

Команды часто ошибаются при оценке. Они выполняют небольшой тест‑запрос, догадываются о размере финального файла и пропускают всё, что происходит после выхода файла из хранилища. Один реальный экспорт, собранный на близких к реальным данных, скажет больше, чем пять догадок в таблице.

Перед релизом подтвердите простые факты. Измерьте экспорт на реалистичной выборке с теми колонками, диапазоном дат и форматом файла, которые будут запрашивать клиенты. CSV, JSON и Parquet могут дать очень разные размеры. Подтвердите, где данные стартуют, где они оказываются и какие сервисы их трогают по пути. Регион, класс хранения, настройки хранилища данных и метод доставки — всё это влияет на счёт.

Установите лимиты заранее. Решите, как часто клиент может экспортировать, сколько дней файл будет доступен и повторные скачивания переиспользуют старый файл или создают новый. Назначьте владельца до запуска. Продукт может хотеть фичу, но кто‑то из данных, инфраструктуры или финансов должен смотреть за расходами и утверждать исключения.

Запишите путь для больших запросов. Если клиент просит целый год вместо 30 дней, команда должна уже знать, разделять ли экспорт, ставить в очередь, брать плату или делать вручную.

Мелкие детали меняют итог больше, чем команды ожидают. Файл, хранящийся в одном регионе и скачиваемый в другом, может стоить дороже, чем запрос, создавший его. Хранение складывается быстро: если вы храните каждый экспорт 30 дней, клиенты и поддержка могут переиспользовать старые файлы, но вы платите за их хранение и отдачу.

Правило простое: сделайте одну прогонную (dry run) для нормального экспорта и одну для самого большого разрешённого экспорта. Если большой пробный запуск уже выглядит болезненно — исправьте политику прежде, чем клиенты на неё опираются.

Что смотреть после релиза

Первая неделя скажет вам больше, чем месячный счёт. Если ждать до конца месяца, плохой паттерн экспорта может работать неделями прежде, чем кто‑то заметит. Проверяйте использование ежедневно сначала, затем переходите на недельный обзор, когда числа стабилизируются.

Три числа обычно раскрывают проблему быстрее всего: размер экспорта, число загрузок и частота повторов. Один большой экспорт может быть нормальным. Десять повторов того же файла — вот где счёт начинает выглядеть грубо.

Отделяйте клиентские экспорты от внутреннего аналитического трафика в логах и метках биллинга. Если продуктовые команды, дата‑команда и клиенты все тянут из одного бакета или пути хранилища, счёт превращается в догадку. Вы хотите ответить на простой вопрос: кто переместил данные и зачем?

Небольшая панель обычно достаточна:

• всего ГБ экспортировано в день
• число созданных задач экспорта
• скачивания на экспорт
• частота повторов и неудачных попыток скачивания
• топ‑клиенты по объёму экспорта

Следите за крупными клиентами особенно внимательно. Команды редко горят из‑за сотен мелких экспортов. Обычно их жгут несколько аккаунтов, которые начинают тянуть всю историю каждый день, или один клиент, который делится файлом между несколькими командами. Клиент, который прыгнул с 20 ГБ в неделю до 400 ГБ в неделю, требует ревью, даже если он «доволен».

Надстройки по умолчанию тоже нуждаются в уборке. Если пользователи постоянно выбирают CSV и полные дампы истории, ваши дефолтные настройки могут толкать их на самый дорогой путь. Измените диапазон по умолчанию, разбивайте очень большие экспорты на плановые батчи или сокращайте время жизни старых файлов, когда ими перестали пользоваться.

Один простой сценарий говорит обо всём. Команда запускает экспорты в понедельник и видит лишь несколько запросов. К пятнице один клиент автоматизировал ночное полное скачивание, другой повторно пытается из‑за падений, а внутренние сотрудники подгружают те же файлы в BI. Счёт хранения всё ещё выглядит нормально. Счёт за передачу — нет.

Поймайте этот паттерн рано, и исправление обычно небольшое. Просмотрите его в течение месяца — и это станет проблемой финансов.

Что делать дальше, если расходы уже взлетели

Начните с одного экспорта, который породил болезненный счёт, а не с полного редизайна. Проследите этот экспорт от первого запроса до финального скачивания. Запишите каждый шаг: задача хранилища, промежуточные файлы, объектное хранилище, CDN, сервер приложения и каждая попытка скачивания.

Это обычно обнаруживает утечку. Команды часто находят экспорт, который выходит из хранилища данных, копируется в бакет в другом регионе, проходит через приложение снова, а затем скачивается три‑четыре раза из‑за повторов или короткого срока жизни файла.

Уберите лишние хопы прежде всего. Если один и тот же файл движется между сервисами больше одного раза, исправьте это первым делом. Если сервер приложения проксирует большие скачивания, прекратите это, если нет веской причины. Если поддержка, QA или автоматические проверки скачивают один и тот же экспорт снова и снова, дайте им более дешёвый путь или маленький тестовый файл.

Несколько изменений часто быстро снижают затраты:

• держите генерацию экспорта и хранение файлов в одном регионе
• генерируйте файл один раз и переиспользуйте его короткое время
• направляйте клиентов прямо к файлу, а не через приложение
• сокращайте время жизни старых файлов, чтобы люди не тянули устаревшие копии
• логируйте повторные загрузки по пользователю, файлу и IP

Если экспорты создают реальную проблему с затратами, сделайте это видимым в продуктовой политике. Вам не нужна сложная биллинговая система в первый день. Простое правило работает: небольшие запланированные экспорты остаются включёнными, а очень большие одноразовые требуют одобрения, более высокого плана или отдельной платы. Даже ограничение по размеру файла может остановить плохой паттерн.

Следите за изменениями в ближайшие дни после каждого исправления. Сравнивайте один экспорт до и после, а не только месячный итог. Это покажет, убрали ли вы реальную расточительность или просто переместили её куда‑то ещё.

Иногда полный путь никто не контролирует. Дата‑команда видит стоимость запроса, бэкенд — API‑трафик, а финансы — только счёт. В таком случае внешний обзор помогает. Oleg Sotnikov на oleg.is работает как Fractional CTO и советник стартапам, и картирование таких запутанных потоков данных — это практическая архитектурная работа, в которой он помогает командам.