SQS vs SNS: Memahami Layanan Messaging AWS

Menguasai AWS bisa jadi menantang, terutama saat memahami dua layanan intinya: Amazon Simple Queue Service (SQS) dan Amazon Simple Notification Service (SNS).

Meskipun keduanya menjadi bagian penting dari solusi cloud, sering kali keduanya disalahpahami dan digunakan secara keliru.

Dalam artikel ini, saya akan menguraikan peran SQS dan SNS, mengidentifikasi persamaan dan perbedaannya, serta menunjukkan bagaimana layanan ini dapat digunakan bersama untuk membangun arsitektur cloud berkinerja tinggi.

SQS vs SNS: Jawaban Singkat

Jika Anda sedang terburu-buru, berikut perbedaan utamanya:

SQS adalah layanan antrean pesan berbasis polling untuk mendekopel layanan, mendukung komunikasi A2A dan retensi pesan.
SNS adalah layanan notifikasi berbasis push untuk pesan waktu nyata, mendukung komunikasi A2A dan A2P.

Lanjutkan membaca untuk penjelasan lebih rinci, termasuk use case, diagram arsitektur, dan praktik terbaik!

Apa itu Amazon SQS?

Amazon Simple Queue Service (SQS) adalah layanan antrean pesan terkelola penuh yang memfasilitasi komunikasi antar komponen perangkat lunak. SQS menggunakan antrean untuk mendekopel mikrolayanan, yang memungkinkan Anda membuat alur kerja asinkron dalam aplikasi.

SQS terdiri dari tiga komponen inti:

Producer: Aplikasi yang mengirim pesan ke antrean.
Queue: Antrean menyimpan pesan hingga diproses. Periode retensi untuk pesan ini dapat diatur mulai dari 60 detik hingga 14 hari.
Consumer: Layanan yang menerima pesan dari antrean.

Diagram arsitektur Amazon SQS, termasuk komponen utama. Gambar oleh Penulis.

SQS menawarkan dua jenis antrean pesan:

Antrean standar menyediakan throughput tak terbatas, pengantaran minimal sekali (artinya pesan selalu akan terkirim), dan best-effort-ordering.
Antrean FIFO menyediakan throughput tinggi, pemrosesan tepat sekali, dan pengantaran first-in-first-out (artinya pesan diterima persis sesuai urutan saat dikirim).

Untuk informasi lebih lanjut mengenai jenis antrean ini, silakan kunjungi dokumentasi AWS.

Amazon SQS dirancang dengan persistensi pesan untuk menyimpan semua pesan dengan aman hingga diproses, memastikan tidak ada pesan yang hilang. SQS terlebih dahulu memungkinkan beberapa kali percobaan untuk memproses suatu pesan. Jika pesan tidak dapat diproses setelah semua upaya habis, Anda dapat menyimpan pesan yang tidak terproses dalam dead-letter queue, yang kemudian dapat ditinjau dan diproses ulang.

Dengan mendekopel aplikasi, Amazon SQS menawarkan sejumlah manfaat. Ia mengakomodasi throughput pesan yang tinggi, memastikan kinerja tinggi bahkan saat beban trafik meningkat. Selain itu, ia menyediakan penskalaan independen, memastikan setiap layanan mendapatkan sumber daya yang cukup sesuai kebutuhannya. Ia juga meningkatkan keamanan dan durabilitas dengan mengenkripsi pesan dan menyimpannya di banyak server.

Untuk mempelajari lebih jauh tentang sistem antrean ini, pertimbangkan untuk membaca tutorial komprehensif SQS kami.

Apa itu Amazon SNS?

Amazon Simple Notification Service (SNS) adalah layanan messaging terkelola penuh yang mendukung komunikasi application-to-application (A2A) dan application-to-person (A2P). Layanan ini dirancang untuk notifikasi waktu nyata dan mengirimkan pesan ke aplikasi serta pengguna akhir secara skalabel dan efisien.

Serupa dengan SQS, Amazon SNS mendukung persistensi pesan dengan memungkinkan pengguna membuat dead-letter queue untuk menyimpan pesan yang tidak dapat diproses.

Amazon SNS menggunakan model messaging publish/subscribe (pub/sub) dan terdiri dari 3 bagian:

Publisher: Sistem yang membuat dan mengirim pesan ke topik SNS.
Topic: Titik akses yang memungkinkan pengiriman pesan ke banyak endpoint.
Subscriber: Subscriber, atau consumer, adalah endpoint yang menerima pesan dari topik.

