#kubernetes #databases #azure #longread
Лонгрид на вечер.

Часть 1 из 4

Раз уж были вопросы, дополню своё мнение про базы в Kubernetes.
Не ради холивара, чисто технический разбор с моим взглядом на вещи.

Всё нижесказанное про базы данных в managed kubernetes (Azure/AWS).
С GCP опыта крайне мало и на него не буду ссылаться.

Мои тезисы строятся так - сама по себе идея "тащить базы в кубер" отличная, но ровно до момента, когда:
- баз мало (ну, скажем, меньше 20 суммарно)
- размер их небольшой (допустим до гига)
- ops-команда шарит в бэкапах и ресторах на уровне профессионалов

В случае, когда баз становится больше, и даже команда вроде всё знает, вылезают проблемы, о которых ты раньше и не думал.
Что в AWS, что в Azure - везде свои сюрпризы, особенно неявные.
Ниже я опишу свой личный опыт большого количества баз в облачных куберах.

Зачем мы тащим базы в кубер?
Сделать себе больно? Потренироваться новыми достижениями?
Потетешкать самолюбие и похвастать на конфе?
Галочка в CV? Нет.
Изначально идея держать базы в кубере часто про экономию и удобство менеджмента(через оператора).
Мелкие базы в простое почти не жрут CPU и памяти, и если у вас есть много мелких баз, то на стоимости compute в AKS/EKS можно прилично сэкономить. Очень и очень прилично.
Плюс операторы - автоматизация, управление, всё красиво.

Мы сразу договорились: каждая база живёт в своём кластере.
Это из-за требований аудита и простой логики - чтобы "коммунальные кластеры" не ломали "соседей", если одна база вдруг начнёт жрать ресурсы как не в себя + секьюрити + изоляция.
По три реплики на базу - это не просто так: здравый смысл, богатый опыт с факапами баз и рекомендация по кворуму, чтобы не терять данные и не ловить даунтайм/сплитбрейн(а вот это я зря сказал, сейчас кааак раскритикуете🤣).

#kubernetes #databases #azure #longread
Часть 2 из 4

Берём пример.
У нас есть AKS-кластер, инстансы Standard_D8as_v5 - 8 ядер, 32 ГБ RAM.
Заливаешь одну среднюю БД, смотришь нагрузочное тестирование - в простое совсем мелкий CPU/memory usage.
Включаешь арифметику с умножением и думаешь "Отлично, сейчас закину кучу баз на пару нод".
Вынужден расстроить, но так у тебя не получится сделать, давай разберёмся почему.


1. Количество дисков

Читаешь доки Azure - максимум 16 диска на наш инстанс. Patroni для HA просит 3 реплики, то есть 3 PV на базу. Считаем: 16 дисков - это 5 изолированных кластеров БД (комплаенс, привет), 1 в запасе или под мелочи.
Поднял 3 кластера по 3 реплики - и всё, приехали, больше некуда.
https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/dasv5-series?tabs=sizestorageremote
Думаешь ладно. Денег много, возьму в этом же семействе инстанс дороже и мощнее, но и там ограничение 32 диска(10 кластеров + 2 диска под другие нужны).

2а. Максимальное количество подов на ноде (параметр MAX_PODS)

В Azure CNI дают до 250 подов на ноду, но по умолчанию нашего инстанса 80.
Считаем: апп с HPA (1 апп + 2 min HPA реплики) + Patroni (3 пода) = 6 подов на микросервис. Минус системные штуки (CNI, CSI, экспортёры, filebeat и так далее) - остаётся где-то 65.
То есть при привычных всем системным ресурсам и 3 репликам на бизнес микросервис апп + 3 реплики кластера БД, мы не сможем поднять больше 10 кластеров(да и не смогли бы, диски раньше нас тормознули бы).
https://learn.microsoft.com/en-us/azure/aks/azure-cni-overlay?tabs=kubectl#maximum-pods-per-node

2б. Резервирование памяти (параметр MAX_PODS)

