#aws #aurora #eks #troubleshooting #longread

Лонгрид "история одного бага".
Часть 1 из 3.

Веселье.
Жил был стартап. Сперва на пару человек, но уже в облаке.
Пару сервисов в ECS и база MySQL.
Всем было весело и интересно.
Со временем продукт вырос, у него появилось масса нового: новые микросервисы, postgresql(а потом была удалена), Mongo и так далее. Обычный жизненный цикл любого продукта.
Стартап перешёл из этапа pre-seed в seed.
Уже есть реальные живые пользователи, кто реально платит живые деньги за продукт.
Это привело к тому, что на инфраструктуре появилась нагрузка.
Из одноинстансовой базы был совершён переход на cluster Aurora(mySQL compatible), был добавлен RDS proxy(а я не знаю зачем изначально), а ECS заменён на EKS.
На самом деле много всего было сделано, но выходе в проекте был макросервис(наполовину распиленный монолит) монорепы и десятки микросервсов.
Потом пришла series a и клиентов появилось сильно больше.
Пришла НАГРУЗКА.

Масштабирование
Продукт, не смотря на то, что это макросервис и монорепозиторий, научили в масштабирование.
Сперва было тупое через HPA и ресурсы, затем появилась KEDA и продукт научился в масштабирование по количеству сообщений в SQS или лагу в кафка топике. Стало не хватать нод, добавили автоскейлер (впоследствии заменив на карпентер).
Да и в целом было сделано на 99% масштабирование и кластеризация всего и вся.
Где-то на этом моменте продукт начал получать весьма негативные фидбеки "ЧОТА ТОРМОЗИТ ИНОГДА" и команда впервые задумалась о мониторинге.

Observability, v1.
Была добавлена графана для инфры, прометиус в куб и опенсёрч для логов(вообще не связан с историей).
Помимо всей инфры в кубах, начали мониторить и алертить стандартные метрики всех ресурсов Амзаона.
невероятно обширная работа, от 60 дашбордов, больше 400 панелей в графане по всем ресурсам стандартных графиков.
И.. и это ничего не дало.

Не верю.
Команда ничего не понимала.
Да как так-то? Все метрики есть, дашборды украдены из интернетов, но любой случай "ЧОТА ТОРМОЗИТ ИНОГДА" по метрикам и графикам не видно.
Начали копать дальше, читать про базы данных, движки, прокси и многое другое.
Стартап вырос из своих штанишек, надо было пересилить себя и разобраться.
Сложность была в том, что никто не понимал что не так то. Откуда вообще копать.
Так же всё усложнялось тем, что нет времени на раскачку и траблшутинг, проблема возникает редко, а надо пилить новые фичи, люди ждут продукт, как и инвесторы.
Шли недели и месяцы. Многие думали, что это не проблема софта, а проблема Амазон. Не верю, картинно возражали они и шли дальше пилить код.
А затем пришёл series b и пришла даже не нагрузка, а НАГРУЗИЩЕ.
х800 трафик и количество от клиентов от того, что было месяц назад.
Проблема стала так же в сотни раз чаще и пришло время её фиксировать.

Observability, v2.
Команда научилась отслеживать slow logs и реагировать на них.
https://xn--r1a.website/makebreakreflect/33
Есть запросы больше 10 секунд? Изучаем query и катим фикс.
И так до тех пор, пока слоу логи не прекратились.
И.. это не решило проблему.

Кубер/хелм/девопс во всём виноват.
Обратили внимание, что частично проблема повторятся, когда идёт деплой или скейлинг.
Проверили всё, пробы, макссёрж, количество реплик, стратеджи, перешли на KEDA с детальнейшим конфигом, пофиксили пару серёезных багов со стороны не совсем корректной настойки проб.
https://xn--r1a.website/makebreakreflect/9
И.. это не решило проблему.

#aws #aurora #eks #troubleshooting #longread

Лонгрид "история одного бага".
Часть 2 из 3.

Observability, v3
Было принято решение мониторить поэтапно, каждый элемент инфры отдельно, а не комплексно, как это было ранее.
Например не просто "базу", а "базу поэтапно.
Что приходит на приложении при обращении к прокси, что происходит на RDS proxy, что приходит от прокси до БД, что внутри БД. На всё метрики и новые дашборды. Где не было метрик - писали сами.
Часть в графине, часть в CloudWatch, смотря откуда source был или быстрее/удобнее.
Эээ трейсинг мониторинга?
Первая зацепка попалась впервые за много месяцев, когда появился дашборд RDS proxy и там был замечен спайк.
Честно говоря не представляю, кто первый придумал назвать это спайком, но дальше по всем post mortem данный фигурант назвался спайк. Спайк количество подключений клиента к БД. Вместо частых 300-500 спайки доходили до 40000(в зависимости от типа инстанса и от настроек, их меняли часто во время эксплуатации и траблшутинга)
И.. спайки совпали с временем жалоб "ЧОТА ТОРМОЗИТ ИНОГДА".