Diagram arsitektur model messaging SNS. Sumber gambar: AWS

SNS sangat andal dan dapat mengirim pesan ke banyak subscriber secara bersamaan. Untuk komunikasi A2A, SNS dapat mengirimkan pesan ke AWS Lambda, Amazon Kinesis Firehose, dan bahkan Amazon SQS. Untuk komunikasi A2P, SNS dapat mengirim pesan langsung ke pengguna melalui SMS, email, atau push notification.

Jika Anda ingin menguasai AWS dan dapat mengintegrasikan banyak layanannya untuk menciptakan solusi optimal, pertimbangkan untuk mengambil kursus AWS Cloud Technology and Services.

Fitur-fitur, termasuk sistem peringatan, arsitektur fan-out, dan notifikasi waktu nyata, berkontribusi pada tingkat ketangguhan dan keandalan Amazon SNS yang tinggi. Karena throughput pesan yang tinggi dan kemampuannya untuk komunikasi A2A dan A2P, SNS sering menjadi komponen integral dalam arsitektur berbasis peristiwa.

Perbedaan Inti antara SQS dan SNS

Memilih antara SQS dan SNS memerlukan pemahaman yang kuat tentang perbedaan kedua layanan messaging ini. Bagian ini menguraikan kriteria utama yang membedakan keduanya.

Push vs berbasis polling

Amazon SQS menggunakan sistem polling di mana consumer secara berkala melakukan polling pada antrean untuk memeriksa pesan baru.

Amazon SNS, sebagai sistem berbasis push, secara otomatis mendorong pesan ke subscriber segera setelah dipublikasikan pada sebuah topik.

Jenis penerima

Amazon SQS hanya mendukung komunikasi A2A, memungkinkan pesan dikirim ke layanan AWS lain, seperti AWS EC2, AWS Lambda, AWS RDS, dan AWS Redshift.

Amazon SNS mendukung komunikasi A2A dan A2P, mengirimkan pesan ke layanan AWS (misalnya, AWS S3, AWS EC2) dan kontak pengguna (misalnya, SMS dan email) sebagai subscriber.

Retensi pesan

Amazon SQS dapat menyimpan pesan hingga 14 hari, memberi waktu yang cukup bagi consumer untuk memprosesnya. Di sisi lain, Amazon SNS tidak menyimpan pesan apa pun, melainkan mengirimkannya ke subscriber segera setelah dipublikasikan.

Model pengantaran pesan

Amazon SQS menggunakan model satu-ke-satu, di mana hanya satu consumer yang memproses setiap pesan. Bahkan jika banyak consumer melakukan polling pada saat yang sama, hanya satu consumer yang akan menerima suatu pesan. Saat consumer tersebut memproses pesan, SQS memanfaatkan fitur visibility timeout untuk membuat pesan itu tidak terlihat oleh consumer lain.

Amazon SNS mendukung pola fan-out, di mana pesan yang sama pada suatu topik dikirim ke setiap subscriber secara bersamaan. Para subscriber ini memproses pesan yang diterima secara independen.

Batching

Amazon SQS memungkinkan pengguna melakukan batching pesan, yakni mengirim pesan ke consumer dalam kelompok. Ukuran batch dapat dikonfigurasi di AWS.

Amazon SNS tidak mendukung batching, hanya memungkinkan satu pesan diproses pada satu waktu.

Tabel berikut merangkum perbedaan utama ini:

Kriteria	Amazon SQS	Amazon SNS
Push versus berbasis polling	Berbasis polling: Consumer melakukan polling antrean untuk pesan baru	Berbasis push: Secara otomatis mendorong pesan ke subscriber
Jenis penerima	Mendukung komunikasi A2A	Mendukung komunikasi A2A dan A2P
Retensi pesan	Menyimpan pesan hingga 14 hari	Tidak menyimpan pesan
Model pengantaran pesan	Mendukung pesan satu-ke-satu	Mendukung fan-out (satu-ke-banyak)
Batching	Mendukung batching pesan	Tidak mendukung batching pesan

Kapan Menggunakan SQS

SQS adalah opsi yang disukai untuk arsitektur cloud ketika sistem pengantaran pesan membutuhkan:

