Приложение уже работает. База данных настроена, развёртывание отлажено, мониторинг показывает состояние системы. Затем появляется интеграция, для которой нужна точка приёма или отправки HTTP-запросов в другом регионе.
На первый взгляд задача небольшая: арендовать VPS и передавать через него вебхуки. Но у привычного провайдера нужной локации нет. У другого не подходит цена или условия подключения. А отдельную машину придётся обновлять, защищать и наблюдать за ней, даже если через неё проходит всего несколько событий в час.
Прежде чем добавлять ещё один сервер, полезно определить, какая именно часть интеграции должна работать в этом регионе. Часто это только приём или отправка вебхуков. Приложение и база данных могут оставаться там, где они уже размещены.
Почему небольшой VPS превращается в отдельную задачу
Виртуальная машина даёт вычислительные ресурсы и возможность настроить окружение под себя. Но для доставки вебхуков поверх неё нужен рабочий сервис.
Публичному приёмнику потребуются HTTPS, правила доступа и мониторинг. Если получатель временно недоступен, нужно сохранить событие и доставить его позже. Если отправка закончилась тайм-аутом, понадобится история попыток, чтобы разобраться в результате.
Стоимость такой схемы складывается из аренды и её сопровождения. Даже редко используемый узел остаётся частью production-инфраструктуры: у него есть обновления, секреты, дисковое пространство и возможные сбои.
При добавлении второй или третьей страны эти обязанности повторяются. Поэтому для небольшого потока вебхуков важен вопрос: сколько инфраструктуры команде потребуется обслуживать ради одной региональной функции?
Разделите географию приёма, обработки и отправки
В интеграции есть несколько разных мест:
Точка приёма — публичный адрес, на который внешний сервис отправляет вебхук.
Место хранения — регион, где сохраняются запрос и его история.
Обработчик — приложение, которое выполняет бизнес-операцию.
Точка отправки — регион, из которого уходит исходящий HTTP-запрос к получателю.
Они могут совпадать, но это не обязательное условие работы вебхуков.
Например, публичная точка приёма может находиться в одном регионе, а обработчик — в закрытой корпоративной сети. Для исходящей интеграции приложение может передавать сообщение в выбранный регион доставки, сохраняя собственное размещение.
Такой подход позволяет добавлять региональные возможности постепенно. Команда определяет географию конкретного потока, не начиная с переноса всего приложения и базы данных.
Принимать в выбранном регионе и доставлять в существующее приложение
Для входящих вебхуков в Adal Cloud создаётся Сервер Adal Cloud в одном из доступных регионов. Его постоянный HTTPS URL указывается в настройках внешнего сервиса.
Сервер принимает Request, а при включённом хранении сохраняет его в выбранном регионе. Затем запрос доставляется в настроенный Destination: публичный HTTP-сервис или закрытое окружение через Adal CLI.
Внешний сервис
→ Сервер Adal Cloud в выбранном регионе
→ приложение в вашей инфраструктуре
Если приложение находится во внутренней сети, Adal CLI запускается внутри неё и устанавливает исходящее защищённое соединение. Для обработчика не нужен публичный IP или открытый входящий порт. Эта схема подходит и для локальной разработки, и для production-сервиса в закрытой сети.
Представим команду, у которой обработчик уже работает в собственной инфраструктуре. Для новой интеграции ей нужна отдельная региональная точка приёма. Команда создаёт Сервер Adal Cloud в подходящем доступном регионе и настраивает доставку в существующий обработчик. Региональный VPS, операционную систему и отдельный сервис пересылки обслуживать ей не требуется.
При этом приём и обработка остаются разными этапами. В панели можно увидеть принятый Request и результат его доставки. Временные ошибки получателя обрабатываются по настроенной retry-политике. Для доставки ожидающих Requests после подключения CLI нужна настройка Deliver pending requests on connect, а сами запросы должны оставаться сохранёнными в пределах retention.
Отправлять через выбранный регион с Adal Outbound
Бывает и обратная задача: приложение должно отправлять вебхуки клиентам или партнёрам через определённый регион.
Для этого предназначен Adal Outbound. Приложение выбирает доступный регион и передаёт туда адрес получателя, метод, заголовки и тело запроса. Adal Cloud выполняет доставку, retries и сохраняет историю попыток в этом регионе.
Ваше приложение
→ Adal Outbound в выбранном регионе
→ публичный HTTP-сервис получателя
Ответ 202 Accepted означает, что сообщение принято на доставку. Результат обращения к получателю появляется отдельно в истории попыток. Поэтому приложение может передать ответственность за дальнейшую отправку Adal Cloud, а команда — проверить, чем завершилась доставка.
Outbound работает независимо от входящих Серверов Adal Cloud. Для отправки не нужно сначала создавать публичную точку приёма или переносить приложение в регион доставки.
Это полезно, когда для разных интеграций нужна разная география исходящих запросов. Регион задаётся явно для отправки; Adal Cloud не выбирает его автоматически. Получатель должен иметь публичный HTTP- или HTTPS-адрес.
Несколько регионов без отдельной копии приложения в каждом
Практическая ценность multi-region начинается с возможности выбрать место для конкретной операции.
Один поток может принимать события в одном регионе, другой — в другом. Приложение может отправлять сообщения через выбранные регионы Adal Outbound. При этом размещение обработчиков определяется архитектурой самого продукта.
Для команды это означает, что добавление региональной интеграции не обязательно начинается с закупки и настройки ещё одной машины. Приём, хранение и доставка вебхуков становятся отдельной частью системы, географией которой можно управлять.
Здесь важно различать выбор региона и резервирование. Наличие нескольких регионов само по себе не означает репликацию данных, автоматический перенос принятых запросов или переключение доставки при сбое. В частности, Adal Outbound не выполняет автоматический межрегиональный failover. План работы при недоступности выбранного региона требует отдельного решения.
Что означает «недоступен» в вашей задаче
Если VPS нельзя арендовать у привычного провайдера, а нужный регион есть в Adal Cloud, региональную часть webhook-интеграции можно передать сервису.
Если требуемого региона пока нет и в Adal Cloud, существующий список не решает эту задачу. Напишите нам, какая локация нужна и для какого потока: приёма, отправки или обоих направлений. Мы отдельно оценим возможность расширения географии. Доступность нового региона и сроки его запуска требуют подтверждения.
Если под недоступностью имеется в виду сетевой сбой, нужно проверить конкретный маршрут. Для входящего потока отправитель должен иметь доступ к Серверу Adal Cloud, а для исходящего приложение должно суметь передать сообщение в выбранный регион. Региональная доставка не устраняет отсутствие связи на этих участках.
Есть и границы самого сценария. Adal Cloud предоставляет слой работы с вебхуками, а не виртуальную машину для произвольного кода или базы данных. Если задача требует разместить в регионе весь сервис, одного регионального webhook URL недостаточно.
Выбирайте регион по всему пути запроса
Перед настройкой определите, где запрос должен приниматься, где храниться и куда доставляться дальше.
Если Request сохранён в одном регионе, а затем передан обработчику в другой стране, данные проходят через оба окружения. Выбор региона хранения в Adal Cloud не означает, что весь дальнейший путь запроса остаётся внутри него.
То же относится к задержке. Близость точки приёма к отправителю может сократить один участок маршрута, но полное время обработки включает доставку до приложения и работу самого обработчика. Оценивать нужно весь путь на реальной интеграции.
Для сохранённых запросов учитывайте retention, а в обработчике сохраняйте проверку подписи отправителя и идемпотентность. Регион меняет географию доставки, но не отменяет возможность повторного события.
Начните с нужного потока
Когда VPS в нужном регионе дорогой или его сложно получить, сначала определите роль этого узла. Для регионального приёма вебхуков создайте Сервер Adal Cloud и настройте Destination в существующее приложение. Для исходящей доставки выберите регион Adal Outbound.
Так география интеграций может расширяться по мере появления задач, а команда продолжит развивать продукт без отдельного VPS для каждого webhook-потока.
Настроить входящую доставку поможет быстрый старт. Формат исходящих сообщений и выбор региона описаны в документации Adal Outbound.