Мы сэкономили 38% затрат на обработку трафика благодаря облачному нативному гейту, но чуть не испортили процесс доставки свежих продуктов в Европу во время праздника Черная пятница.

Вчера, после завершения собрания по анализу результатов большой акции в День Черной пятницы, у нас, трех человек из команды, отвечающей за доставку свежих продуктов в Европе, до сих пор остается ощущение тревоги: в день предварительных заказов 17% запросов на холодильную доставку были отклонены, количество жалоб от пользователей увеличилось вдвое, и мы чуть не испортили годовую акцию, на подготовку к которой ушло три месяца.

Проблема возникла из-за использования традиционного API-шлюза в течение двух лет: мы установили единый порог ограничения нагрузки для двух ключевых интерфейсов — разрешения адресов и бронирования в холодильной цепи. В день распродажи Black Friday запросы на разрешение адресов внезапно увеличились, что полностью исчерпало возможности шлюза, и последующие запросы на бронирование вообще не смогли быть обработаны. Раньше мы всегда считали, что замена шлюза — это процесс, подходящий только для крупных команд, но только после этой ошибки поняли, что облачный нативный шлюз может оказаться более экономически выгодным вариантом даже для небольших команд.

Что такое облачно-ориентированный гейтвей?

Одним словом: это входной пункт трафика, работающий в кластере K8s, и вам не нужно отдельно арендовать сервер для его развертывания.Вы должны заниматься только правилами маршрутизации и стратегиями ограничения трафика, а все остальные аспекты, такие как гибкость использования ресурсов и обновления системы обслуживания, осуществляются поставщиками облачных услуг.Мы используем текущую версию, которая может обрабатывать до 20 000 запросов в секунду на одном экземпляре системы, поэтому не требуется заранее планировать ее мощности.

После замены мы получили три фактических дохода.

После сбоя в день предварительной продажи мы потратили три дня на переход на облачный нативный шлюз, и в день основных соревнований (Black Friday) не возникло ни одного случая ошибочного ограничения пропускной способности. Кроме того, было еще три преимущества, которые превзошли наши ожидания:

• Стоимость снизилась прямо: ранее мы арендовали два четырехядерных сервера 8G для работы на традиционных шлюзах, плюс один операционный и технический сотрудник тратил 8 часов в месяц на обновление версии, что составляло 1200 евро в месяц. Теперь облачный шлюз платит по количеству вызовов, что составляет всего 740 евро в месяц.Было сэкономлено 38% затрат на обработку трафика.
• Наконец-то я понял, как работает стратегия лимитирования трафика: ранее шлюз позволял устанавливать значения лимитов для всех интерфейсов в целом, но теперь мы можем задавать отдельные правила для различных сценариев использования системы. Например, для интерфейса разрешается не более 5000 запросов в секунду, и даже если этот интерфейс будет перегружен, это не повлияет на работу последующих модулей системы, таких как оплата или бронирование.
• Время, затрачиваемое на процесс handshake по протоколу HTTPS, сократилось вдвое: ранее наши SSL-сертификаты хранились на собственных гейтвейн-серверах, из-за чего задержки при обмене данными между пользователями из разных регионов Европы могли достигать 200 мс. Теперь, когда поставщики облачных услуг кэшируют сертификаты на периферийных узлах, большинство запросов выполняются менее чем за 80 мс.

Не спешите садиться в машину — мы уже столкнулись с этими двумя проблемами раньше.

Не все аспекты использования облачно-ориентированных гейтвейнов являются положительными; в процессе перехода на такие решения мы столкнулись с двумя проблемами, из-за которых пришлось перерабатывать работу:

Первая проблема касается задержки при холодном запуске системы. После первого дня тестирования мы обнаружили, что после 10 минут без запросов время ответа на первый запрос внезапно увеличивается до более чем 300 мс. Позже мы узнали, что эластичные инстансы облачного провайдера запускаются по мере необходимости, и для ключевых интерфейсов необходимо задать минимальное количество запасных инстанцй, чтобы избежать проблем с тайм-аутами при внезапном увеличении объема трафика в неактивное время.

Вторым ограничением являются требования к пользовательским плагинам. Ранее мы написали собственный плагин для проверки подписей запросов, который работал на традиционном гейтвее. Только при переходе на облачный нативный гейтвейн мы обнаружили, что он поддерживает плагины только в формате WebAssembly. Нам потребовалось два дня, чтобы адаптировать код. Если у вас много пользовательской логики, лучше заранее узнать, какие плагины поддерживает производитель.

Стоит ли менять? Просто посмотрите на эти два критерия оценки.

Ситуация, в которой вам следует вмешаться:

• Команда состоит из менее пяти специалистов по обработке запросов (бэкенд-разработке), у нас нет отдельного персонала для обслуживания и обновления серверов-шлюзов. Мы не хотим тратить время на их обслуживание и модернизацию.
• Поток пользователей сильно колеблется: например, во время акций скидок он может быть в 3–10 раз выше, чем в обычное время. Мы не хотим заранее арендовать множество серверов, которые потом будут простаивать и тратить деньги впустую.

Ситуации, в которых не стоит менять что-либо:

• Комплексные требования к соблюдению правил: весь трафик должен проходить через серверы, находящиеся под вашим контролем, и не может использовать общие узлы облачных провайдеров.
• Ваш гейтвейт содержит очень много пользовательской специальной логики, которую не поддерживают существующие облачно-ориентированные гейтвеи. Стоимость изменений в таком гейтвее самостоятельно может оказаться выше, чем стоимость его собственного обслуживания.

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

• Не нужно переносить весь трафик сразу; сначала перенесите 10% трафика на облачный нативный шлюз на протяжении недели. После того, как вы убедитесь, что нет никаких проблем с мониторингом, постепенно переносите оставшийся трафик. Мы сначала перенесли только интерфейс разрешения адресов, и только после того, как убедились, что все работает корректно, перенесли весь трафик.
• Ключевые интерфейсы должны иметь минимальное количество экземпляров для обеспечения надежной работы. Не экономьте на этом; сейчас мы выделили по 2 постоянных экземпляра для интерфейсов бронирования и оплаты в системе холодного цепочки, и с тех пор больше не возникало проблем с просрочками при запуске системы.
• Не нужно покупать самую производительную версию; для большинства малых и средних предприятий функционал базовой версии более чем достаточен. В нашем случае, при объеме трафика до 20 тысяч запросов в секунду (QPS), дополнительные расходы не требуются.

Последний вопрос, который чаще всего задают внутри команды: будет ли система привязана к конкретному облачному провайдеру?

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