Cloud Integration

ใน cloud applications ที่มีหลาย services การสื่อสารระหว่างกันสามารถทำได้ 2 รูปแบบหลัก — แต่ละแบบมีข้อดีข้อเสียและเหมาะกับสถานการณ์ต่างกัน

• •Synchronous communication: app-to-app โดยตรง (ผู้ส่งต้องรอผู้รับตอบ)
• •Asynchronous / Event-based communication: สื่อสารผ่านตัวกลาง (queue, topic, stream) — ทั้งสองฝั่งทำงานอิสระกัน

ทางออก: Decouple ระบบด้วย integration services — ทำให้แต่ละส่วน scale ได้อย่างอิสระ และไม่พึ่งพากันโดยตรง

เข้าใจความแตกต่างระหว่าง sync และ async เป็นพื้นฐานสำคัญในการเลือก integration pattern ที่เหมาะสม

App A  ──── HTTP request ────►  App B
       ◄─── HTTP response ────

  - App A ต้อง "รอ" จนกว่า App B จะตอบกลับ
  - ถ้า App B ช้า → App A ก็ช้าตาม
  - ถ้า App B ล่ม → App A error ทันที
  - Traffic spike → App B รับไม่ไหว → ทั้งระบบพัง

App A  ──► [SQS Queue / SNS Topic / Kinesis] ──► App B
                       ▲ ตัวกลาง (buffer)

  - App A ส่งแล้วจบ ไม่ต้องรอ App B
  - App B ค่อย consume เมื่อพร้อม (rate ของตัวเอง)
  - App B ล่ม → message รออยู่ใน queue ไม่หาย
  - Traffic spike → queue ดูดซับไว้ → App B ไม่พัง

• •Sync เหมาะกับ: งานที่ต้องการคำตอบทันที เช่น login, payment confirmation, query data
• •Async เหมาะกับ: งานที่ไม่ต้องรอผล เช่น send email, process order, generate report, log analytics
• •Decoupling = Resilience: services ไม่พึ่งพากันโดยตรง → ตัวหนึ่งล่ม ตัวอื่นยังทำงานได้
• •Independent scaling: producer และ consumer scale ได้คนละ rate

Amazon SQS เป็น service ที่เก่าแก่ที่สุดของ AWS (เปิดตัวกว่า 10 ปีแล้ว) เป็น fully managed message queue (~serverless) ใช้ decouple applications ระหว่างกัน

• •Scale อัตโนมัติ: 1 message/วินาที → 10,000+ messages/วินาที
• •Default retention: 4 วัน, maximum: 14 วัน
• •ไม่จำกัดจำนวน messages ใน queue
• •Messages ถูก ลบหลัง consumer อ่านสำเร็จ (consumer ต้องเรียก delete)
• •Low latency: < 10ms ในการส่งและรับ message
• •Message size สูงสุด 256 KB ต่อ message
• •Consumers สามารถ แชร์งานกัน (horizontal scaling — เพิ่ม consumer = เพิ่ม throughput)

Producer 1 ──┐
Producer 2 ──┼──► [ SQS Queue ] ──► Consumer 1 (process & delete)
Producer 3 ──┘                  ──► Consumer 2 (process & delete)
                                ──► Consumer 3 (process & delete)

  - Producers ส่ง message เข้า queue
  - Consumers แต่ละตัวแย่งกันดึง message ไป process
  - Consumer หลายตัว = scale horizontally

Visibility Timeout: เมื่อ consumer อ่าน message — message จะ invisible สำหรับ consumer ตัวอื่นชั่วคราว (default 30 วินาที) เพื่อป้องกันการ process ซ้ำ ถ้า consumer ทำเสร็จก็ delete ถ้าไม่เสร็จในเวลา message กลับมา visible อีกครั้ง

Dead Letter Queue (DLQ): ถ้า message ถูก process ล้มเหลวซ้ำๆ (เกิน maxReceiveCount) → จะถูกย้ายไปยัง DLQ เพื่อให้ developer ตรวจสอบและ debug — แทนที่จะ retry ไปเรื่อยๆ และ block queue

Amazon SNS ใช้ Pub/Sub model — event publishers ส่ง message ไปที่ 1 Topic เดียว แล้ว subscribers ทุกตัวที่ subscribe topic นั้นจะได้รับ message ทุกอัน

• •Up to 10,000,000 subscriptions ต่อ 1 topic
• •Limit 100,000 topics ต่อ AWS account
• •Push-based — SNS push ไปหา subscribers ทันทีที่มี message ใหม่
• •ไม่มี message retention — ถ้า subscriber รับไม่ทัน message หาย (ยกเว้น HTTP retry)