Sistem polling - consumer dapat memilih kapan melakukan polling pesan.
Pemrosesan asinkron - layanan dapat memproses pesan secara independen.
Retensi pesan - pesan dapat disimpan hingga 14 hari.
Pengantaran pesan terjamin - tidak ada pesan dalam antrean yang hilang.
Batching - layanan memproses pesan dalam kelompok.

Pertimbangkan contoh nyata berikut: Sebuah platform e-commerce ingin memproses pesanan pelanggan, yang mencakup menyimpan data terkait pesanan dalam basis data RDS.

Diagram arsitektur sistem yang menggunakan Amazon SQS untuk memproses data—gambar oleh Penulis.

Dalam alur kerja ini, pelanggan mengirimkan pesanan, yang masuk ke antrean SQS. Fungsi Lambda (yakni consumer) melakukan polling pada antrean, menerima pesan, lalu menuliskan data ke basis data RDS.

Ada beberapa manfaat menggunakan SQS untuk use case ini. Karena SQS mendekopel proses, pelanggan dapat mengirimkan pesanan bahkan ketika basis data tidak beroperasi. Karena SQS menawarkan pengantaran minimal sekali, semua pesanan akan diproses tanpa risiko kehilangan pesan. Terakhir, SQS mendukung batching, yang memungkinkan pesan diproses dalam kelompok, sehingga meningkatkan efisiensi.

Amazon SNS tidak cocok di sini karena tidak menyimpan pesan dan justru akan segera mendorong pesan ke fungsi Lambda tanpa memedulikan status basis data. Jadi, jika basis data menjadi tidak tersedia, pesan dapat hilang. Selain itu, karena SNS tidak mendukung batching, ia akan memproses pesan satu per satu, sehingga kurang optimal.

Kapan Menggunakan SNS

SNS adalah opsi yang disukai untuk arsitektur cloud ketika sistem pengantaran pesan membutuhkan:

Notifikasi waktu nyata - pesan segera didorong ke subscriber dengan latensi rendah.
Distribusi fan-out - banyak subscriber dapat menerima pesan yang sama secara bersamaan.
Banyak subscriber notifikasi - pesan dapat dikirim ke aplikasi (misalnya, AWS Lambda) dan pengguna akhir (misalnya, email).

Pertimbangkan skenario di mana seorang developer memantau penggunaan CPU dari instance EC2 mereka. Untuk memastikan penggunaan tetap rendah, mereka ingin memantau metrik pemanfaatan CPU di CloudWatch dan menerima notifikasi setiap kali melampaui ambang batas tertentu.

Amazon SNS akan sangat membantu developer dalam membuat solusi karena mendorong notifikasi secara waktu nyata dan mendukung proses A2A serta A2P. Dengan pola fan-out, SNS dapat segera mengirim notifikasi ke fungsi Lambda yang dapat bekerja mengatasi masalah dan kepada developer melalui email untuk memberi tahu tentang alarm yang terpicu.

Diagram arsitektur sistem yang menggunakan Amazon SNS untuk pemantauan—gambar oleh Penulis.

Amazon SQS akan kurang efektif untuk tugas ini karena retensi pesannya. Jika developer ingin merespons pelanggaran ambang batas, mereka perlu menerima peringatan waktu nyata, yang tidak memungkinkan jika pesan disimpan dalam antrean. Selain itu, karena SQS menggunakan sistem polling, pesan hanya diakses ketika dipolling oleh consumer, yang meningkatkan latensi.

Amazon SQS dan Amazon SNS memiliki fitur dan karakteristik yang berbeda, tetapi pengguna AWS dapat memaksimalkan keduanya dengan mengombinasikannya untuk membangun sistem messaging yang efisien, skalabel, dan toleran kesalahan.

Mengintegrasikan kedua layanan ini mudah karena antrean SQS dapat menjadi subscriber pada topik SNS. Jadi, SNS dapat mengirim notifikasi waktu nyata ke antrean SQS, setelah itu SQS akan mendekopel semua proses sambil memastikan pengantaran pesan.

Pertimbangkan contoh berikut: Seorang developer AWS membuat sistem pengiriman dokumen yang mengekstrak konten dari dokumen yang dikirimkan oleh pengguna akhir. Sistem ini harus melakukan dua tugas untuk setiap dokumen yang dikirimkan:

Memproses dokumen menggunakan aplikasi pemrosesan teks.
Mengirim email konfirmasi kepada pengguna akhir.

Developer dapat menggabungkan SQS dan SNS untuk membuat solusi yang efisien:

