7 записей с тегом "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».

Почти любой бэкенд рано или поздно сталкивается с необходимостью отложенной обработки задач: отправить email после регистрации, пересчитать агрегаты, выполнить задачу по расписанию. Часто для этого подключают отдельную систему — RabbitMQ, Kafka, Redis-очереди. Но если ваши данные уже живут в YDB, нужные примитивы уже рядом: таблицы, changefeed, топики и координационные ноды.

В этой статье разберём четыре подхода к асинхронной обработке задач — от простой таблицы до архитектуры, пригодной для production-сценариев. Каждый следующий подход решает проблемы предыдущего, но добавляет сложности. Вместо абстрактных описаний — рабочий код на Go с использованием ydb-go-sdk.

Я уже полтора года пишу в этот standalone блог. До этого я писал на Medium. И вот там была классная фича, сделать которую тут у меня все не доходили руки. Это форма подписки на email. Я хотел сделать так, чтобы читатели могли подписаться на новые статьи и получать на почту уведомления. Но я не хотел использовать Mailchimp или подобные сервисы. Я хотел сделать все, используя Yandex Cloud. И вот наконец-то я это сделал. В этой статье я расскажу, как я это сделал.

Кстати, справа вы видите именно эту форму подписки. Если вы хотите подписаться на новые статьи, введите свой email и нажмите кнопку "Подписаться". А теперь давайте разберемся, как это работает.

В прошлом посте говорил, что в задачах для которых создавалась YDB использование автоинкремента нецелесообразно. Так как он может стать бутылочным горлышком при вставке большого количества данных.

Однако, с развитием YDB, разработчикам стало понятно, что serial типы данных востребованы пользователями. И в версии 24.3 они были добавлены.

Паттерн Outbox решает проблему двойной записи, которая возникает в распределенных системах, когда одна операция включает в себя как операцию записи в базу данных, так и отправку сообщения или уведомления.

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

Ошибка в одной из этих операций может привести к не консистентным данным.

Его нет. И вообще это плохая идея и вот почему.

В первой части мы закончили на том, что запустили Apollo в облаке. Но это слишком простое API. Поэтому сейчас добавим интеграцию с Severless YDB.