Topik SNS dan Arsitektur Penyebaran

Amazon Simple Notification Service (SNS) adalah layanan pesan pub/sub yang dikelola sepenuhnya. Penerbit mengirim pesan ke sebuah topik SNS, lalu SNS segera mengirimkan pesan tersebut kepada semua pelanggan. Berbeda dengan SQS (berbasis pull), SNS bersifat berbasis push—SNS mengirimkan pesan kepada pelanggan segera setelah pesan diterbitkan. Hal ini menjadikan SNS ideal untuk menyiarkan peristiwa ke beberapa sistem hilir secara bersamaan.

Seperti SQS, SNS memiliki dua jenis topik: Topik Standard menawarkan pengurutan pesan dengan upaya terbaik, pengiriman setidaknya sekali, dan throughput yang nyaris tidak terbatas—topik ini dapat mengirimkan pesan ke SQS, Lambda, titik akhir HTTP, email, SMS, dan push seluler. Topik FIFO menjamin pengurutan ketat dan pengiriman tepat satu kali hanya kepada pelanggan FIFO SQS. Topik FIFO mendukung hingga 3.000 pesan per detik dengan pemrosesan batch dan digunakan ketika urutan peristiwa harus dipertahankan di beberapa pelanggan.

SNS mendukung beberapa jenis pelanggan berbasis protokol:

• SQS: antrean tahan lama (paling umum untuk pemrosesan asinkron)
• Lambda: pemanggilan langsung (sinkron dari sudut pandang SNS)
• HTTP/HTTPS: pengiriman webhook ke titik akhir eksternal
• Email / Email-JSON: notifikasi untuk manusia
• SMS: pengiriman pesan teks
• Mobile Push: FCM, APNs melalui aplikasi platform
• Firehose: aliran ke S3 atau Redshift melalui Kinesis Data Firehose

Fan-out adalah pola utama SNS: menerbitkan satu pesan ke sebuah topik dan SNS mengirimkannya secara bersamaan kepada semua pelanggan. Sebagai contoh, peristiwa pesanan baru didistribusikan ke: antrean SQS untuk pemenuhan pesanan gudang, antrean SQS lain untuk pembaruan inventaris, fungsi Lambda untuk pendeteksian penipuan, dan langganan email untuk tim operasional. Setiap pelanggan memproses peristiwa secara mandiri tanpa ketergantungan satu sama lain. Pola ini jauh lebih skalabel daripada satu konsumen yang merutekan ke beberapa sistem.

Pola yang direkomendasikan menggabungkan SNS dan SQS: terbitkan ke SNS, yang mendistribusikannya ke beberapa antrean SQS. Pola ini menyediakan:

• Ketahanan: jika konsumen tidak aktif, pesan mengantre di SQS
• Penskalaan mandiri: setiap konsumen memproses sesuai kecepatannya sendiri
• Pemisahan: konsumen baru cukup berlangganan ke SNS tanpa mengubah penerbit
• Ketahanan terhadap percobaan ulang: SQS menyediakan visibility timeout dan DLQ

Pelanggan Lambda langsung tidak memiliki penyangga yang disediakan SQS, sehingga SNS→SQS→Lambda merupakan pola tiga lapis yang lebih tangguh.

Saat SNS gagal mengirimkan pesan kepada pelanggan (titik akhir HTTP mengembalikan 5xx, Lambda melempar pengecualian, SQS tidak tersedia), SNS mencoba lagi dengan strategi exponential backoff. Kebijakan percobaan ulang berbeda menurut protokol: titik akhir HTTP mendapat hingga 4 percobaan ulang langsung ditambah exponential backoff selama 23 hari; Lambda dan SQS mendapatkan percobaan ulang yang dikelola oleh mekanisme masing-masing. Konfigurasikan SNS Topic DLQ untuk menampung pesan yang telah menghabiskan seluruh percobaan ulang pengiriman, sehingga tidak ada peristiwa yang hilang tanpa diketahui.

