Integration & Messaging — SQS, SNS, Kinesis

ในระบบกระจาย (distributed system) เราไม่อยากให้ service ต่างๆ เรียกกันแบบ synchronous ตรงๆ เพราะถ้า service ปลายทางช้าหรือล่ม จะลามมาทำให้ต้นทางพังตาม Decoupling คือการแยก application components ออกจากกันเพื่อให้แต่ละส่วน scale และล้มเหลวได้อย่างอิสระ AWS มี 3 บริการหลักสำหรับเรื่องนี้: SQS (queue), SNS (pub/sub), และ Kinesis (streaming)

• SQS (Simple Queue Service) — message queue model: producer ส่ง message เข้า queue, consumer ดึง (pull) ไปประมวลผลแล้วลบทิ้ง
• SNS (Simple Notification Service) — pub/sub model: publish ครั้งเดียว ส่งถึง subscribers หลายตัวพร้อมกัน (push)
• Kinesis — real-time big data streaming: ingest ข้อมูลปริมาณมหาศาล, อ่านซ้ำ/replay ได้ตาม retention

SQS เป็น fully managed queue ที่ producer ใช้ SendMessage ส่ง message เข้า queue และ consumer ใช้ ReceiveMessage ดึงไปประมวลผล จากนั้นต้องเรียก DeleteMessage เพื่อยืนยันว่าประมวลผลเสร็จ (ถ้าไม่ลบ message จะกลับมาให้ดึงใหม่) SQS มี 2 ประเภทหลัก

เมื่อ consumer ดึง message ไป SQS จะซ่อน message นั้นชั่วคราวไม่ให้ consumer อื่นเห็น ระยะเวลานี้คือ visibility timeout (ค่า default 30 วินาที, ตั้งได้ 0 วินาที ถึง 12 ชั่วโมง) ถ้า consumer ประมวลผลเสร็จและลบ message ก่อนหมดเวลา ก็จบ แต่ถ้าหมดเวลาก่อน message จะกลับมา visible และอาจถูกประมวลผลซ้ำ

• ถ้าประมวลผลนานกว่า timeout ให้เรียก ChangeMessageVisibility เพื่อขยายเวลา
• Message retention — เก็บ message ใน queue ค่า default 4 วัน ปรับได้ตั้งแต่ 60 วินาที ถึง 14 วัน; เกินกว่านี้ message ถูกลบทิ้ง
• Delay queue / DelaySeconds — ซ่อน message ใหม่ตั้งแต่แรกก่อนให้ consumer เห็น สูงสุด 15 นาที (900 วินาที)

Dead Letter Queue (DLQ) คือ queue สำรองที่รับ message ซึ่งประมวลผลล้มเหลวซ้ำหลายครั้ง โดยตั้ง redrive policy ที่ source queue กำหนด maxReceiveCount เมื่อ ReceiveCount ของ message เกินค่านี้ SQS จะย้าย message ไป DLQ เพื่อแยกออกมาวิเคราะห์ ภายหลังใช้ redrive feature ส่งกลับ source queue ได้

• DLQ ของ FIFO queue ต้องเป็น FIFO และ DLQ ของ Standard queue ต้องเป็น Standard
• ควรตั้ง retention ของ DLQ ให้นาน (เช่น 14 วัน) เพื่อมีเวลา debug
• Long polling — consumer รอจนมี message หรือครบ wait time (ReceiveMessageWaitTimeSeconds 1-20 วินาที, สูงสุด 20s) ลด empty responses และลด API cost
• Short polling — return ทันที (WaitTimeSeconds = 0) แม้ไม่มี message ทำให้ API call ถี่และเปลือง

{
  "deadLetterTargetArn": "arn:aws:sqs:us-east-1:111122223333:MyDLQ",
  "maxReceiveCount": 5
}

SQS message มีขนาดสูงสุด 256 KB ถ้าต้องส่ง payload ใหญ่กว่านั้น ใช้ SQS Extended Client Library (Java) ที่เก็บ payload จริงไว้ใน S3 แล้วส่งเฉพาะ reference/metadata ผ่าน queue (รองรับได้ถึงระดับ GB)

FIFO Deduplication และ Message Group

• MessageDeduplicationId — ระบุ id เพื่อ dedup; ภายใน deduplication interval 5 นาที message ที่มี id เดียวกันจะถูกมองว่าซ้ำและถูกทิ้ง
• Content-based deduplication — ทางเลือกที่ให้ SQS คำนวณ SHA-256 hash ของ body เป็น dedup id อัตโนมัติ
• MessageGroupId — จัดกลุ่ม message ที่ต้องเรียงลำดับร่วมกัน; group เดียวกันเรียงตามลำดับ, ต่าง group ประมวลผลขนานกันได้ (เพิ่ม parallelism)

aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/1111/orders.fifo \
  --message-body '{"orderId":"A123"}' \
  --message-group-id "customer-42" \
  --message-deduplication-id "A123-create"

SNS เป็น pub/sub: producer publish message ไปยัง topic ครั้งเดียว แล้ว SNS push ไปยังทุก subscription ที่ subscribe กับ topic นั้น subscriber อาจเป็น SQS, Lambda, HTTP/S endpoint, email, SMS, mobile push หนึ่ง topic รองรับ subscriptions จำนวนมาก

Fan-out Pattern: SNS + SQS

แทนที่จะให้ producer ส่งตรงไปทุก queue เอง ให้ publish ไป SNS topic ครั้งเดียว แล้วให้หลาย SQS queue subscribe เข้ากับ topic แต่ละ queue จะได้สำเนา message ของตัวเอง ข้อดีคือ message persist อยู่ใน SQS (ไม่หายถ้า consumer ล่ม), retry/DLQ ได้, และเพิ่ม subscriber ใหม่ภายหลังได้โดยไม่แตะ producer

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "sns.amazonaws.com" },
    "Action": "sqs:SendMessage",
    "Resource": "arn:aws:sqs:us-east-1:1111:MyQueue",
    "Condition": {
      "ArnEquals": { "aws:SourceArn": "arn:aws:sns:us-east-1:1111:MyTopic" }
    }
  }]
}

SNS FIFO topic ให้ทั้ง ordering และ deduplication เหมือน SQS FIFO ใช้ MessageGroupId และ deduplication id (หรือ content-based dedup) แต่มีข้อจำกัดสำคัญคือ subscribe ได้เฉพาะ SQS FIFO queue เท่านั้น (ไม่รองรับ Lambda/HTTP/email โดยตรง)

Message Filtering

แต่ละ subscription สามารถมี filter policy (JSON) เพื่อรับเฉพาะ message ที่ตรงเงื่อนไข โดย default ตรวจจาก message attributes (ตั้ง FilterPolicyScope เป็น MessageBody เพื่อตรวจ body ได้) ช่วยให้ใช้ topic เดียวแต่แยกการรับของแต่ละ subscriber แทนการสร้างหลาย topic

{
  "order_status": ["placed", "shipped"],
  "region": [{ "prefix": "ap-" }]
}

Kinesis Data Streams ใช้ ingest streaming data ปริมาณมหาศาลแบบ real-time ข้อมูลถูกแบ่งเป็น shards producer ส่ง record พร้อม partition key ซึ่งถูก hash เพื่อกำหนด shard ปลายทาง record ที่มี partition key เดียวกันจะไปอยู่ shard เดียวกันและรักษา ordering ภายใน shard นั้น (เรียงด้วย sequence number ที่ Kinesis กำหนดให้)

• แต่ละ shard เขียนได้ 1 MB/s หรือ 1,000 records/s, อ่าน (classic) 2 MB/s แชร์กันทุก consumer
• เกิน limit จะเจอ ProvisionedThroughputExceededException แก้ด้วย partition key ที่กระจายดี และ/หรือ resharding
• Retention — default 24 ชั่วโมง, ขยายได้สูงสุด 365 วัน; consumer replay ข้อมูลได้
• Enhanced fan-out — consumer แต่ละตัวได้ dedicated 2 MB/s ต่อ shard ผ่าน HTTP/2 push (SubscribeToShard) ไม่ต้องแย่ง throughput กัน เหมาะกับ consumer หลายตัว latency ต่ำ

Kinesis Data Firehose เป็น fully managed service สำหรับโหลด streaming data ไปยังปลายทางแบบ near-real-time (ไม่ใช่ real-time แท้) เพราะมี buffering ตาม buffer size หรือ buffer interval ไม่ต้องบริหาร shard และ ไม่เก็บข้อมูลถาวร (no storage/replay ต่างจาก Data Streams)

• Destinations: Amazon S3, Amazon Redshift (ผ่าน S3), Amazon OpenSearch, Splunk, และ HTTP endpoints/third-party
• รองรับ data transformation ด้วย Lambda และแปลงรูปแบบ (เช่น เป็น Parquet/ORC) ก่อนเขียนลง S3
• จ่ายตามปริมาณข้อมูลที่ส่ง (pay-as-you-go) ไม่มี provisioning capacity

เรื่อง ordering เป็นจุดตัดสินใจสำคัญ: SQS FIFO เรียงตาม message group, SNS FIFO เรียงตาม message group (ต้องคู่กับ SQS FIFO), และ Kinesis เรียงภายใน shard ตาม partition key ส่วน SQS Standard และ SNS Standard ไม่รับประกันลำดับ