Радость, v1.
О чудо, кричала команда, мы нашли причину.
Однако радость быстро омрачилась осознанием того, что никто не знал ээээ а кто собственно создаёт спайки подключений и зачем? Все микросервисы, от монолита, макросервиса монорепы и других микросервисов сидели под одной учёткой на один ендпойнт.

Кастомизейшн, v1
Были созданы отдельные учётные записи для каждого сервиса.
И.. это ничего не дало.
Видно спайк, видно проблему, не видно источника.

Кастомизейшн? v2
Были созданы отдельные RDS proxy endpoint для каждого сервиса отдельно.
https://xn--r1a.website/makebreakreflect/55
То есть каждый сервис со своими подами(независимо сколько их в скейлинге сейчас) подключается через отдельный эндпойнт RDS proxy, с отдельной учётной записи.

Радость, v2.
О чудо, снова закричала команда.
Радость улетучилась раньше, чем прошло эхо от коллективного крика.
Стало понятно, что нагрузка идет только на один определённый эндпойнт, только от конкретного юзера-приложения.
Команда глянула в код и.. это ничего не дало.
Приложением из монорепозитория.
У него буквально 1-2 параметра энтрипойнта других и немного другой функционал.
Сами параметры запуска этого сервиса 100% на влияют на проблему.
Грубо говоря у одного сервиса задача "слушай вебхуки, пушь в базу", у второго "слушай sqs, пушь в базу", а у третьего "слушай кафку, пушь в базу". Всё остальное одинаковое.

Observability, v4
Ок, команда знает про спайк, про нагрузку от RDS proxy от одного сервиса, но откуда оно?
Создаётся ещё несколько новых dashboard, устанавливается Performance insight от AWS.
Команда видит, что есть нагрузка на read/write IOPS область, снова читаются книги, статьи, снова оптимизация кода и инфры.
https://xn--r1a.website/makebreakreflect/115

#aws #aurora #eks #troubleshooting #longread

Лонгрид "история одного бага".
Часть 3 из 3.

Финал. Финал без разбивки.
Понимаю, что вы уже устали читать, но конец близок.
И вот мы приходим к состоянию, что команда видит чуть ли не каждый трейс, обращение, логи, слоу логи, мониторинг базовых сущностей и метрик, мониторинг кастом метрик, всё это обвешано алёртингом, а количество дашбордов больше 50(панелей около 450). Господи, да даже влияние запроса на IOPS видно в аналитике.
Все. Ждут. Проблему.
Создана целая вселенная, как во Black and White и теперь под микроскопом смотрим кто же из наших мелких хулиганит.

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

В саппорте сперва сперва катают как в доте новичка тупыми вопросами категории "вы пробовали выключить и включить", на что сразу получают максимально подробный и отчасти грубый ответ "дайте нам другого менеджера" и сразу переключают на очень умного инженера, явно выше первого уровня технической поддержки.
Он анализирует все десятки скриншотов, логов, аргументов, истории траблшутинга и даёт одну единственную ссылку на документацию и ссылку на логи.
первая ссылка https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-pinning.html
где нас интересует только это
Any statement with a text size greater than 16 KB causes the proxy to pin the session.
А вторая ссылка на логи, которые упустила команда, и где есть чёткое
The proxy can't reuse this connection until the session ends. Reason: The connection ran a SQL query which exceeded the 16384 byte limit.
(это было пропущено при траблшутинге, есть косяк).
Срочный созвон, брейншторм разработчиков за 0.00000001мс, фикс на 2 строчки(ограничение payload).
И.. и проблема ушла.

Итог.
Вот так, в поисках одного бага, который возникал на 1-3 секунды, аффектил всех клиентов, который появился только при нагрузке при росте продукта, позволили потратить больше 11.000 долларов(дебаг, включение фичей, доп услуги, хранение и обогащение метрик, борды, разделение по rdx proxy endpoints и многоие другое), десятки часов траблшутинга, научив всю команду обсервабилити и пониманию КАЖДОГО этапа всех элементов продукта.
Всего-лишь большой payload в базу через прокси.. Всего-лишь большой payload..

*В этой истории упущены ещё два десятка незначительных модификаций, которые либо вели команду не тудла, либо ну совсем ни на что не влияли, а текста отняли бы ещё на пару постов.