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

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

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

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

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

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

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

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

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

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

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

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

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

Оплата

Открыть все

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Открыть все

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Очереди FIFO

Открыть все

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Открыть все

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

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

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

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

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

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

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

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

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

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

Открыть все

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соответствие требованиям

Открыть все

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

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

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

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

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

Открыть все

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Открыть все

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

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

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

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

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

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

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

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

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

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

Открыть все

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

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

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

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

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

Очереди необрабатываемых сообщений

Открыть все

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

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

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

Принцип работы AWS Local Zones

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

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