Наши проекты: модернизация BNPL-платформы

Ещё один проект, о котором мы бы хотели рассказать подробнее в нашем блоге: масштабная модернизация международной BNPL-платформы, которой сегодня пользуются более 150 000 человек в США и Австралии.

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

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

• Сложность повторного использования кода и постоянное разрастание кодовой базы.
• Увеличение количества непреднамеренных ошибок, времени и затрат на их устранение.
• Медленное обновление и увеличение времени вывода продукта на рынок.
• Ограничения в расширяемости платформы, что мешает интеграции с новыми партнёрами, платежными шлюзами и источниками данных для скоринга.

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

Так как особое внимание клиента было уделено решению проблемы масштабирования платформы, Sibedge сформировала комплексный сервис по модернизации, который состоит из двух ключевых этапов:

1. Аудит системы нашими экспертами.
2. Рефакторинг кода и редизайн архитектуры.

Основными метриками BNPL-системы в части производительности можно считать: количество запросов в секунду (Request per Second, RPS), время отклика (Response Time), максимальное время отклика (Peak Response Time) и частоту ошибок (Error Rate). При этом важно учитывать нагрузку на процессор, использование памяти и время отклика накопителей информации. Чтобы протестировать систему под реальной нагрузкой, мы создали точную её копию на трёх внутренних серверах Sibedge.

Нам предстояло протестировать четыре ключевых модуля платформы. Рассмотрим каждый из них по отдельности.

Платёжный шлюз является точкой входа для пользователей платформы. Он должен принимать большое количество запросов и передавать их далее по цепочке без заметных задержек и с низким числом ошибок.

Мы начали тестирование с 10 запросов в секунду, постепенно увеличивая значение, чтобы найти точку отказа. До отметки в 200 запросов время отклика выросло с 200 миллисекунд до 1 секунды. После преодоления отметки в 800 запросов время отклика превысило 30 секунд. Некоторые запросы стали отклоняться по причине таймаута, а процент ошибок превысил 1%.

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

Нам пришлось смоделировать работу внешних систем, так как антифрод-служба опирается на сторонние сервисы и, прежде чем ответить на запрос, дожидается их ответа. Проблемы с работой были обнаружены уже при нагрузке в 100 запросов в секунду. Попытка увеличить количество запросов до 500 привела к полной загрузке процессора и последующему отказу в обслуживании (DoS).

Скоринг — валидация покупателя на предмет его благонадёжности для вынесения вердикта: одобрить рассрочку, одобрить, но с дополнительными условиями, или же отказать. Система извлекает из внутренней базы имеющиеся данные на клиента, поэтому наибольшая нагрузка приходится на HDD и RAM системы. Скоринг также обращается с запросами к сторонним финансовым учреждениям.

Средний объём данных на одного пользователя составляет около 1 КБ. При 10 запросах в секунду пропускная способность системы удовлетворяла нашим требованиям. При повышении количества запросов до 3000 в секунду, время отклика базы данных значительно возросло.

При работе с внешними сервисами мы также столкнулись с проблемами. Например, один из сторонних сервисов имел ограничение на обработку лишь 100 запросов в секунду. При превышении этого порога сервис делал паузу на 3 минуты. Логика платформы не предусматривала этого, поэтому выполнение задачи заканчивалось по таймауту.

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

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

Проблем с целостностью данных обнаружено не было, с их сохранением справилась СУБД. А вот скорость работы базы данных оставляла желать лучшего. Конкуренция с другими сервисами за ресурсы CPU и медленные накопители информации привели к существенному замедлению работы при увеличении нагрузки до 500 RPS.

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

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

Модуль интеграции системы с внешними платёжными шлюзами и брокерами данных был спроектирован ещё на этапе MVP и учитывал особенности лишь одной конкретной внешней системы. Поэтому все последующие интеграции должны были строиться вокруг этих особенностей и требовали написания избыточного кода. Это увеличивало время на подключение к платформе новых систем и усложняло тестирование подсистемы.

Проблемы были выявлены и в инфраструктурной составляющей:

• База данных платформы размещена лишь на одном сервере.
• Отсутствие какого-либо балансировщика нагрузки.
• Сложная система обмена данными с облачными серверами MS Azure и AWS.

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

Мы переписали большую часть кода и разделили монолитную систему на микросервисы, которые запускаются в отдельных контейнерах. Для взаимодействия между ними теперь используется событийная модель вместо прямой связи. В качестве шины для обмена данными в модели pub-sub выступил программный брокер Kafka.

Отслеживание ошибок для последующей отладки занимало слишком много времени. Мы реализовали систему распределенного логирования между микросервисами, а также настроили систему централизованного хранения логов и их визуализации. Использовали стек ELK (Logstash, Elasticsearch, Kibana) и добавили логирование в код приложения. В результате теперь можно просматривать подробный лог работы каждого компонента.

База данных и веб-сервер постоянно конкурировали за системные ресурсы, особенно за CPU. Мы вынесли базу данных на отдельный физический сервер, а медленный HDD заменили на современный высокоскоростной SSD-накопитель. Тем самым мы повысили скорость отклика базы данных и избавились от чрезмерной нагрузки на CPU. Большинство SQL-запросов мы оптимизировали, переписав их представления, а также настроили механизмы кэширования основной базы данных.

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

Перед точкой входа API в процедуру обработки запроса мы добавили ещё один веб-сервер в режиме балансировщика нагрузки. В качестве решения был выбран Nginx. Дополнительный виртуальный сервер Amazon EC2 был использован в качестве второго балансировщика нагрузки. Когда первый не будет справляться с высоким объёмом запросов — второй подключится и разгрузит его.

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

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

Решение выявленных проблем положительно отразилось на бизнесе клиента:

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

В таблице приведены результаты тестов до и после модернизации BNPL-платформы при одинаковых нагрузках. Цифры отражают максимальное количество запросов в секунду, при котором сервис работает без сбоев и ошибок.

Платформа работает стабильно при 1000 запросах в секунду, использование ресурсов не достигает максимума и имеет запас 10–15%, что является нормальным показателем в высоконагруженных системах.

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

Устранение выявленных недостатков в использовании облачных сервисов позволило снизить затраты на обслуживание на 15%.

• Удалось в 5 раз увеличить количество обрабатываемых запросов.
• На 15% снизилось время отклика системы.
• Процесс подключения новых партнёров к платформе был сокращён на 4 дня.
• Экономия на обслуживании инфраструктуры составила примерно $60 000 в год.

Больше подробностей о проекте — в англоязычной версии материала по ссылке: https://proposals.sibedge.com/bnpl_service_modernization_successstudy