Налаштування черг повідомлень Amazon SQS для веб-додатку

Ваші фонові завдання зависають при пікових навантаженнях, а повідомлення губляться без сліду? Amazon SQS — це керована черга повідомлень, яка вирішує ці проблеми без адміністрування брокера. SQS обробляє понад 10 000 повідомлень на секунду, зберігає їх до 14 днів і автоматично масштабується. 99,9% uptime SLA гарантує доступність. Ми налаштуємо SQS для вашого веб-додатку під ключ: від проектування до деплою.

На відміну від самописних рішень, SQS не вимагає налаштування кластера та моніторингу брокера. Ви платите лише за використання, що економить до $2000 на рік на інфраструктурі (при навантаженні 1 млн повідомлень/день). З чергою ви уникаєте втрат даних при збоях consumer'ів — кожне повідомлення зберігається до 14 днів. Dead Letter Queue страхує від необроблених завдань.

Чому SQS може бути кращим за RabbitMQ?

RabbitMQ потребує виділеного сервера та ручного керування кластером. Redis Queue — швидкий, але не гарантує довготривалого збереження при збоях. SQS — повністю керований сервіс з автоматичним масштабуванням, довготривалим зберіганням (до 14 днів) і вбудованою підтримкою Dead Letter Queue. За продуктивністю SQS Standard обробляє тисячі повідомлень на секунду, а FIFO — до 3000 (з пакетною відправкою). Для більшості веб-додатків SQS — оптимальний баланс між простотою та надійністю. Налаштування черги SQS займає в 3 рази менше часу, ніж розгортання RabbitMQ.

Як налаштувати Visibility Timeout та DLQ?

Visibility timeout — час, протягом якого повідомлення приховане від інших consumer'ів після отримання. За замовчуванням — 30 секунд. Якщо повідомлення не видалено за цей час, воно знову стає видимим. Збільште таймаут, якщо обробка займає більше 30 секунд. Наприклад, для обробки платежу із зовнішнім API встановіть 2-5 хвилин. Для завдань, які можуть зависнути, використовуйте Dead Letter Queue: після 3 невдалих спроб повідомлення переміщується до DLQ. 95% повідомлень обробляються з першої спроби при правильно виставленому таймауті.

Інтеграція з вашим стеком

Terraform (Infrastructure as Code)

Стандартний інфраструктурний код для реплікації в будь-якому середовищі, включаючи прив'язку Lambda:

# Dead Letter Queue resource "aws_sqs_queue" "dlq" { name = "myapp-jobs-dlq" message_retention_seconds = 1209600 # 14 днів } # Основна черга resource "aws_sqs_queue" "jobs" { name = "myapp-jobs" visibility_timeout_seconds = 300 message_retention_seconds = 86400 receive_wait_time_seconds = 20 redrive_policy = jsonencode({ deadLetterTargetArn = aws_sqs_queue.dlq.arn maxReceiveCount = 3 }) } # FIFO черга (для завдань, що потребують порядку) resource "aws_sqs_queue" "orders_fifo" { name = "myapp-orders.fifo" fifo_queue = true content_based_deduplication = true deduplication_scope = "messageGroup" fifo_throughput_limit = "perMessageGroupId" } # IAM політика для додатку resource "aws_iam_policy" "sqs_app" { name = "myapp-sqs-access" policy = jsonencode({ Version = "2012-10-17" Statement = [{ Effect = "Allow" Action = [ "sqs:SendMessage", "sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes", ] Resource = [aws_sqs_queue.jobs.arn, aws_sqs_queue.dlq.arn] }] }) } # Lambda event source mapping resource "aws_lambda_event_source_mapping" "sqs_lambda" { event_source_arn = aws_sqs_queue.jobs.arn function_name = aws_lambda_function.worker.arn batch_size = 10 maximum_batching_window_in_seconds = 5 function_response_types = ["ReportBatchItemFailures"] } 

PHP: AWS SDK

Кастомний consumer для не-Laravel проектів:

