Penyaringan Pesan SQS dan Integrasi SNS + SQS

Dalam arsitektur fan-out tanpa pemfilteran, setiap pelanggan SQS menerima setiap pesan SNS. Jika topik Anda menerbitkan peristiwa pesanan untuk 10 kategori produk berbeda, tetapi sebuah pelanggan hanya memproses pesanan elektronik, pelanggan tersebut tetap menerima dan harus membuang pesan makanan serta pakaian. Hal ini memboroskan komputasi, meningkatkan biaya, dan menambah beban yang tidak diperlukan pada konsumen. Kebijakan filter langganan SNS menyelesaikan masalah ini dengan membuat SNS sendiri merutekan pesan hanya kepada pelanggan yang sesuai.

Kebijakan filter adalah objek JSON yang diterapkan pada langganan SQS atau Lambda. SNS mengevaluasi kebijakan terhadap atribut pesan setiap pesan sebelum mengirimkannya. Jika atribut pesan cocok dengan kebijakan filter, pesan dikirimkan; jika tidak, SNS melewati pelanggan tersebut tanpa pemberitahuan. Kebijakan filter mendukung pencocokan string, rentang numerik, pencocokan awalan, serta operator exists untuk memeriksa keberadaan atau ketiadaan atribut.

Secara default, kebijakan filter dicocokkan dengan atribut pesan (metadata). Sejak 2023, SNS juga mendukung pemfilteran berbasis payload (isi) dengan menetapkan cakupan kebijakan filter ke MessageBody. Hal ini memungkinkan pemfilteran berbasis jalur JSON langsung pada isi pesan tanpa mengharuskan penerbit menambahkan atribut. Pemfilteran isi lebih fleksibel, tetapi mengharuskan isi pesan berupa JSON yang valid. Selalu pastikan cakupan yang sesuai dengan format output penerbit Anda.

Kebijakan filter mendukung beberapa operator pencocokan selain kesetaraan string sederhana:

• Numerik: {"numeric": ["=", 100]}, {"numeric": [">", 50, "<=", 200]}
• Awalan: {"prefix": "order-"} cocok dengan string apa pun yang diawali awalan tersebut
• Selain-ini: {"anything-but": ["CANCELLED"]} cocok dengan nilai apa pun selain yang tercantum
• Ada: {"exists": true} cocok jika atribut tersedia; false jika tidak tersedia

Agar pemfilteran berfungsi, penerbit harus menyertakan atribut pesan saat menerbitkan ke SNS. Atribut berupa pasangan kunci-nilai dengan tipe data (String, Number, Binary). Penerbit tidak perlu mengetahui pelanggan mana yang memiliki kebijakan filter tertentu—penerbit cukup memperkaya pesan dengan atribut yang menjelaskan peristiwa tersebut. SNS menangani perutean secara otomatis. Ini membuat penerbit tetap sepenuhnya terpisah dari logika khusus pelanggan.

Topologi fan-out yang canggih dapat membuat SNS merutekan ke antrean SQS pada beberapa tingkat kekhususan: satu antrean menerima semua pesanan (tanpa filter) untuk audit, antrean lain hanya menerima pesanan HIGH_VALUE (jumlah >= 1000) untuk peninjauan penipuan, dan antrean ketiga hanya menerima pesanan ELECTRONICS untuk gudang elektronik. Setiap antrean SQS memiliki konsumen Lambda sendiri. Pola ini menskalakan setiap tingkat pemrosesan secara mandiri dan menambahkan konsumen baru tanpa menyentuh konsumen yang ada maupun penerbit.

SNS dapat mengirimkan pesan ke antrean SQS di akun AWS yang berbeda. Kebijakan berbasis sumber daya antrean SQS harus mengizinkan principal layanan SNS memanggil sqs:SendMessage dari ARN topik SNS akun penerbit. Hal ini memungkinkan penerbitan peristiwa terpusat (satu akun menerbitkan, tim dari beberapa akun berlangganan) tanpa berbagi kredensial. Fan-out lintas akun adalah pola umum dalam pengaturan AWS Organizations dengan banyak akun.

Saat volume peristiwa melonjak, pemanggilan langsung SNS-ke-Lambda langsung menskalakan Lambda, yang berpotensi membebani basis data atau API hilir. Menambahkan SQS di antara SNS dan Lambda menciptakan penyangga: SNS mengirimkan ke SQS, lalu Lambda melakukan polling SQS dengan ukuran batch yang terkendali. Ini memungkinkan Lambda memproses pada laju yang berkelanjutan sementara SQS menyerap lonjakan lalu lintas. Kedalaman antrean berfungsi sebagai mekanisme tekanan balik—Anda dapat memantaunya dan mengirim peringatan ketika nilainya melampaui ambang batas yang menandakan keterlambatan konsumen.

SNS → Lambda (langsung): latensi paling rendah, tanpa penyangga, Lambda langsung diskalakan. Paling sesuai untuk peringatan waktu nyata atau notifikasi mendesak ketika latensi di bawah satu detik penting. SNS → SQS → Lambda: menambahkan dukungan DLQ, throughput terkendali, percobaan ulang dengan visibility timeout, serta pemantauan kedalaman antrean. Paling sesuai untuk pemrosesan transaksi, pembaruan inventaris, dan setiap skenario yang harus mematuhi batas sistem hilir. Untuk pertanyaan ujian, pilih penyanggaan SQS setiap kali ketahanan dan pengendalian laju disebutkan.

Gunakan editor kebijakan penyaringan di konsol SNS untuk menguji apakah contoh pesan akan cocok dengan kebijakan penyaringan Anda sebelum diterapkan. Anda juga dapat menggunakan Sandbox SNS untuk menyimulasikan pengiriman pesan dan memverifikasi perutean. Dalam kode, validasikan kebijakan penyaringan dengan menerbitkan pesan uji yang atributnya telah diketahui, lalu periksa metrik CloudWatch untuk setiap langganan: metrik NumberOfMessagesFiltered menunjukkan jumlah pesan yang diblokir oleh penyaring, sehingga Anda dapat menyempurnakan kebijakan tanpa menunggu kejadian di lingkungan produksi.

Integrasi SNS + SQS yang lengkap berlangsung seperti ini: (1) Aplikasi menerbitkan suatu kejadian ke topik Standar SNS dengan atribut pesan; (2) SNS mengevaluasi setiap kebijakan penyaringan langganan dan hanya mengirimkan pesan yang cocok ke setiap antrean SQS; (3) Lambda melakukan polling pada setiap antrean SQS dengan ukuran batch yang dikonfigurasi dan memproses pesan; (4) Pesan yang gagal mencapai DLQ setelah maxReceiveCount; (5) alarm CloudWatch pada kedalaman DLQ memberi tahu tim. Pola yang sepenuhnya terpisah dan tangguh ini merupakan contoh arsitektur SAA-C03.

Uji pemahaman Anda tentang konsep AWS Solutions Architect (SAA-C03) dari pelajaran ini.

Dalam pelajaran ini Anda mempelajari bahwa kebijakan penyaringan SNS merutekan pesan berdasarkan atribut pesan atau isi isi pesan pada tingkat SNS, sehingga pemrosesan yang tidak diperlukan oleh konsumen hilir dapat dihilangkan; pola SNS→SQS→Lambda menambahkan penyanggaan yang tahan lama dan pengaturan laju di antara siaran fan-out dan pemrosesan; serta pengiriman SQS lintas akun memungkinkan pub/sub terpusat di lingkungan multi-akun menggunakan kebijakan sumber daya antrean. Berikutnya kita akan membahas API REST, HTTP, dan WebSocket dari Amazon API Gateway.