Самостоятельно разработанный API-шлюз позволил нам сэкономить 38% затрат на вызовы сторонних сервисов, но при этом мы столкнулись с проблемами, связанными с адаптацией системы к работе в разных регионах.

На прошлой неделе наша команда инструментов электронной коммерции в Юго-Восточной Азии только что завершила пересмотр счета за техническую стоимость Q1, и коллега, отвечающий за оплату интерфейса, чуть не подскочил: после замены предыдущего стороннего шлюза на собственный, расходы на вызов API в месяц были непосредственно снижены на 38%, но в тесте на серой шкале перед большим продвижением, успешный платеж пользователей узла в Сингапуре внезапно упал на 6%, проверил полдня, прежде чем обнаружил, что правила межрегионального разрыва шлюза не были адаптированы.

Сначала нужно понять: что такое собственный созданный гейтвей (самостоятельно разработанный интерфейс для взаимодействия с системами).

Проще говоря, вы написали свой собственный набор входа трафика, который перенести все внешние запросы API, обратные вызовы сторонних сторон и межсервисовые вызовы через этот уровень, заменив ранее приобретенные услуги шлюза сторонних сторон.В настоящее время мы используем версию, которая работает на четырех 2-ядерных серверах 4G за рубежом, и один из них может выполнять 1200 запросов в секунду, что полностью покрывает наши потребности в 1,8 миллионах платежей и синхронизированных вызовов товаров в день.

Три реальных преимущества, которые вы можете получить:

• Во-первых, затраты действительно можно снизить. Раньше мы использовали сторонний гейтвей, который взимал плату за количество вызовов, и ежемесячно это стоило 2100 долларов. Теперь, с использованием собственного сервера и системы мониторинга, затраты составляют менее 1300 долларов в месяц, к тому же мы не подвержены ограничениям по ступенчатому увеличению цен.
• Во-вторых, правила теперь полностью находятся в нашем контроле. Раньше ограничения на трафик, установленные сторонними гейтвеями, были едиными для всех сервисов. Во время крупных акций нам приходилось временно увеличивать квоты на обработку платежных запросов, и для этого требовалось подавать заявки, на рассмотрение которых уходило по 3 рабочих дня. Теперь же мы можем изменить конфигурацию прямо на сервере, и изменения вступают в силу уже через 10 секунд.
• В конце концов, не нужно использовать сторонние сервисы для обработки данных. Поскольку мы разрабатываем инструменты для электронной коммерции, нам часто приходится обрабатывать платежные запросы от пользователей. Раньше все запросы проходили через узлы сторонних поставщиков услуг, но теперь все чувствительные данные обрабатываются на наших собственных серверах, что значительно снизило затраты на соблюдение правил.

Не спешите с началом работы – сначала посмотрите на ошибки и проблемы, с которыми мы столкнулись ранее.

Первая проблема касалась адаптации сети к различным регионам. Изначально мы разместили главный узел шлюза в Сингапуре, а когда открыли сайт в Малайзии, мы просто перенаправили трафик туда. В результате запросы местных пользователей сначала проходили через Сингапур, а затем снова возвращались назад, что приводило к увеличению задержек в сети на 200 мс. Многие пользователи не могли дождаться завершения процесса оплаты и просто закрывали страницу. Нам потребовалась неделя, чтобы настроить краевые узлы в Малайзии.

Вторая проблема заключается в упущениях в правилах безопасности. Ранее сторонние гейты по умолчанию обеспечивали защиту от DDoS-атак и блокировку злонамеренных запросов, но мы забыли включить эту защиту при создании собственного решения. Всего через три дня после запуска наш сайт получил 200 000 недействительных запросов от спам-ботов, что чуть не привело к сбою работы интерфейсов, отвечающих за управление запасами.

Третья проблема заключается в том, что затраты на обслуживание и управление системой оказались выше ожидаемых. Раньше, когда возникали проблемы с третьими сторонними гейтвеями, мы просто обращались в службу поддержки. Теперь нам, трем сотрудникам бэк-офиса, приходится по очереди дежурить ночью, следить за мониторингом гейтвеев, и в прошлом месяце только устранение неисправностей гейтвеев заняло у всех 15% рабочего времени.

Какие команды подходят для сотрудничества, а с какими лучше не тратить время?

Если ваша команда делает более миллиона запросов к API в среднем в день, если вам необходимо обрабатывать большие объемы конфиденциальных данных, или если вас достали ограничения по пропускной способности и процедуры обработки заявок от сторонних гейтвейнов, то создание собственного гейтвейна определенно стоит того.

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

Три практических совета для тех, кто впервые занимается сборкой

1. Начнем с одной конкретной сценарии работы системы, не заменяя сразу всё. Сначала мы перенесли трафик платежных интерфейсов на наш собственный шлюз, и две недели всё работало без проблем. Только после этого мы постепенно начали мигрировать другие интерфейсы. Даже если возникнут проблемы, они повлияют только на сценарий платежей, а не на весь сайт.
2. Обязательно проводите тестирование на нагрузку в разных регионах. Особенно это важно для компаний, занимающихся зарубежным бизнесом. Не стоит запускать продукт сразу после тестирования на местном уровне – нужно запустить тесты на узлах в целевых рынках в течение 24 часов, чтобы проверить, нет ли проблем с задержками в передаче данных и уровнем потерь пакетов.
3. Не экономьте на панелях мониторинга. Обязательно следите за тремя ключевыми показателями: количеством запросов, уровнем успешности и задержками. Установите соответствующие пороги тревоги, чтобы не дожидаться жалоб пользователей, когда вы обнаружите, что гейтвейк не работает.

Распространенные мелкие проблемы

Вопрос: Обязательно ли писать код на Go или Rust?
Не нужно, наша первая версия была написана на Node.js, и она способна справляться с пиковыми нагрузками. Просто используйте тот язык, с которым хорошо знакомы ваши сотрудники. Можно будет заменить его позже, если появятся проблемы с производительностью.

Вопрос: Что лучше – использовать собственный гейтвейк или гейтвейк облачного провайдера?
Гибкость гейтвеев облачных провайдеров выше, чем у сторонних решений, но все же она не сравнится с той свободой действий, которую предоставляет создание собственной инфраструктуры. Если вы не хотите быть привязанными к конкретному облачному сервису, самостоятельное развертывание инфраструктуры окажется более экономически выгодным вариантом.