Связаться по Skype: vkarabedyants
Позвонить Написать
+7 (499) 404-28-83

Блог о системном администрировании серверов и сайтов

Установка, настройка программного обеспечения Linux, Windows операционных систем

Смерть от распродажи. Часть 1

Доклад на конференции HighLoad++ 2017: Смерть от распродажи: как Яндекс.Деньги попытались разогнаться к  Black Friday и выстоять. Докладчик Анатолий Пласковский, сотрудник Яндекс.Деньги.

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

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

нагрузка интернет магазина

В чём интересная разница. Ребята из Киви сказали, что это опыт их работы на распродаже, распродажи по эквайрингу АлиЭкспресс. А вы знаете какие у этой компании большие распродажи. Я где-то поискал и нашел,  от 1000 операций. Всё сводится к тому что любая распродажа обладает приблизительно вот такой вот спецификой работы: медленно ….., потом много. И главная специфика этих акции в нашей стране, как вы думаете какая? Это смерть от распродажи.

подготовка к распродаже

Как раз таки самые запоминающиеся распродажи на моей памяти, которые я наблюдал даже как пользователь  — это распродажа АлиЭкспресс 11.11 2015 года. В тот момент на 3 дня легла эмиссия большинства банков Российской Федерации.

Вот как взвесить если какой-то сервис который миллиард операций в секунду ляжет и люди пойдут гулять, как-нибудь в детстве когда там телевизор выключали мультики заканчивались мы все ушли на улицу гуляли, то тут если ляжет эмиссия всех карт, мы не сможем делать нечего. Я помню тот прекрасный день 11 числа, когда я вечером заехал на заправку. Ну и думаю распродажи видимо там идёт всё лежит и женщина на заправке смотрит на меня и говорит: “У вас наличные есть?”. Есть. “Платите наличными, у нас сегодня весь день что-то не работает”. Пришлось заплатить наличными, при этом каждую купюра она отдельно посмотрела, потому что видимо посчитала, что это заговор какой-то. Оно так или иначе это распродажа заэффектила  3 дня нормальной работы всей платежной системы всех банков России.

Так вот смотри в свете распродажи у нас есть два варианта или умереть на этой распродаже, не выдержав этого потока, или убежать от смерти.

В принципе я считаю, выбор дело личное. Какие-то банки не хотят вкладываться в развитие и говорят, ну это случается знаете раз в году. Ну подумаешь мы полежим потом 3 дня после этого пока будем переваривать весь поток операций который идет, ничего страшного. Но есть такие люди особенно на финансовой системы в том числе и денежные которые говорят “Нет давайте мы всё-таки подготовимся, выдержим эту нагрузку и получим хороший куш”. Судя потому график и что Вы видели,  люди наверно там за одну секунду сразу месячный баланс получили. Ну это нормально. Яндекс Деньги тоже хотят и участвуют в разного рода распродажах. У нас на входе есть несколько магазинов, а конкретно нескольких десятков тысяч  магазинов,  каждый из которых или несколько вместе устраивают распродажи.

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

нагрузка на сайт

Для того, чтобы подготовиться нормально, к эффективным распродажам. Нам необходимо подготовить и себя и всю цепочку, которая стоит за нами.  Повлиять не только на свою производительность, а на всех партнеров,  учитывая что мы работаем в финансовой среде и работаем с реальными деньгами чужих людей дело это весьма непростое. Карточные авторизации обычно состоят из двух частей: это блокировка денег на счёте, а потом уже последующие списание. Наверняка если вы были за границей, то при заезде в гостиницу с Вас например блокировалась какая-то сумма на счёте но потом возвращалась. Ну если вы конечно брали с собой полотенце сумма не возвращалась. Здесь тоже самое сначала сумму денег блокируется, потом списывается, поэтому во время распродажи обычно идут два потока 1 поток основной, которой обычно и укладывает всю систему денежных переводов спать на долгие годы и 2 идущий после неё это поток этих самых списание клирингов.

нагрузочное тестирование

Что подразумевается, когда я говорю про распродажу в Яндекс деньгах.

10.000 магазинов, несколько банков эквайрингов с которыми мы сотрудничаем и банки эмитенты, практически все потому что мы не знаем, какой картой будет платить человек это может быть и Mastercard, VISA, unionpay и даже American Express Поэтому когда мы первый раз услышали о том, что у нас грядет распродажа мы оживились, потому что наши например высшее кадры сказали:Ну здорово.

прибыль от распродаж

 

Вот смотрите какие там графики замечательные, 1000 операций в секунду. Ну и наверное чек этой операции в среднем как бы тут 500 рублей,  можете представить себе что за секунду 500000 руб. Это шикарно многим там ипотеки вот так вот заплатить 4 секунды, ипотека закрыта. Вот это были наши ожидания. Естественно, все наши технические работники сказали мы выдержим — зуб даем. Вот и сказали давайте пока на тестовой среде, спокойненько посмотрим, что у нас есть.  Мне просто интересна эта тема, потому что я пришел на неё работать. В Яндексе это-то задание,  которое мне дали как знаете стажеру. Я на тестовой среде посмотрел и получилось 5 транзакций в секунду, система больше не тащила.

