Айкон Солюшнз и MongoDB: IPF обрабатывает 6 000 платежей в секунду без потери данных

Компании Айкон Солюшнз (Icon Solutions) и MongoDB сегодня опубликовали результаты совместного нагрузочного тестирования (бенчмарка), согласно которым платёжная платформа Icon Payments Framework (IPF), работающая на MongoDB Atlas, обрабатывала 6 000 сквозных платёжных транзакций в секунду (около 430 000 операций с базой данных в секунду) при средней сквозной задержке 0,51 секунды и восстанавливалась после отказов как узлов приложения, так и узлов базы данных без потери данных.

Объёмы платежей между счетами быстро переходят на инфраструктуру мгновенных платежей. Трафик мигрирует из систем с нетто-расчётами в системы мгновенных платежей, а объёмы прямого дебетования, как ожидается, частично перейдут на модель «запрос на оплату» (request-to-pay) с расчётами через системы мгновенных платежей. Для банков это означает более резкие пики трафика, растущую долю платежей, привязанных к SLA платёжных систем в несколько секунд, и полную недопустимость простоев. Учреждения, разрабатывающие решения своими силами, как правило, недооценивают сложность стабильной обработки нескольких тысяч платежей в секунду при сохранении отказоустойчивости, доступности и низкой задержки, а модернизация унаследованных платформ для круглосуточной обработки представляет собой серьёзную задачу.

IPF — это проверенная на международном уровне платформа для разработки платёжных решений, которой доверяют банки первого эшелона (Tier 1), включая Ситибанк (Citi), НатВест (NatWest) и BNP Paribas. Построенная на облачной событийно-ориентированной архитектуре, она изначально создавалась для сред, где масштабируемость, отказоустойчивость и непрерывная доступность являются базовыми требованиями. Бенчмарк был задуман именно для того, чтобы это проверить.

В бенчмарке использовался эталонный сценарий исходящего платежа SEPA Instant (мгновенные переводы в евро), в котором каждый платёж проходит 12 отдельных этапов обработки — включая проверку на дубликаты, валидацию сообщений и правил платёжной схемы, проверку на мошенничество и санкционный скрининг, получение валютного курса, резервирование и списание средств, а также формирование сообщений платёжной схемы, — при этом окружающие системы банка были представлены симуляторами. IPF и MongoDB Atlas прошли «лестничный» тест с целевой нагрузкой от 500 до 6 000 платёжных транзакций в секунду, чтобы пропускную способность, задержку и нагрузку на базу данных можно было наблюдать на каждом этапе, а не только на пике. Затем под реальной транзакционной нагрузкой были отработаны сценарии отказов.

Ключевые результаты

• 6 000 платежей в секунду от начала до конца. IPF обрабатывала 6 000 платёжных транзакций в секунду, каждая из которых проходила все 12 этапов обработки. Эту бизнес-производительность обеспечивали около 430 000 операций с базой данных в секунду на двух кластерах MongoDB Atlas: примерно 236 000 — в журнале событий IPF Event Journal и 196 000 — в операционном хранилище данных IPF Operational Data Store.
• Задержка с большим запасом укладывается в SLA мгновенных платежей. Средняя сквозная задержка при 6 000 транзакций в секунду составила 0,51 секунды — лишь малую долю 10-секундного окна, которое обычно допускают системы мгновенных платежей. Задержка записи данных даже на пике оставалась ниже 30 миллисекунд.
• Почти линейное и предсказуемое масштабирование. В диапазоне от 500 до 6 000 транзакций в секунду приложение и база данных масштабировались синхронно: загрузка процессора и скорость вставки на каждый шард росли пропорционально с каждой ступенью «лестницы», а задержка оставалась практически неизменной вплоть до верхней границы диапазона. Поэтому мощности можно уверенно прогнозировать, а рост планировать как функцию инфраструктуры, а не как прыжок в неизвестность.
• Значительный запас мощности. При пиковой нагрузке загрузка процессора на самом нагруженном шарде MongoDB Atlas составляла около 50%, поды платёжного сервиса IPF работали примерно на 60%, очередь записи WiredTiger оставалась нулевой, а задержка репликации на протяжении всего теста была низкой.
• Восстановление после отказов без потери данных. При реальной нагрузке 3 500 транзакций в секунду IPF восстановилась после аварийного отказа узла приложения менее чем за 90 секунд, а после планового отключения узла — примерно за 60 секунд. В обоих случаях каждая транзакция достигла конечного состояния без потери данных и без ручного вмешательства: механизм перебалансировки шардов IPF перераспределяет незавершённые транзакции на оставшиеся узлы и восстанавливает их состояние из сохранённых событий.
• Переключение базы данных за секунды. Отдельно было проведено переключение первичного узла MongoDB Atlas — с помощью встроенного в Atlas теста отказоустойчивости, который клиенты могут запускать самостоятельно, — и оно завершалось в среднем примерно за 5 секунд, при этом обработка платежей не прерывалась, не было ни потерь платежей, ни перезапусков приложения.
• Улучшения платформы напрямую повышают производительность платежей. Переход с MongoDB Atlas 8.0 на 8.3 сократил задержку записи данных примерно на 50% — примерно с 40 до 20 миллисекунд при 4 000 транзакций в секунду.

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

