Service Discovery при помощи координационных нод YDB
Когда приложению нужен service discovery, первое привычное решение — взять отдельный инструмент: Consul, ZooKeeper или аналогичный сервис. Но иногда координационный механизм уже есть в стеке, и тогда отдельный сервис оказывается лишней инфраструктурной сущностью.
Ниже разберём такой сценарий на примере YDB Coordination Node. Задача не в том, чтобы заменить любой service discovery на YDB, а в том, чтобы показать конкретный класс задач, где координационная нода может работать как простой реестр живых инстансов и их конфигурации.
Представим мультитенантное приложение, в котором пользователи могут регистрировать адреса вебхуков. Основная бизнес-логика живёт в группе машин App: она принимает события, определяет нужного пользователя, выбирает зарегистрированный webhook endpoint и отправляет туда HTTP-запрос.
Для большинства пользователей исходящий трафик может идти через общий пул инфраструктуры. Но премиальные пользователи попросили отдельную возможность: чтобы все запросы к их webhook-адресам уходили только с заранее известных выделенных IP-адресов. Тогда они смогут добавить эти IP в свои firewall allowlists и не открывать доступ для всего интернета.
Наивное решение — поднимать отдельную виртуальную машину под каждый выделенный IP или под каждого премиального клиента. На небольших объёмах это работает, но быстро становится экономически невыгодным: ресурсы простаивают, количество машин растёт вместе с числом клиентов, а операционная сложность начинает жить своей жизнью.
Поэтому вводится отдельный тип машин, который будем называть Border. Это пограничные ВМ, через которые уходит внешний трафик к webhook-получателям. На одной такой машине может быть настроено несколько выделенных IP-адресов, а разные пользователи могут быть привязаны к разным адресам или наборам адресов. Таким образом, Border выступает как общий, но управляемый слой egress-инфраструктуры: он позволяет переиспользовать вычислительные ресурсы, сохраняя для клиентов предсказуемые исходящие IP.
Остаётся ключевая проблема: App не может просто один раз получить список Border-машин и считать его постоянным. Количество Border может динамически меняться: группа может масштабироваться, отдельные машины могут перезапускаться во время релиза, временно выпадать из работы или заменяться новыми инстансами.
Итого слой App должен в каждый момент времени знать не просто список Border, а актуальную карту: какой выделенный IP жив, на каком Border он доступен и можно ли через него сейчас отправлять трафик. В дальнейшем мы будем рассматривать именно этот сценарий: как организовать взаимодействие между App и Border так, чтобы маршрутизация webhook-запросов оставалась корректной, устойчивой к изменениям инфраструктуры и при этом не требовала неэффективной схемы «одна ВМ — один IP».