тестирование продаж

Сказать, что многих это расстроило, это ничего не сказать.  Люди сразу начали придумывать какие-то различные объяснения того почему именно 5, а не тысяча, кто-то говорил что тестовый стенд, этого не Production. На продакшен нельзя. А кто-то говорил, что вы знаете это просто вы не правильно меряете. Ладно тогда мы подумали. Ну хорошо если у нас на тестовой среде такие данные получается давайте попробуем мягко и безопасно выйти на продакшн, чтобы померить на продакшене, данные с Production они же должны быть лучше. Так вот на тестере приблизительно или на продакшене выглядит наша система.

схема тестирования сайта

Какие-то данные у нас приходят из магазин, поступают в приёмник для карт, он уже делает запись о заказе в базу данных, обновляя её статус,  последующем ходит защитник который так или иначе обновляет данные об этом заказе, смотрит ссть ли какие-то ограничения по числу операций, по сумме операции , подозрительная ли вы личность может быть вообще террорист или ещё кто-то. Бывает блокирует платежи. Также есть отдельный модуль, компонент, который называется магазы. Эти магазы работают непосредственно уже со списание,  которые идут за авторизации,  и соответственно передают данные в систему для полноценной обработки. И Учет. После чего получив все необходимые данные по данной транзакции в банк посылает запрос в банк эквайер, а он уже идет дальше по цепочке платежные системы. Главным вопросом по этой схеме было, как же мы будем эмулировать работу нашего банка эквайера. Самый простой вариант который только пришёл на ум давайте заглушку напишем. Заглушки у нас развивались.

Самые первые  были откровенно тупыми, они всегда говорили ОК. Была написана json и просто говорила — Ок. Скорость ответа около 0. Фактическим мы просто забили на банк-эквайер и смотрели на всю работу в отрыве от него.

Умная заглушка, но я бы сказал чуть поумнее, она чуть чуть поумнее потому, что она генерирует задержку от банка эквайера в указанном нами диапазоне В чём тут проблема? Распределение равномерное, то есть, если мы указываем что банк отвечает за время от 2 секунд до 5 секунд, то где-то в конце мы собираем данные по всем нашим запросам и получается, что там равное распределение времени ответа. Наконец нас это перестало устраивать мы взяли реальные логи обработали их,  написали систему регулярной обработки, мы получили что-то наподобие гауссовской зависимости. Померили эту голосовую зависимость и написали интеллектуальную заглушку.  И теперь у нас появилась вероятность времени ответы в этой заглушке, которая, так или иначе помогает эффективно эмулировать работу  банка эквайера. Ну хотя бы хоть какой-то вот такой вот аналог.

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

продуктивное нагрузочное тестирования

C начала была идея сделать такую канареечное ветку на продакшене,  выделенную исключительно специально для наших экспериментов. Помните в Шахтах первой умирает канарейка,  если умерла канарейка, то Шахтер эвакуируются. Еесли бы умирала деятельность в этой ветке мы бы моментально прекращали деятельность эксперимента и разбирались с его последствиями. Но в итоге это не прокатило. Вот смотрите это наши yandex-tank. Мы постреляли, первые результаты с нашего продакшена.

Действительно не 5 во-первых 20( с права) и причём пиково 20, а слева время ответа, приблизительно полсекунды. Я не думаю что 20 это настолько же хорошо как,например 1000. У нас появились первые узкие места которые, мы в принципе только где бы только не находили. Провалы в сохранение данных в БД магазов,  дефицит памяти. Стреляли первый раз мы достаточно интересно, а подготовка стрельбы на такой системе проходит обычно в ночное время и все стрельбы проходят где-нибудь там с 3 ночи до 6:00 утр,  когда пользовательская  активность минимальна.

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

Мы свели вместе админов баз данных и разработчиков и попытались исправить такие проблемы.

Кроме этого нам удалось оптимизировать выгрузку логов потому что оказалось, что наша система была не предназначена для работы с логами большого размера. И одно дело когда у вас постоянно на продавшене идёт порядка 10 транзакций в секунду а тут пришла например 1.000 или 2.000 с этим возникают сложности. Ну естественно мы не забыли проверять жива ли вообще наша заглушка, более того,чтобы более или менее уравновесить работу этих заглушек, мы сделали балансировщик и поставили несколько хвостов на которых были размещены эти самые заглушки эти самые заглушки работали прекрасно — “их интеллектуальная версия” они очень четко работали и показывали то как работает банк эквайер с точки зрения времени ответы, но на небольшом потоке. Спустя пару недель после всех приведённых оптимизации совместно с dba с разработчиками мы получили? что у нас есть существенный прирост  до 300 транзакций в секунду.

Мы уже более-менее выросли с 5 до 300 возвращаемся к нашим схема после того как мы потюнили магаза и bd мы вернулись обратно к нашей основной компоненте которая принимает на себя запрос из магазинов это база скарта.

Продолжение в следующей статье….

 

Оставить комментарий

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.