Сжатие и дедупликация вместо толстого канала: когда это дешевле апгрейда порта

MAATRIX

Бэкап не укладывается в ночное окно, синхронизация между дата-центрами ест всё больше трафика, а счёт за исходящий канал растёт быстрее, чем хотелось бы. Первый инстинкт — заказать более широкий порт или более дорогой тариф. Но у нехватки полосы есть и другой ответ: не расширять трубу, а уменьшить то, что через неё течёт. Разберём, когда сжатие и дедупликация реально дешевле апгрейда канала, а когда это лишняя трата CPU без всякой пользы.

Два ответа на нехватку полосы: труба шире или поток тоньше

У проблемы «не хватает пропускной способности» два симметричных решения, но на практике часто рассматривают только одно — расширить канал.

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

Снижение объёма — сжатие и дедупликация перед передачей. Труба остаётся той же, уменьшается то, что через неё нужно протолкнуть. Взамен тратится процессорное время на сжатие и распаковку на обоих концах — и это время часто уже оплачено: у арендованного сервера почти всегда есть свободные ядра именно в те часы, когда идут бэкапы или синхронизация (обычно ночью, вне пиковой нагрузки приложения). Использование простаивающего CPU не добавляет ни рубля к ежемесячному счёту — в отличие от более широкого порта.

Это не значит, что сжатие всегда побеждает. Дальше — где программная оптимизация реально дешевле апгрейда, а где она бесполезна или вредна.

Где сжатие даёт реальный выигрыш: бэкапы и текстовые данные

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

Хорошо сжимаются:

• Дампы баз данных — pg_dump, mysqldump состоят из повторяющихся SQL-конструкций и однотипных значений в столбцах.
• Логи приложений — однотипные строки, повторяющиеся форматы timestamp, ограниченный набор уровней и сообщений. Один из самых благодарных кандидатов на сжатие вообще.
• Конфиги, JSON, XML, CSV, исходный код — текст с ограниченным алфавитом и предсказуемой структурой.
• Файловые бэкапы — конфиги, код, текстовые данные приложений сжимаются хорошо, если это не медиатека и не уже упакованные архивы.

На практике для бэкапов это выглядит так:

# Дамп базы сразу через компрессор, без промежуточного несжатого файла
pg_dump -Fc mydb | zstd -T0 -o mydb.dump.zst

# Файловый бэкап каталога с текстовыми данными приложения
tar -cf - /var/www/app | zstd -T0 -19 -o app-backup.tar.zst

zstd здесь обычно предпочтительнее классического gzip — на средних уровнях даёт сравнимую или лучшую степень сжатия при заметно меньшей нагрузке на CPU, а флаг -T0 задействует все доступные ядра параллельно, что критично для больших дампов в ограниченном ночном окне. Насколько конкретно сожмутся именно ваши данные — зависит от структуры, и проверяется это только на своих файлах, а не по чужим цифрам из статей.

Не путайте сжатие для передачи с блочным дедупом файловой системы вроде ZFS — это разные механизмы с разной экономикой: дедуп ZFS требует таблицы DDT почти целиком в RAM и почти всегда обходится дороже, чем экономит, тогда как сжатие потока перед передачей — разовая трата CPU без постоянного отпечатка в памяти.

Дедупликация в передаче: инкремент вместо полного бэкапа

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

Самый очевидный пример — схема бэкапа. Полный бэкап каждый раз пересылает всё заново, независимо от того, сколько реально изменилось. Инкрементальный — только изменения с последнего бэкапа: для сервера со стабильным содержимым (система и код меняются редко, растут в основном логи и пользовательские данные) разница в объёме передачи может быть огромной. Подробный разбор на конкретных цифрах — в статье инкрементальный, дифференциальный, полный: разница в цифрах.

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

# rsync передаёт только изменившиеся блоки файла, а не файл целиком
rsync -avz --delete /data/ user@backup-host:/data/

Флаг -z добавляет сжатие поверх дельта-алгоритма — оба механизма складываются: дельта уменьшает число байт для передачи, сжатие дополнительно ужимает то, что осталось.

