Comments 106
Ссылка на шаблон постмортема выдает 403. За материал спасибо, очень познавательно.
Да уж... Который раз убеждаюсь: совместить в одной СУБД бизнес-критикал функционал (заказы) и всякий маркетинг (пуши) - путь к факапу.
Имхо, упомянутые "витрины данных" - правильное направление.
С одной стороны, возможно. С другой стороны, в теории это мелкий процент нагрузки должен быть.
В mysql (не знаю сильно про другие) очень важно работать с индексами. Просто поиск по данным очень долгий (хотя та же Aurora более оптимизирована, например). В данной статье как раз то, что система работает на кэше, как раз и подсказывает, что возможно проблема в этом. В моей практике программисты очень редко попадают в индексы в mysql, потому что там попать далеко не всегда просто, ошибки не прощаются :)
Проблема еще в том, что пуши конвертируются в открытие приложения, загрузку меню, а в итоге возможно и в совершение заказа..
OLAP система (в вашем варианте «маркетинг») — оперирующая выборкой больших объемов данных с агрегацией. Основными оптимизационными шагами тут служат либо докидывание индексов на все эти агреграции, либо хранение предрассчитанных данных.
А «заказы» из вашего варианта — это OLTP система — для них требуется быстро проводить операции записи и очень простого чтения (поиск по ключу в таблице как правило). А для оптимизации тут часто применяют партиционирование (мол, только какая-то последняя часть из таблицы нужна, а в остальные куски почти никогда не залезаем).
Все оптимизационные шаги для OLAP ухудшают OLTP составляющую и наоборот.
Поэтому хорошим подходом является разделение этих 2х систем — у каждой своя СУБД. Одно только это разделение разнохарактерной нагрузки уже хорошо проявляется на системе, т.к. каждая СУБД подстраивается под свой характер нагрузки.
здесь проблема не в совмещении базы данных, а в увеличении нагрузки из-за пушей. собственно это увеличение нагрузки -- и есть цель этих пушей
2. Прочитал всю статью и понял, что у вас в команде нет DBA. Если бы он был, то большая часть проблем бы не возникла.
3. Перешёл на сайт dodo.dev. Там в jobs есть вакансия SRE DBA. Типа актуальная, но при переходе по ней редиректит на dodobrands.huntflow.io/vacancy/sre-dba-1, где указано, что вакансия уже в архиве. Судя по всему, SRE DBA уже наняли.
4. Проблема с архитектурой, т.к. единой точкой отказа является монолитная база данных Mysql. В разделе Решения не нашёл ничего, чтобы касалось разбиения этой базы не несколько более мелких, чтобы в случае проблем, ложился лишь 1 канал продаж, а не все сразу.
5. Статья интересная, было приятно прочитать про внутреннюю «кухню» компании.
Сам постмортем мы писали около 3х недель. 1 неделя после сбоя ушла на отработку гипотезы с "косячным" релизом, потом подбивали детали, еще гоняли нагрузку, определили проблемы с кэшом в базе. Долго переносил в статью.
Ога, DBA нет. Тоже проблема. Я не написал, но мы в конце года как раз нашли именно DBA себе.
Закрыли в конце декабря,
Не написал тоже(слишком длинно выходило уже), но все верно. Например, в единой монолитной базе находятся промоакции и хранение додокоинов(программа лояльности), находятся данные о зонах доставки. Мы это сейчас выносим, но результаты будут позже. Уверен, ребята напишут об этом отдельно.
а не проще заодно ещё бд сменить? хотя бы на tidb и clickhouse? разнести функционал и жить спокойно? dba поможет облегчить инциденты, синтаксис у tidb схожий с mysql, функционал поддерживается, а большие выборки по меню и тп вынести в клик.
" в команде нет DBA"
Зацепило.
Как погруженный в тему - не всегда можно предвидеть. Имея весьма нескромный опыт в кровавом энтерпрайзе и построив эшелонированную оборону от разработки до деплоя на прод, несколько раз ловил epic fail.
В качестве примера - была задача по ограничению доступной инфы на экране признаку VIP. VIP'ов было пара сотен, что на фоне миллионов клиентов даже в пределы погрешности не укладывалось. Задачку примитивная, скинули джуну, по феншую фичу даже протестировали на паре офисов и забыли до отмашки заказчиком. Через пару месяцев вместе с глобальным обновлением включили в релиз - как крыжик в настройках...
Джун, ему простительно, реализовал прекрасно: на каждый (ты вдруг VIP'ом стал внезапно) got/lost focus элемента формы проверка через select * from vip, дальше поиск по массиву уже на клиенте...
В форме, центральной, было несколько десятков закладок, пара сотен статических и, в зависимости от, еще минимум сотня динамических элементов. А в момент открытия формы, как мы потом узнали, каждый (!) элемент генерил эти 2 события. И в понедельник утром > 5 тыс. ничего не подозревающих пользователей пришли на работу. И не могли открыть форму, приложение "висело", они его срубали и открывали заново. Восточные регионы успели, а следующие часовые пояса уже нет, что внесло свои коррективы в понимание проблемы. Мы докидывали сервера приложений, которые принимались переваривать все новые сессии пользователей, а старые никуда не девались, пока не дорабатывали до конца или мы не перегружали сервак. Между БД и серверами приложений гнался немеренный траффик. К БД было подключено несколько десятков и других приложений, и там тоже началась деградация.
Тем, кто не очень в теме БД, простой select из базы в таком виде грубо: declare stmt/open cursor/fetch 200+ rows/close cursor, каждое действие это несколько пакетов, каждый фетч страница в 4Кб, умноженное на число строк в таблице - 200+ и умноженное на 2*300 раз за контрол на форме на каждого пользователя=5000 и каждую зависшую сессию - умножить еще на 2. И все это в единицу времени. "Ватага зайцев мочит льва."
Мы ddos-или собственную инфру. И самое главное, не понимали причину, поднимали новые сервера => создавали все новую нагрузку, положили сеть. Снять дампы или включить детальный мониторинг было нереально. А причину, без инструмента и исходных данных, искали, как вы понимаете, теоретически, в последних-предпоследних-предпредпоследних изменениях. Судорожные откаты к результату не приводили, управлять пользователям мы в тот момент не умели. А про крыж в настройках никто не подумал, потому что дата файла с этими настройками из репозитория (феншуй епрст!) оказалась, как можно догадаться, 2-х месячной давности.
Как DBA отвечу:
И разработка и ревью изменений БД - было. И на деве, тесте, предпроде и, частично на проде, были настроены мониторинги - кривые запросы к БД отлавливались автоматом по целому сету условий. Но на экранах радаров эту мелочь не заметили, от пары юзверей пусть даже несколько тысяч запросов, из кеша в пару тестовых записей, которые относительно нескольких сотен транзакций в секунду, не попали в top-100 ни по одному показателю.
Графики нагрузки на продуктивные БД имели историю, анализ, с указанием причин изменений ключевых показателей, объяснения динамики и "красные линии", с историчностью в несколько лет и разбирались на еженедельной основе вместе с разрабами. И с точки зрения написанного кода, и бизнес-показателей, внедрения новых фич и тп. Не говоря уже про даш-борды и алерты для группы онлайн-мониторинга 24х7.
"Можно придумать защиту от дурака, но только неизобретательного" ИТ-шная мудрость
А почему VIP-ам ограничивалась информация на экране?
Если я правильно понимаю, проверку на VIP вообще не нужно было делать, а просто принимать эту информацию с бекенда. Либо во время разработки логику конструктора изменить, чтобы обычным пользователям одна страница отправлялась, а випам чуть-чуть другая.
а как код ревью это пропустило?
А что за база была? В mysql даже обычный show processlist дает информацию для размышления. Если успеть его выполнить до полного зависания ).
Не очень ясны графики статистики, тот же Order , показывает около 350 заказов в минуту , тоесть в час 350*30*2= 21000 обрабатывается 21к заказов? бредово звучит.
Хотя потом вы пишите "В обычный будний вечер (не пик) на сайте около 20 заказов в минуту, на мобилке — около 200. "
del
Усложнение систем идет такими темпами, что скоро настанет момент, когда понять проблему и устранить ее будет в принципе невозможно и останется только "попробовать перезагрузить виндовс" ))
Часто вижу похожие подходы к анализу проблемы. Обычно начинается паника и идет клич от руководства найти проблему. Создается такой режим ожидания. В этом режиме нередко кто-то бросает случайную идею и на неё все разом набрасываются. Обычно никто не задает вопросов может ли эта идея реально быть причиной, стоит ли найти подтверждение вначале. Иногда я видел, что на такие идеи могло уходить до пары часов. Попробовали - не получилось. Дальше опять режим ожидания новой случайной идеи.
Самое интересное, когда в этом случае инцидент сам собой решается (например, какая-то пиковая нагрузка проходит) и образуется такая непонятность, то ли решили проблему, то ли она сама.
Причем понятно почему это происходит. Приложения (как open source, так и свои) не очень часто выдают реальную ошибку. К примеру, на любую проблему с базой данных не в режиме отладки WordPress выводит что-то похожее на "something is wrong with the database". Плюс, часто начинает сбоить все и везде и ошибки лезут с разных сторон. Нередко ошибки также спрятаны на уровне warning и т.п. Действительно, найти в этом круге сообщения об ошибках, которые являются коренной проблемой непросто.
Хорошее замечание.
Я обычно приходя на инциденты, пытаюсь смотреть туда, куда другие еще не смотрят и искать новые гипотезы... Если то, что делают другие - верный путь, они найдут решение и без меня, а если нет, есть шанс найти реальную проблему.
По поводу мониторинга, метрик у нас много, от ошибок в логах, до "Percona Monitoring and Management", которые позволяют обычно докопаться до сути, но вот такие крупные инциденты затрагивают очень много подсистем и искать причинно-следственные связи становится довольно сложно.
Это была обычная пятница.
У нас в МТС (да, не IT отдел) есть негласное правило не накатывать изменения на сеть в пятницу. Потому что пятница.. это пятница. Пока новые параметры будут загружены на сеть, пока пройдет несколько часов для сбора статистики, а еще нужно время для ее анализа. В итоге в лучшем случае проблема будет найдена на последних часах рабочего дня, а в худшем - в понедельник утром. Имхо в пятницу можно заняться множеством других дел, и не накатывать свежие релизы.
такие правила обычно пишутся кровью красными глазами тех кто потом это чинит в пятничный вечер-субботу-воскресенье. есть даже обычно жёсткие правила о запрете установок менее чем за 2-3 часа до конца рабочего дня вне зависимости от дня недели
Да какая разница? Инцидент мог бы произойти и в любой другой день. Понедельник, вторник или в среду. Точно также утром бы все обвалилось. Если просто не лить в пятницу, чтобы не чинить все выходные, это значит, что всё обвалился допустим в понедельник, а чинить будут весь вторник и всю среду, когда всем надо работу работать...
Конкретно правило "не лить в пятницу" никак бы не спасло от этого инцидента.
Сегодня мы не льем в пятницу. Завтра не заливаем за 2 недели до и 2 недели после нового года. После завтра запрещено заливать в полнолуние или если Меркурий в ретрограде...
простой пример - в пятницу разработчик запланировал отдохнуть и когда ему позвонили в 20.00 с вопросом по его функционалу - уже не отвечает.
запрет в пятницу, перед праздниками - привязан не к бизнес логике а к людям сопровождающим систему.
ПС. поднимать в понедельник-вторник гораздо веселее и продуктивнее когда команда отдохнула на выходных, чем в пятницу-субботу когда команда думает об остывшей пицце а не о работе.
простой пример - в пятницу разработчик запланировал отдохнуть и когда ему позвонили в 20.00 с вопросом по его функционалу - уже не отвечает.
Поменяйте пятницу на четверг. Разработчик также может будет недоступен, ничего не поменялось:
в четверг разработчик запланировал отдохнуть и когда ему позвонили в 20.00 с вопросом по его функционалу - уже не отвечает
Так то оно так, только 2 нюанса:
В четверг шансы на подобный отдых намного меньше. Тем более меньше ситуаций "Я уже выехал из города на все выходные. Связи нет и не будет.".
Даже если подобное случилось, разработчик будет на связи уже в пятницу (через считанные часы), а не через два дня, в понедельник.
Так что правило "не лить обновления в пятницу" достаточно популярно. Как и "не обновляться перед длинными выходными" по тем же причинам.
Хотя в данном случае оно бы не помогло, с этим я тоже полностью согласен. Хотя бы потому, что в данном случае, пятница вечер - это пик нагрузки. И не говоря уже о том, что с обновлением инцидент не связан.
Хотя в данном случае оно бы не помогло
Я именно про это и хотел сказать. Конечно деплоиться утром лучше, чем вечером. И что в будний день лучше чем в выходной. Но конкретно в этой истории из статьи, постулат "Никогда не деплоиться в пятницу" вообще как будто приплетён сюда по чистому совпадению, что у Dodo сбой произошел тоже в пятницу. If (today() == "Пятница") then DoNotDeploy();
Как мы видим в статье, сбой обнаружили ещё днём, в рабочее время, когда все были онлайн и на работе. Должны были (в теории) решить за вполне ещё рабочее время. В итоге решили на 3 часа позже конца рабочего дня.
Заменить пятницу на любой другой день недели - события бы произошли абсолютно те же самые, постулат "не деплоиться в пятницу" ничего бы не изменил. При этом я отвечал на комментарий выше, где советовалось просто "не деплоиться в пятницу", как будто это помогло бы.
Всё так. Но выручка сети пиццерий в пятницу в разы больше выручки в другие будние дни. Случись эта неприятность во вторник - потеряли бы миллионы рублей. Но случилась она в пятницу и потери измерялись десятками миллионов.
Стоит ли изменение релизной политики этих денег? Спросите у автора.
К слову, да, во многих компаниях релизы не делаются ни по пятницам, ни в последние несколько дней перед праздниками.
Какая разница когда там релиз? Упало-то от нагрузки, а не от релиза. Баг мог хоть полгода ждать пока маркетологи не разошлют свои пуши в одну из пятниц...
выручка сети пиццерий в пятницу в разы больше выручки в другие будние дни. Случись эта неприятность во вторник - потеряли бы миллионы рублей. Но случилась она в пятницу и потери измерялись десятками миллионов.
Стоп. Запрет на релизы в пятницу ведь связаны с тем, что люди обычно в пятницу уходят по раньше, и никого не найти все выходные.
Или запрет на релизы по пятницам связаны всё-же с тем, что по пятницам выручка больше?
По моему, вы натягиваете одну причину нерелизов на другую, и это получается чистым совпадением. Представьте, что день максимальной выручки у них был бы по средам. И по средам нет запретов на релиз. Точно также потеряли бы десятки миллионов. И запреты на релизы по пятницам никак бы не помог.
Ещё раз: Запреты на релизы по пятницам проводятся по совершенно другим причинам, и защищает абсолютно от других причин и последствий (когда никого нет на связи, ни до кого не дозвониться, и от этого чинят все выходные). Как мы видим по статье, ни одна из этих причин не наступила - все сотрудники были на связи, и были доступны, починили в тот же день. Единственное совпадение было то, что это была тоже пятница.
У нас запреты на релизы в пятницу и за определенное время до всплеска трафика (НГ, гендерные праздники и т. п.) связаны именно с тем, что буде баг вылезет в обычный день - это не так страшно, как если он вылезет в прайм-тайм, потому что авария в прайм-тайм приносит больше потерь, как финансовых, так и репутационных, что еще хуже.
В конкретно обсуждаемой ситуации да, проблема была не в релизе. Но могла же быть и в релизе. Зачем подкладывать дополнительных граблей?
в данном случае в пятницу лучше не выкатывать по причине того что это пик продаж всей недели, а не потому что разработчик забухал :)
А из взрослых дома есть кто-нибудь?
Очень долго читал. И нашёл ответ на ваши проблемы в другой статье хабра:
https://habr.com/ru/post/709328/
Извините за обидную прямоту.
Но 64 ядра... Kubernetes...
Сайт Додо из 20 товаров. 220 заказов в МИНУТУ, Карл!
А рекламные пуши нормальные люди вообще выделяют на отдельное железо. И они не должны мешать сервисной части бизнеса.
Это не дерево изделия "Самолёт" из 5000000 запчастей, каждая из которых имеет габариты, размер, число зубьев на венце, напряжение питания и т.д. и. т.п. И такие базы крутятся на обычном i7 процессоре с 64 Гб ОЗУ. ОЗУ - характеристика для кеширования реально критическая в сервере. А сколько там ядер 64 или 564 - так забудьте про микросервисы (как написано здесь https://habr.com/ru/post/709328)!
Соотв, круг сузился до изменения релиза (кто-то неоптимальный запрос добавил) и/или изменения самих настроек СУБД.
Скейлинг ядер для sql это как надежда на соломинку, чаще всего ведь упирается все в disk-intensive, а вовсе не в cpu-intensive (по крайней мере в моем опыте было так всегда). И манипуляции очередью и скоростью приема в нее — примерно такая же надежда — есть относительно небольшая вероятность, что запросы ожидают друг друга и sql сервер их выполнит по очереди намного хуже, чем тоже самое сделаете вы, принудительно подавая по одному.
И в блокировки на уровне бд. Порой даже неявные.
Имхо, это следствие подхода "разработчики и разрабатывают, и занимаются эксплуатацией". По моим наблюдениям, склад характера, жизненный и рабочий опыт и прочие софтскиллы у разрабов сильно отличаются от тех, что нужны в эксплуатации.
Я уже не говорю о том, что быть одновременно и ДБА, хорошо погруженным во внутренюю кухню СУБД, и понимать взаимодействие софта с ОС и железом, и быть хорошим разработчиком, умеющим и в архитектуру, и в оптимизацию, и т. п. - весьма сложно, даже чисто по временнЫм затратам.
Нам надо изменить архитектуру. Нужен сервис, который бы заранее стоил готовое меню, выкладывал бы его в JSON как статический контент, а дальше источники приёма заказа уже получали бы меню как файл. Тогда мы бы не зависели от кешей, тяжелые операции построения меню были бы отделены от критических операций получения меню.
Но это тоже вариант кеша (как неких предрассчитанных данных, уводящих БД от нормальных форм), поэтому никуда вы не ушли. Это кеш с хранением между перезапусками и инвалидацией при записи. То, что вы хотите сделать — можно, например, в битриксе подсмотреть. Называется «управляемый кеш».
Этот подход хорошо работает, потому что число операций записи обычно на порядки меньше операций чтения. Соотв, секунда проигранная при записи вполне может давать профит в 100 секундах при чтениях. Более того, чаще всего нормирование времени на операции записи мягче, т.к. это внутренний сотрудник пишет — он может подождать +1 секунду, а вот клиент может и уйти.
Из того что ещё можно сделать "малой кровью" - например ReadOnly реплика БД, на которую "заварачивать" часть запросов - то же получение меню, может даже большинство GET запросов.
У нас у монолита раньше было 3 сервера - Мастер, Read-реплика как раз для таких кейсов + AHD реплика для жирных отчетов.
Через какое то время отпилы и оптимизации довели уровень нагрузки на read-реплику упал до минимальных значений и ее убрали, завернув эти запросы в мастер.
Финально по итогам последних падений мы снова ее вернули, вероятно временно.
В длинном списке «Долгосрочные системные решения» не увидел одного из самых главных пунктов:
- Периодически проверять пиковую нагрузку на проде. Как только она приблизится к нагрузке на тестовом стенде для нагрузочного тестирования, масштабировать стенд.
Описываем наш путь во время этого инцидента:
Накинем ресурсов и все полетит?
Рассылка от маркетинга пушей в самый пик — может, дело в этом?
Наверняка это DDoS.
Или плохой релиз, вышедший недавно?
Короче, это что-то с базой.
У вас же мониторинг по идее должен быть настроен и не простейший на дефолтных дашбордах графаны, а что-то более серьёзное. Если у вас есть подозрение на нехватку ресурсов, система мониторинга и алертинга должна должна сообщить об этом. Если идёт атака, это можно увидеть в мониторинге. Не хватает возможностей собственного мониторинга, можете глянуть дополнительно в Azure. Короче, это в вас что-то сделано с мониторингом из рук вон плохо.
Это была обычная пятница
у собравшихся появляется идея посмотреть, что же выходило в этот день на продакшен из обновлений
Ну ту вы сами себе злобные буратины. Кто же в пятницу заливает измнения, тем более на прод? Это же табу! Только резервные копирование и прочая безопасная активность.
Вообще скадывается впечатление, что архитектура застряла во вемена MVP и только росла вертикальным масштабированием железных ресурсов, а мониторинг в зачаточном состоянии.
Кто же в пятницу заливает измнения, тем более на прод? Это же табу!
А если бы они заливали его в четверг, эффект был бы другим?
Очень немаловероятно. Некоторые в пятницу уже подустали за неделю и имеют меньший фокус внимания, у кого-то планы на вечер и они спешат сделать работу быстрее, чтобы не задерживаться, а есть те, которые всеми мыслями и одной ногой в субботе. Это тот самый человеческий фактор.
Кроме этого для пятницы характерен (не всегда и не для всех, но всё же) больший наплыв посетителей (offline or online) что вызывает большую нагрузку на сервисы. Поиск ошибки и её осправление, когда твои сервисы хорошенько нагружены занятие на самое простое. Не замечали интересную вещь? Apple релизит по вторникам.
Потери были бы другими.
За prometheus обидно, что ж его сразу выкидывать-то.. а про bulkheads не понятно - почему про них так много, но нет хотя бы вкратце, как они у вас используются. как глобальный лимит запросов на LF? если да, и у LF есть известный жестко заданный лимит запросов к нему, есть ли у него SLA? и у остальных сервисов, получается, заданных лимитов нет, и наверно SLA нет, потому что нагрузку не считали по-честному?
Про Bulkhead, помнится, они рассказывали вот в этом посте
Читаю, и сразу на будущее хочется прикрутить «Graceful Degradation» — возможность контролируемо срезать нагрузку. В духе «упёрлись в базу» — сразу отключили «Воронеж» (в смысле самый неэффективный по выручке на один запрос регион/ресторан+источник (источник — мобилка или сайт). Потом — следующий, и так пока поднимется.
Я, если честно, от dodo в плане инфраструктуры ожидал много большего. Одна база, которую в итоге положили довольно тривиальным образом. Никакого смысла нет в том, что настройки были неправильные. Вы всегда где-нибудь продолбаетесь с настройками, что-то случится с диском, в конце концов что-то случится с серваком. DBA тут поможет отсрочить неизбежное. Не иметь реплики базы - это вообще нечто странное в моей картине мира.
Весь продолб в изначальной архитектуре, которая спроектирована так, чтобы всё влияло на всё. Я в страшном сне представить не могу, что рассылка пушей может положить всю систему. Какого чёрта вообще? Есть же OLAP-хранилища, ну в конце концов под это можно просто отдельную базу использовать даже с базовыми настройками. Шардов на базе нет (что в случае потока заказов (а это прям TS-данные) довольно очевидное решение), ну или TSDB в конце концов. Сами же берёте неоптимальные решения, в итоге получается жёсткий непродакшн-реди.
Рад, что вы дошли до меню в json, но камон, на дворе 2023 год, этому довольно устоявшемуся решению уже лет 10. Есть сильно более эффективные возможности.
У вас упал прометеус вместе с продом - это вообще просто прекрасно. Ребят, прометеус в 10 раз больше данных прекрасно переваривает, это вы натворили там дичь полную.
И вам очень правильно насыпают. 4 заказа в секунду - и вам не хватает 64 ядер на базе? Вы блин, шутите что ль? На кого это рассчитано вообще?
Я не считаю ваш пост-мортен адекватным. Это явное сглаживание ситуации и отсутствие поиска реальных ошибок.
Часто в проектах, выросших из маленьких, а не разработанных с нуля под хайлоад, так и бывает: ресурсов на то чтобы переделать "правильно" нет, разработчики пилят для бизнеса новые фичи, которые должны приносить больше денег. Изменить архитектуру невозможно, потому что на это нет ни ресурсов ни желания - все опасаются сломать поток денег. И все серьезные сдвиги в архитектуре происходят только по итогам факапов. А пока факап не случился - бывает и сессии пользователей хранят в базе mysql, постепенно доводя муську до инстанса в 256 ядер с терабайтом ОЗУ.
Бизнес выделит ресурсы на "переделать правильно" когда почувствует, что теряет деньги.
Я в страшном сне представить не могу, что рассылка пушей может положить всю систему. Какого чёрта вообще?
Любая рекламная компания, включая пуши, способна положить систему независимо от архитектуры.
Вообще нет. Очень зависит от архитектуры. Есть куча примеров когда архитектура делается правильно, с расчётом на скачкообразную нагрузку и переваривает огромные маркетинговые активности. Как вы думаете живут бизнесы которые покупают рекламу во время чемпионатов или когда запускаются массовые рекламные кампании.
Пиковые нагрузки архитектурно фиг решишь (если сложить всё в очередь и разгребать её 4 часа не вариант).
Можно сделать такую систему, которая бы хоть как-то работала при нехватке ресурсов вместо того чтобы падать полностью — но проблему в целом можно решить только достаточными ресурсами и отсутствием ошибок вроде этого ихнего GetMenu
Сгладишь, ещё как. Есть куча примеров когда можно разменять throughput на latency и при нагрузке начать подтормаживать при этом кратно увеличив способность переваривать запросы. В большинстве обычных систем, чем больше нагрузка тем меньше производительность, но это не всегда так, есть варианты и наоборот. Из самого простого и на слуху это вставка в Clickhouse, когда они старгетились на throughput и при росте нагрузки можно копить данные в кеширующих стораджах и вставлять большими пачками, в итоге затраты на вставку строки упадут (https://clickhouse.com/docs/ru/introduction/performance/). И таких примеров много, сервер вставший в 100% CPU тоже на самом деле может быть более эффективен, если он написан правильно и вычитывает из каждого сокета больше данных за раз. Это уже достаточно сложные вопросы, но системы которые не деградируют под нагрузкой существуют. Это сложно, это дорого, это не всегда получается, это иногда с грохотом падает, но это бывает.
Но все равно стоит учитывать, что у оптимизации потолок близко и, как правило, она производится с убывающей эффективностью — каждый следующий шаг даст все меньше прироста. А у наращивания железа почти не существует :)
По первой части согласен, но это специально организовывать надо, и кстати микросервисы тут как раз вредят, не удивлюсь если каждый микросервис будет ходить в базу и что-то запрашивать.
А по второй части как раз всё сложно, если где-то закралась нелинейные затраты на обработку клиента от их количества(всего в базе) то масштабирование не поможет в принципе. Поможет только выяснение почему это происходит и замена функционала, иногда с отказом от каких-то бизнес требований. Тогда достаточно долго можно будет переваривать значительные объёмы клиентов на скромном железе. Короче баланс нужен. Пытыться вывезти всё на одном серваке не нужно, но и десятки серваков для обработки десятка запросов в секунду тоже не нужно.
добрый день, я может что то упустил, заранее извиняюсь, но не очень понял, если ошибка в каскадной нагрузке на бд при получении меню из за большого количества пушей, как откат к предыдущей версии помог решить эту проблему?
Ребят, что-то явно не так. На таком железе надо обрабатывать ну если не тысячи запросов в секунду то сотни. Что-то где-то совсем не так. Или очень много бесполезных запросов, когда можно было сделать один, или где-то все данные денормализованы до пятой нормальной формы и в базе джоин на джоине джоином погоняет. Или индексы не там где надо, или где-то кто-то выбирает всю базу чтобы посчитать количество(случай из практики, через ORM) Очень часто академически красивые подходы и производительность радикально расходятся на практике. Если вы хотите ускориться то нужно строить полную карту того что происходит от того, как пользователь открыл приложение, до того какие запросы упали в базу. Всё, Днс, домены, https с его keep-alive, какой там сервер, куда и что он положил, через все медиаторы и балансировщики до EXPLAIN ANALYZE на базе. А вдруг у вас постоянные реконнекты к базе, или ещё какая-нибудь ересь. Во сколько потоков вы в неё идёте? И глазами смотреть, нет ли там лишнего. Именно "вдоль" процесса, а не "сбоку". Сбоку это смотреть на массу, типа через этот серевер лезет столько и таких запросов в секунду. Таким образом нельзя сложить целостную картину. "Водль" это проследить путь всех данных одного конкретного пользовательского действия типа открыл приложуху, выбрал заказ, заказал, оплатил, получил уведомления, принял заказ, оставил отзыв. Вот берёте это всё, бьёте на этапы и в ниточку выкладываете всё что произошло, путь в глубину и назад, как прошли данные. Подозреваю что собрав это в одну карту вы ооочень удивитесь сколько там всего лишнего, и какие вещи идут чудовищно неэффективно. Жопное чувство говорит, что что-то идёт сильно не так, радикально, на порядки. Вот пример https://habr.com/ru/post/580066/comments/#comment_23523460 где конечно всё проще и речь просто про более простые запросы, но человек смог осознать что те цифры к которым он привык и которые он воспринимает нормально, отличаются от нормальных на несколько порядков.
Начните думать о миллионах клиентов которые будут делать в тысячу раз больше запросов и попробуйте делать инфраструктуру из этого расчёта, быстро выяснится что просто залить железом не получится но можно придумать как справиться. Подумайте как работают онлайн игры, сколько там игровых заказов в игровых пиццериях печётся? Миллионы. И там есть и таргетинг, и все монетизационные метрики и персональные офферы, всё тоже самое, только на миллионы заказов за вечер.
Заказы в секунду/минуту != запросы в секунду/минуту.
Вот прямо сейчас графана говорит о 5500 запросов в секунду при 200 заказах в минуту.
Кроме получаения меню клиентами и приемом заказа, базой пользуются пиццерии, чтобы видеть эти заказы, менять их статус, списывать ингредиенты, следить за закончившимися, чтобы останавливать продажи необходимых продуктов, отправлять курьеров, и много чего еще.
В разделе про DDOS есть цифры, там говориться, что норма 11000 rpm на сайт, при том что там очень маленький процент заказов, как пример только на мобильное апи сейчас при 200 заказах в минуту около 500rps.
5500 запросов в секунду при 200 заказах в минуту.
5500 запросов в секунду это 330 тысяч запросов в минуту при 200 заказах в минуту, т.е. 1650 запросов на заказ, ничего не смущает? Т.е. ваша инфраструктура построена так, что в целом по компании, чтобы продать одну пиццу нужно 1650 запросов. Нет, я понимаю что не все клиенты делают заказ, но это очень странно. Ну и просто запросы вида раздача статики и картинок они к вопросу отношения не имеют, у вас легла база на приёмке заказов, на очень маленькой интенсивности этих заказов для этой базы. Я хочу сказать что такое железо должно нормально переваривать 200 заказов в секунду. Может я конечно чего-то не понимаю, во выглядит оочень всё это странно.
Статика идет с cdn и не входит в эти цифры, это запросы на nginx.
И я же говорю, что на этой базе не только прием заказа. В каждой пиццерии открыты экраны менеджеров, где они смотрят метрики, заказы, двигают пиццы по трекеру, передают курьерам, Dodo IS это не только принять заказ.
Да и сам прием заказа с просчетом акций, у которых много условий и сложных триггеров может быть, которые нужно на каждое изменение корзины прогонять, тоже не просто получить меню..
Безусловно можно на этом железе сильно ускориться, но это не малые вложения в разработку, у бизнеса возникнут вопросы, если мы на полгодика перестанем выпускать новые фичи, но сократим расходы на инфру в пару раз.
Многие низковисящие фрукты мы уже собрали, каждое последующее улучшение дает меньший результат при тех же вложениях, тут уже нужно найти баланс, который всех устроит.
т.е. это 1650 динамических запросов которые в базу лезут или скрипты крутят? На один заказ. Да хоть коневеер из 500 стадий и это не должно столько занимать. Я понимаю кухня всё такое, курьеры. В своё время я видел как несколько лет подряд в веб версии facebook мессенджер хреначио по 2 запроса в секунду постоянно с целью проверит, а нет ли новых сообщений. Вы уже влипаете в то, что не понимаете что происходит с системой и как её оживить. Жесть. Ребят, я много чего видел, но чтобы сохранить контроль в будущем нужно на порядки снижать количество запросов. Что-то не так с организацией данных и процессов.
У нас 882 пиццерии.
В каждой открыты планшеты(Раскатка, Начинение, Печь, Упаковка, Выдача, Мотивация, Доставка).
Одна или более кассы ресторана.
Экран с метриками у менеджера смены.
У каждого курьера мобильное приложение.
Интерфейсы для проведения ревизий и заготовок.
(это кроме клиенских запросов c сайта и мобильного приложения и я еще не все перечислил)
Естественно не все запросу лезут в базу(много чего за кэшами) + это запросы в сервисы, у которых разные базы(микросервисы, все дела)
Если это так, то подумайте о push-модели. Когда каждое из устройств подписывается на изменения ровно того, что ему сейчас нужно. И только когда к нему приходят события изменения этого — тогда и переспрашивает у СУБД (а может и вообще не переспрашивать, если все полезные данные можно передать с событием).
Непонятно, как у вас сочетается "много чего за кэшами" и "1650 запросов на один заказ".
Думаю, если бы вы расписали статистику как:
сценарий с оформлением заказа - K запросов,
сценарии без оформления заказа ("просмотры") - N1-N2 запросов, в среднем M запросов,
заказов в минуту столько-то,
просмотров в минуту столько-то,
то было бы нагляднее.
меня всё ещё не отпускает, даже если каждый слайс колбасы в пепперони списывать отдельным запросом, я не понимаю как столько получить. Или у вас конверсия в покупку с приложения 1%? Я думаю значительно значительно больше. Короче очень не понятно зачем и как можно нагенерить столько осмысленных динамических запросов.
А можно на эти метрики посмотреть ночью. У меня получилось 18 тысяч запросов на один заказ...
Dodo IS - это не только прием закаказа. Это автоматизация всей деятельности пиццерии, и даже если заказы не принимаются, там есть что поделать (провести ревизии, принять поставки, выгрузить данные в бухгалтерию и т.д.)
Я всё это понимаю, ревизии списания, бухгалтерия, уверен что и учёт сроков хранения и поставщики и всякие температуры в холодильниках, и охрана труда и рабочее время, и даже вполне возможно зарядка курьерских самокатов. Я всё это понимаю и понимал с самого начала. Это не укладывается в мою голову. Ни микросервисы, ни масштабирование никак не позволят мне уместить в голову такое количество запросов, со всем экранами в 880 пиццериях. Я понимаю что там много информационных потоков, но это не отменяет того что, по моим кожножопным ощущениям перерасход ресурсов происходит в сотни раз. Не в два раза, а в сотни. 18 тысяч запросов на один заказ это что-то за гранью моего понимания вообще, мы в каких-то разных мирах крутимся. В наши игры играют миллионы пользователей ежедневно со всего глобуса всегда, и нет, нигде никаких подобных вещей я не видел. И в большинстве этих игр это полноценная онлайн игра, это клики каждые несколько секунд, а у ботоводов и то чаще. Всё это обрабатывается, всё это анализируется, всё это работает. Там крутятся персонифицированные офферы, локализация на десятки языков, динамическая подстановка контента для разных регионов и языков, чаты, викторины, игры, да миллион всего. И да, там где надо, мы держим стейт игрока в памяти, имеем постоянный коннект и базу пинаем раз в тысячелетие. Я видел разные бизнесы, кинотеатры, вендинг, финтех с тонной графиков. Но то о чём вы говорите я понять ну никак вообще не могу.
Вы зря привязались к количеству заказов.
Если разбить запросы на разные задачи и считать «количество запросов на задачу» - будет более адекватное число.
Это как взять современный телефон и посчитать, сколько времени мы используем относительно количества звонков в день. Получится, что на то, чтобы совершить один звонок длительностю в 5 минут у нас уходит 2-8 часов.
Просто неверный вариант подсчёта
Они делают пиццу. Если бы чтобы звонить мне нужно было торчать в телефоне 2 часа я бы его выкинул. В телефоне торчат не для того чтобы звонить. Пиццерия же всё делает чтобы делать и продавать пиццу. Принимает товар чтобы делать пиццу, блюдёт сроки, чтобы делать пиццу, показывает меню чтобы продавать пиццу, принимает заказ чтобы продавать пиццу. Да это бизнес процесс, да он состоит из сотен стадий. Да он большой и сложный. И да, он выглядит несуразно избыточным, когда на то, чтобы обрабатывать несколько пицц в секунду тратится столько серверных мощностей.
Я понимаю вашу логику, но она не применима к этому случаю.
Это как сказать:
«Мне нужен телефон чтобы звонить и пользоваться интернетом. Почему у него 100500 кнопочек в настройках?»
Да, было бы круто, если бы запросов было бы меньше. Но сильно меньше на самом деле не получится. Раза в 3-10 меньше - да, наверное можно. Только.. нужно ли? Что за самоцель «сделать меньше запросов». Цели другие важны: сделать пользователю удобно.
И тому, кто заказывает, и тому кто готовит, и всем остальным пользователям.
А как так получилось что вот тут https://dodo.dev/manager#stack можно выиграть в bullshit bingo от количества новомодных технологий, сайт весь выглядит весь из себя "не как все", а в разделе вакансий https://dodo.dev/manager#jobs все кроме одной ведут на устаревшие вакансии? И список там и на huntflow отличается. Зачем кто-то вложил время, деньги и душу в этот сайт в 2021, если он застыл без поддержки и обновления?
Релиз в пятницу - к хлопотным выходным. Вроде 100 лет уже этой народной мудрости, не?
19:21 дежурная смена принимает решение остановить реактор, пиццы перестают выпекаться и медленно остывают
Мне кажется, основная проблема — в использовании SQL-базы (тем более, MySQL) на интерактивном трафике. Можно очень долго заниматься оптимизациями, но глобально это не изменит того факта, что SQL-базы тяжело масштабируются в целом.
Нам надо изменить архитектуру. Нужен сервис, который бы заранее строил готовое меню, выкладывал бы его в JSON как статический контент, а дальше источники приёма заказа уже получали бы меню как файл. Тогда мы бы не зависели от кешей, тяжелые операции построения меню были бы отделены от критических операций получения меню.
Это один из вариантов, но файлики — это может быть в целом не очень удобно, и с ними бывают свои приколы. Одна из стандартных архитектур в таком случае — это SQL-база, которая служит в роли ground truth, и NoSQL-базы, которые служат собственно интерфейсом к данным. Может быть некий батч-процесс, запускаемый очень часто (например, несколько раз в минуту), который вытягивает нужные данные из SQL-базы, раскладывает правильным образом по NoSQL-базам, и те в свою очередь уже занимаются обслуживанием запросов. Это существенно более гибко, чем файлики, потому что размер файлика со временем может начать неконтролируемо расти, да и просто раскладывать его по куче машин — проблематично и чревато всякого рода проблемами типа "на части машин остался старый вариант файла, а никто не заметил".
На самом деле, вместо прослойки из NoSQL-баз может быть простой сервис, который собирает in-memory версию (тот самый "json") и отдаёт его напрямую из памяти. В части случаев это удобнее. Такой сервис асинхронным background-тредом ходит в SQL-базу и регулярно обновляет свой стейт, а наружу торчит интерфейс, который на каждый запрос делает несколько хеш-лукапов в памяти — это тоже очень быстро, бесконечно горизонтально масштабируется, ну и в этом сервисе можно писать любую бизнес-логику.
Самое главное — никаких, никаких, никогда никаких синхронных запросов в SQL-базу на интерактивном трафике.
Я так понял причину так и не нашли и воспроизвести поведение не удалось?
Жуть как не люблю такие вещи когда вроде чета сделал но не точно, сидишь потом постоянно как на бочке с порохом.
именно одной причины не было. если прям супер коротко, то:
система не стартовала, потому что кэши базы не могли все вгрузить
рассылка пушей была первопричиной, начавшей все падение
наша архитектура с одной базой раньше держала пиковые нагрузки, а к моменту падения перестала держать. Додо растет, заказов в пики прилетает все больше. мы проиграли гонку по распилу монолита в части приема заказа
Спасибо за интересный пост-мортем!
>Не хватает поэтапного заведения трафика на приложения (1, 10, 50, 100%), чтобы кеши всех нижележащих сервисов успели прогрузиться."
Пара комментов про этот action item из опыта починки аналогичных инцидентов:
лучше иметь рубильник для возврата нагрузки произвольной плавности от 0 до 100%. Переход с 50% до 100% легко может свалить систему заново.
в зависимости от специфики бизнеса возможно рубильник нужен не только по проценту, но и как-то более умно
выглядит, что этот action item важнее всех остальных вместе взятых, тк он самый обобщаемый на произвольные инциденты. В инцидент-менеджменте важна фокусировка. На практике, когда много action items, то они как-то паралеллятся, и в итоге может оказаться, что из-за этого самый важный action item сделан только через месяц.
довольно много тонкостей как делать этот рубильник надежно: по запросам / пользователям / заказам; делать ли его в форме rps лимита или concurrency лимита (link); если concurrency то на каком уровне - все in progress заказы или еще как-то; если по запросам то как решать проблемы этого подхода; и др.
кэши это лишь частный случай. Могут быть очереди запросов.
советую изучить теорию про metastable failure state (там внутри также крутая pdf-ка), она довольно хорошо структурирует произошедшее и объясняет почему этот action item самый ключевой. Например, из теории становится понятным почему ребут системы после отката версии помог, а следующее при починке только ухудшило ситуацию:
увеличение размера очереди запросов (BulkheadQueue), лучше наоборот уменьшать
увеличение лимита на concurrency (BulkheadConcurrency) в 7 раз, лучше наоборот уменьшать
апскейл сервисов перед базой без апскейла базы перед этим. Лучше опять таки наоборот - даунскейлить сервис, чтобы базе полегчало скорее
На уровне ощущений и интуиции, кажется что технический руководитель (CTO или Head of Engineering) всего этого вырос из разработки (шёл по пути как developer). Так ли это?
Спасибо за разбор. Читать было увлекательно.
Но почти сразу начали возникать вопросики :-)
Не могли бы вы поделиться уточнениями:
По первому алерту видно что началось все с БД.
На этом этапе разве не увидили в мониторинге что с БД явно что то не то?
Разве не было в cookbook минимальных указаний в какие метрики сломтреть/что делать с БД в этом случае?У вас нет метрик среднего времени и количество обработанных запросов на backend?
Если бы тормозила БД/сервисы то в этих метриках наверное можно было бы увидеть что проблема не в DDOS а в каком то узком горлошке внутри.Неужели в логах не было кикаких ошибок?
Я прям не могу поверить что приложения нигде не чихали и все проглатывали и до последнего момента не было понятно что БД не тянет.Я правильно понял что основная БД одна без реплик?
Как тогда происходит увеличение CPU? Все останавливается, DODO IS встает колом, и через пару минут начинает оживать?
А часто такое делаете? Это обкатаный этап?Я правильно понял что сначала накинули экземплятров приложений и следом перезагрузили БД?
Просто звутит как выстрелить себе в ногу... увеличить нагрузку на БД (которая вроде как и так вышла за алерт) и потом еще ее перезапустить...
Тут много тем.
Мониторинг был, но был точно недостаточен. Например, текущий используемый размер кэша базы не использовали.
В самом начале была перезагрузка базы. И была она именно потому, что мы туда ресурсов накидали. Дальше по нашему мониторингу в базе, мы не могли задетектить детально проблемы.
Рестарт базы нам точно не помог. Мы фактически задестроили систему.
Я, конечно, не настоящий сварщик, и статью случайно прочел, но все это для меня выглядит примерно так: "оно не работает, мы видим только главные цифры, по ним что-то понять невозможно". И комменты, например, oldDBA, в том же ключе - "главное, не понимали причину". В вашей области что, о возможности возникновения проблем вообще мало кто думает? И какого-то инструмента, где бы всегда были видны главные и второстепенные (а в случае необходимости любые другие цифры и сведения) вообще нет?
Тут такое дело - просто кто-то в этой компании решил, что надо писать на хабр. Возможно даже гендир, и возможно даже неспроста, а чтобы как-то улучшить ситуацию, но забыл при этом вписать в календарь, что надо еще комментарии с хабра потом самому сесть почитать.
Теперь мы все можем видеть эти тлен и безнадегу. Не везде конечно, но во многих остальных компаниях все примерно также раздолбайски, но они об этом просто не пишут.
Ребята, спасибо вам за статью. Это многим даст понять, что ошибаются все и важнее не заниматься охотой на ведьм, а делать вывод.
Но сказать в первую очередь я хотел о выводах относительного нагрузочных тестов и практик перфоманса. У меня тут жирный опыт и коротко могу сказать вот о чем:
привлекать разработку к перформанс тестам это полезно, часто даже интересно самой разработке, а главное это приносит пользу. но сильно зависит от вовлечённости
вбухивать кучу денег в перф инженеров, пытаться держать окружение для перф тестов 1в1 как прод и делать "суперреалистичные" нагрузочные тесты - миф. прод такой один и тоже самое сделать не выйдет, суперреалистичные тесты бесконечно дорогие - вы придете к тому что будете трейдоффить относительно параметризации и скорости тестирования, например, ну а куча перф инженеров должны будут сначала как-то сделать единый фреймворк и потом уже что-то тестить с каким-то качеством тестов. вот у меня есть статья как раз про подходы https://habr.com/ru/company/oleg-bunin/blog/682746/
я бы на вашем месте выстраивал фреймворки для перформанс тестирования продакшена. теневые инстансты, зеркалирование траффика, грейсфул деградейшн. и тут куча бонусов, чтобы тестировать прод надо сделать его отказоустойчивым, а трафик управляемым - это раз. если вы боитесь падений вы делаете фолбэки и фичатоглы - это два. прод есть прод и его не надо пытаться повторить со всеми его сайдэффектами и уникальным железом - это три. ну и бонусный трек - испытания на проде дадут вам такой же профит как инцидент, только это будут контролируемые и подготовленные условия (осторожно - тоже можно прилечь на 4 часика, но оно того стоит :))
Хороших стрельб
Я правильно понял, что нагрузка в главную mySQL базу была на чтение? Есть какая-то причина, почему у вас на ней не реализованы master-slaves репликация и чтение с реплик?
В порядке конструктива: не думали сделать отдельные копии инстансов всей системы (все сервисы + бд) для каждого региона или набора пиццерий на более слабом железе? Пиццерия с 0 по 99 на одном инстансе, 100 по 199 на втором и т.д.
Возможно, это могло бы быть сравнительно безболезненным решением в текущих условиях, не требующим больших затрат ни по железу, ни по реусурсам на разработку новых решений. И раскатывать это можно последовательно, начиная с отдельных пиццерий, сохраняя возможность степбэка, на каждом этапе.
Единую аналитику будет несложно собрать, например, сливая из ридонли реплик бд регионов в какую-то удобную СУБД.
О да, одна база данных на весь огромный бизнес... А потом "внезапные" проблемы с падением всего.
Поражает только то, что такая проблема встречается практически в каждой первой компании. Например, на текущей моей работе тоже самое - на огромное количество сервисов - один инстанс постгресса. Уже были случаи, когда кто-то из-за кривых рук одного программиста, на одном из сервисов, не закрывалось соединение с базой, соответственно забивался лимит подключений и из-за ошибки в одном сервисе падала вся система. Хотя в принципе любая надежная система не должна валиться целиком из-за одного программиста или одного сервиса.
Уже больше года говорю, что это надо исправлять - тем более в самом постгрессе под каждый сервис есть отдельная база - и разбить это на несколько инстансов (каждый, по-хорошему, разместив на независимом физическом жестком диске) дело не сложное.
Но, пока вот также, на несколько часов все не упадет - бизнес шевелиться не станет.
Более того, уверен, что в команде Dodo были люди, которые эту проблему озвучивали - но пока все работает таких людей не слушают.
А всё описанное почему происходит?
А потому, что в большинстве случаев, последнее слово не за техническим специалистом, а за менеджером.
Странно только, что ответственность за последствия почему-то на менеджера в этом случае не переключается...
у подхода "отдельный инстанс СУБД под микросервис" есть не только преимущества - например, в изоляции отказов, но и недостатки. Самый жирный недостаток в контексте аптайма - потеря эластичности. Когда базы общие/коммунальные - при всплеске нагрузки у таблицы/базы только одного сервиса - оно нормально прожевывается за счет запаса остальных баз/таблиц. С выделенными СУБД под микросервисы это теряется и мы быстро упираемся в cpu инстанса.
4 часа недоступности: постмортем падения Dodo IS