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

• быстрый запуск

• готовая PCI DSS ready инфраструктура

• дополнительная поддержка, в том числе при прохождении аудита PCI DSS

• брендирование

• гибкая цена

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

Будучи одними из первопроходцев на рынке решений для процессинга электронных платежей, мы построили архитектуру платформу на базе популярных на тот момент (примерно 2012 год) и хорошо зарекомендовавших себя решений - PCI DSS ready инфраструктура с аппаратными межсетевыми экранами Cisco ASA, с сегментацией сети, использовались отдельные хосты для каждой роли - фронтенд с админкой, платежными формами, API и incoming/outgoing прокси; процессинг; хосты выдачи вакантных ключей для шифрования карточных данных; хосты с реляционными БД и т.д. Стек был тоже достаточно традиционный - PHP, Apache, MySQL.

<Схема проксима>

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

Однако, с течением времени накопился ряд существенных проблем:

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

• горизонтальное масштабирование решалось путем заказа новых нод, что приводило к остановке целой зоны доступности на время продолжительных технических работ (зоны доступности были географически распределены и идентичны по составу и настройкам серверов / Cisco)

• большое количество legacy кода и решений, как по дев, так и по админ части

Сопровождать платформу стало достаточно сложно, плюс все это в комплексе влияло на расширение клиентской базы и после нескольких попыток глубокого рефакторинга стало очевидно - в корне изменить ситуацию не удастся. Также манила перспектива работы с новыми технологиями, которые к тому времени уже стали мейнстримом - Docker, Kubernetes, ELK. И заручившись поддержкой руководства, сформировав инициативную группу было принято решение - переделать проект “с нуля”.

Был сформирован MVP куда, помимо ядра процессинга, вошла админка с базовым набором функционала, несколько популярных коннекторов к банкам-эквайерам и скрипты миграции данных со старой платформы. После реализации объема MVP, проведения серии тестов и демо хотелось как можно быстрее “пощупать” это на практике и выбор естественным образом пал на готовые облачные решения Amazon AWS - EC2, RDS, Elastic, Load balancer и т.д. Все, действительно, завелось с минимальными трудозатратами со стороны девопс, смущало лишь одно - цена. С учетом нескольких зон доступности в самом AWS, шифрования дисков и фирменного Elastic все это стоило порядка 2000$/мес на этапе тестов и было понятно, что цена готового продакшен значительно возрастет. Тут, конечно, можно было продолжать оптимизировать и по-максимуму отказаться от использования коробочных сервисов AWS, но при этом нужно понимать, что в таком случае теряется гарантия тех самых заветных 99.99% на весь набор.

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

<Схема рафинита>

Ядром сети, как и раньше, выступают аппаратные межсетевые экраны, единственное отличие - предпочтение было отдано моделям Juniper SRX вместо Cisco ASA использовавшимся ранее. Во-первых, как оказалось, эта линейка больше популярна у хостеров, во-вторых, получили приятный бонус в виде поддержки фильтрации с запоминанием состояния (stateful) и работы на всех уровнях модели OSI. Отказоустойчивость на высоком уровне обеспечивается несколькими зонами доступности, работающими по принципу active-standby. Для этого мы использовали простую автоматическую балансировку на уровне DNS сервиса Cloudflare.

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

Принцип “один сервер - одна функция” перешел на уровень микросервисов. Входящий трафик проходя через сетевой экран Juniper, NAT, NGINX Proxy с Web application firewall (WAF), поступает на Kubernetes LoadBalancer и перенаправляется на один из микросервисов. Микросервисы работают с тремя сервисами вне кластера Kubernetes: кластер RabbitMQ, кластер Elasticsearch, кластер Percona XtraDB (mysql). Для асинхронной мастер-мастер репликации транзакционных БД между зонами доступности используется решение Percona replication manager, использующее шифрованный IPSec туннель через Juniper.

Изменения затронули и разработку/тестирование - помимо перехода на фреймворки Symfony, Vue.js,TypeScript на фронтенде, git и прозрачные процессы CI/CD заметно улучшилось само качество кода за счет применения SOLID подхода при проектировании, использования автоматических проверок вроде phpmd, phpcpd, phpcs, phpstan, eslint и т.д. QA же вовсю используют Behat и Selenium тестировании.

Наши выводы

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