Diagram arsitektur sistem yang menggunakan SNS bersama SQS—gambar oleh Penulis.

Dalam alur kerja ini, sebuah pesan dikirim ke topik SNS ketika pengguna mengirimkan dokumen, yang langsung mendorong pesan ke fungsi Lambda dan antrean SQS. Fungsi Lambda bertugas mengirim email konfirmasi, sementara antrean SQS akan menangani pesan, yang akan dipolling oleh instance EC2 yang menjalankan aplikasi pemrosesan teks.

Kesimpulan

Amazon SQS dan SNS adalah layanan inti dalam ekosistem AWS, masing-masing menawarkan keunggulan yang berbeda. SNS menawarkan notifikasi waktu nyata, sementara SQS menawarkan pemrosesan pesan yang andal.

Solusi messaging yang ideal untuk suatu masalah dapat melibatkan SNS, SQS, atau keduanya. Dengan memahami seluk-beluk kedua layanan, developer AWS dapat membangun solusi messaging yang sesuai dengan kebutuhan bisnis mereka yang unik, memastikan efisiensi, skalabilitas, dan ketangguhan.

Jika Anda ingin meningkatkan pengetahuan AWS ke tingkat berikutnya, pertimbangkan untuk mengambil dua kursus lanjutan ini:

Atau bahkan bersiap untuk sertifikasi AWS Cloud Practitioner dengan skill track kami:

AWS Cloud Practitioner (CLF-C02)

FAQs

Bisakah saya mengintegrasikan Amazon SQS dan SNS dengan layanan AWS lainnya?

Ya, baik SQS maupun SNS terintegrasi mulus dengan berbagai layanan AWS. Misalnya, Anda dapat memicu fungsi AWS Lambda dengan pesan dari SQS atau SNS, mengirim notifikasi ke Amazon S3 saat file baru diunggah, atau menggunakan Amazon CloudWatch untuk memantau kinerja SQS dan SNS Anda.

Bagaimana cara memastikan keandalan pengantaran pesan dengan SQS dan SNS?

Dengan SQS, Anda dapat menggunakan dead-letter queue (DLQ) untuk menangkap pesan yang gagal diproses setelah beberapa kali percobaan, memastikan tidak ada data yang hilang. Untuk SNS, Anda dapat mengonfigurasi percobaan ulang atau mekanisme fallback jika pengantaran pesan gagal, seperti menggunakan SQS sebagai subscriber cadangan ke sebuah topik SNS.

Bisakah saya menggabungkan SQS dan SNS dalam satu arsitektur?

Ya, SQS dan SNS dapat digabungkan untuk membuat arsitektur messaging hibrida. Misalnya, SNS dapat mendorong notifikasi waktu nyata ke banyak consumer, termasuk antrean SQS. Ini memungkinkan Anda memperoleh manfaat notifikasi waktu nyata (SNS) dan pemrosesan yang andal serta tertunda (SQS).

Apa model harga untuk SQS dan SNS?

Baik SQS maupun SNS mengikuti model harga bayar sesuai penggunaan. SQS menagih berdasarkan jumlah permintaan, transfer data, dan fitur tambahan seperti long polling. SNS menagih berdasarkan jumlah pesan yang diterbitkan dan metode pengantarannya (misalnya, email, SMS, atau endpoint HTTP). Penting untuk memantau penggunaan Anda guna mengontrol biaya, terutama untuk aplikasi dengan frekuensi tinggi.

Bagaimana cara mengoptimalkan kinerja saat menggunakan SQS dan SNS?

Untuk mengoptimalkan kinerja, Anda dapat menggunakan batching dengan SQS untuk mengirim dan memproses banyak pesan sekaligus, mengurangi permintaan API dan biaya. Dengan SNS, pastikan subscriber Anda dapat menangani throughput tinggi dengan menyiapkan autoscaling untuk layanan pemrosesan Anda (seperti Lambda atau EC2) agar dapat mengelola lonjakan trafik secara efisien.

Penulis

Aashish Nair

Sebagai calon data scientist, saya unggul dalam mengubah data mentah menjadi strategi yang dapat ditindaklanjuti. Saya mengkhususkan diri dalam memanfaatkan Python, SQL, dan teknik machine learning untuk menghasilkan solusi berdampak dalam analisis data serta merancang pipeline ETL yang andal untuk mengumpulkan dan memproses data dalam jumlah besar.

Topik

AWS Rekayasa Data