Terbitkan ke SNS menggunakan AWS SDK atau CLI. Setiap pesan dapat menyertakan Subject (untuk email), isi Message (hingga 256 KB), serta Message Attributes untuk perutean. Untuk berbagai jenis pelanggan (SQS, email, atau seluler), Anda dapat menggunakan Message Structure untuk mengirimkan konten berbeda ke setiap protokol—JSON dengan kunci khusus protokol memungkinkan Anda menyesuaikan payload untuk setiap jenis pelanggan.

Kebijakan filter langganan memungkinkan setiap pelanggan menerima hanya pesan yang relevan baginya, berdasarkan atribut pesan. Tanpa pemfilteran, semua pelanggan menerima semua pesan yang diterbitkan. Dengan kebijakan filter, pelanggan menentukan nilai atribut yang menjadi perhatiannya. Sebagai contoh, antrean pesanan 'PREMIUM' berlangganan dengan filter {"orderType": ["PREMIUM"]}; antrean 'STANDARD' memfilter berdasarkan ["STANDARD"]. Setiap pelanggan hanya menangani subset yang relevan, sehingga mengurangi pemrosesan yang tidak diperlukan.

SNS mendukung notifikasi push seluler langsung ke perangkat iOS (APNs) dan Android (FCM/GCM). Anda mendaftarkan token perangkat sebagai ARN titik akhir platform, lalu menerbitkan langsung ke titik akhir atau ke topik dengan pelanggan aplikasi platform. Untuk notifikasi langsung ke perangkat dalam skala besar (jutaan perangkat), gabungkan SNS dengan fan-out SQS: SNS merutekan peristiwa notifikasi ke SQS, dan layanan pekerja menangani resolusi token massal serta pengiriman dalam skala besar.

Lindungi pesan SNS dengan enkripsi sisi server menggunakan AWS KMS. Ini mengenkripsi pesan saat disimpan dalam infrastruktur SNS. Kontrol akses menggunakan kebijakan berbasis sumber daya (siapa yang dapat menerbitkan ke atau berlangganan dari topik) dan kebijakan IAM. Untuk mengizinkan bucket S3 menerbitkan notifikasi ke topik SNS, berikan sns:Publish kepada principal layanan S3 dalam kebijakan sumber daya topik. Selalu batasi penerbitan pada sumber yang berwenang untuk mencegah penyisipan peristiwa tanpa otorisasi.

SNS dan SQS saling melengkapi, bukan alternatif. SNS (push) digunakan untuk menyiarkan ke beberapa konsumen secara langsung—gunakan saat beberapa sistem harus merespons suatu peristiwa. SQS (pull) digunakan untuk pemrosesan satu konsumen yang andal dan tahan lama, dengan percobaan ulang serta DLQ—gunakan saat satu konsumen harus memproses setiap pesan tepat satu kali sesuai kecepatannya sendiri. Pola fan-out SNS→SQS memberi Anda keduanya: pengiriman siaran dari SNS serta pemrosesan yang tahan lama dan dapat dicoba ulang dari SQS. Kombinasi ini sering muncul dalam skenario ujian SAA-C03.

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

Dalam pelajaran ini Anda mempelajari: topik SNS menyediakan siaran pub/sub berbasis push kepada pelanggan, termasuk SQS, Lambda, HTTP, SMS, dan email secara bersamaan, arsitektur fan-out menggunakan satu topik SNS yang mengirimkan pesan ke beberapa antrean SQS untuk mencapai pemrosesan peristiwa oleh banyak konsumen yang tahan lama dan dapat diskalakan secara mandiri, serta kebijakan filter langganan mengurangi pemrosesan yang tidak diperlukan dengan merutekan hanya peristiwa relevan kepada setiap pelanggan berdasarkan atribut pesan. Selanjutnya, kita akan membahas pemfilteran pesan SQS dan integrasi SNS + SQS secara mendalam.