Временно забудем про первый пункт с дисками и пофантазируем "Сейчас увеличу до 200 макс подс, в конфиге же легко и нам не будет мешать этот параметр".
AKS забирает память под ОС и kubelet: примерно 20 МБ на под + запас + операционная система +hard eviction.
Формула примерно такая, тут не буду топить за точность вычислений, на память пишу
(20 MB × 200(max_pods)) + 50 MB + 100 MB
Из ожидаемых тобой 32 гигабайт на ноде ты получаешь доступным для аллокации будет меньше.
С учётом hard eviction 100mb цифры примерно такие для нашего инстанса:
При --max-pods=80: ~28.7 GB (28714 MB)
При --max-pods=200: ~26.3 GB (26314 MB)
При --max-pods=250: ~25.3 GB (25314 MB)
В попытке уместить не умещаемое ты теряешь драгоценную память на ноде.

#kubernetes #databases #azure #longread
Часть 3 из 4

3. Сетевой стек

Azure CNI 250 IP на ноду, звучит неплохо. Но неявные проблемы - это отдельная песня. Первое: задержки между репликами. Думаешь, раз в одном кластере, сеть летает, а на деле CNI overlay добавляет 1-5 мс, и для синхронной репликации (типа Patroni) это уже ощутимо. Второе: подсеть кластера. Сотни баз, поды плодятся, и твоя дефолт /24 (256 IP) заканчивается на раз-два, а расширить - рестарт кластера и нервы. Третье: пропускная способность. NIC на ноде (12500 Mb/s) делится на всех, и 200 подов с трафиком - это бутылочное горлышко.

4. Бекапы

Мы разобрались(нет) с первыми болями и дошли до масштабирования.
Подняли dev кластер, развесили taints/toleration, скейлинг нод и подов, задеплоили оператора, на аппы повесили клеймы кластеров/БД, рассчитали, что вам надо, допустим по 4 кластера на ноду. Везде всё умещается.

Время учится делать бекапы. Допустим вы решили пойти путем через velero(а оно чертовски удобное).
Поставили расписание снепшотов, радостно проверили пару баз и ушли домой.
Утром приходите и видите - все запланированные бекапы не сработали. Копаясь в ивентах и логах вы поняли, что не хватило дисков.
с Azure Disk и VolumeSnapshot нюанс: для восстановления из снапшота нужен новый PVC, а дисков и так не хватает. Сами снапшоты PVC не требуют, но при развёртывании - да.
А если расписания в Velero, то без костылей никак: все снепшоты штатно запускаются разом - и по всему кластеру дисков не найти. Пока новые ноды в нужных зонах/регионах запустятся, джоба велеро просто упадёт по таймауту.
Разносишь по времени, ограничиваешь параллельность - выкручиваешься.

Уже на этих аргументах, подкрепленных моей болью, поеданием полной ложки коричневой субстанции я предлагаю завершить монолог "почему много баз в кубере это плохо", но мы идём дальше.

#kubernetes #databases #azure #longread
Часть 4 из 4

5. Операторы и типы баз данных.

"ой, а ты же даже ничего не сказал про типы базы данных(MySQL, PostgreSQL, MongoDB etc), ты ничего не сказал про операторы и разницу между ними, как же так?".
Каждый из операторов, которые я трогал в 2024-2025 годах обладал своими минусами.
Пожалуй отдельно могу отметить только https://cloudnative-pg.io/. Он невероятно чертовски хорош и очень быстро развивается.
Остальные почти все не годятся вам с дефолтными параметрами.
Например zalando оператор по дефолту с выключенной фичей DCS.
https://github.com/zalando/postgres-operator/blob/master/charts/postgres-operator/values.yaml#L454
Это гарантирует вам регулярную проблему с demoting self because DCS is not accessible and I was a leader и тем, что аппликейшны не смогут подключаться к кластеру (помогает рестарт аппликейшна, как ни странно).
Почитать вам https://patroni.readthedocs.io/en/master/dcs_failsafe_mode.html
Другой дефолтный параметр вообще превратит ваш кластер в постоянно расползающийся лаг, который будет течь как красотки на концерте Энрике Иглесиаса.

6. IOPS
Потом в процессе эксплуатуации доходит, что IOPS в Azure (и в AWS EKS) от размера диска зависит.
Мелкий диск (допустим 128 ГБ) - 500 IOPS, и для активных баз это ни о чём.
Хочешь больше - бери 512 ГБ (2300 IOPS) или 1 ТБ (5000 IOPS).
База мелкая, а из-за трёх реплик платишь за объём втридорога.
То есть в том случае, если ваш тип базы данных потребляет много IOPS, то вам придётся брать большие скоростные диски, а это уже не так весело и совсем не так дёшево.

