Техно-демо Mireapay

Спустя три месяца с публикации самой популярной статьи автора наконец-то удалось собрать первый прод и настроить его. Если вам интересно развитие проекта mireapay, а так же желаете выяснить почему по статистике 9 разработчиков из 10 считает DevOps потрясающими, то добро пожаловать под кат.

Прежде чем читать эту статью, автор предупреждает. Что все что сделано — в состоянии жуткой альфы. Веб‑приложение реально использовать только если смотреть в консоль разработчика. Возможны баги и прочие неприятности, если что‑то идет не так, работает только если делать все «правильно». Приятного прочтения и использования приложения!

Демо будет закрыто для внешних пользователей в понедельник (2 декабря) утром.

Состав техно-демо

Для получения доступа к демо, нужно перейти на сайт. Для внешних пользователей установлен лимит на количество запросов в секунду. На любые запросы кроме перевода средств — 100 в секунду (сегодня в день публикации будет 1000, завтра утром ограничу до 100), для перевода средств — 1 запрос в секунду на всех. Серверных nvme нет, поэтому защита только такая.

Для авторизации используйте уже заготовленных пользователей, их всего 100к.

login=user000000 password=user000000aeGf23%mF

В рамках демонстрации можно выполнить перевод средств с одного кошелька на другой по идентификатору кошелька, он записывается в виде {nodeId}@{walletId}, например 0000@12. Для того, что бы не пользоваться postman для отправки запросов — разработан веб‑клиент.

Для начала нужно авторизоваться, вводим креды и жмем «вход»:

Экран логина

Регистрация недоступа для внешних пользователей, будет всегда отдавать 404 на любые запросы в /signup. Можете не пытаться.

После успешной авторизации переходим в «Кошельки»:

Кошельки

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

curl -X POST -H "Cookie: jwt=${jwt}" -d '{"name": "Wallet"}' https://mireapay.ru/rest/v1/wallet

При нажатии на кнопку «Подробнее» будет выведена мини-выписка по операциям с кошельком (последние 20 контрактов). Кнопка «Перевести» — форма перевода средств на другой кошелек.

Перевод средств

Что бы увидеть подробную информацию по переводу нужно кликнуть на него, что бы развернуть панель. Иногда статус может остановиться на COMPLETING, потому что проверяется только ACTIVE. Но это редкость. Обычно без нагрузки контракт завершается за 0,2-0,4 секунды.

Если необходимо разлогиниться, то удаляйте куки. Некоторые состояния пока обновляются только через F5. Веб-приложение написано за неделю включая изучение react-native (и потраченное время на изучение и разработку на next.js). Получилось то, что получилось.

Оборудование, программы и настройки НТ

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

Оборудование кластера состоит из следующих компонент.

Виртуальные машины кластера:

• Балансировщик cpu=2 ram=2g;

• Три etcd сервера cpu=4 ram=8g;

• Три контроллера k8s cpu=2 ram=2g;

• Три рабочих ноды k8s cpu=16 ram=64g.

Генерация запросов с отдельной машины в локальной сети. Хранилища БД, топиков и и прочего через ceph, в качестве osd использовались nvme SOLIDIGM P41 Plus PCIe NVMe 4.0 x4 M.2 2280 1Tb (SSDPFKNU010TZX1). На каждом из трех серверов 4 таких nvme. На серверные nvme не хватило бюджета, итак превысил на 20% 😉

Процессоры машин — два AMD EPYC 7543, и один AMD EPYC 75F3. У каждого сервера памяти достаточно для НТ с запасом (включая будущие тесты более сложных систем с несколькими субъектами платежной системы и общим клирингом).

Все метрики записывались prometheus и отображались через grafana.

Postgresql настроен двумя репликами — мастер и репликация. Keycloak, а так же сервисы mireapay используют эту БД. У каждого инстанса БД 4 ядра и 8 ГБ ОЗУ, с лимитом 8 ядер и 16 ГБ ОЗУ.

Redis работает в режиме sentinel с тремя подами.

Pulsar — три реплики на каждый контейнер.

Keycloak — две реплики.

Каждый контейнер mireapay развернут двумя репликами. В 7:55 для contract-processor была добавлена третья.

Графики

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

Количество завершенных контрактов в секунду

Количество создаваемых контрактов при этом сохранялось более менее ровным. В 7:40 автор сделал изменение, что бы увеличить число потоков генератора. Далее вернул как было. Эту метрику можно просуммировать.

Скрытый текст

Пока не дотягивает до 100 млн запросов в сутки, только 83 млн.

Время обработки контракта является не менее важной метрикой, поэтому ее следует так же привести. В 7:40 было увеличение количества создаваемых контрактов. В 7:55 пик был вызван тем, что автор дал нагрузку на другие системы, что бы проверить что будет. Результат не очень. Во всем виноваты локи.

Скрытый текст

Утилизация процессора и памяти

Скрытый текст

База данных и пульсар почти не нагружались в процессе (менее 0,1 ядра), поэтому графики приводить нет смысла.

По результатам тестирования было создано 41532 контракта, из них 131 куда-то ушли не туда (зависли, в топиках их нет, просто испарились на середине процесса или в самом начале). Расследовать эту проблему без kibana не представляется возможным, а ее настройки пока нет в планах, да и ssd будут против.

Заключение

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

С другой стороны, автором были намечены дальнейшие пути развития системы и найдены точки для проведения оптимизации, которые должны дать прирост производительности до желаемых 100 млн контрактов в день (сайчас оптимистично можно только 80 млн при 16 rps), например за счет уменьшения числа блокировок (в ходе теста держались на уровне 150-300 для БД узлов). Очевидно, что этого можно достичь и масштабированием, но те, кто давно читают автора, знают, что это не его путь.

Для работодателей

Работодатель, поспеши завести себе Java-кота в команду! Мышей не ловит, но зато пишет Java-код, а еще проектирует немножко.

https://hh.ru/resume/b33504daff020c31070039ed1f77794a774336

И не забываем, дорогие мои HRы:

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