Вопросы и ответы по Amazon SQS

Вы платите только за то, чем пользуетесь, без минимальной платы.

Стоимость Amazon SQS рассчитывается по количеству запросов, к чему добавляется плата за передачу данных из сервиса Amazon SQS (за исключением передачи данных в инстансы Amazon Elastic Compute Cloud (EC2) или функции AWS Lambda в пределах одного региона). Подробный расчет стоимости в зависимости от типа очереди и региона см. на странице цен на Amazon SQS.

В рамках уровня бесплатного пользования Amazon SQS ежемесячно предоставляется 1 миллион запросов бесплатно.

Многие небольшие приложения могут полностью работать в рамках уровня бесплатного пользования. Однако при этом может начисляться плата за передачу данных. Дополнительную информацию см. на странице цен на Amazon SQS.

Уровень бесплатного пользования предоставляется на ежемесячной основе. Неиспользованные ресурсы на следующий месяц не переносятся.

Да, плата начисляется за все запросы, выходящие за пределы уровня бесплатного пользования. За все запросы Amazon SQS начисляется плата, при этом они тарифицируются по единому тарифу.

Стоимость пакетных операций (SendMessageBatch, DeleteMessageBatch и ChangeMessageVisibilityBatch) не отличается от стоимости других запросов Amazon SQS. Группируя сообщения в пакеты, можно уменьшить расходы на Amazon SQS.

Для начала работы с сервисом Amazon SQS не требуется предоплата. В конце месяца с кредитной карты клиента автоматически снимается сумма за использование сервиса по итогам месяца.

На сайте Amazon Web Services можно в любое время ознакомиться с начислениями за текущий расчетный период.

1. Нужно войти в аккаунт AWS.
2. В разделе Ваш аккаунт для веб-служб выберите пункт История аккаунта.

Используя теги распределения расходов, можно пометить очереди и затем отслеживать их для управления ресурсами и расходами. Тег – это метка метаданных, состоящая из пары ключ-значение. К примеру, можно пометить тегами очереди по центру затрат, впоследствии распределить их по категориям и отслеживать свои расходы на основании этих центров.

Дополнительную информацию см. в разделе Tagging Your Amazon SQS Queues Руководства по Amazon SQS для разработчиков. Дополнительную информацию об использовании для ресурсов AWS тегов распределения расходов см. в разделе Использование тегов распределения затрат Руководства пользователя по управлению счетами и затратами на AWS.

Если не указано иное, представленные цены не включают применимые налоги и сборы, в том числе НДС и применимый налог с продаж.

Для клиентов с платежным адресом в Японии использование AWS в любом регионе облагается потребительским налогом Японии. Подробнее см. в разделе Вопросы и ответы по потребительскому налогу на Amazon Web Services.

Да. Приложения можно сделать более гибкими и масштабируемыми, используя сервис Amazon SQS совместно с вычислительными сервисами, такими как Amazon EC2, Amazon Elastic Container Service (ECS) и AWS Lambda, а также с сервисами хранения и баз данных, такими как Amazon Simple Storage Service (Amazon S3) и Amazon DynamoDB.

Доступ к Amazon SQS можно получить из Консоли управления AWS, с помощью которой проще создавать очереди Amazon SQS и отправлять сообщения.

Сервис Amazon SQS также поддерживает API веб-сервисов. Кроме того, он интегрирован с пакетами SDK AWS, что позволяет работать с необходимыми языками программирования.

Подробнее об операциях с очередями сообщений см. в Справочном руководстве по API сервиса Amazon SQS.

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

Да. Можно использовать все преимущества масштабируемости, экономичности и высокой доступности сервиса Amazon SQS без необходимости самостоятельно организовывать работу кластера JMS. 

Amazon предоставляет библиотеку Amazon SQS Java Messaging Library, в которой реализована спецификация JMS 1.1 с использованием Amazon SQS в качестве поставщика JMS. Дополнительную информацию см. в разделе Использование JMS с Amazon SQS Руководства по Amazon SQS для разработчиков.

Служба сообщений Java (JMS)

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

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