Результаты были достигнуты за счёт распределённой горизонтально масштабируемой архитектуры, а не избыточно мощного оборудования. IPF работала в виде 12 подов приложения в Kubernetes в трёх зонах доступности одного облачного региона; для параллельной отказоустойчивой обработки использовался Akka, потоки с контролем обратного давления (back-pressure) из IPF Connector Framework не позволяли перегружать последующие системы противодействия мошенничеству, санкционного контроля и учёта по мере роста нагрузки, а Kafka передавала данные обработки в потоковом режиме в операционное хранилище данных. Хранение данных построено по шаблонам event sourcing и CQRS (разделение команд и запросов), а MongoDB Atlas обслуживает как IPF Event Journal (кластер из пяти шардов), так и IPF Operational Data Store (кластер из шести шардов). Каждый шард работал на конфигурации класса M80 с 32 виртуальными процессорами (vCPU) и 128 ГБ оперативной памяти.

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

«Банкам нужна платёжная инфраструктура, способная адаптироваться к экономике мгновенных платежей, — заявил Тойне ван Бёсеком (Toine van Beusekom), директор по стратегии Айкон Солюшнз. — Однако стабильно обрабатывать тысячи платежей в секунду, сохраняя отказоустойчивость, доступность, масштабируемость и сверхнизкую задержку, непросто, особенно для учреждений, которые опираются на унаследованную архитектуру или разрабатывают всё своими силами. Этот бенчмарк демонстрирует, что IPF предлагает альтернативный подход, созданный для того, чтобы отвечать беспрецедентным требованиям мира, работающего без перерывов, и позволяющий банкам уверенно вести развитие платежей вперёд».

«При 6 000 платежей в секунду уровень данных обрабатывает почти полмиллиона операций с базой данных в секунду, восстанавливаясь после отказа узла за пять секунд и без потери данных, — сказал Борис Бялек (Boris Bialek), вице-президент по отраслевым решениям и глобальный технический директор по работе с клиентами (Global Field CTO) MongoDB. — Мгновенные платежи требуют динамичной событийно-ориентированной основы для данных, а не просто статичной учётной системы, и этот бенчмарк показывает, что MongoDB обеспечивает в реальном времени, причём с запасом. Масштабируемость, отказоустойчивость и операционная производительность на единой управляемой платформе. Это и есть двигатель современных платежей».

Отчёт о бенчмарке: Scale Without Sacrifice: How Icon Solutions and MongoDB Power Always-On Payments («Масштаб без компромиссов: как Айкон Солюшнз и MongoDB обеспечивают непрерывные платежи»).

Полный набор данных, включая все метрики «лестницы» для каждой ступени от 500 до 6 000 платёжных транзакций в секунду и дополнительные сведения о том, как были достигнуты результаты, можно получить по запросу в Айкон Солюшнз или MongoDB.