🟧 AWS SQS – Architecture, Opérations & Bonnes Pratiques

Comparatif détaillé

Visibility Timeout

Après réception, un message devient invisible pour la durée du VisibilityTimeout. Si non supprimé → redelivery.

# Recommandation
VisibilityTimeout = P95 durée de traitement + marge

Message Retention

Durée de conservation : 1 minute → 14 jours. Plus haut → coûts + risque backlog.

Producteur
  ↓ SendMessage / Batch
File SQS (Standard ou FIFO)
  ↓ ReceiveMessage (long polling 20s)
Worker / Lambda
  ↓ DeleteMessage (sinon redelivery)
DLQ si maxReceiveCount atteint

Cas d’usage concrets

• Webhooks → SQS → Workers → DB (garantie que rien n’est perdu).
• E‑commerce : commandes FIFO groupées par customer_id.
• Analytics : ingestion d’événements avant traitement batch ou Lambda.
• IoT : buffering des capteurs pour éviter l’écrasement en cas de pic.

RedrivePolicy = { deadLetterTargetArn: DLQ_ARN, maxReceiveCount: 5 }

• DLQ par domaine (ex: orders-dlq, billing-dlq).
• Pipeline de replay contrôlé (filtrer poison vs transitoire).
• Tagger les messages (attrs) avec reason, tenant, traceId.

• MessageGroupId = file logique d’ordre strict (un consommateur par groupe).
• MessageDeduplicationId fenêtre 5 min (ou ContentBasedDeduplication).
• Stratégies de choix du group id : customer_id, account_id, aggregate_id.

[Producer] --Send/Batch--> [SQS] --Receive(10)--> [Workers k8s]
                                    |--DLQ (maxReceiveCount)
LongPoll 20s ↓ coûts, ↑ throughput | FIFO: GroupId → ordre strict

aws sqs create-queue --queue-name orders --attributes VisibilityTimeout=45,MessageRetentionPeriod=604800
aws sqs create-queue --queue-name orders.fifo --attributes FifoQueue=true,ContentBasedDeduplication=true
aws sqs set-queue-attributes --queue-url URL --attributes RedrivePolicy='{"deadLetterTargetArn":"DLQ_ARN","maxReceiveCount":"5"}'
    

Resources:
  OrdersQ:
    Type: AWS::SQS::Queue
    Properties:
      QueueName: orders
      VisibilityTimeout: 45
      MessageRetentionPeriod: 604800
  OrdersDLQ:
    Type: AWS::SQS::Queue
    Properties:
      QueueName: orders-dlq
      MessageRetentionPeriod: 1209600
  OrdersRedrive:
    Type: AWS::SQS::QueuePolicy
    Properties:
      Queues: [!Ref OrdersQ]
      PolicyDocument:
        Statement:
          - Effect: Allow
            Action: ["sqs:SendMessage"]
            Resource: !GetAtt OrdersQ.Arn
            Principal: { "AWS": "*" }
    

resource "aws_sqs_queue" "orders" {
  name                      = "orders"
  visibility_timeout_seconds= 45
  message_retention_seconds = 604800
  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.orders_dlq.arn
    maxReceiveCount     = 5
  })
}
resource "aws_sqs_queue" "orders_dlq" { name = "orders-dlq" }
    

{
  "Version":"2012-10-17",
  "Statement":[{
    "Effect":"Allow",
    "Action":["sqs:SendMessage","sqs:ReceiveMessage","sqs:DeleteMessage","sqs:ChangeMessageVisibility"],
    "Resource":"arn:aws:sqs:eu-west-3:123456789012:orders"
  }]
}
# SSE‑KMS → Autoriser kms:Decrypt aux rôles producer/consumer
    

Créer un VPC Interface Endpoint pour com.amazonaws.${region}.sqs : trafic privé, moins de latence et pas d’egress Internet.

entries=[{"Id":str(i),"MessageBody":json.dumps({"order_id":i})} for i in range(10)]
sqs.send_message_batch(QueueUrl=URL, Entries=entries)
    

Toujours vérifier Failed dans la réponse et réémettre uniquement les entrées en échec.

# FIFO: idempotence → group & dedup
def send_fifo(order):
  return sqs.send_message(QueueUrl=URL_FIFO,
    MessageBody=json.dumps(order),
    MessageGroupId=str(order['customer_id']),
    MessageDeduplicationId=hashlib.sha256(json.dumps(order,sort_keys=True).encode()).hexdigest())
    

En Standard, gérer l’idempotence côté consommateur avec un store (Redis/DB) de messageId ou clé métier.

from pydantic import BaseModel
class Order(BaseModel):
  order_id:str; total:float; items:list
# valider avant envoi
Order(**body)
    

• VisibilityTimeout = P95 traitement + marge; appeler change_message_visibility pour jobs longs.
• Batch delete pour réduire le coût : regrouper les ReceiptHandle.
• Jitter sur les retries pour éviter les hérissements (thundering herd).

# Mapping Lambda
batchSize=10; maximumBatchingWindow=5s; visibilityTimeout=6x lambdaTimeout
# Gestion des échecs: Destinations ou DLQ SQS
    

import redis
r=redis.Redis(host='redis')

def already_processed(key:str)->bool:
  return r.setnx(f"done:{key}", 1)==0

# Dans handle()
key=payload['order_id']
if already_processed(key):
  return  # idempotent
    

# Event source mapping
batchSize=10, maximumBatchingWindow=5s, visibilityTimeout=6x timeout lambda
# Gérer les échecs: on-failure DLQ (SQS) ou Destinations

Orchestration de workflows : tâches asynchrones avec attente sur files, ré-essais et branches.

# Coût approximatif (simplifié)
Cost ≈ (Send + Receive + Delete + PayloadExtensions) * PricePerRequest
→ Réduire en:
  - activant le LongPolling (WaitTime=20)
  - utilisant send/receive/delete en batch (10)
  - évitant les messages vides (polling inutile)
    

• Maximiser WaitTimeSeconds (20s) → moins d’appels facturés.
• Regrouper les DeleteMessageBatch.
• Mettre une TTL réaliste et surveiller OldestMessageAge.
• Préférer FIFO uniquement si l’ordre strict est impératif.

# Producteur → buffer en mémoire → flush toutes les 50ms ou 10 msgs
# Consommateur → receive(10) → traitement parallèle (pool) → delete_batch
    

• Configurer DLQ (maxReceiveCount=3..5).
• Ajouter reason/stack dans attributes; requêter DLQ pour analytics.
• Replay outillé (scripts) pour les cas réparables.

• Implémenter retry avec backoff + jitter côté SDK.
• Limiter la QPS (token bucket) côté producteur.
• Utiliser VPC Endpoint pour réduire la latence réseau.

• Activer LongPolling 20s ; supprimer le polling « vide ».
• Regrouper via batch; surveiller NumberOfEmptyReceives si dispo.
• Réduire les tailles/attributs inutiles; externaliser gros payloads (S3 Extended).