tgoop.com/data_days/338
Last Update:
и следом ютуб-фид мне выдал релевантный доклад с AWS re:Invent «как не терять данные в стриминге»
Рассказывает AWS Hero из консалтинга, т.е. она насмотрелась за свою карьеру на разные aws-архитектуры.
доклад понравился тем, что он практико-ориентированный: на примере одного проекта разобрали основные ошибки и как тихо не терять данные. При этом советы были простые, но действенные — на уровне вызываемых функций и их параметров. И всё это относиться не только в AWS или Kinesis, ведь терять данные можно в любом инструменте.
⌘⌘⌘
кейс начинается с того, что при простом паблише и консьюме из Kinesis Streams они заметили недостачу данных. И дальше по цепочке разбирали кейсы, которые они обнаружили (вместе с поддержкой aws)
хорошим тоном считается отправлять события пачкой, а не по одному. Прикол в том, что вызов апи может вернуть статус 200, но при этом часть событий не примет. Помимо самого статуса, надо в респонсе смотреть поле с количеством ошибок по отдельным евентам.
отдельные ошибки могут возникать из тротлинга со стороны авс — там есть лимиты на мегабайты и штуки в секунду (при этом логи в cloudwatch будут уже аггрегированные по минутам и криминала не подсветят)
у Streams единица параллелизации — шард. Хотя AWS называет это serverless, но по сути провизией мощностей надо заниматься самоу. Скейлить вниз и вверх в зависимости от текущей нагрузки, чтобы не попасть не попасть на тротлинг, но и не переплатить за лишнее.
из streams события консьюмит лямбда. По умолчанию 1 шард = 1 конкурентный запуск лямбды. Если включить event source mapping, то можно увеличить фактор параллелизации до 10 одновременно запущенных лямбд на каждый шард.
подстава кроется в том, что у всего аккаунта есть лимит на количество запущенных лямбд — и если вдруг у вас станет слишком много шардов и запущенных лямбд, то где-то у соседнего отдела их лямбды (работающие на том же аккаунте) могут начать кидать ошибки.
выводы
🟣 обработать ошибки правильно — не доверять общему коду, а смотреть детализацию в респонсе
🟣 настроить ретраи — exponential backoff + jitter, чтобы распределять нагрузку в случае проблем
🟣 добавить кастомные метрики на тротлинг в cloudwatch, чтобы не пропустить логи с ошибками
🟣 настроить ESM для Лямдб, чтобы распрараллелить обработку событий
и всё то же самое в виде статьи с примерами кода
BY data будни
Share with your friend now:
tgoop.com/data_days/338