Однажды наша команда решилась на эксперимент по расстрелу боевой платежной системы реальными деньгами. Это позволило бы понять, сколько сможем выдержать мы вместе с нашими партнерами. Об этом неоднозначном опыте и хочу рассказать.
К исследованию побудили два фактора: появление у нас собственного процессинга карт и предстоящая крупная распродажа одного из популярных в РФ онлайн-ритейлеров.
Идея выглядела вполне бюджетной – примерно на 125 000 р. (по 1 р. на операцию), но кто же знал, как все обернется. Особая перчинка в том, что вся информация об эксперименте долгое время была закрыта и впервые публикуется в открытом источнике.
Как оказалось, мы не одиноки – ни один из наших банков-партнеров еще полгода назад не знал своего настоящего «потолка» и решал проблемы по мере поступления. По сути, они просто добавляли новые мощности прямо во время распродаж, хотя и не всегда успешно.
Будущие жертвы
Система карточных платежей (Mastercard в нашем случае) соединяет между собой множество внешних организаций, у каждой из которых свой зоопарк систем. Под нагрузку карточных платежей попадают практически все они, поэтому сразу посмотрим на всех участников.
Ниже представлена упрощенная схема взаимодействия нескольких организаций для обеспечения возможности оплатить какой-то товар картой через сервис Яндекс.Денег:
Все ключевые участники эксперимента на одной схеме. Яндекс.Танк – это отличный инструмент Яндекса для нагрузочного тестирования и комфортного анализа производительности.
Яндекс.Деньги принимают данные пластиковой карты у пользователя (в случае с тестом передается уже заполненный шаблон формы), а дальше происходит следующее:
Заполненная форма с данными карты передается на серверы фронтенда, которые ее обрабатывают и передают данные в бэкенд, а в дальнейшем – в отвечающее за работу со счетами ядро.
Платежный сервис блокирует сумму операции на счете пользователя и параллельно отправляет информацию об операции в банк-эквайер, который далее передает сведения в Mastercard и НСПК.
- Спустя сутки НСПК присылает файл блокировок в банк-эквайер и Яндекс.Деньги, после чего список блокировок разбирается в наших микросервисах и происходит списание денег со счета пользователя.
При масштабных онлайн-распродажах таких оплат может быть сотни в секунду, поэтому достанется всем звеньям платежной цепочки. Чтобы ни у кого не было претензий, мы заранее договорились с парой дружественных банков о том, что в определенные даты будут «боевые стрельбы» и что их сотрудники будут во всеоружии на местах.
Забегая вперед, после проведения первого эксперимента из 17 000 операций оказалось, что банки используют горизонтальную модель масштабирования платежных шлюзов, добавляя новые мощности по мере необходимости. В обычной жизни они успевают отреагировать на постепенный рост нагрузки, но в стрессовом режиме этого оказалось недостаточно.
Тут есть один тонкий момент. Дело в том, что все банки и Mastercard зарабатывают на выставляемых друг другу комиссиях за переводы. Сделать такую комиссию нулевой для тестов было практически невозможно. По нашим оценкам, совокупная цифра должна была составить 0,7% по отдельному коду категории оплаты MCC.
Величина комиссии являлась минимально возможной согласованной цифрой на момент проведения эксперимента с точки зрения всех принимающих участие сторон.
Запомните этот момент – в конце статьи будет с чем сравнить.
А не расстрелять ли нам процессинг
При тестировании производительности платежных сервисов неизбежно возникает ряд нюансов и ограничений, которые вынудили нас выйти с экспериментом на продакшн:
Производительность ключевых микросервисов (например, связанных с шифрованием карточных данных) ограничена лицензией.
Расположение микросервисов тоже ограничено лицензией. То есть сервер с купленной лицензией нельзя даже перенести в тестовую среду.
- Никто из наших банков-партнеров ранее ничего подобного не проводил и свою емкость не исследовал, поэтому просить мудрого совета было не у кого. Здесь выручило тесное сотрудничество с Mastercard и крупицы знаний из личного опыта отдельных людей.
В качестве подготовительных действий, мы также отключили дополнительную защиту платежа 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 минут. Для контраста, обычный разбор среднестатистического списка блокировок занимает десяток минут.
Проблемы возникли также с производительностью антифрод-машины и фронтенд-балансировщика запросов. Дело было в том, что балансировщик не проверял логическую доступность сервиса на узле, ограничиваясь только его присутствием в сети.
Кроме того, массированныи? обстрел повсеместно привел к росту размера логов, что дополнительно проверило на прочность нашу систему сбора логов на EHK (Elasticsearch/Heka/Kibana), о которой недавно рассказывали.
Кульминацией стал эксперимент на двое суток с суммарным числом операций 1 400 000, во второй день которого одновременно происходили две вещи:
Проходили тестовые стрельбы с платежами.
- Разбирался файл блокировок предыдущего дня объемом 3,1 ГБ.
Две эти операции нагрузили процессинг по полной в рамках существующих лицензионных ограничений 20 RpS.
Боевые стрельбы закончились через два дня на отметке 3 157 800 проведенных операций. Однако как следует отпраздновать успех и полюбоваться цифрами нам не дали.
Привет от Mastercard
Нам выставили счет в €157 890 в качестве комиссии за проведенные операции, что немного не вписывалось в оговоренные 0,7% с 125 000 р.
При заказе терминала под тестовые операции мы указали неверный MCC код, из-за чего и получилось невероятная комиссия.
А вот и причина безобразия – мы выбрали не тот код MCC для терминала эквайринга, через который проходили все тестовые стрельбы. Поэтому за операцию на 1 р. платили 4 р. комиссии. Узнать об этой проблеме в ходе эксперимента не представлялось возможным, так как Mastercard выставил счет через неделю.
Недоразумение обошлось нам в 2 месяца напряженной работы по ручному урегулированию вопроса с Mastercard. Фактически мы подняли логи всего эксперимента, по которому выполнялся поиск и изменение операций в Mastercard. Лишнее подтверждение, что без подробных логов никуда.
Несмотря на давность эксперимента и незначительные финансовые убытки от его проведения, опыт однозначно положительный. Более того, подобные боевые стрельбы стали регулярными, а полученные данные позволи серьезно увеличить производительность карточных операций.
Конечно же, все персонажи и числа в статье были творчески переосмыслены из соображений безопасности, но фантазировали мы не слишком бурно и сохранили соотношения полученных по эксперименту данных.
Комментарии (81)
dimkss
01.06.2017 18:40-3Особая перчинка в том, что вся информация об эксперименте долгое время была закрыта и впервые публикуется в открытом источнике.
Да, это ужасно интересно!
klavis
01.06.2017 18:58+3Какая прекрасно мелкая, нелепая и дорогая ошибка. Человеческий фактор во всей красе, надо полагать.
khim
02.06.2017 16:13Без него никуда. Я помню как-то несколько лет назад Гугл пропал для всей России на несколько часов. Оказалось тоже кто-то опечатался: подключили новый, ускоренный, канал но ошибка в таблицах роутинга привела к тому, что вместо разрешения обоих каналов они оба оказались запрещены (где-то «или» с «и» перепутали).
Думаю там убытки сравнимые были…
radli
01.06.2017 19:02+1> Как нагрузочное тестирование процессинга обошлось нам в €157 000 и почему никого не уволили
Я то подумал проблема была у вас и с интересом читал что же вы не правильно сделали, а оказывается банка-эквайринг ошибся(
st0ne_c0ld
01.06.2017 19:23+1вообще поток слабоват, в начале статьи писали про сотни операций в секунду. Все таки хорошо, если бы можно было на полноценной тестовой системе всё это повторить, было бы и дешевле и можно было бы больше чем 20tx/sec послать. Которыми в общем то мало кого удивишь…
embriodead
01.06.2017 21:28Вы сильно удивитесь, когда начнете узнавать реальные цифры производительности российских банков-эммитентов. Действительно думаете, что по карточке среднего российского банка идет поток в 20 транзакций в секунду?
Vest
01.06.2017 21:49+1Мне интересно, или даже любопытно, у вас есть какие-нибудь числа по поводу пиковой нагрузки в такого рода случаях?
Например, среднее время ответа (запрос + валидация + перевод) какой-либо операции (например, оплата по карте), сколько транзакций в секунду в час пик, а сколько ночью.
Я иногда присутствую при нагрузочном тестировании и мне интересна чужая статистика для сравнения.
Спасибо заранее.
GEG
01.06.2017 22:31+5В Qiwi, правда, по кошельку тестируем от 100 до 200 транзакций в секунду на магазин. AliExpress умеют устраивать красивые акции с эффектным ростом оборота. :)
justboris
02.06.2017 11:24+7Как можно читать этот график, если на нем нет оси Y?
Иллюстрация в тему
GEG
02.06.2017 19:39Число оплат за 5 минут. Y раскрыть не могу, NDA же. :)
justboris
02.06.2017 23:48Так Y не обязательно должно быть в настоящих числах, может быть и в у.е.
Главное видеть, сколько было до, и насколько это линия подскочила.
Сейчас это может быть так: было 90 у.е, стало 99, а шкала от 90 до 100
fourwingedsun
02.06.2017 11:32AliExpress умеют устраивать красивые акции с эффектным ростом оборота. :)
О, да, распродажи и подготовка к ним — это уйма других интересных историй :) Производительность карточных авторизаций крайне важна и для нашего бизнеса, и для исследований. Хотя бы потому что нагрузки там значительно больше и финансовые риски выше, особенно в преддверии распродаж. Такие акции — как раз интересны взрывным ростом интенсивности, когда график улетает в потолок. Мы на регулярной основе исследуем на боевой среде latency и throughput возможностей нашей системы по карточным авторизациям, чтобы гарантировать поддержку на уровне сотен операций в секунду (точно не меньше 500 TpS). Причем такие эксперименты не требуют от нас финансовых затрат, там мы давно всё учли :).GEG
02.06.2017 19:40500 — огонь. А в чем была разница с тестированием из статьи? Почему там всего 20 тогда?
fourwingedsun
02.06.2017 21:24+1Так от 500 TpS — это про авторизации карточных операций, а операций по картам собственной эмиссии — от 20 TpS. Кроме того для авторизаций карточных операций проводились эксперименты по нахождению конкретно максимума производительности, а в текущей статье мы описали stress и volume тестирование для операций по своим эмитированным картам.
Vest
02.06.2017 14:13Спасибо, если я правильно понимаю, вы симулируете ситуацию, когда магазин получает платежей от Qiwi клиентов с throughput 100-200 TpS? А какой в этом случае получается response time? Когда пользователь видит, что покупка успешна, она действительно успешна, или «запрос принят и сейчас обрабатывается»?
А график, насколько я вижу, содержит тот самый пик при тестировании? Или же это Shopping Festival 11.11, а стрелочка показывает обыкновенный «размер» выручки в каждый день?GEG
02.06.2017 19:44Спасибо, если я правильно понимаю, вы симулируете ситуацию, когда магазин получает платежей от Qiwi клиентов с throughput 100-200 TpS
Да.
А какой в этом случае получается response time?
Норма — в пределах 2-3 секунд.
Когда пользователь видит, что покупка успешна, она действительно успешна, или «запрос принят и сейчас обрабатывается»?
Успешна. Причем онлайн обновляется баланс клиента и, по умолчанию, баланс компании, которая принимает платеж.
Или же это Shopping Festival 11.11, а стрелочка показывает обыкновенный «размер» выручки в каждый день?
Все верно, это Ali 11.11. Только не выручки, а числа оплат. Графики с тестов не такие эффектные. :)
MarinaGrom
08.06.2017 16:55без оси y этот график не представляется важным или несущим хоть какую-то информацию… ну понятноже, иначе как соотношение понять
fourwingedsun
02.06.2017 10:48Я иногда присутствую при нагрузочном тестировании и мне интересна чужая статистика для сравнения.
Я бы с радостью рассказал о них подробнее, но пока это тайна.
st0ne_c0ld
02.06.2017 12:05работая в одном из вендоров процессинга — в принципе, какие-то цифры есть…
Но насчёт «среднего российского банка» — думаю вы правы, 20tps вполне реальная ситуация.
fourwingedsun
02.06.2017 00:06+2В рамках проведённого эксперимента в первую очередь нам было важно провести именно stress и volume тестирование, оценить влияние на систему в ходе постоянного длительного накопления операций. Мы не пытались выяснить максимальную производительность, поэтому и стреляли не до отсечки. Кроме того предметом исследования являлись не авторизации карточных операций, а операции по картам собственной эмиссии на одном из сегментов процессинга. Каждый такой сегмент использует готовое платное решение от стороннего производителя. Мощности одного такого сегмента ограничены, а их увеличение требует привлечения дополнительных денежных средств.
degs
01.06.2017 22:04+1Спасибо огромное, материал и опыт просто бесценные.
Безумству храбрых поем мы песню.
stalkerxxl
01.06.2017 22:08+14Так вы заплатили все-таки 157 000 евро или отсудили свою правоту?
fourwingedsun
02.06.2017 12:10Так вы заплатили все-таки 157 000 евро или отсудили свою правоту?
В итоге мы заплатили существенно меньше, сократив стоимость на порядок. А это уже успех, достаточный, чтобы никого не увольнять :)
pnetmon
01.06.2017 22:17+1Как то непонятно
Идея выглядела вполне бюджетной – примерно на 125 000 р. (по 1 р. на операцию)… Нам выставили счет в €157 890 в качестве комиссии за проведенные операции, что немного не вписывалось в оговоренные 0,7% с 125 000 р… Поэтому операции проводились не по оговоренной ставке. Грубо говоря, за операцию на 1 р. мы платили 4 р. комиссии.
Как с 1 р. за операции при комиссии в 4 р. сумма выросла более чем в 75 раз?
Спустя сутки НСПК присылает файл блокировок в банк-эквайер и Яндекс.Деньги, после чего список блокировок разбирается в наших микросервисах и происходит списание денег со счета пользователя.
…
Такой файл каждый банк-эквайер ежедневно получает от Mastercard каждый раз в одно и то же время по согласованию и далее его разбирает.Mastercard и НСПК присылают файлы, но в одном моменте один, в другом другой...
Дело в том, что все банки и Mastercard зарабатывают на выставляемых друг другу комиссиях за переводы.
НСПК не за бесплатно работает
fourwingedsun
02.06.2017 12:19+1Как то непонятно. Как с 1 р. за операции при комиссии в 4 р. сумма выросла более чем в 75 раз?
В итоге мы провели 3 157 800 операций при комиссии 4 р. за штуку, и общая сумма составила 12 631 200 р. или € 157 890 на момент организации эксперимента.
PinGniX
01.06.2017 22:25+1Странная терминология для процессинга. Обычно процессинг оперирует термином tps (transaction per second). И что это за нагрузка 20 tps? Вон в процессингах идут 1500 tps от которых TSYS загибается — вот это нагрузка!
Вообще не ясен смысл статьи, если честно. Статья о том как мы накосячили с MCC в проде? Почему нельзя было в тестовой среде это сделать?Ghool
01.06.2017 23:00+1Вероятно причина в том, что хотели протестировать работу всей структуры в целом.
Надо сказать, что 125 тысяч (с учётом комиссии 0.7 212.5 тысяч) очень небольшая цена за такие данные.
Главное, что бы такое тестирование не вызвало проблемы на проде!
OpenMan
01.06.2017 23:05Подскажите, а вы проводили эксперимент одновременно с работой обычных клиентов? От них не было жалоб на какие-нибудь задержки в обслуживании?
fourwingedsun
02.06.2017 12:26Подскажите, а вы проводили эксперимент одновременно с работой обычных клиентов? От них не было жалоб на какие-нибудь задержки в обслуживании?
Да, эксперимент проводился вместе с работой обычных клиентов на той же среде. При этом наши экспериментальные операции фактически ничем не отличались от аналогичных пользовательских. И самое приятное для нас — никто из них не пострадал. Все было сделано более, чем аккуратно.
shhhidan
01.06.2017 23:06-4Если что-то обошлось в круглую сумму, но никого не уволили — статья про Яндекс.
Dronablo
01.06.2017 23:06+1Для любого, кто видел какой-нибудь процессинг изнутри статья странная примерно вся, но как базовика меня более всего удивило вот это:
А ведь ключевая БД процессинга работает на Oracle с ограничением в 4 ГБ на файл.
Что это за ограничение и откуда взялось?
Cubus
02.06.2017 11:27Действительно, странно. UTL_FILE ограничений на размер читаемого файл не имеет, external table тоже, sql*loader тем более. Было бы интересно узнать подробнее про это ограничение.
Ghool
02.06.2017 15:26Я по оракл не спец, но тоже заинтересовался, вспонив fat32 :)
Нагуглил вот это:
http://alldba.ru/index.php/38-subd/index.php?option=com_content&view=article&id=64&Itemid=164
sharptop
02.06.2017 15:33+1Единственное, что приходит в голову с таким ограничением — это Oracle Database Express Edition. Цитата с сайта —
Oracle Database XE может быть установлена на любой компьютер с любым количеством процессоров (одна база данных на машину), но с ограничением в 4Гб пользовательских данных, использует не более 1Гб оперативной памяти и только один из имеющихся процессоров.
Собственно пруф
fourwingedsun
02.06.2017 17:19+1Что это за ограничение и откуда взялось?
Гипотезы интересные, но в нашем случае всё несколько иначе :) На момент проведения эксперимента все блокировки приходили в виде xml-файла, загружающего в поле Oracle типа CLOB, максимальный размер которого 4 Гб. Мы уже переписали этот механизм и результаты проведённого эксперимент тут сыграли не последнюю роль.
CreFroD
01.06.2017 23:06А что было бы если размер файла превысил 4ГБ и база упала? И вообще был ли риск для простых пользователей?
alexoron
01.06.2017 23:40-26Что-то мне кажется, потому никого не уволили так как решение принимал какой-то начальник, важный начальничек.
А так как он чей-то родственник начальничка повыше, за него сверху заступились и убыток «списали».
Ну в прочем как обычно в большинсте компаниях на постсоветском пространстве.
За коррупцию вообще молчу, это поголовно.
ИМХО.Erelecano
02.06.2017 03:29+1Равнять совок и Яндекс не стоит. Яндекс — единственная европейская компания на территории РФ зародившаяся и ныне живая. Нет в них совка, так уж получилось.
dklein
02.06.2017 08:59+6Вы статью вообще до конца дочитали? Или вы хотите, чтобы Яндекс уволил сотрудников банква-экваера за то, что те затупили? :D
alexoron
02.06.2017 11:10-11Конечно прочитал.
Только мне не понятно, кто тот самый ответственный человек допустивший такую оплошность.
Если бы это был рядовой или руководитель низшей планки — он бы уже давно был уволен, как минимум.
Эта «счастливая» статья напоминает пару месяцев назад историю как devops случайно удалил не ту базу и как они потом восстанавливали старую базу при посторонней помощи. И всю эту историю выложили в паблик.
PS. сотрудники яндекса всегда минусуют критику? И это называется «единственная европейская компания на территории РФ зародившаяся и ныне живая»?
amarao
02.06.2017 12:38+11Я не сотрудник Яндекса, но я минусанул. Причина? Со словами «мне кажется» идёт оголтелое (ака не имеющее доказательств) обвинение в кумовстве, с плавным переводом вопроса в политическую плоскость, с параллельным обобщением на всю индустрию.
michael_vostrikov
02.06.2017 13:05+1"Это был рядовой или руководитель низшей планки" только блин не из Яндекса. Это так сложно понять?
ganqqwerty
07.06.2017 00:54+3> он бы уже давно был уволен, как минимум.
я не очень понимаю, а что бы это улучшило? Увольнение сотрудника за оплошность — это вообще как-то дико, на мой взгляд, звучит. Можно уволить за саботаж, за то, что не работает, за обнаружившуюся непроходимую тупость, постоянно приводящую к убыткам, можно по политическим мотивам. А за единичную ошибку — вы это как потом объясните его коллегам?
grossws
07.06.2017 01:40+1Лучше наказания относительно рядового работника за первую ошибку только коллективная ответственность. Лучше для развала команды и ухода всех более-менее разумных работников, разумеется.
Если же серьёзно, то такого рода ошибки, зачастую, не вина исполнителей, а вина их руководителей, которые не смогли/не успели отладить процессы. И за систематические проблемы такого рода нужно увольнять не исполнителей, а их начальников. К сожалению, это происходит куда реже.
Ghool
02.06.2017 15:24Ну, можно было сперва прогнать пару пробных транзакций, выждать день, убедиться что всё ок и гнать нагрузку.
fourwingedsun
02.06.2017 15:29Собственно говоря, так и было, мы провели пробные транзакции, подождали день, перешли к крупномасштабному эксперименту, но счёт по ним всем выставили через неделю. При этом итоговый счет содержал только сумму по всем транзакциям в совокупности без дополнительных комментариев.
aynur_safin
04.06.2017 19:54+1"Или вы хотите, чтобы Яндекс уволил сотрудников банква-экваера за то, что те затупили? :D"
Насколько я понял, ошиблись сотрудники Яндекс.Денег.
MrAloof
02.06.2017 08:59-2Тема "… почему никого не уволили" не раскрыта :-) В результате 2-х месяцев боданий был перерасчет или как?
Проглядывает жуткая не технологичность процессинга — обмен файлами транзакций, ежесуточный их разбор…
Планируется ли переход на блокчейн или что-то подобное?
ggo
02.06.2017 09:23обмен файлами транзакций, ежесуточный их разбор
;) добро пожаловать в реальный мир…
Cobolorum
02.06.2017 09:44+5Зачем тут блокчейн!?!?!? Что в платежной системе банк не доверяет оператору платежный системы? Что есть ситуации кода целые сегменты ПС выплывают на стуки из онланйа?
Что это за новомодный тренд пытаться засунуть блокчейн во все щели!
PsyHaSTe
03.06.2017 12:22Вполне полезный тренд. До этого например был тренд засунуть компьютеры во все, включая холодильник. Как мне кажется, вполне успешно. Где-то отомрет, как ненужное, а где-то зацепится.
difiso
02.06.2017 10:48+2Обмен данными по блокировкам нужен. В некоторых случаях операцию по карте может одобрить платежная система, и банк не будет об этой операции знать пока она ему об этом не скажет.
Frank59
02.06.2017 10:42+1Классная статья, спасибо!
Вопрос насчет вашей системы логирования на основе эластика: сколько ГБ логов туда попало за день при максимальной нагрузке(если не секрет конечно)?fourwingedsun
02.06.2017 16:56Сотни миллионов операций во всей системе не сравнимы с единицами миллионов операций процессинга во время нашего эксперимента, поэтому существенной нагрузки на систему логирования на основе эластика мы не заметили.
XNoNAME
02.06.2017 13:32Почему графики как у JMeter? Использовалась та же библиотечка?
fourwingedsun
02.06.2017 13:46Да, там самая библиотека. В качестве генераторов трафика использовались и phantom (дефолтный для Яндекс.Танка) и jmeter.
iListo
02.06.2017 13:46Для меня самое большое приключение — это купить билет на КампНоу, когда за 2 дня до матча выбрасывают оставшиеся 10тыс билетов. Сайт пускает в порядке живой очереди, иногда с часовым ожиданием… Платежная система может выбросить на последнем этапе…
В общем, хотелось бы, чтобы системы были более совершенны и дарили пользователям только радость)
Survtur
03.06.2017 10:10Активная работа ритейла подразумевает ещё и активную работу ККМ нового типа. Не будет ли этот момент узким местом?
fourwingedsun
03.06.2017 12:29Гипотетически вполне вероятно ККМ может стать узким местом. Это, кстати, хорошая перспектива для дальнейших исследований, которые нам ещё предстоит провести. Пока у нас такой возможности не было.
Orky
06.06.2017 19:23Там проблема в фискальных накопителях. Они обрабатывают около 1 чека в три секунды.
Как только они научатся быстрее шифровать — будет легче.
anatan
11.06.2017 11:36Для полноты картины нужно было бы упомянуть железо, на котором работает процессинг.
Приведенные цифры мало о чем говорят без этого.
SyrexS
Разъясните, пожалуйста, что такое RpS?
3 157 800 операций — это за сколько дней?
easyman
requests per second же
fourwingedsun
RpS — Request per Second — число запросов в секунду, метрика использования сетевого ресурса. В нашем случае, один запрос был равен одному переводу с карты на счёт.
3 157 800 операций было проведено за двое суток эксперимента.
Ghool
Мы обычно используем термин tps — transaction per second
var
rps != tps, обычно rps в лучшем случае равен tps или всегда меньше (а порой на порядок).
«Хозяйке на заметку»: если общаться не только внутри IT, а ещё из бизнесом — rps проще объяснить и " продать", чем tps (хотя и то и то, весьма сложно объяснимо, обычно все хотят мерять «пользователями» — что совершенно неверно с точки зрения нагрузочного тестирования).
Да и «запросы», по-хорошему, «транзакциями» называть не стоит (легко будет запутаться, если читать литературу, пользоваться инструментами, например newrelic), если речь только про название, а не суть.
RPS — это прежде всего, то что породило запросы к сервису (как правило внешние), а TPS — это то, что уже происходило внутри и пораждало запросы (транзакции) к другим сервисам, базам данных, да даже просто другим участкам кода и в принципе много чего ещё можно измерять, в зависимости от возможностей вашего мониторинга.
Всё конечно весьма условно, но по опыту, в такой терминологии жить гораздо проще. ;)
Ghool
Спасибо!
Мы чаще тестируем только одну систему, все остальные на заглушках, так что tps отличается от rps только если часть транзакций принимаются но не обрабатываются, то есть после достижения макс.перф, так что мы rps называем tps.
В данном случае, конечно, все эти ньюансы надо учесть.
dimskiy
+поправили в статье — спасибо!