"Так каков итог?" - спросите вы. Можно или нельзя пихать БД в managed кубер AKS/EKS?
Мой ответ такой:
- когда много баз - нельзя. Аргументы выше.
- когда базы очень большие(размер, большое потребление ресурсов CPU/Memory) - совершенно нельзя. Аргумент мне не хватило времени написать, может позже накатаю пост. не обещаю, много работы.
- когда OPS команда неквалифицированная. При ресторах будут большие проблемы, а DRP вам не всегда сможет помочь.
Это основные тезисы и рекомендации.

Мы можем сделать фактор репликации 2 или даже 1 реплику, но это уже не про HA.
Мы можем сделать 1 кластер на все базы, но это уже не про изоляцию и безопасность.

Выбор за каждым.

Update:
Апдейтнул пост, добавив, что рекомендации только для AKS/EKS.
Ничего не смогу сказать за других облачных провайдеров, у меня нет этого опыта.
Там могут не быть этих корнер кейсов(но могут быть другие).
Ничего не могу сказать за managed k8s, меня вселенная бережёт от работы с ними.

#одинденьизжизни #longread #kubernetes

Импровизация.
Лонгрид.

Да-да, часть моей работы это импровизация.
Зачастую бывает ситуация, что мне надо что-то решить, а я ну воообще не понимаю что это такое.

Сложилась такая ситуация, что у нас перестал работать стабильно некий сервис.
Пользователи/коллеги жалуются: "при работе с фронтенд приложением видим ошибку ****, помогает рестарт нескольких подов в кубере".
Речь идёт про DEV, но потенциально может аффектить и PROD часть.
Продакшн нам нельзя ломать, иначе меня уволят и мне нечем будет хвастать в интернетах успехами своих успехов.

Идём разбираться.
Какая ошибка? Ошибка в вебе звучит примерно так

{
    “errorCode”: “ERR_DIRECT_INVOKE”,
    “message”: “failed to invoke, id: REPLACEMESERVICENAME, err: failed to resolve address for ‘REPLACEMESERVICENAME-dapr.REPLACEMENAMESPACE.svc.cluster.local’: lookup REPLACEMESERVICENAME-dapr.REPLACEMENAMESPACE.svc.cluster.local on 10.0.12.10:53: no such host”
}

Я честно говоря хер знает что такое инвоук, что такое дапр и уж тем более не знаю почему такая ошибка возникает.
И почему тут вообще ресолв, с*ка. Причем тут внутренний DNS. Вы поехавшие что-ли?

В подобных случаях я строго не рекомендую пользоваться нейронками.
Во-первых конкретно в подобных случаях вы не знаете проект(как я), во-вторых, не знаете все 500 вводных, что важны для промпта и вы их просто пропускаете и нейронка не даст ни-ког-да вам точного ответа. Я не знаю примерно ничего, даже с чего начать и нейронка тут не поможет, лишь запутает.

Ок, смотрим что такое DAPR.
Читаем официальную документацию. https://dapr.io/
На основании документации выносим для себя определение что это.
DAPR (Distributed Application Runtime) - это фреймворк для упрощения разработки микросервисов, предоставляющий готовые решения для обмена сообщениями, управления состоянием и взаимодействия сервисов. Используется для создания масштабируемых и устойчивых распределённых приложений.
Ага, нихера не понятно. Очередная всратость для кубернетеса.
Что-то должна упростить, осталось понять кому она упрощает и как.
Смотрим, а что же у нас есть.

У нас есть отдельный неймспейс, в котором стоит
- dapr оператор
- dapr dashboard
- dapr-sidecar-injector
- dapr-scheduler
и всякое подобное.
Почитал логи, порестартил поды, посмотрел ивенты. Ничего не понятно.
Не понимаю чем это должно мне помочь, читаю дальше и разбираюсь по коду.

А как деплоится этот проблемный сервис?

>ky pods REPLACEMESERVICENAME-7766b4d5c-w66vc
apiVersion: v1
kind: Pod
metadata:
  annotations:
    dapr.io/app-id: REPLACEMESERVICENAME
...
    dapr.io/enabled: "true"
...
  labels:
    app: REPLACEMESERVICENAME
...
    dapr.io/app-id: REPLACEMESERVICENAME
    dapr.io/metrics-enabled: "true"
    dapr.io/sidecar-injected: "true"