Publisher ──► SNS Topic ──┬──► SQS Queue A ──► Service A
                          ├──► SQS Queue B ──► Service B
                          ├──► SQS Queue C ──► Service C
                          └──► Lambda Function ──► Service D

  - Publisher ส่งครั้งเดียว → ทุก subscriber ได้รับ
  - แต่ละ consumer process อิสระกัน
  - เพิ่ม subscriber ใหม่ได้โดยไม่แก้ publisher
  - SQS ใน fan-out ทำหน้าที่ buffer + persistence

SNS Filtering: Subscriber แต่ละตัวสามารถกำหนด filter policy (JSON) เพื่อรับเฉพาะ messages ที่ตรงตามเงื่อนไข — ลด load และ cost (ไม่ต้อง process message ที่ไม่เกี่ยวข้อง)

SNS และ SQS มักถูกถามให้เปรียบเทียบในข้อสอบ — เข้าใจความแตกต่างเพื่อเลือกใช้ถูกตัว:

Feature              | SNS                      | SQS
─────────────────────|──────────────────────────|─────────────────────────
Model                | Pub/Sub (push)           | Queue (pull)
Distribution         | One-to-many (broadcast)  | One-to-one (compete)
Retention            | ไม่เก็บ (no retention)     | 4 วัน default, 14 วัน max
Subscribers / Consumers | 10M subscribers/topic | unlimited consumers
DLQ                  | Yes (ผ่าน SQS)            | Yes (built-in)
Use Case             | Notifications, fan-out   | Decoupling, buffering

Amazon Kinesis เป็น managed service สำหรับ real-time big data streaming — เก็บ, process, วิเคราะห์ streaming data ที่ scale ได้ระดับ big data

• •Real-time ไม่ใช่ batch — process data ทันทีที่เข้ามา
• •Scale ได้ระดับ หลายแสน data sources พร้อมกัน
• •เหมาะสำหรับ application logs, metrics, IoT, clickstreams, social media data
• •เก็บข้อมูลใน stream ได้ 1-365 วัน สำหรับ replay และ multiple consumers

IoT Sensors ──► Kinesis Data Streams ──► Kinesis Data Analytics (SQL real-time)
   (100k sensors)                          ──► Kinesis Data Firehose ──► S3 (archive)
                                            ──► Lambda ──► DynamoDB (alerts)

Amazon MQ เป็น managed message broker สำหรับ traditional protocols ที่ใช้กันมานานก่อนยุค cloud-native — เช่น MQTT, AMQP, STOMP, Openwire, WSS

• •Managed Apache ActiveMQ และ RabbitMQ
• •รองรับ protocols: MQTT, AMQP, STOMP, Openwire, WSS
• •มีทั้ง queue feature (~SQS) และ topic feature (~SNS) ในตัวเดียว
• •ไม่ scale ได้แบบ SQS/SNS — รันบน dedicated server (ไม่ใช่ serverless)
• •เหมาะกับการ migrate on-premises applications มาที่ cloud โดยไม่ต้อง re-engineer code

                    | Amazon MQ          | SQS / SNS
────────────────────|────────────────────|───────────────────
Type                | Managed broker     | Cloud-native service
Protocols           | MQTT, AMQP, STOMP, | AWS proprietary API
                    | Openwire, WSS      |
Scale               | Limited (server)   | Massive (serverless)
Architecture        | Dedicated machines | Fully serverless
Features            | Queue + Topic      | SQS=queue, SNS=topic
Use case            | Migrate on-prem    | Cloud-native apps

Note: Amazon MQ ทำงานบน dedicated machines (instance-based) จึงต้อง provision capacity ล่วงหน้า ต่างจาก SQS/SNS ที่เป็น serverless และ scale อัตโนมัติ

Decision matrix สำหรับเลือก integration service ที่เหมาะกับงาน — เป็นจุดที่ข้อสอบมักถามบ่อย:

"async background job processing"          → SQS
"send email/SMS notification"               → SNS
"broadcast event ไป 5 services พร้อมกัน"     → SNS + SQS (Fan-out)
"real-time IoT sensor data + analytics"     → Kinesis
"clickstream / log streaming + S3 archive"  → Kinesis Data Firehose
"migrate Java app ที่ใช้ AMQP จาก on-prem"  → Amazon MQ
"order processing — ห้ามหาย ถ้า consumer ล่ม" → SQS
"trigger Lambda จาก S3 upload"              → SNS (หรือ S3 event direct)

สรุปบริการในกลุ่ม Cloud Integration ที่ออกข้อสอบ CLF-C02 บ่อย — แต่ละตัวมีจุดเด่นและ use case ของตัวเอง:

• •SQS: queue, pull-based, retention 4-14 วัน, มี Visibility Timeout + DLQ, message size 256 KB
• •SNS: pub/sub, push-based, สูงสุด 10M subscribers/topic, รองรับ Email/SMS/HTTP/SQS/Lambda
• •Kinesis: real-time streaming big data — Streams, Firehose, Analytics, Video Streams
• •Amazon MQ: managed broker (ActiveMQ/RabbitMQ) สำหรับ MQTT/AMQP/STOMP — ใช้ migrate on-prem