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

Служба простых запросов (SQS) была одной из первых услуг, предлагаемых AWS. Это управляемая служба очередей, позволяющая снизить давление со стороны нижестоящих служб. Вы ставите свои элементы в очередь, и другие службы могут извлекать их, когда у них есть возможность поработать над ними.

Это управляемая служба, поэтому вам не нужно самостоятельно устанавливать или обслуживать программное обеспечение; вы просто настраиваете очередь и начинаете вставлять и извлекать из нее. Таким образом, с SQS очень просто начать работу.

Как и со всеми сервисами на AWS, при использовании SQS могут возникнуть проблемы, потому что не всегда очевидно, что каждый сервис может и чего не может делать. Но не бойтесь, так как эта статья призвана помочь вам как можно быстрее решить наиболее распространенные из них. Готовы исправить свои очереди? Тогда давайте погрузимся!

1. Java SDK — невозможно получить атрибуты сообщения

Вы пытались получить сообщения с атрибутом, не сообщая SDK имя атрибута. Чтобы исправить это, вам нужно вызвать receiveMessage со следующим параметром:

sqs.receiveMessage(

receiveMessageRequest

.withMessageAttributeNames("мойАтрибут")

).getMessages()

Таким образом, SDK знает, что он должен включать нужные вам атрибуты.

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

AWS SDK позволяет определить, какие атрибуты сообщения необходимы для запуска этой оптимизации. Но позже, когда вы получаете доступ к атрибутам, вы должны помнить о том, что вы выбрали; в противном случае вы обнаружите что-то похожее на исключение нулевого указателя: доступ к данным, которых нет.

2. Тема SNS не публикуется в SQS

Вы попытались опубликовать в SQS тему SNS, для которой нет разрешения. Чтобы исправить это, необходимо разрешить SQS действие SendMessage из субъекта-службы SNS.

Вот пример политики:

"Утверждение": [{

"Sid": "Разрешить-SNS-SendMessage",

"Эффект": "Разрешить",

"Основной": {

"Сервис": "sns.amazonaws.com"

"Действие": ["sqs:SendMessage"],

"Ресурс": "arn:aws:sqs:us-east-2:444455556666:MyQueue",

"Условие": {

"ArnEquals": {

"aws:SourceArn":

"arn:aws:sns:us-east-2:444455556666:MyTopic"

Эта проблема основана на ошибочном представлении о том, что темы SNS развернуты в вашей учетной записи. Вы можете ожидать, что ваша учетная запись будет выступать здесь в качестве принципала, но сама служба SNS действует как принципал. Таким образом, ваша учетная запись получает разрешение, которое она не может использовать, а фактический принципал заблокирован.

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

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

3. Отказано в доступе к SQS через AWS SDK

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

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

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

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

4. Предотвращение добавления повторяющихся сообщений SQS

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

SQS не предназначен для такого случая использования, поэтому вы не можете запретить очереди принимать элементы, которые она уже содержит. Если у вас есть это ограничение, вам нужно выбрать более сложную службу, например DynamoDB, которая позволяет помечать документы как уникальные. Пошаговые функции также могут быть здесь, но это зависит в основном от вашего варианта использования.

5. Сообщения в полете

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

sqs.deleteMessage({

QueueUrl: 'STRING_VALUE',

ReceiptHandle: 'STRING_VALUE'

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

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

6. FIFO блокирует очередь

Вы настроили очередь как FIFO, и сообщение блокирует всю очередь. Чтобы смягчить эту проблему, сгруппируйте свои сообщения с идентификаторами группы сообщений; сообщения будут блокировать только тех, кто находится в той же группе.

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

Резюме

SQS — это простой сервис. Вы можете видеть это как временную базу данных. Если вам нужно куда-то поместить данные для последующей обработки, вам подойдет SQS.

Каждый сервис в AWS, очередь SQS и все другие сервисы в вашем стеке, использующие эту очередь, будут настроены с минимальными разрешениями, что приведет к проблемам с доступом. Поэтому перед развертыванием в рабочей среде убедитесь, что вы правильно настроили политики IAM.

Роли администратора могут помочь при разработке, но они представляют собой кошмар безопасности при использовании в рабочей среде, поэтому вам нужно следить за политиками IAM при развертывании!

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

Мониторинг очередей SQS с помощью Dashbird

Dashbird автоматически отслеживает очереди SQS в вашем аккаунте AWS; никаких дополнительных настроек не требуется. Все будет оцениваться в соответствии с [платформой Well-Architected Framework] (https://dashbird.io/serverless-well-architected-reports/), поэтому вы сразу увидите, следуете ли вы рекомендациям.

Вы можете попробовать Dashbird прямо сейчас; кредитная карта не требуется. Ознакомьтесь с нашим обзором продукта здесь.

В Dashbird мы понимаем, что основная идея и ценность бессерверных технологий – сосредоточение внимания на клиенте и возможность избежать тяжелой работы. Это именно то, что мы предоставляем. Мы снова возвращаем внимание разработчиков, чтобы они думали только о конечном пользователе, а не отвлекались на отладку и управление аварийными сигналами или беспокоились о том, работает что-то или нет.