...
    metrics_scrape_enabled: "true"
    metrics_scrape_from_pods: "true"
    pod-template-hash: 7766b4d5c
    release: REPLACEMESERVICENAME
    tier: web
    track: stable

По аннотациям видно, что генерация манифеста идёт через хелмчарт.
Ага, дошёл до helm чарта, у нас есть параметр-аннотация для дапра.
Понимаю, что при добавлении

dapr:
  enabled: true

Для каждого сервиса, где включен этот параметр, добавляется сайдкар.
Круто, хоть куда то сдвинулся в понимании что есть что.

#одинденьизжизни #longread #kubernetes

Промежуточное мнение: у нас есть N сервисов, между собой они используют dapr сайдкар контейнеры, который инжектится при помощи оператора и сайдкар инжектора при добавлении параметра в values файле.
Ага, ну хоть что-то.
Смотрим а как вообще роутинг устроен:
- в пределах кубера
- за пределами кластера кубера
Внутри кубера через DAPR (ну то есть через SVC адрес), снаружи через кастомный ингресс контроллер с кучей стрёмных аннотаций и хидеров.
Давай, Алекс, решать, куда будем копать.
Логика самой первой ошибки подсказывает, что ошибка не на уровне ингресса.
И как бы мне не хотелось с кровью выкорчевать весь этот кастомный ингресс контроллер из левой репы и сделать "по нормальному", мне сейчас надо чинить сервис и траблшутить ,а не правда матку рубить и настраивать как по книжке.
ПлАчу, засовываю своё негодование в известное место и забиваю на ингресс, иду в сторону service сущностей кубера.

Что мы имеет на данный момент? В валуес файл добавили параметр, оператор добавляет сайдкар, другие сервисы обращаются по адресу service к падающему сервису и получают иногда(с*ка, да как так то??!) ошибку.
Причём рестарт пода помогает.

Методом наблюдательности глаз вижу, что у нас на самом деле ДВЕ проблемы.
Первая проблема - у некоторых подов, где параметр стоит, нет сайдкара.
Я совершенно не знаю как это случилось и почему и как такое детектировать.
Делаем рестарт пода - появляется сайдкар с dapr.
Чтобы "поиграться" в будущем с такими ситуациями, мне нужен алёрт, который будет это отслеживать и рапортовать мне в слак. Я увижу проблемную ситуацию и буду иметь возможность в реалтайме траблшутить.
Пишем алерт

- alert: DAPR_ibanni_1
  expr: |-
    (
      sum(kube_pod_annotations{annotation_dapr_io_enabled="true"}) by (cluster, exported_namespace, pod)
    ) unless (
      sum(kube_pod_container_info{container="daprd"}) by (cluster, exported_namespace, pod)
    )
  for: 5m
  annotations:
    summary: "DAPR sidecar is not running on `{{ $labels.cluster }}`/`{{ $labels.exported_namespace }}`/`{{ $labels.pod }}`"

Тут мы проверяем есть ли поды, у которых есть аннотация на сайдкар дапра и матчим это с подами, у которых нет сайдкар-контейнера с именем daprd(украл название из чарта). То есть если сайдкара нет, где он должен быть, я получу оповещение.

Вторая проблема, которую вижу - "что-то" "где-то" "как-то" происходит и перестаёт ресолвится.
Как такое детектировать? Оно же не всегда.
Идём в документацию кубернетиса. Читаем что же такое может случится, что адрес service есть, но ресолва нет.
Лейблы? Селекторы? Херекторы? Я не знаю.
Документация сходу ничего не подсказывает и вот тут я иду в нейронку и спрашиваю напрямую "какие бывают случаи, когда у меня дапр сайдкары и в какой-то момент времени service есть но ресолва нет". Помучав вопросами я понимаю, что проблема в kubernetes endpoints.
Получив ключевые слова от нейроники я снова ухожу в документацию кубернетис.
Оказывается если ПОД не реди, то из endpoints пропадает IP адрес POD и service в кубере перестаёт ресолвится.
Ура! Зацепка! Под нот реди.

#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..

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

#longread #docker #debezium #всратость #mysql #kafka #realtime

https://telegra.ph/Catch-the-Latest-07-30

#aws #devops #longread #longstory #msk #apigateway #cloudfront

Суббота, отличная погода и великолепное настроение - идеальный момент для меня, чтобы написать новую историю.

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

https://telegra.ph/My-maiden-magnum-opus-08-01