200 rps что это
Как оценить ёмкость сервиса и не упасть под нагрузкой
Рано или поздно любому растущему сервису приходится оценивать свои технические возможности. Сколько посетителей мы в силах обслужить? Какова ёмкость (она же capacity) системы? Не добрались ли мы до предела и не упадём ли, если привлечём ещё несколько тысяч пользователей? Сколько дополнительных вычислительных ресурсов заложить в бюджет на следующий год, чтобы соответствовать планам роста?
Ответы можно получить аналитическим путём, адресовав вопросы опытному разработчику/DevOps/SRE/админу. Достоверность оценки зависит от огромного числа факторов: начиная с темпов наполнения системы функциональностью и графа взаимосвязей между компонентами и заканчивая временем, которое эксперт с утра провёл в пробке. Чем сложнее система — тем больше сомнений в адекватности аналитической оценки.
Меня зовут Максим Куприянов, вот уже пять лет я работаю в Яндекс.Маркете. Сегодня я расскажу читателям Хабра, как мы учились оценивать ёмкость наших сервисов и что из этого вышло.
Выходим на позицию
Структура компонентов Маркета довольно сложна, так что мы решили оценить ёмкость только самых крупных и дорогих в масштабировании сервисов. При этом ежедневное количество запросов на них должно явно зависеть от размера дневной аудитории Маркета (daily active users, DAU). Почему именно от DAU? Да потому что аналитики, строя прогнозы на месяцы и годы вперёд, всегда подсчитывают будущий размер аудитории, а мы этим приятным обстоятельством как раз и воспользуемся.
Теперь поговорим о том, без чего точно не построить объективные оценки: о метриках работы сервиса. Если число запросов на сервис зависит от DAU — значит, нам точно понадобится метрика «число запросов в секунду» (requests per second, RPS). Кроме того, чтобы оценить качество работы сервиса, нужно знать процент ошибок и времён ответа (таймингов запросов). Ошибкой будем считать ответ с HTTP-кодом от 500 и выше. Ошибки из диапазона 4xx клиентские и в нормально работающей системе обычно ничего не говорят о проблемах сервиса. Что касается таймингов, то тут у нас принято рассчитывать и хранить 80-й, 95-й, 99-й и 99,9-й перцентили времён ответа, но конкретный набор может немного отличаться от сервиса к сервису.
Итак, у нас есть метрики частоты запросов, процента ошибок и набор перцентилей времени ответа. А ещё мы знаем DAU сервиса на каждый день и на будущие периоды (в виде прогноза). Учитывая, что усреднённые паттерны поведения пользователей не слишком меняются день от дня, допустим следующее: зная RPS в наиболее активный период рабочего дня (пиковое RPS), мы можем спрогнозировать пиковое RPS на будущие периоды, при условии, что у нас есть прогноз DAU. И наоборот: если мы знаем, сколько запросов в секунду выдерживает система, не нарушая договорённости по времени ответа и проценту ошибок, то можем оценить, какой объём аудитории сможем обслужить, т. е. знаем ёмкость системы.
Отлично, мы определились с задачей: зафиксировать в виде договорённостей тайминги ответа и процент ошибок и найти максимальное RPS, которое система выдержит при этих условиях. Как будем решать?
Стреляем по мишени
Вот классический подход к решению задачи: собираем тестовый полигон, берём access-логи системы из production-окружения, делаем из них патроны и обстреливаем систему, повышая частоту запросов, пока полигон не покажет значимую деградацию по таймингам ответа и/или ошибкам. В этот момент останавливаемся и фиксируем частоту запросов (то самое RPS). Победа? Как бы не так. И вот почему:
Имитируем реальность
Общая идея такова: скопируем часть трафика с балансеров на площадку, где соберём полный аналог production-окружения в миниатюре и, регулируя объём копируемого трафика, станем искать точку деградации. Идея красивая, и мы в Маркете так делаем, чтобы протестировать новую функциональность и сравнить поведение новых версий со старыми. Мой коллега Евгений в подробностях рассказывал об этом — см. раздел о теневом кластере. Но тут тоже есть очевидные сложности:
Тестируем прямо в production
И вот мы наконец добрались до вкусного. Для каждого тестируемого компонента мы поднимаем в production отдельный экземпляр, частоту запросов на который регулируем с балансировщика с высокой точностью. В прошлый раз читатели нас спрашивали: «Хватает ли возможностей HAProxy? Не возникала ли необходимость писать что-то своё?». Так вот, это тот самый редкий случай, когда не хватило и пришлось писать.
При этом есть отдельный сервис, который пристально наблюдает за метриками нагружаемого экземпляра и, когда показатели приближаются к критическим величинам, прикрывает вентиль на балансировщике, уменьшая частоту запросов. Если же сервис работает в допустимых границах — вентиль, наоборот, открывается. Конечно, пороги таймингов и ошибок при нагрузке живого сервиса заметно более консервативны (обычно на 5–10%), чем на полигоне, ведь мы не хотим ухудшать взаимодействие с пользователями. Таким образом, нагружаемый экземпляр всегда работает на пределе возможностей. Эти показатели мы фиксируем. А дальше уже арифметика: мы знаем количество ядер сервиса под нагрузкой на каждый момент, знаем DAU за вчерашний день. Из этого считаем утилизацию, резервы по ёмкости и варианты поведения системы при отключении той или другой локации. Всё это ложится в базу, откуда строятся красивые графики. На основании этих данных при снижении ёмкости ниже заложенного порога срабатывают алерты.
Давайте посмотрим на графики
Вот так мы регулируем подачу трафика на тестируемый инстанс. Шаг может быть любым кратным 1 RPS. На графике для иллюстрации смоделирован подъём с трёхминутным интервалом: сначала от 650 до 1K RPS с шагом 50, а потом от 200 до 1K с шагом 100. Напомню, это настоящий пользовательский трафик, на который клиенты получали ответы.
Здесь показано RPS на три инстанса: один под нагрузкой и два контрольных. Для испытуемого искусственно задали верхний предел — 600 RPS. Сервис может и больше, но становится слишком неустойчивым и зависимым от внешних воздействий. Хорошо видно, что в первой половине дня запросы на сервис в среднем более тяжёлые и инстанс не может на приемлемых условиях достичь пиковой ёмкости, но ближе к вечеру всё приходит в норму. Всплески и пропуски на графике — это рестарты инстансов для выкладки релизов и прочих обновлений (все они под балансировкой, никто не пострадал). А ступенчатые корректировки RPS на испытуемом — как раз работа алгоритма, который ищет предел возможностей.
Хорошо видна частота запросов на сервис и нагрузка, которую может выдержать один инстанс.
А тут мы пересчитываем всё в проценты утилизации. На графике видно, что сервис был довольно сильно нагружен и при отключении одной из локаций возникли риски уйти за SLA. Но сейчас уже всё в порядке: в сервис добавили ресурсы, утилизация вернулась в приемлемые границы.
Таким образом, нагрузочное тестирование в production позволяет быстро оценить ёмкость системы и спрогнозировать потребление ресурсов на будущие периоды. При этом система фактически не добавляет заметных расходов и можно спокойно работать со stateful-сервисами, так как мы не порождаем новый трафик, а лишь аккуратно перераспределяем тот, что есть. Ну и напоследок: для работы, как правило, не требуется изменять код само́й подопытной системы, что позволяет тестировать даже legacy-приложения.
Рефлексируем
В Маркете эта методика работает уже не первый год, и мы можем поделиться наблюдениями и рекомендациями:
Тестирование производительности веб-сервиса в рамках Continuous Integration. Опыт Яндекса
Почти всех новых сотрудников Яндекса поражают масштабы нагрузок, которые испытывают наши продукты. Тысячи хостов с сотнями тысяч запросов в секунду. И это только один из сервисов. При этом отвечать на запросы мы должны за доли секунды. Даже незначительное изменение в продукте может оказать существенное влияние на производительность, поэтому важно тестировать и оценивать влияние своего кода на сервис.
В нашем сервисе рекламных технологий тестирование работает в рамках методологии Continuous integration, более подробно об организации которой мы расскажем 25 октября на мероприятии Яндекс изнутри, а сегодня мы поделимся с читателями Хабра опытом автоматизации оценки важных продуктовых метрик, связанных с производительностью сервиса. Вы узнаете, как доверить анализ машине, а не следить за ними на графиках. Поехали!
Речь не пойдет о том, как протестировать сайт. Для этого есть немало онлайн-инструментов. Сегодня мы поговорим о высоконагруженном внутреннем бэкенд-сервисе, который является частью большой системы и готовит информацию для внешнего сервиса. В нашем случае – для страниц поисковой выдачи и сайтов партнеров. Если наш компонент не успевает отвечать, то информацию от него просто не отдадут пользователю. А значит, компания потеряет деньги. Поэтому очень важно отвечать вовремя.
Какие важные показатели сервера можно выделить?
Итак, давайте по порядку.
Request per second
Наш разработчик, который долгое время занимался вопросами нагрузочного тестирования, любит говорить про критический ресурс системы. Давайте разберемся, что это такое.
У каждой системы есть свои конфигурационные характеристики, которые определяют работу. Например, длина очереди, время ожидания ответа, threads-worker pool и т.д. И вот может так случиться, что ёмкость вашего сервиса упирается в какой-то из этих ресурсов. Можно провести эксперимент. Увеличивать по очереди каждый ресурс. Ресурс, увеличение которого повысит ёмкость вашего сервиса, и будет для вас критическим. В хорошо сконфигурированной системе, чтобы поднять ёмкость, придется увеличить не один ресурс, а несколько. Но такой всё равно можно «нащупать». Будет отлично, если вы сможете настроить свою систему так, чтобы все ресурсы работали в полную силу, а сервис укладывался в заданные ему временные рамки.
Чтобы оценить, сколько запросов в секунду выдержит ваш сервер, нужно направить в него поток запросов. Так как у нас этот процесс встроен в CI-систему, мы используем очень простую «пушку», с ограниченной функциональностью. Но из открытого ПО для этой задачи отлично подойдет Яндекс.Танк. У него есть подробная документация. В подарок к Танку идёт сервис для просмотра результатов.
Небольшой офтоп. У Яндекс.Танка достаточно богатая функциональность, не ограниченная автоматизацией обстрела запросами. Он также поможет собрать метрики вашего сервиса, построить графики и прикрутить модуль с нужной вам логикой. В общем, очень рекомендуем познакомиться с ним.
Ёмкость можно измерять двумя способами.
Открытая модель нагрузки (стресс-тестирование)
Сделать «пользователей», то есть несколько потоков, которые будут отправлять запрос в вашу систему. Нагрузку мы будем давать не постоянную, а наращивать или даже подавать её волнами. Тогда это приблизит нас к реальной жизни. Наращиваем RPS и ловим точку, в которой обстреливаемый сервис “пробьёт” SLA. Таким образом можно найти пределы работы системы.
Для расчета количества пользователей можно воспользоваться формулой Литтла (о ней можно почитать тут). Опуская теорию, формула выглядит так:
RPS = 1000 / T * workers, где
• T – среднее время обработки запроса (в миллисекундах);
• workers – количество потоков;
• 1000 / T запросов в секунду – такое значение выдаст однопоточный генератор.
Закрытая модель нагрузки (нагрузочное тестирование)
Берём фиксированное количество “пользователей”. Нужно настроить так, чтобы входная очередь, соответствующая конфигурации вашего сервиса, была всегда забита. При этом делать число потоков больше, чем лимит очереди, бессмысленно, так как мы будем упираться в это число, а остальные запросы будут отбрасываться сервером с 5xx ошибкой. Cмотрим, сколько запросов в секунду конструкция сможет выдать. Такая схема в общем случае не похожа на реальный поток запросов, но она поможет показать поведение системы при максимальной нагрузке и оценить её пропускную способность на текущий момент.
Для подавляющего большинства систем (где критический ресурс не имеет отношения к обработке соединений) результат будет одинаковый. При этом у закрытой модели шум меньше, потому что система всё время теста находится в интересующей нас области нагрузки.
Мы при тестировании нашего сервиса используем закрытую модель. После отстрела пушка выдает нам, сколько запросов в секунду наш сервис смог выдать. Яндекс.Танк этот показатель тоже легко подскажет.
Time per request
Если вернуться к предыдущему пункту, то становится очевидно, что при такой схеме оценивать время ответа на запрос не имеет никакого смысла. Чем сильнее мы нагрузим систему, тем сильнее она будет деградировать и тем дольше будет отвечать. Поэтому для тестирования времени ответа подход должен быть другим.
Для получения среднего времени ответа воспользуемся тем же Яндекс.Танком. Только теперь зададим RPS, соответствующий среднему показателю вашей системы в продакшене. После обстрела получим времена ответов каждого запроса. По собранным данным можно посчитать процентили времен ответов.
Дальше нужно понять, какой процентиль мы считаем важным. Например, мы отталкиваемся от продакшена. Мы можем оставить 1% запросов на ошибки, неответы, дебажные запросы, которые отрабатывают долго, проблемы с сетью и т.п. Поэтому мы считаем значимым время ответа, в которое вмещается 99% запросов.
Resident set size
Непосредственно наш сервер работает с файлами через mmap. Измеряя показатель RSS, мы хотим знать, сколько памяти программа забрала у операционной системы за время работы.
В Linux пишется файл /proc/PID/smaps – это расширение, основанное на картах, показывающее потребление памяти для каждого из отображений процесса. Если вы ваш процесс использует tmpfs, то в smaps попадёт как анонимная, так и неанонимная память. В неанонимную память входят, например, файлы, подгруженные в память. Вот пример записи в smaps. Указан конкретный файл, а его параметр Anonymous = 0kB.
А это пример анонимного выделения памяти. Когда процесс (тот же mmap) делает запрос в операционную систему на выделение определенного размера памяти, ему выделяется адрес. Пока процесс занимает только виртуальную память. В этот момент мы ещё не знаем какой физический кусок памяти выделится. Мы видим безымянную запись. Это пример выделения анонимной памяти. У системы запросили размер 24572 kB, но им не воспользовались и фактически заняли только RSS = 4 kB.
Так как выделенная неанонимная память никуда не денется после остановки процесса, файл не удалится, то такой RSS нас не интересует.
HTTP-ошибки
Не забывайте следить за кодами ответов, которые во время тестирования возвращает сервис. Если что-то в настройке теста или окружения пошло не так, и вам на все запросы сервер вернул 5хх и 4хх ошибки, то смысла в таком тесте было не много. Мы следим за долей плохих ответов. Если ошибок много, то тест считается невалидным.
Немного о точности измерений
А теперь самое важное. Давайте вернёмся к предыдущим пунктам. Абсолютные величины посчитанных нами метрик, оказывается, не так уж нам и важны. Нет, конечно же, вы можете добиваться стабильности показателей, учтя все факторы, погрешности и флуктуации. Параллельно написать научную работу на эту тему (кстати, если кто искал себе такую, эта может быть неплохим вариантом). Но это не то, что нас интересует.
Нам важно влияние конкретного коммита на код относительно предыдущего состояния системы. То есть важна разница метрик от коммита к коммиту. И вот тут необходимо настроить процесс, который будет сравнивать эту разницу и при этом обеспечит стабильность абсолютной величины на этом интервале.
Окружение, запросы, данные, состояние сервиса – все доступные нам факторы должны быть зафиксированы. Вот эта система и работает у нас в рамках Continuous integration, обеспечивая нас информацией о всевозможных изменениях, которые произошли в рамках каждого коммита. Несмотря на это, всё зафиксировать не удастся, останется шум. Уменьшить шум мы можем, очевидно, увеличив выборку, то есть произвести несколько итераций отстрела. Далее, после отстрела, скажем, 15 итераций, можно посчитать медиану получившейся выборки. Кроме того, необходимо найти баланс между шумом и длительностью отстрела. Мы, например, остановились на погрешности в 1%. Если вы хотите выбрать более сложный и точный статистический метод в соответствии со своими требованиями, рекомендуем книгу, в которой перечислены варианты с описанием, когда и какой применяется.
Что ещё можно сделать с шумом?
Отметим, что немаловажную роль в таком тестировании занимает среда, в которой вы проводите тесты. Тестовый стенд должен быть надежным, на нём не должны быть запущены другие программы, так как они могут приводить к деградации вашего сервиса. Кроме того, результаты могут и будут зависеть от профиля нагрузки, окружения, базы данных и от различных “магнитных бурь”.
Мы в рамках одного теста коммита проводим несколько итераций на разных хостах. Во-первых, если вы пользуетесь облаком, то там может происходить что угодно. Даже если облако специализированное, как наше, всё равно там работают служебные процессы. Поэтому полагаться на результат от одного хоста нельзя. А если хост у вас железный, где нет, как в облаке, стандартного механизма поднятия окружения, то его можно вообще один раз случайно сломать и так и оставить. И врать он будет вам всегда. Поэтому мы гоняем наши тесты в облаке.
Из этого, правда, вытекает другой вопрос. Если ваши измерения производятся каждый раз на разных хостах, то результаты могут немного шуметь и из-за этого в том числе. Тогда можно нормировать показания на хост. То есть по историческим данным собрать “коэффициент хоста” и учитывать его при анализе результатов.
Анализ исторических данных показывает, что «железо» у нас разное. В слово «железо» тут входят версия ядра и последствия uptime (по-видимому, не перемещаемые объекты ядра в памяти).
Таким образом, каждому «хосту» (при перезагрузке хост «умирает» и появляется «новый») ставим в соответствие поправку, на которую умножаем RPS перед агрегацией.
Поправки считаем и обновляем крайне топорным способом, подозрительно напоминающим некоторый вариант обучения с подкреплением.
Для заданного вектора похостовых поправок считаем целевую функцию:
Дальше одну поправку (для хоста, у которого сумма этих весов наибольшая) фиксируем в 1.0 и ищем значения всех остальных поправок, дающие минимум целевой функции.
Чтобы провалидировать результаты на исторических данных, считаем поправки на старых данных, считаем поправленный результат на свежих, сравниваем с неисправленным.
Ещё один вариант корректировки результатов и уменьшения шума – это нормировка на «синтетику». Перед запуском трестируемого сервиса запустить на хосте “синтетическую программу”, по работе которой можно оценить состояние хоста и рассчитать поправочный коэффициент. Но в нашем случае мы используем поправки по хостам, а эта идея так и осталась идеей. Возможно, кому-то из вас она приглянется.
Несмотря на автоматизацию и все её плюсы, не забывайте о динамике ваших показателей. Важно следить, чтобы сервис не деградировал во времени. Маленькие просадки можно не заметить, они могут накопиться, и на большом временном промежутке ваши показатели могут просесть. Вот пример наших графиков, по которым мы смотрим на RPS. Он показывает относительное значение на каждом проверенном коммите, его номер и возможность посмотреть откуда был отведен релиз.
Если вы дочитали статью, значит, вам точно будет интересно посмотреть доклад про Яндекс.Танк и анализ результатов нагрузочного тестирования.
Также напоминаем, что более подробно об организации Continuous integration мы расскажем 25 октября на мероприятии Яндекс изнутри. Приходите в гости!
[обновлено] Как нагрузочное тестирование процессинга обошлось нам в €157 000 и почему никого не уволили
К исследованию побудили два фактора: появление у нас собственного процессинга карт и предстоящая крупная распродажа одного из популярных в РФ онлайн-ритейлеров.
Идея выглядела вполне бюджетной – примерно на 125 000 р. (по 1 р. на операцию), но кто же знал, как все обернется. Особая перчинка в том, что вся информация об эксперименте долгое время была закрыта и впервые публикуется в открытом источнике.
Как оказалось, мы не одиноки – ни один из наших банков-партнеров еще полгода назад не знал своего настоящего «потолка» и решал проблемы по мере поступления. По сути, они просто добавляли новые мощности прямо во время распродаж, хотя и не всегда успешно.
Будущие жертвы
Система карточных платежей (Mastercard в нашем случае) соединяет между собой множество внешних организаций, у каждой из которых свой зоопарк систем. Под нагрузку карточных платежей попадают практически все они, поэтому сразу посмотрим на всех участников.
Ниже представлена упрощенная схема взаимодействия нескольких организаций для обеспечения возможности оплатить какой-то товар картой через сервис Яндекс.Денег:
Все ключевые участники эксперимента на одной схеме. Яндекс.Танк – это отличный инструмент Яндекса для нагрузочного тестирования и комфортного анализа производительности.
Яндекс.Деньги принимают данные пластиковой карты у пользователя (в случае с тестом передается уже заполненный шаблон формы), а дальше происходит следующее:
Заполненная форма с данными карты передается на серверы фронтенда, которые ее обрабатывают и передают данные в бэкенд, а в дальнейшем – в отвечающее за работу со счетами ядро.
Платежный сервис блокирует сумму операции на счете пользователя и параллельно отправляет информацию об операции в банк-эквайер, который далее передает сведения в Mastercard и НСПК.
При масштабных онлайн-распродажах таких оплат может быть сотни в секунду, поэтому достанется всем звеньям платежной цепочки. Чтобы ни у кого не было претензий, мы заранее договорились с парой дружественных банков о том, что в определенные даты будут «боевые стрельбы» и что их сотрудники будут во всеоружии на местах.
Забегая вперед, после проведения первого эксперимента из 17 000 операций оказалось, что банки используют горизонтальную модель масштабирования платежных шлюзов, добавляя новые мощности по мере необходимости. В обычной жизни они успевают отреагировать на постепенный рост нагрузки, но в стрессовом режиме этого оказалось недостаточно.
Тут есть один тонкий момент. Дело в том, что все банки и Mastercard зарабатывают на выставляемых друг другу комиссиях за переводы. Сделать такую комиссию нулевой для тестов было практически невозможно. По нашим оценкам, совокупная цифра должна была составить 0,7% по отдельному коду категории оплаты MCC.
Величина комиссии являлась минимально возможной согласованной цифрой на момент проведения эксперимента с точки зрения всех принимающих участие сторон.
Запомните этот момент – в конце статьи будет с чем сравнить.
А не расстрелять ли нам процессинг
При тестировании производительности платежных сервисов неизбежно возникает ряд нюансов и ограничений, которые вынудили нас выйти с экспериментом на продакшн:
Производительность ключевых микросервисов (например, связанных с шифрованием карточных данных) ограничена лицензией.
Расположение микросервисов тоже ограничено лицензией. То есть сервер с купленной лицензией нельзя даже перенести в тестовую среду.
В качестве подготовительных действий, мы также отключили дополнительную защиту платежа 3DSecure (SMS-коды), сняли лимиты на число и сумму операций на каждом этапе платежа, а также договорились со службами безопасности участников, чтобы они не били тревогу.
Тем важнее становился проект для Яндекс.Денег, так как кроме практической пользы можно было сделать нечто полезное для всей российской банковской отрасли – результаты и методика исследования могут пригодиться не только нам. Кроме того, мне лично всегда было любопытно, как поведет себя наш процессинг, если его как следует «расстрелять».
Радиус поражения
Как вы понимаете, никто не согласовал бы команде даже потенциальную остановку сервиса. Даже на несколько секунд.
Поэтому расстрел предстояло сделать бережным и прогнозируемым:
В качестве нагрузочной операции выбрали пополнение счета кошелька с банковской карты, которая привязана к другому кошельку. Эта достаточно простая операция влечет за собой массу транзакций между Яндекс.Деньгами, банком-эквайром, платежной системой и НСПК. Что и требуется для эксперимента.
Участвующий в эксперименте банк предоставил отдельный терминал для проведения платежей с оговоренным кодом MCC. На этом этапе каждая тестовая операция начинает стоить реальных денег, так как к MCC привязана определенная комиссия.
MCC код (Merchant Category Code) — представляет собой 4-значный номер, присваиваемый платежными системами VISA, Mastercard и др. для классификации деятельности торговой точки в операции оплаты по банковским картам. Для владельца такой торговой точки важно получить как можно более выгодный MCC и платить меньшую комиссию платежной системе.
Все эти меры гарантировали хороший уровень отказоустойчивости платежного сервиса для пользователей даже при пиковых нагрузках.
Общая схема эксперимента: многопоточное пополнение кошельков с банковских карт других кошельков.
Для эксперимента мы согласовали уровень подаваемой интенсивности в 20 RpS (Requests per Second, число запросов в секунду). Для достижения большей производительности можно добавлять новые модули, но в схеме эксперимента присутствовал только один.
Яндекс.Деньги сотрудничают с несколькими банками-партнерами, но на масштабный эксперимент с реальными деньгами согласился только один из них.
На графике виден рост производительности на модуле процессинга при росте входной интенсивности, с провалом в центре как раз в момент проседания производительности нашего процессинга.
Кроме того, тесты вызвали некоторые проблемы в нашем бэкенде и ядре системы, создав массу блокировок по карточным счетам. Блокировки – это нормальная ситуация для любой карточной операции, так как перед реальным списанием деньги просто блокируются на счету пользователя и запись об этом попадает в общий файл Mastercard.
Такой файл каждый банк-эквайер ежедневно получает от Mastercard каждый раз в одно и то же время по согласованию и далее его разбирает. Так вот, после экспериментов файл с обычным размером 20 МБ увеличился в 5 раз и стал весить 104 МБ. На отработку такого списка потребовалось больше ресурсов, то есть пришлось переписать отдельные модули микросервисов, которые обрабатывали файл блокировок.
Что ж, мы немного оптимизировали запросы к БД, снизив нагрузку на процессор, и выпустили больше карт для снижения числа блокировок на одну карту.
Продолжаем обстрел
Вторая волна эксперимента проходила уже более ровно и спокойно, несмотря на более чем вдвое возросшее число обрабатываемых платежей.
График уже более равномерный, что говорит об успешности принятых мер. RpS равняется 20, так как это максимальное согласованное для эксперимента значение.
После окончания потока в 24 778 операций объем блокировок для каждой карты продолжил расти, что приводило к замедлениям при проведении платежей: перед каждым списанием процессингу приходилось считывать заново весь список блокировок конкретной карты. Решение — увеличить число карт с 50 до 10 050, что позволило для каждой сократить список блокировок с 200 до 1 при аналогичном количестве операций.
Следующая волна тестов принесла 50 000 операций, а списания подгрузились в базу процессинга за 40 минут, после чего нужно было их еще и обработать. Файл блокировок продолжал угрожающе расти с каждым экспериментом. А ведь ключевая БД процессинга работает на Oracle с ограничением в 4 ГБ на файл. До предела еще далеко, но становилось некомфортно.
В ходе отдельного эксперимента мы оценили производительность обработки списаний. За сутки провели тесты с интенсивностью 15 блокировок в секунду и последующим потоком списаний. Файл со списаниям пришел к нам в 18:00 следующего дня с задержкой в 1,5 часа, и наш процессинг обработал все 1 135 000 записей за 2 часа 10 минут. Для контраста, обычный разбор среднестатистического списка блокировок занимает десяток минут.
Проблемы возникли также с производительностью антифрод-машины и фронтенд-балансировщика запросов. Дело было в том, что балансировщик не проверял логическую доступность сервиса на узле, ограничиваясь только его присутствием в сети.
Кульминацией стал эксперимент на двое суток с суммарным числом операций 1 400 000, во второй день которого одновременно происходили две вещи:
Проходили тестовые стрельбы с платежами.
Две эти операции нагрузили процессинг по полной в рамках существующих лицензионных ограничений 20 RpS.
Боевые стрельбы закончились через два дня на отметке 3 157 800 проведенных операций. Однако как следует отпраздновать успех и полюбоваться цифрами нам не дали.
Привет от Mastercard
Нам выставили счет в €157 890 в качестве комиссии за проведенные операции, что немного не вписывалось в оговоренные 0,7% с 125 000 р.
При заказе терминала под тестовые операции мы указали неверный MCC код, из-за чего и получилось невероятная комиссия.
А вот и причина безобразия – мы выбрали не тот код MCC для терминала эквайринга, через который проходили все тестовые стрельбы. Поэтому за операцию на 1 р. платили 4 р. комиссии. Узнать об этой проблеме в ходе эксперимента не представлялось возможным, так как Mastercard выставил счет через неделю.
Недоразумение обошлось нам в 2 месяца напряженной работы по ручному урегулированию вопроса с Mastercard. Фактически мы подняли логи всего эксперимента, по которому выполнялся поиск и изменение операций в Mastercard. Лишнее подтверждение, что без подробных логов никуда.
Несмотря на давность эксперимента и незначительные финансовые убытки от его проведения, опыт однозначно положительный. Более того, подобные боевые стрельбы стали регулярными, а полученные данные позволи серьезно увеличить производительность карточных операций.
Конечно же, все персонажи и числа в статье были творчески переосмыслены из соображений безопасности, но фантазировали мы не слишком бурно и сохранили соотношения полученных по эксперименту данных.