Дополнительную информацию см. в разделе Идентификаторы очередей и сообщений Руководства по Amazon SQS для разработчиков.

Amazon SQS позволяет использовать API или консоль для настройки очередей необрабатываемых сообщений, которые получают сообщения из других исходящих очередей. При настройке очереди необрабатываемых сообщений вам необходимо предоставить соответствующие разрешения на ее перезапуск с помощью политики RedriveAllowPolicy.

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

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

Дополнительную информацию см. в разделе Использование очередей необрабатываемых сообщений Amazon SQS в Руководстве по Amazon SQS для разработчиков.

Тайм-аут видимости – это период времени, в течение которого сервис Amazon SQS не дает другим компонентам, получающим сообщения, получать и обрабатывать сообщения. Дополнительную информацию см. в разделе Тайм-аут видимости Руководства по Amazon SQS для разработчиков.

Да. Сообщение Amazon SQS может содержать до 10 атрибутов метаданных. Атрибуты сообщения можно использовать для отделения тела сообщения от метаданных, описывающих его. Это позволяет обрабатывать и сохранять информацию быстрее и эффективнее, поскольку приложениям не нужно проверять сообщение целиком, чтобы понять, как его обработать.

Атрибуты сообщений Amazon SQS представляют собой триады «имя-тип-значение». Поддерживаются следующие типы данных: строка, бинарные данные и число (включая целое число, число с плавающей запятой и число двойной точности). Дополнительную информацию см. в разделе Использование атрибутов сообщений Amazon SQS Руководства по Amazon SQS для разработчиков.

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

Порядок обычного времени задержки для запросов API SendMessage, ReceiveMessage и DeleteMessage измеряется в десятках или нескольких сотнях миллисекунд.

Когда идентификатор аккаунта AWS недоступен (например, при отправке сообщения анонимным пользователем), Amazon SQS указывает вместо него IP-адрес.

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

Длинные опросы позволяют легко и без лишних затрат извлекать сообщения из очереди Amazon SQS, как только они станут доступны. Использование длинных опросов может уменьшить стоимость пользования сервисом SQS за счет сокращения числа пустых ответов. Дополнительную информацию см. в разделе Длинные опросы Amazon SQS Руководства по Amazon SQS для разработчиков.

Нет. Вызовы ReceiveMessage длинных опросов тарифицируются точно так же, как вызовы ReceiveMessage коротких опросов.

В большинстве случаев использовать длинные опросы Amazon SQS предпочтительнее, чем короткие. Длинные опросы позволяют получателям принимать сообщения из очереди по мере их поступления в очередь, уменьшая количество возвращенных пустых ответов ReceiveMessageResponse.

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

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

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

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

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

Все AWS SDK по умолчанию работают с 20-секундным периодом ожидания длинных опросов. Если для доступа к Amazon SQS не используется AWS SDK или если для AWS SDK уже установлено меньшее время ожидания, возможно, потребуется изменить настройки клиента Amazon SQS, чтобы использовать более длинные опросы или использовать длинные опросы с меньшим временем ожидания.

AmazonSQSBufferedAsyncClient для Java обеспечивает реализацию интерфейса AmazonSQSAsyncClient и добавляет несколько важных возможностей.

• Автоматическое пакетирование нескольких запросов SendMessage, DeleteMessage или ChangeMessageVisibility без внесения каких-либо необходимых изменений в приложение.
• Предварительная загрузка сообщений в локальный буфер, которая позволяет приложению немедленно начать обработку сообщений из Amazon SQS, не дожидаясь извлечения сообщений.

Совместное использование автоматического пакетирования и предварительной загрузки увеличивает пропускную способность и уменьшает задержку, вносимую приложением, одновременно снижая затраты из-за уменьшения количества запросов Amazon SQS. Дополнительную информацию см. в разделе Буферизация на стороне клиента и создание пакетов запросов Руководства по Amazon SQS для разработчиков.

Клиент AmazonSQSBufferedAsyncClient можно загрузить в составе AWS SDK для Java.

Нет. Клиент AmazonSQSBufferedAsyncClient для Java реализован в виде быстрой замены существующего клиента AmazonSQSAsyncClient.

Если обновить приложение для использования последней версии AWS SDK и изменить устройство своего клиента, чтобы он использовал клиент AmazonSQSBufferedAsyncClient для Java вместо клиента AmazonSQSAsyncClient, то приложение получит дополнительные преимущества автоматического пакетирования и предварительной загрузки.

1. В консоли Amazon SQS выберите очередь Amazon SQS.
2. В разделе Queue Actions из раскрывающегося списка выбрать Subscribe Queue to SNS Topic.
3. В диалоговом окне подписки выбрать тему из раскрывающегося списка Choose a Topic и нажать кнопку Subscribe.

Дополнительную информацию см. в разделе Подписка очереди на тему Amazon SNS Руководства по Amazon SQS для разработчиков.

Да. Все сообщения в очереди Amazon SQS можно удалить с помощью операции PurgeQueue.

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

Чтобы удалить только определенные сообщения, используйте операции DeleteMessage или DeleteMessageBatch.

Более подробные сведения см. в учебном пособии Удаление сообщений из очереди Amazon SQS.

Очереди FIFO доступны во всех регионах AWS, в которых представлен Amazon SQS. Сведения о доступности Amazon SQS по регионам см. здесь.

В очередях FIFO предполагается полное отсутствие дублирующих сообщений. Однако в некоторых сценариях дублирующие сообщения могут появляться на стороне отправителя. К примеру, если сообщение отправлено, а ответ не получен, это сообщение может быть отправлено повторно. API сервиса Amazon SQS предоставляют функциональные возможности для защиты от отправки дублирующих сообщений на стороне отправителя. Все дублирующие сообщения, созданные на стороне отправителя, удаляются из очереди каждые пять минут.

При работе со стандартной очередью получение дублирующих сообщений возможно (доставка по принципу «хотя бы один раз»). Поэтому при использовании стандартных очередей приложения должны быть идемпотентными (т. е. при обработке одного и того же сообщения более одного раза их работа не должна нарушаться).

Дополнительную информацию см. в разделе Строго однократная обработка Руководства по Amazon SQS для разработчиков.

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

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

Нет. Тип очереди указывается в момент ее создания. Тем не менее переход от стандартной очереди к очереди FIFO возможен. Дополнительную информацию см. в разделе Переход от стандартной очереди к очереди FIFO Руководства по Amazon SQS для разработчиков.

Чтобы воспользоваться функционалом очередей FIFO, необходимо использовать последнюю версию SDK AWS.

Очереди FIFO используют те же действия API, что и стандартные очереди, и предлагают аналогичные принципы получения и удаления сообщений, а также изменения тайм-аута видимости. Однако при отправке сообщений необходимо указать идентификатор группы сообщений. Дополнительную информацию см. в разделе Логика очередей FIFO Руководства по Amazon SQS для разработчиков.

Очереди FIFO поддерживают все метрики, поддерживаемые стандартными очередями. При использовании очередей FIFO для всех приблизительных метрик отображаются точные результаты подсчета. Например, поддерживаются следующие метрики AWS CloudWatch:

• ApproximateNumberOfMessagesDelayed – количество в очереди задержанных сообщений, недоступных для немедленного прочтения.
• ApproximateNumberOfMessagesVisible – количество сообщений, доступных к извлечению из очереди.
• ApproximateNumberOfMessagesNotVisible – количество передаваемых сообщений (отправленных клиенту и еще не удаленных или еще не достигших окончания окна видимости).

В рамках очередей FIFO сообщения сгруппированы в четко определенные и упорядоченные «пакеты». Для каждого идентификатора группы сообщений отправка и получение всех сообщений осуществляется в строго установленном порядке. Однако отправка и получение сообщений с различными значениями идентификатора группы сообщений могут осуществляться вне очереди. Необходимо привязать идентификатор группы сообщений к сообщению. Если не указать идентификатор группы сообщений, произойдет сбой.

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

Дополнительную информацию см. в разделе Логика очередей FIFO Руководства по Amazon SQS для разработчиков.

Да. Сообщения в очередь FIFO могут отправляться из одного или нескольких источников. Порядок сохранения сообщений соответствует порядку их успешного получения сервисом Amazon SQS.

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

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

По умолчанию очереди FIFO поддерживают до 3000 сообщений в секунду при использовании пакетной обработки и до 300 сообщений в секунду (300 операций отправки, получения или удаления в секунду) без нее. Если вам требуется более высокая пропускная способность, вы можете включить в консоли Amazon SQS режим высокой пропускной способности для очереди FIFO. В этом режиме поддерживается до 70 000 сообщений в секунду при использовании пакетной обработки или даже больше. Подробную разбивку квот режима высокой пропускной способности FIFO по регионам см. в документации AWS.

Название очереди FIFO должно заканчиваться суффиксом .fifo. Максимальная длина названия очереди составляет 80 символов с учетом суффикса. Чтобы определить, является ли очередь FIFO, нужно убедиться, что название очереди заканчивается этим суффиксом.

Amazon SQS хранит все очереди сообщений и сообщения в одном регионе AWS с высокой доступностью и несколькими избыточными зонами доступности (AZ), поэтому сообщения остаются доступны при отказе одного компьютера, сети или всей зоны доступности. Дополнительную информацию см. в разделе Регионы и зоны доступности Руководства пользователя сервисов реляционных баз данных Amazon.

Механизмы аутентификации сервиса гарантирует надежную защиту сообщений, хранящихся в Amazon SQS, от несанкционированного доступа. Управлять можно как отправителями сообщений в очередь, так и получателями сообщений из очереди. Для дополнительной защиты можно предусмотреть в приложении шифрование сообщений перед их размещением в очереди сообщений.

В Amazon SQS используется собственная система разрешений на основе ресурсов, использующая политики, написанные на том же языке, что и политики управления идентификацией и доступом AWS (IAM); к примеру, можно использовать переменные, как и в политиках IAM. Дополнительную информацию см. в разделе Примеры политик Amazon SQS Руководства по Amazon SQS для разработчиков.

Amazon SQS поддерживает протокол HTTP на базе SSL (HTTPS) и протокол безопасности транспортного уровня (TLS). Большинство клиентов могут автоматически договариваться об использовании более новых версий протокола TLS без каких-либо изменений в коде или настройках. Amazon SQS поддерживает версии 1.0, 1.1 и 1.2 протокола безопасности транспортного уровня (TLS) во всех регионах.

Когда сервис Amazon SQS возвращает сообщение, оно остается в очереди независимо от того, было ли фактически получено. Поэтому необходимо выполнить удаление сообщения. Запрос на удаление подтверждает, что сообщение было обработано.

Если сообщение не будет удалено, Amazon SQS повторно доставит его в ответ на следующий запрос о получении. Дополнительную информацию см. в разделе Тайм-аут видимости Руководства по Amazon SQS для разработчиков.

Нет. В очередях FIFO полностью отсутствуют дублирующие сообщения.

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

При выдаче запроса DeleteMessage по отношению к ранее удаленному сообщению Amazon SQS направит ответ об успешном выполнении операции.

SSE позволяет передавать конфиденциальные данные через зашифрованные очереди. Благодаря SSE обеспечивается защита содержимого сообщений в очередях Amazon SQS с помощью ключей, управляемых сервисом управления ключами AWS (AWS KMS). Шифрование сообщений выполняется, как только Amazon SQS получает их. Сообщения хранятся в зашифрованном виде. Amazon SQS расшифровывает сообщения только тогда, когда они отправляются авторизованному получателю.

Дополнительную информацию см. в разделе о защите данных с помощью шифрования на стороне сервера (SSE) и AWS KMS в руководстве по Amazon SQS для разработчиков

Да. Для этого потребуется обеспечить совместимость между сервисами AWS (например, Amazon CloudWatch Events, Amazon S3 и Amazon SNS) и очередями с шифрованием на стороне сервера. Подробные инструкции см. в разделе «Совместимость» Руководства по SQS для разработчиков.  

Шифрование на стороне сервера (SSE) для Amazon SQS доступно во всех регионах AWS, где доступен сам сервис Amazon SQS. Сведения о доступности Amazon SQS по регионам см. здесь.

Чтобы включить SSE для новой или существующей очереди с помощью API сервиса Amazon SQS, укажите ID главного ключа клиента (CMK): псевдоним, псевдоним ARN, ID ключа или ключ ARN управляемого AWS или настраиваемого CMK (для этого нужно установить атрибут KmsMasterKeyId действия CreateQueue или SetQueueAttributes).

Подробные указания см. в разделах Создание очереди Amazon SQS с шифрованием на стороне сервера и Настройка шифрования на стороне сервера (SSE) для существующей очереди Amazon SQS Руководства по Amazon SQS для разработчиков.

SSE поддерживают как стандартные очереди, так и очереди FIFO.

Прежде чем приступать к использованию SSE, необходимо разрешить шифрование очередей и шифрование и дешифрование сообщений в основных политиках AWS KMS.

Включить SSE для очереди можно с помощью управляемого AWS главного ключа клиента (CMK) для Amazon SQS или настраиваемого ключа CMK. Дополнительную информацию см. в разделе Главные ключи клиента Руководства по AWS KMS для разработчиков.

Чтобы отправлять сообщения в зашифрованную очередь, отправитель должен иметь разрешения kms:GenerateDataKey и kms:Decrypt для CMK.

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

Дополнительную информацию см. в разделе Какие разрешения требуются для использования SSE? Руководства по Amazon SQS для разработчиков.

Дополнительная плата за использование Amazon SQS не взимается. Однако есть плата за вызовы AWS KMS из Amazon SQS. Дополнительную информацию см. на странице Цены на сервис управления ключами AWS.

Плата за использование AWS KMS зависит от периода повторного использования ключа данных, заданного для ваших очередей. Дополнительную информацию см. в разделе Как оценить свои затраты на эксплуатацию AWS KMS? Руководства по Amazon SQS для разработчиков.

С помощью SSE шифруется текст сообщения в очереди Amazon SQS.

Следующие компоненты с помощью SSE не шифруются:

• метаданные очереди (имя очереди и атрибуты);
• метаданные сообщений (ID сообщения, временная метка и атрибуты);
• метрики для каждой очереди.

Amazon SQS генерирует ключи данных на основе управляемого AWS главного ключа клиента (CMK) для Amazon SQS или настраиваемого CMK для шифрования конвертов и дешифрования сообщений в настраиваемый период времени (от 1 минуты до 24 часов).

Дополнительную информацию см. в разделе Что в Amazon SQS шифруется с помощью SSE? Руководства по Amazon SQS для разработчиков.

SSE использует алгоритм AES-GCM 256.

SSE не ограничивает пропускную способность (TPS) сервиса Amazon SQS. Количество очередей SSE, которые можно создать, ограничено. Оно зависит от приведенных ниже условий.

• Период повторного использования ключа данных (от 1 минуты до 24 часов).
• Квота на количество транзакций AWS KMS в секунду для аккаунта (по умолчанию составляет 100 TPS).
• Число пользователей IAM или аккаунтов, обращающихся к очередям.
• Наличие большого количества сообщений в списке выполнения (чем их больше, тем больше вызовов AWS KMS нужно совершить).

Предположим, заданы следующие ограничения.

• Период повторного использования ключа данных составляет 5 минут (300 секунд).
• Для аккаунта установлена квота на количество транзакций AWS KMS в секунду по умолчанию, равная 100 TPS.
• Используется очередь Amazon SQS без помещения сообщений в список выполнения и с одним пользователем IAM, выполняющим действия SendMessage или ReceiveMessage для всех очередей.

В этом случае можно вычислить теоретический максимум очередей Amazon SQS с SSE следующим образом.

300 секунд × 100 TPS/1 пользователь IAM = 30 000 очередей

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

Примечание. Хотя с помощью приведенной ниже формулы можно получить довольно четкое представление о предстоящих расходах, фактические затраты могут быть выше из-за распределенного характера Amazon SQS.

Количество запросов API на очередь (R) вычисляется по следующей формуле.

R = B/D * (2 * P + C)

B — это расчетный период (в секундах)

D — период повторного использования ключа данных (в секундах)

P — количество отправителей сообщений в очередь Amazon SQS

C — количество получателей сообщений из очереди Amazon SQS

Важно! Как правило, расходы отправителей в два раза превосходят расходы получателей. Дополнительные сведения см. в разделе Как работает период повторного использования ключа данных в Руководстве по Amazon SQS для разработчиков.

Если у отправителя и получателя разные пользователи IAM, стоимость увеличивается.

Дополнительную информацию см. в разделе Как оценить свои затраты на эксплуатацию AWS KMS? Руководства по Amazon SQS для разработчиков

Да. Сервис Amazon SQS сертифицирован по стандарту PCI DSS Level 1. Подробнее см. в разделе Соответствие требованиям PCI.

Да, AWS расширила свою программу соответствия требованиям HIPAA. Теперь сервис Amazon SQS соответствует требованиям HIPAA. Если вы заключили с AWS договор делового партнерства (BAA), можно использовать Amazon SQS для создания приложений, совместимых с HIPAA, передачи сообщений и хранения сообщений при передаче, включая сообщения, содержащие закрытую медицинскую информацию (PHI).

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

Примечание. Если вы предпочитаете не передавать PHI через Amazon SQS (или если у вас есть сообщения размером более 256 КБ), можно использовать вариант отправки полезных данных сообщений Amazon SQS через Amazon S3 с помощью расширенной клиентской библиотеки Amazon SQS для Java (сервис Amazon S3 соответствует требованиям HIPAA, за исключением использования сервиса ускорения передачи данных Amazon S3). Дополнительную информацию см. в разделе Использование расширенной клиентской библиотеки Amazon SQS для Java Руководства по Amazon SQS для разработчиков.

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

В качестве срока хранения сообщения Amazon SQS можно указать значение от 1 минуты до 14 дней. Значение по умолчанию составляет 4 дня. По достижении квоты на хранение сообщения удаляются автоматически.

Чтобы настроить период хранения сообщений, укажите значение атрибута MessageRetentionPeriod с помощью консоли сервиса либо метода Distributiveness. Используйте этот атрибут для указания количества секунд, в течение которых сообщение будет храниться в Amazon SQS.

Можно использовать атрибут MessageRetentionPeriod для указания срока хранения сообщения от 60 секунд (1 минуты) до 1 209 600 секунд (14 дней). Дополнительные сведения о работе с этим атрибутом сообщения см. в Справочном руководстве по API Amazon SQS.

Чтобы настроить максимальный размер сообщений, задайте значение атрибута MaximumMessageSize с помощью консоли или метода SetQueueAttributes. Этот атрибут позволяет указать максимальный размер сообщения Amazon SQS в байтах. Установите значение этого атрибута между 1024 байтами (1 КБ) и 262 144 байтами (256 КБ). Дополнительную информацию см. в разделе Использование атрибутов сообщений Amazon SQS Руководства по Amazon SQS для разработчиков.

Для отправки сообщений, размер которых превышает 256 КБ, можно воспользоваться расширенной клиентской библиотекой Amazon SQS для Java. Эта библиотека позволяет отправлять сообщение Amazon SQS, содержащее ссылку на полезную нагрузку сообщения размером до 2 ГБ, которая хранится в Amazon S3.

Сообщения Amazon SQS могут содержать до 256 КБ текстовых данных, включая форматы XML, JSON и неформатированный текст. Допускается использование следующих символов Юникода:

#x9 | #xA | #xD | [от #x20 до #xD7FF] | [от #xE000 до #xFFFD] | [от #x10000 до #x10FFFF]

Подробнее см. в разделе Спецификация XML 1.0.