use Aws\Sqs\SqsClient; class SqsQueue { private SqsClient $client; private string $queueUrl; public function __construct() { $this->client = new SqsClient([ 'version' => 'latest', 'region' => config('aws.region', 'eu-west-1'), ]); $this->queueUrl = config('queue.connections.sqs.queue'); } public function send(string $jobClass, array $payload, int $delaySeconds = 0): string { $result = $this->client->sendMessage([ 'QueueUrl' => $this->queueUrl, 'MessageBody' => json_encode([ 'job' => $jobClass, 'payload' => $payload, 'attempts' => 0, 'sent_at' => now()->toIso8601String(), ]), 'DelaySeconds' => $delaySeconds, 'MessageAttributes' => [ 'JobClass' => [ 'DataType' => 'String', 'StringValue' => $jobClass, ], ], ]); return $result['MessageId']; } public function poll(int $maxMessages = 10): void { $result = $this->client->receiveMessage([ 'QueueUrl' => $this->queueUrl, 'MaxNumberOfMessages' => $maxMessages, 'WaitTimeSeconds' => 20, 'VisibilityTimeout' => 300, ]); foreach ($result->get('Messages') ?? [] as $message) { $this->processMessage($message); } } private function processMessage(array $message): void { try { $body = json_decode($message['Body'], true); $job = app($body['job']); $job->handle($body['payload']); $this->client->deleteMessage([ 'QueueUrl' => $this->queueUrl, 'ReceiptHandle' => $message['ReceiptHandle'], ]); } catch (\Throwable $e) { Log::error('SQS job failed', [ 'job' => $body['job'] ?? 'unknown', 'error' => $e->getMessage(), ]); } } } 

Laravel Queue

У Laravel SQS підтримується з коробки. Конфігурація через .env:

QUEUE_CONNECTION=sqs AWS_ACCESS_KEY_ID=AKIA... AWS_SECRET_ACCESS_KEY=secret AWS_DEFAULT_REGION=eu-west-1 SQS_QUEUE=https://sqs.eu-west-1.amazonaws.com/123456789/myapp-jobs 

А сам Job клас:

class ProcessOrderJob implements ShouldQueue { use Dispatchable, InteractsWithQueue, Queueable, SerializesModels; public int $tries = 3; public int $timeout = 120; public function __construct(private int $orderId) {} public function handle(OrderService $service): void { $service->process($this->orderId); } public function failed(\Throwable $e): void { Log::error('Order processing failed', [ 'order_id' => $this->orderId, 'error' => $e->getMessage(), ]); } } ProcessOrderJob::dispatch($order->id); ProcessOrderJob::dispatch($order->id)->delay(now()->addMinutes(5)); 

SQS + Lambda (serverless)

Для event-driven архітектури використовуйте Lambda. Код обробника на Python:

import json def handler(event, context): failed_ids = [] for record in event['Records']: try: body = json.loads(record['body']) process_job(body) except Exception as e: print(f"Failed: {record['messageId']}: {e}") failed_ids.append({'itemIdentifier': record['messageId']}) return {'batchItemFailures': [{'itemIdentifier': id} for id in failed_ids]} 

Порівняння підходів до інтеграції

Типові помилки та моніторинг

• Занадто маленький visibility timeout призводить до повторної обробки. Завжди закладайте запас у 30%.
• Відсутність DLQ — втрата повідомлень при збоях consumer.
• Неправильні IAM політики — додаток не може відправити/отримати повідомлення.
• Моніторинг не налаштований — глибина черги зростає непомітно.

CloudWatch метрики SQS: ApproximateNumberOfMessagesVisible, NumberOfMessagesSent, NumberOfMessagesDeleted, ApproximateAgeOfOldestMessage. Рекомендуємо встановити оповіщення на глибину черги — наприклад, при >1000 повідомлень надсилати сповіщення у Slack. Документація AWS CloudWatch рекомендує відстежувати ці метрики для своєчасного реагування.

Як ми налаштовуємо SQS: покроковий процес

1. Аналітика. Визначаємо навантаження, вимоги до порядку та довговічності.
2. Проектування. Вибираємо тип черги, налаштовуємо visibility timeout, DLQ, IAM політики.
3. Реалізація. Пишемо consumer (Laravel, кастомний PHP/Node.js) або Lambda-тригери.
4. Тест. Проводимо навантажувальне тестування, перевіряємо відмовостійкість.
5. Деплой. Розгортаємо через Terraform, налаштовуємо CI/CD, ставимо оповіщення в CloudWatch.

Що входить у роботу та терміни

• Документація з архітектури черг
• Terraform-код для всієї інфраструктури
• Доступи та IAM політики
• Consumer з обробкою помилок та DLQ
• Моніторинг (CloudWatch метрики + оповіщення)
• Навчання команди роботі з чергою
• Підтримка після запуску (1 місяць)

Терміни: Laravel Queue + SQS — 1 день. Кастомний PHP/Node.js consumer з DLQ та моніторингом — 2–3 дні. SQS + Lambda serverless — 2–3 дні. Точні терміни оцінюємо після аналізу вашого проекту. Ми працюємо з чергами понад 5 років та реалізували 30+ проектів. Отримайте консультацію по вашому проекту прямо зараз. Замовте налаштування SQS і забудьте про проблеми з чергами.