Развёртывание вблизи биржи: объяснение

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

География движка сопоставления заявок

Крупные криптовалютные биржи запускают свою инфраструктуру сопоставления в небольшом числе облачных регионов — как правило, Токио, Сингапур и одна зона на востоке США. Некоторые биржи публикуют регион; другие — нет, и его можно определить по распределению задержек из разных точек мира. Главное: физически место, где обрабатывается заявка, существует, и скорость света в волокне устанавливает нижний предел скорости связи с ним.

Сколько стоит работа из неправильного региона

Цифры ниже носят иллюстративный характер и не относятся к конкретной бирже:

# Иллюстративно — типичный RTT клиента до движка сопоставления
Движок сопоставления в Сингапуре, клиент в:
  Сингапур (тот же регион)        ~15-30 мс     <- цель
  Токио                           ~70-90 мс
  Мумбаи                         ~110-130 мс
  Франкфурт                      ~150-180 мс
  Восток США (Северная Вирджиния) ~200-240 мс
  Запад США (Орегон)             ~170-200 мс

Оказавшись в неправильном регионе, никакая оптимизация кода не компенсирует скорость света. Самый быстрый клиент в мире, работающий с востока США до движка сопоставления в Сингапуре, всё равно добавит ~200 мс к каждой отправке заявки.

Что реально делает автоматический выбор региона

Маршрутизатор заявок с «автоматическим выбором региона» должен выполнять четыре конкретных действия, а не одно:

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

Первый пункт — самый простой. Четвёртый — тот, который большинство платформ тихо пропускают, потому что он требует, чтобы мощности в нескольких регионах были всегда живы и прогреты.

Почему «мы в AWS Токио» недостаточно

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

Как должны выглядеть доказательства маршрутизации

Честный способ продемонстрировать это — публичная таблица на странице доказательств платформы:

• Одна строка на поддерживаемую биржу.
• Столбцы для медианного, 95-го и 99-го перцентилей RTT из каждого региона.
• Метка, указывающая, какой регион выбран в данный момент.
• Временная метка обновления.

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

Чего ожидать клиенту

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