5 распространенных проблем с Amazon Kinesis
serverless amazon-web-services microservices serverless-monitoring aws-lambda aws-services amazon-kinesis kinesis

5 распространенных проблем с Amazon Kinesis

31 мая 2022 г.

Amazon Kinesis — это сервис потоковой обработки AWS в реальном времени. Если у вас есть видео, аудио или потоковые данные IoT для обработки, Kinesis — это то, что вам нужно.


Kinesis — это бессерверная управляемая служба, хорошо интегрируемая с другими службами, такими как Lambda или S3. Часто вы будете использовать его, когда SQS или SNS слишком низкого уровня.


Но, как и все другие сервисы на AWS, [Kinesis] (https://aws.amazon.com/kinesis/) — это профессиональный инструмент, который имеет свои сложности. В этой статье мы обсудим наиболее распространенные проблемы и объясним, как их исправить. Итак, приступим!


1. Какие ограничения применяются, когда AWS Lambda подписан на Kinesis Stream?


Если в вашем потоке Kinesis есть только один сегмент, функция Lambda не будет вызываться параллельно, даже если в потоке ожидают несколько записей. Для масштабирования до многочисленных параллельных вызовов вам необходимо добавить больше сегментов в Kinesis Stream.


Kinesis будет строго сериализовать все ваши вызовы для каждого сегмента. Это хорошая функция для управления вашими параллельными вызовами Lambda. Но это может замедлить общую обработку, если функция выполняется слишком долго.


Если вы не полагаетесь на предыдущие события, вы можете использовать больше сегментов, и Lambda автоматически масштабируется до большего количества одновременных вызовов. Но имейте в виду, что у самой Lambda есть мягкое ограничение на 1000 одновременных вызовов. Вы можете обратиться в AWS, чтобы снять это ограничение. Выше этого явно определенного жесткого ограничения нет, но AWS упоминает его число, кратное 10 000.


2. Потеря данных с помощью Kinesis Streams и Lambda


Если вы вызываете put_record в цикле для публикации записей из функции Lambda в поток Kinesis, это может привести к сбою в середине цикла. Чтобы исправить это, убедитесь, что вы улавливаете все ошибки, которые выдает метод put_record; в противном случае ваша функция выйдет из строя и опубликует список записей только частично.


Если один вызов Lambda отвечает за публикацию нескольких записей в потоке Kinesis, вы должны убедиться, что сбой функции Lambda не приведет к потере данных. В зависимости от вашего варианта использования это может означать, что вам нужно использовать повторные попытки или другую очередь перед вашей функцией Lambda.


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


3. Ошибка InvokeAccessDenied при отправке записей из Firehose в Lambda


Вы пытаетесь передать запись из Kinesis Firehose в функцию Lambda, но получаете сообщение об ошибке. Обычно это проблема с разрешениями для ролей IAM. Чтобы это исправить, назначьте пожарному шлангу правильную роль IAM.


В разделе «Ресурс» вашего документа политики вам необходимо убедиться, что ARN всех ваших функций Lambda перечислены. Это достигается либо с помощью подстановочного знака в ARN, либо с помощью массива ARN.


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


  • Отсутствует «Действие»: ["лямбда:InvokeFunction"]

  • Наличие «Эффекта»: где-то «Запретить»

  • Присвоение неправильной роли пожарному рукаву

4. Ошибка при попытке обновить количество осколков


Вы слишком часто пытались обновить количество сегментов за определенный период. Метод UpdateShardCount имеет довольно жесткие ограничения. Чтобы обойти эту проблему, вы можете вызвать другие функции, такие как SplitShard и MergeShards с более щедрыми квотами.


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


  • Масштабирование более чем в десять раз за скользящий 24-часовой период на поток

  • Масштабирование более чем в два раза по сравнению с текущим количеством осколков для потока

  • Уменьшите масштаб ниже половины вашего текущего количества осколков для потока

  • Масштабирование до более чем 10000 осколков в потоке

  • Масштабируйте поток с более чем 10 000 осколков, если результат не меньше 10 000 осколков.

  • Масштабируйте больше, чем лимит осколков для вашей учетной записи

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


5. Шард не закрыт


Вы взаимодействовали слишком рано после того, как создали новый поток. Создание нового потока может занять до 10 минут. Вы можете установить время ожидания после создания трансляции или повторить попытку несколько раз, чтобы исправить это.


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


Резюме


Если вам нужно обрабатывать данные или мультимедиа в режиме реального времени, лучше всего выбрать Kinesis на AWS.


К сожалению, это не так просто, как SQS и SNS, но и более гибко, чем эти сервисы.


Лучше всего узнать об ограничениях службы, чтобы не засорять сообщениями об ошибках, которых можно избежать. Кроме того, не забудьте надежно запрограммировать свои функции Lambda , чтобы они не зависли, если половина ваших данных еще не обработана.


Мониторинг Kinesis с помощью Dashbird


Dashbird отслеживает все ваши потоки Kinesis по умолчанию. Кроме того, Dashbird будет оценивать все ваши журналы Kinesis в соответствии с структурой Well-Architected Framework. Таким образом, это не просто массовые метрики и ошибки, а полезная информация , которая поможет улучшить вашу архитектуру с помощью лучших практик AWS.


Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE