Обзор

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

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

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

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

Вопрос. Чем отличаются сервисы Amazon SQS и Amazon SNS?

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

Вопрос. Чем отличаются сервисы Amazon SQS и Amazon MQ?

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

Вопрос. Обеспечивает ли Amazon SQS упорядочение сообщений?

Да. В очередях FIFO, работающих по принципу «первым получено – первым отправлено», сохраняется точный порядок отправки и получения сообщений. При использовании очередей FIFO добавлять информацию, служащую для упорядочения сообщений, не требуется. Дополнительную информацию см. в разделе FIFO Queue Logic Руководства по Amazon SQS для разработчиков.

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

Вопрос. Гарантирует ли сервис Amazon SQS доставку сообщений?

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

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

Вопрос. Чем Amazon SQS отличается от Amazon Kinesis Streams?

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

Amazon Kinesis Streams позволяет организовать обработку потоков больших данных в режиме реального времени и обеспечивает возможность считывать и воспроизводить записи в различных приложениях Amazon Kinesis. Клиентская библиотека Amazon Kinesis (KCL) обеспечивает доставку всех записей с заданным ключом секции к одному и тому же обработчику записей, что упрощает процесс создания различных приложений, считывающих данные из одного потока Amazon Kinesis (например, приложения для подсчета, объединения и фильтрации).

Дополнительную информацию см. в документации по Amazon Kinesis.

Вопрос. Использует ли Amazon сервис Amazon SQS при создании своих приложений?

Да. Разработчики Amazon используют Amazon SQS для различных приложений, ежедневно обрабатывающих большое количество сообщений. Основные бизнес-процессы, лежащие в основе веб-сайта Amazon.com и Amazon Web Services, используют Amazon SQS.

Оплата

Вопрос. Сколько стоит использование сервиса Amazon SQS?

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

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

Вопрос. Какой объем ресурсов предоставляется в рамках уровня бесплатного пользования Amazon SQS?

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

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

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

Вопрос. Плата начисляется за все запросы Amazon SQS?

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

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

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

Вопрос. Каков принцип начисления платы за использование сервиса Amazon SQS?

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

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

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

Вопрос. Как отслеживать расходы, связанные с очередями Amazon SQS, и управлять ими?

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

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

Вопрос. Ваши цены указаны с учетом налогов?

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

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

Функциональные возможности и интерфейсы

Вопрос. Можно ли использовать Amazon SQS с другими сервисами AWS?

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

Вопрос. Как взаимодействовать с сервисом Amazon SQS?

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

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

Вопрос. Какие действия API доступны для Amazon SQS?

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

Вопрос. Кто может выполнять операции с очередями сообщений?

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

Вопрос. Можно ли с сервисом Amazon SQS использовать Java Message Service (JMS)?

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

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

Вопрос. Как сервис Amazon SQS определяет сообщения?

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

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

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

Вопрос. Что происходит с необработанными сообщениями в Amazon SQS?

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

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

Дополнительные сведения см. в разделе «Можно ли использовать очередь необрабатываемых сообщений с очередями FIFO» на этой странице и Использование очередей необрабатываемых сообщений Amazon SQS в Руководстве по Amazon SQS для разработчиков.

Вопрос. Что такое тайм-аут видимости?

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

Вопрос. Поддерживает ли Amazon SQS метаданные сообщений?

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

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

Вопрос. Как определить время ожидания в очереди?

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

Вопрос. Каково обычное время задержки для Amazon SQS?

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

Вопрос. Какое значение имеет атрибут SenderId сообщения при анонимном доступе?

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

Вопрос. Что такое длинные опросы Amazon SQS?

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

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

Вопрос. Взимается ли дополнительная плата при использовании длинных опросов Amazon SQS?

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

Вопрос. Когда следует использовать длинные опросы Amazon SQS, а когда короткие?

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

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

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

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

Вопрос. Какое значение периода ожидания длинных опросов следует использовать?

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

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

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

Вопрос. Что такое AmazonSQSBufferedAsyncClient для Java?

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

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

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

Вопрос. Где можно загрузить клиент AmazonSQSBufferedAsyncClient для Java?

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

Вопрос. Потребуется ли внесение изменений в приложение при использовании клиента AmazonSQSBufferedAsyncClient для Java?

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

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

Вопрос. Как подписать очереди сообщений Amazon SQS для получения оповещений из тем Amazon SNS?

  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

Вопрос. В каких регионах поддерживаются очереди FIFO?

В настоящее время очереди FIFO поддерживаются в регионах Запад США (Орегон), Восток США (Огайо), Восток США (Сев. Вирджиния) и ЕС (Ирландия). В ближайшие месяцы данная возможность появится в других регионах.

Вопрос. Сколько копий сообщения я получу?

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

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

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

Вопрос. Будут ли ранее созданные очереди Amazon SQS теперь работать как очереди FIFO?

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

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

Вопрос. Можно ли превратить существующую стандартную очередь в очередь FIFO?

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

Вопрос. Являются ли очереди FIFO сервиса Amazon SQS обратно совместимыми?

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

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

Вопрос. Какие сервисы AWS или внешние сервисы совместимы с очередями FIFO сервиса Amazon SQS?

Некоторые сервисы AWS или внешние сервисы, позволяющие отправлять уведомления в Amazon SQS, могут оказаться несовместимы с очередями FIFO несмотря на то, что позволяют выбирать очередь FIFO в качестве объекта назначения.

Перечисленные ниже возможности сервисов AWS в настоящее время несовместимы с очередями FIFO.

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

Вопрос. Совместимы ли очереди FIFO сервиса Amazon SQS с буферным асинхронным клиентом Amazon SQS, расширенной клиентской библиотекой Amazon SQS для Java и клиентом Amazon SQS Java Message Service (JMS)?

На текущий момент очереди FIFO несовместимы с буферным асинхронным клиентом Amazon SQS.

Очереди FIFO совместимы с расширенной клиентской библиотекой Amazon SQS для Java и клиентом Amazon SQS Java Message Service (JMS).

Вопрос. Какие метрики AWS CloudWatch поддерживаются очередями FIFO сервиса Amazon SQS?

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

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

Вопрос. Что такое группы сообщений?

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

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

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

Вопрос. Поддерживают ли очереди FIFO сервиса Amazon SQS работу с несколькими источниками?

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

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

Вопрос. Поддерживают ли очереди FIFO сервиса Amazon SQS работу с несколькими получателями?

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

Вопрос. Можно ли использовать очередь необрабатываемых сообщений с очередями FIFO?

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

Вопрос. Каков предел пропускной способности для очереди FIFO сервиса Amazon SQS?

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

Вопрос. Существуют ли какие-либо особые ограничения для атрибутов очереди FIFO?

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

Безопасность и надежность

Вопрос. Насколько надежно хранятся данные в Amazon SQS?

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

Вопрос. Как защитить сообщения в очередях сообщений?

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

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

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

Вопрос. Для чего нужны отдельные операции ReceiveMessage и DeleteMessage?

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

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

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

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

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

Вопрос. Что произойдет при выдаче запроса DeleteMessage по отношению к ранее удаленному сообщению?

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

Шифрование на стороне сервера (SSE)

Вопрос. В чем заключаются преимущества шифрования на стороне сервера (SSE) для Amazon SQS?

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

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

Вопрос. Можно ли использовать SNS, CloudWatch Events и S3 Events с зашифрованными очередями?

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

Вопрос. В каких регионах доступны очереди с поддержкой SSE?

Шифрование на стороне сервера (SSE) для Amazon SQS доступно в следующих регионах: Азия и Тихий океан (Мумбаи, Осака, Сеул, Сингапур, Сидней и Токио), Канада (Центр), ЕС (Франкфурт, Ирландия, Лондон и Париж), Южная Америка (Сан-Паулу), Запад США (Сев. Калифорния, Орегон), Восток США (Сев. Вирджиния, Огайо) и GovCloud (US).

Вопрос. Как включить SSE для новой или существующей очереди Amazon SQS?

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

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

Вопрос. Какие типы очередей Amazon SQS могут использовать SSE?

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

Вопрос. Какие разрешения требуются для использования SSE с Amazon SQS?

Прежде чем приступать к использованию 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 для разработчиков.

Вопрос. Взимается ли плата за использование SSE с Amazon SQS?

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

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

Вопрос. Что в Amazon SQS шифруется с помощью SSE и как выполняется шифрование?

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

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

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

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

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

Вопрос. Какой алгоритм использует SSE для шифрования сообщений Amazon SQS?

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

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

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 KMS?

Чтобы прогнозировать расходы и лучше понимать счета 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?

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

Вопрос. Соответствует ли сервис Amazon SQS требованиям HIPAA?

Да, 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 Transfer Acceleration). Дополнительную информацию см. в разделе Использование расширенной клиентской библиотеки Amazon SQS для Java Руководства по Amazon SQS для разработчиков.

Лимиты и ограничения

Вопрос. Сколько времени сообщения могут находиться в очереди сообщений Amazon SQS?

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

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

Вопрос. Как настроить Amazon SQS для поддержки более длительного хранения сообщений?

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

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

Вопрос. Как настроить максимальный размер сообщений для 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?

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

Вопрос. Сколько очередей сообщений можно создать?

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

Вопрос. Ограничена ли длина имени очереди сообщений Amazon SQS?

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

Вопрос. Существуют ли ограничения для имен очередей сообщений Amazon SQS?

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

Вопрос. Можно ли повторно использовать имя очереди сообщений?

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

Совместное использование очередей

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

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

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

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

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

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

Вопрос. Как определить другого пользователя AWS, которому я хочу предоставить совместный доступ к очереди сообщений?

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

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

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

Вопрос. Поддерживает ли сервис Amazon SQS анонимный доступ?

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

Вопрос. В каких случаях следует использовать API разрешений?

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

Вопрос. В каких случаях следует использовать операцию SetQueueAttributes с объектами JSON?

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

Доступ к сервису в регионах AWS

Вопрос. В каких регионах доступен сервис Amazon SQS?

Для получения списка регионов, в которых доступен сервис, см. таблицу регионов глобальной инфраструктуры AWS.
Примечание. В настоящее время очереди FIFO доступны только в регионах Запад США (штат Орегон), Восток США (штат Огайо), Восток США (штат Сев. Вирджиния) и ЕС (Ирландия). В ближайшие месяцы данная возможность появится в других регионах.

Вопрос. Можно ли обмениваться сообщениями между очередями в разных регионах?

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

Вопрос. Различаются ли цены сервиса в разных регионах?

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

Вопрос. Как изменяются цены при использовании разных регионов?

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

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

Подробнее о ценах на Amazon SQS

Перейти на страницу цен
Готовы приступить к разработке?
Начать работу с Amazon SQS
Есть вопросы?
Свяжитесь с нами