Привет, я Денис Лыков, IT-директор ЮMoney. Пока в России продолжается сезон больших распродаж, наш сервис ЮKassa работает под повышенной нагрузкой. Для нас очень важно, чтобы система была стабильной даже в пиковые моменты, ведь от этого напрямую зависит прибыль наших клиентов. Рассказываю, как IT в финтехе готовится к сезону скидок, какие могут возникнуть трудности и как с ними справиться.

Зачем айтишникам в финтехе готовиться к распродажам

ЮKassa помогает десяткам тысяч онлайн-магазинов принимать платежи. У нас более десяти способов оплаты (карты, кошелёк, онлайн-банкинг, SberPay, СБП и другие) и много дополнительных продуктов для бизнеса. Всё это должно стабильно работать, иначе наши клиенты могут потерять своих покупателей и часть прибыли. А в горячий сезон, когда количество транзакций в секунду (TPS) кратно растёт, рисков становится в разы больше.

Мы в IT-департаменте отвечаем за то, чтобы свести их к минимуму и обеспечить стабильную работу системы в любых условиях. Проще говоря, делаем так, чтобы подключенные к ЮKassa магазины могли спокойно принимать платежи разными способами, зная, что не упадут даже в момент самого высокого спроса. И чтобы их клиенты могли успешно рассчитываться за свои покупки, без сбоев и ошибок.

Как мы определяем свою задачу

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

В преддверии распродаж к нам могут обратиться коллеги и партнёры:

• Кто-то из коммерческого департамента, который занимается подключением и сопровождением магазинов, может прийти и напомнить, что скоро распродажи.

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

Такие коммуникации очень важны — они помогают понять, какой нагрузки нам ждать и к чему готовиться вместе с партнёрами.

Когда мы начинаем подготовку

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

Если упрощать, можно выделить три основных шага:

1. Проводим на боевой среде платёжную нагрузку по нашим основным платёжным методам и каналам — через платёжные виджеты, через API, которым пользуются наши партнёры. Через систему идут реальные платежи, которые помечены как тестовые, поэтому они не попадают в финансовый учёт. Но для системы это реальная нагрузка.

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

3. Потом лечим эти узкие места и начинаем всё заново. И так до тех пор, пока количество этих самых узких мест и их размер не будут такими, какие нас устраивают. Такими, чтобы мы понимали, что с запасом выдержим нагрузку, которую ждём.

Как мы работаем с партнёрами, которые помогают нам обрабатывать платежи

У нас в ЮKassa есть собственный эквайринг, но также мы работаем с несколькими банками-партнёрами, по которым равномерно распределяем нагрузку. Это в обычные дни. А во время распродажи мы направляем больше потоков тем, кто стабильно их держит. Идём к нашим эквайерам и спрашиваем, на что они способны, сколько операций могут выполнить в секунду. Эквайеры заинтересованы в стабильной работе, поэтому, как правило, соглашаются на совместные стрельбы.

Если к нам приходит какой-то крупный мерчант и спрашивает, готовы ли мы к увеличенному потоку платежей, мы тоже предлагаем ему провести совместные тесты, можем поднять лимиты на количество тестовых операций в секунду.

Бывает, партнёры думают, что смогут выдержать, скажем, 500 TPS (количество транзакций в секунду). А после тестов выясняется, что на самом деле только 200. Может, в прошлом году они и правда держали 500, но, как я уже говорил, любая система меняется, где-то становится лучше, где-то хуже. Поэтому нужно периодически смотреть, что же она реально может.

Какие бывают узкие места и как их усилить

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

Рассмотрим на примерах:

• Допустим, есть кластер баз данных с какими-то платёжными и неплатёжными компонентами, которые попадают под нагрузку, а перед ними стоит PgBouncer. Что можно сделать? Можно расти вертикально, меняя сервера базы данных и добавляя более мощные процессоры или память. Или расти горизонтально, добавляя ещё один-два шарда для каких-то платёжных компонент, чтобы размазать нагрузку по разным серверам баз данных.

• Или, например, всё дело в PgBouncer, который стоит перед нашим PostgreSQL (это основная платёжная база данных наших микросервисов). В этом случае нужно учиться масштабировать сам PgBouncer (желательно тоже горизонтально, а не вертикально, чтобы не было предела по расширению) и балансировать ноды PgBouncer.

• Если сложности на уровне эксплуатации, всё просто. Мы видим проблемный компонент и можем увеличить его «майку». (У всех компонентов есть «майка» — X, S, M, размер определяется по количеству подов и выделенных для них ресурсов). Когда увеличили ресурсы, тестируем ещё раз. Если добавление количества подов помогло, значит, дело не в производительности самого компонента, в логике его работы, а на уровне «железа». Где-то могут быть и другие простые решения — например, увеличить количество доступных соединений до базы данных внутри компонента.

Ещё мы можем упереться в «разработку», в логику работы компонента. Как правило, это самое сложное, потому что тут и платёжная логика, и взаимодействие между разными сервисами, и десятки вызовов на платежи, часть из которых синхронные, часть — асинхронные. В этот момент нужно начинать аналитику и искать возможности по оптимизации работы отдельных компонент и связей между ними.

Какая роль у мониторинга процессов

Нагрузочные стрельбы были бы неэффективными, если бы мы не понимали, что происходит с нашей системой. Поэтому после каждой крупной ежегодной нагрузки мы идём в мониторинг и что-то подкручиваем. Без этого нельзя, потому что с прошлого раза система сильно поменялась. Если мы упёрлись в новое узкое место, которого не было раньше, и поняли, что там не хватает мониторинга, мы его тут же добавляем.

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

Это всё на уровне разработки. Если с разработкой всё хорошо, значит, мы спотыкаемся где-то в других местах. Если мы программируем на Java или на Node.js, надо смотреть, что у нас с Garbage Collector, с потоками внутри JVM, с очередью обработки, с Event-Loop внутри Node.js. Дальше идём уже на уровень железа: что у нас с вводом-выводом, с процессором, с памятью. Если говорить про базу данных, встаёт вопрос памяти не только процессора, но и диска: сколько чтений и конкурентных чтений, нет ли каких-то взаимных блокировок и неэффективных запросов. Нужно понимать, за какое время выполняется запрос, сколько раз он выполняется, нужен ли он вообще и так далее. 

Как IT работает во время распродажи

На время распродаж у нас есть стандартные операции:

• Мы вводим мораторий на релизы и любые изменения. То есть без острой необходимости мы ничего не меняем на боевой среде — ни с точки зрения инфраструктуры, ни с точки зрения компонент разработки.

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

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

Также иногда во время распродажи применяются какие-то ручные действия. То есть мы останавливаем определённые процессы и проталкиваем их на ручном приводе. Потому что расширять их ради одного-двух дней смысла нет, это очень дорого.

Как правило, когда цикл распродаж подходит к концу, мы собираем результаты и делимся ими не только с департаментом IT, но и с компанией в целом. Готовим несколько слайдов и рассказываем, как всё прошло, с какими сложностями мы столкнулись, как с ними справились и так далее. В общем, делаем выводы и исправляем ошибки, если они были. А это уже, по сути, предварительный этап подготовки к новым распродажам. ????