Трафик между своими серверами в Лондоне и Нью-Йорке: сколько стоит и как ускорить

MAATRIX

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

Где вообще возникает трафик между своими серверами в разных странах

Чаще всего это не разовая передача, а постоянный фоновый поток, который легко недооценить на старте:

• Репликация базы данных — мастер в одном регионе, реплика в другом: ради географической отказоустойчивости, чтения ближе к части аудитории или как холодный резерв на случай катастрофы. Поток здесь — журнал изменений (WAL в PostgreSQL, binlog в MySQL), который льётся практически непрерывно, пока есть запись в базу.
• Синхронизация файлов и объектных хранилищ — бэкапы, медиатека, пользовательские загрузки, которые нужно иметь в двух точках одновременно, а не только «на всякий случай раз в сутки».
• Межсервисное общение в распределённой архитектуре — часть сервисов стоит в одной стране (ближе к поставщику данных или по требованиям локализации), часть — в другой, и они регулярно дёргают друг друга по API, gRPC или через очередь сообщений.
• Репликация очередей и шины событий — mirror-топики Kafka, зеркалирование RabbitMQ между кластерами в разных регионах ради отказоустойчивости самой шины.

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

Цена: где прячется счёт за исходящий трафик между регионами

Ключевая вещь, которую стоит выяснить заранее: как именно ваш провайдер тарифицирует трафик, уходящий за пределы дата-центра. У многих исходящий (outbound/egress) трафик платный, часто по прогрессивной шкале — первые сотни гигабайт дёшевы или бесплатны, дальше ставка за гигабайт растёт. При этом входящий трафик почти везде бесплатен, и трафик внутри одного региона одного провайдера тоже часто идёт по льготной ставке. Из-за этой асимметрии передача между своими серверами в разных странах может незаметно попасть в самую дорогую категорию — как обычный публичный egress, даже если оба сервера ваши.

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

Чек-лист, который стоит пройти до того, как закладывать межрегиональную репликацию или синхронизацию в архитектуру:

1. Уточните тарификацию именно для трафика между вашими серверами в разных странах — это не всегда та же ставка, что за обычный egress в открытый интернет. Спрашивайте прямо, не полагайтесь на общее описание тарифа.
2. Прикиньте реальный объём в месяц. Для репликации БД — примерно объём журнала изменений (WAL/binlog) за период, его несложно измерить на существующей базе, накопив статистику за сутки-другую. Для синхронизации файлов — объём новых и изменённых данных за тот же период.
3. Умножьте на тариф и сравните с ценой самих серверов. Если трафик сопоставим или больше стоимости вычислительных ресурсов — повод пересмотреть архитектуру (сжатие, батчинг, только дельты вместо полной синхронизации) ещё до того, как решение зафиксировано в проде.
4. Спросите у провайдера про приватную связность между его же дата-центрами в разных странах — если она есть, трафик по ней часто тарифицируется иначе. Подробнее — в отдельном разделе ниже.

Не берите за основу расчёта чужие цифры тарифов из статей — ставки различаются между провайдерами и меняются со временем; единственный надёжный источник — актуальный прайс-лист или ответ поддержки конкретно по вашей паре локаций.

Задержка: физический предел и как он проявляется на практике

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

Возьмём пару Лондон — Нью-Йорк из заголовка: по кратчайшим маршрутам подводных кабелей через Атлантику это порядка пяти-шести тысяч километров. По правилу «5 мс на 1000 км» теоретический минимум в одну сторону — примерно 25–30 мс, то есть RTT (время туда-обратно) не может быть ниже примерно 50–60 мс даже в идеальных условиях — это чисто физический расчёт, а не измерение. Реальный RTT, который вы увидите в ping или mtr, почти всегда будет выше: кабель не идёт по идеальной прямой, добавляются промежуточные узлы и обработка на маршрутизаторах. Насколько выше — зависит от конкретного провайдера и маршрута, и предсказать это без измерения нельзя; о том, почему реальный маршрут пакета вообще редко совпадает с кратчайшим географическим путём, разобрано в статье почему маршрут не совпадает с географией.

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

Как задержка бьёт по репликации баз данных на расстоянии

Самый чувствительный к RTT сценарий — синхронная репликация базы данных между удалёнными регионами. При синхронной репликации мастер не подтверждает клиенту COMMIT, пока не получит подтверждение от реплики, а это подтверждение должно физически долететь по сети туда и обратно. RTT между мастером и репликой добавляется к каждой отдельной транзакции, без исключений, а при последовательных транзакциях в одном соединении эта задержка ещё и накапливается. Механика этого компромисса, включая режимы synchronous_commit в PostgreSQL и semi-sync в MySQL, разобрана в статье синхронная репликация: цена надёжности — если в планах именно синхронная схема между дальними дата-центрами, это обязательное чтение до принятия решения.

Для write-heavy нагрузки (много мелких транзакций в секунду) синхронная репликация между континентами часто оказывается неприемлемо медленной: даже лёгкая транзакция вынуждена дожидаться RTT до дальней реплики, который становится доминирующей частью времени её выполнения. На практике выбирают один из двух путей:

