и следом ютуб-фид мне выдал релевантный доклад с 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 для Лямдб, чтобы распрараллелить обработку событий


и всё то же самое в виде статьи с примерами кода