Специализированные инструменты бэкапа (borgbackup, restic, kopia) идут дальше — делят данные на чанки по контенту (content-defined chunking) и хранят каждый уникальный чанк один раз, даже если он встречается в десятках последовательных снапшотов. Для регулярных бэкапов, которые почти всегда передают похожие данные, это даёт совокупную экономию и по объёму передачи, и по месту хранения без ручной настройки инкрементов.

Синхронизация между дата-центрами: сжатие там, где трафик тарифицируется

Отдельный сценарий с прямолинейной экономикой — регулярная синхронизация между своими серверами в разных странах. Если провайдер тарифицирует исходящий трафик за пределы дата-центра (а для трафика между своими серверами в разных локациях это часто именно так, даже если оба сервера ваши), каждый сжатый гигабайт — не только более быстрая передача, но и прямая экономия на строке «исходящий трафик». Механика такой тарификации и как её проверить для своей пары локаций — в статье трафик между своими серверами в разных странах.

Практический рецепт для регулярной синхронизации обычно комбинирует все приёмы разом:

# Только изменения (дельта rsync), со сжатием потока,
# и с ограничением полосы, чтобы не забивать канал в пиковые часы
rsync -avz --bwlimit=50000 /data/ user@dc2-host:/data/

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

Где сжатие не даёт выигрыша или прямо вредит

Обратная сторона того же принципа: если в данных нет избыточности, сжимать их — чистая трата CPU без отдачи. Это касается всего, что уже прошло через собственный алгоритм сжатия на этапе создания:

• Видео и аудио — кодеки уже устранили основную избыточность.
• Изображения в JPEG, PNG, WebP — данные уже плотные по энтропии.
• Готовые архивы — ZIP, RAR, уже сжатые gzip/zstd-бэкапы. Повторное сжатие поверх почти ничего не даёт.
• Зашифрованные данные — шифрование превращает данные в псевдослучайный набор байт, структуры для сжатия там просто нет.

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

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

Когда сжатие не решает проблему вообще: дело в задержке, а не в объёме

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

Сжатие снижает объём данных, и от этого выигрывают сценарии, ограниченные пропускной способностью: узкий канал, тарификация по объёму, ограниченная полоса на аплинке. Но если проблема не в объёме, а в задержке — например, гигабитный канал есть, а один поток scp или rsync без параллелизации ползёт на скорости, не имеющей с гигабитом ничего общего, — сжатие тут не поможет вообще, оно не устраняет причину. Причина почти всегда — размер TCP-окна, недостаточный для произведения полосы канала на задержку (bandwidth-delay product), особенно заметный на длинных маршрутах между дальними регионами. Механика эффекта и диагностика через iperf3 подробно разобраны в статье TCP-окно и проклятие длинных толстых каналов.

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

Экономический фрейм: считаем CPU против апгрейда канала

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

Стоимость апгрейда канала — прямые деньги каждый месяц, независимо от того, используется новая полоса постоянно или только в пиковые часы бэкапа. Предсказуемая, но негибкая статья расходов: более широкий порт означает платить за него всегда, даже если реальная потребность — несколько часов в сутки. Когда более широкий номинальный канал (например, переход с 1G на 10G) действительно оправдан, а когда становится переплатой за цифру в характеристиках — в статье сетевой канал 1G против 10G.

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

Практический метод:

1. Оцените реальный объём трафика без сжатия — по логам бэкапа или счётчикам сети (vnstat, iftop) за характерный период.
2. Прикиньте эффект сжатия на своих данных, а не по чужим цифрам — сожмите образец вручную и сравните размер до и после.
3. Проверьте, есть ли свободный CPU в окне передачи — через top/mpstat в момент фактического бэкапа. Если ядра простаивают ночью, сжатие практически бесплатно с точки зрения общей загрузки сервера.
4. Сравните два числа: стоимость более широкого тарифа в месяц против нуля дополнительных денег за использование уже оплаченного CPU — с поправкой на то, что при явной нехватке ядер сжатие может замедлить саму передачу, и тогда сравнение уже не в пользу сжатия.

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

Частые вопросы