• Асинхронная репликация для дальней географически-резервной копии — мастер не ждёт подтверждения, но появляется узкое окно, в котором последние транзакции могут быть потеряны при внезапном падении мастера. Для холодного резерва «на случай катастрофы всего региона» это обычно приемлемый компромисс.
• Синхронная репликация только внутри региона (реплика с малым RTT) плюс асинхронная — уже в дальний регион. Это даёт гарантию нулевой потери при обычном отказе и не завязывает каждый COMMIT на межконтинентальный RTT.

Прежде чем закладывать конкретную схему, измерьте реальный RTT между вашими серверами (ping, mtr) и прикиньте по нему ожидаемое падение пропускной способности записи — универсальной цифры здесь нет, всё зависит от пары локаций и профиля нагрузки.

Сжатие и батчинг: снижаем объём и число походов туда-обратно

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

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

• Для файлов и бэкапов — rsync -z (сжатие на лету) или предварительное сжатие архива алгоритмом вроде zstd, который на средних уровнях даёт хорошее соотношение скорости и размера — заметно быстрее классического gzip при сравнимой степени сжатия.
• Для потока репликации базы — проверьте, поддерживает ли СУБД сжатие журнала на уровне протокола репликации, или сжимайте сам туннель передачи целиком, а не каждый пакет отдельно.
• Не сжимайте то, что уже сжато — видео, изображения в современных форматах, уже заархивированные бэкапы. Повторное сжатие почти не уменьшает объём, но исправно тратит CPU впустую на серверах с ограниченным числом ядер.
• Выбирайте уровень сжатия осознанно: максимальный уровень даёт чуть меньший размер, но кратно больше нагрузку на CPU за небольшой выигрыш в байтах — для потокового трафика между серверами обычно выгоднее средний уровень.

Батчинг снижает не объём, а число отдельных сетевых обменов — не менее важная экономия, потому что каждый round trip между дальними регионами стоит минимум одного RTT, независимо от размера полезной нагрузки внутри него. Тысяча последовательных запросов по одной строке вместо одного батча — это тысяча RTT вместо одного, и итоговое время может оказаться в разы больше времени самой передачи данных. Практические приёмы:

• Вместо множества единичных INSERT — один INSERT с несколькими VALUES или COPY для больших объёмов в PostgreSQL.
• Вместо последовательных вызовов API между сервисами в разных регионах — batch-эндпоинты, принимающие сразу массив объектов.
• Для очередей сообщений — батчинг у продюсера (batch.size и linger.ms у Kafka-продюсера), чтобы сообщения группировались перед отправкой.
• Для синхронизации множества мелких файлов — упаковывайте их в архив перед передачей, а не устанавливайте отдельное соединение на каждый файл.

Оба приёма комбинируются без противоречий: сжатый батч передаётся быстрее и стоит дешевле, чем поток мелких несжатых запросов.

Параллельные потоки и TCP-окно для больших передач

Для разовых или периодических крупных передач — полный дамп базы, перенос большого архива, первичная синхронизация хранилища — вылезает другая физика: одно TCP-соединение на канале с большой пропускной способностью и заметным RTT (та самая пара «Лондон — Нью-Йорк») часто не может выбрать весь номинал канала. Причина — в размере TCP-окна: отправитель должен держать «в полёте» объём данных, равный произведению полосы канала на RTT (bandwidth-delay product), а на длинных маршрутах это произведение может оказаться больше, чем позволяет фактически согласованное окно — из-за устаревших настроек буферов или обрезанного где-то на маршруте window scaling.

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

Практический обход для одноразовых крупных передач — не чинить TCP-окно вручную, а распараллелить сам перенос: aria2c с несколькими соединениями на файл, multipart-загрузка для объектных хранилищ, rsync через xargs/parallel по нескольким файлам одновременно. У каждого параллельного потока своё независимое окно, и в сумме они кратно ближе к номиналу канала, чем один поток с заниженным окном.

Приватные каналы между дата-центрами одного провайдера

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

• Цена. Трафик по собственному backbone провайдера между его же дата-центрами нередко тарифицируется отдельно от обычного исходящего трафика в открытый интернет — дешевле или вообще бесплатно в пределах разумных объёмов, поскольку провайдер не платит за него транзитным операторам.
• Предсказуемость маршрута. Приватный канал идёт по выделенным мощностям провайдера, а не через цепочку публичных пиринговых точек и транзитных сетей с их загрузкой в час пик — задержка на нём обычно стабильнее, хотя физический предел «5 мс на 1000 км» никуда не девается и здесь.

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

Если приватного backbone нет или серверы у разных провайдеров, разумная альтернатива — свой зашифрованный туннель (например, WireGuard) поверх публичного интернета. Он не даёт выгоды в цене или задержке — трафик идёт тем же маршрутом, только упакованным в шифрование, — но решает отдельную задачу: изоляцию чувствительных данных вроде журнала репликации или внутреннего API, которые не должны ходить открытым текстом. Это другая мотивация, чем экономия на трафике: backbone провайдера экономит деньги и стабилизирует маршрут, а свой туннель — про безопасность передачи, а не про её цену или скорость.

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