В одной очереди сообщений Amazon SQS может содержаться неограниченное число сообщений. Однако квота на количество находящихся на передаче сообщений составляет 120 000 для стандартных очередей и 120 000 для очередей FIFO. Сообщения считаются находящимися на передаче в промежуток времени, когда они уже переданы из очереди принимающему компоненту, но еще не удалены из очереди.

Число очередей сообщений, создаваемых пользователем, не ограничено.

Длина имени очереди ограничена 80 символами.

Можно использовать буквенно-цифровые символы, дефис (-) и нижнее подчеркивание (_).

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

С очередью сообщений, которая будут использоваться совместно, можно связать заявление о политике доступа (и указать предоставленные разрешения). Amazon SQS предоставляет API для создания и управления заявлениями о политике доступа:

• AddPermission;
• RemovePermission;
• SetQueueAttributes.
• GetQueueAttributes;

Подробнее см. в Справочном руководстве по API Amazon SQS.

Доступ к совместно используемой очереди оплачивает ее владелец.

Для идентификации пользователей AWS в API сервиса Amazon SQS используется номер аккаунта AWS.

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

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

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

Операция SetQueueAttributes полностью поддерживает язык политик доступа. Например, можно использовать язык политики, чтобы ограничить доступ к очереди сообщений по IP-адресу или времени суток. Дополнительную информацию см. в разделе Примеры политик Amazon SQS Руководства по Amazon SQS для разработчиков.

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

Нет. Каждая очередь сообщений Amazon SQS является независимой в каждом регионе.

Цены сервиса Amazon SQS одинаковы во всех регионах, за исключением региона Китай (Пекин). Дополнительную информацию см. на странице цен на Amazon SQS.

Можно бесплатно передавать данные между сервисами Amazon SQS и Amazon EC2 или AWS Lambda в пределах одного региона.

При передаче данных между сервисами Amazon SQS и Amazon EC2 или AWS Lambda в разных регионах будет взиматься стандартная плата за передачу данных. Дополнительную информацию см. на странице цен на Amazon SQS.

Очередь необрабатываемых сообщений – это очередь Amazon SQS, в которую исходная очередь может отправлять сообщения, если приложение потребителя в исходной очереди не может успешно принять сообщения. Очереди необрабатываемых сообщений упрощают обработку сбоев в приеме сообщений и управляют жизненным циклом непринятых сообщений. Можно настроить предупреждение для любых сообщений, передаваемых в очередь необрабатываемых сообщений, изучать журналы на предмет исключений, которые могут привести к передаче таких сообщений в очередь, и анализировать содержимое сообщений, чтобы диагностировать проблемы с приложениями потребителя. После восстановления приложения потребителя можно повторно направить сообщения из очереди необрабатываемых сообщений в исходную очередь.

При создании исходной очереди Amazon SQS дает возможность указать очередь необрабатываемых сообщений (DLQ) и условие, при котором SQS должен перемещать сообщения в DLQ. Условие – это количество раз, которое потребитель может принять сообщение из очереди, определенное как maxReceiveCount. Эта настройка очереди необрабатываемых сообщений с исходной очередью и maxReceiveCount называется политикой перенаправления. Когда ReceiveCount для сообщения превышает maxReceiveCount для очереди, Amazon SQS согласно настройке перемещает сообщение в очередь необрабатываемых сообщений (с оригинальным ID сообщения). Например, если в исходной очереди есть политика перенаправления, в которой для maxReceiveCount установлено значение пять, а потребитель исходной очереди получает сообщение шесть раз без успешного приема, SQS перемещает это сообщение в очередь необрабатываемых сообщений.

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

Сначала пользователь может изучить образцы сообщений, доступные в очереди необрабатываемых сообщений, просмотрев их атрибуты и связанные метаданные. Затем, изучив сообщения, пользователь может переместить их обратно в одну или несколько исходных очередей. Можно также выбрать скорость перенаправления, указав частоту, с которой Amazon SQS будет перемещать сообщения из очереди необрабатываемых сообщений в исходную очередь.

Да. Однако для очереди FIFO необходимо использовать очередь необрабатываемых сообщений FIFO. (Точно так же для стандартных очередей можно использовать только стандартные очереди необрабатываемых сообщений.)