Batas Waktu Visibilitas, DLQ, dan Polling Panjang

Ketika konsumen menerima pesan dari SQS, pesan tersebut disembunyikan dari semua konsumen lain selama periode yang disebut batas waktu visibilitas. Selama jangka waktu ini, konsumen memproses pesan lalu menghapusnya. Jika konsumen mengalami kerusakan atau tidak selesai tepat waktu, batas waktu visibilitas berakhir dan pesan menjadi terlihat kembali, sehingga konsumen lain dapat mengambilnya. Inilah mekanisme utama di balik jaminan pengiriman setidaknya sekali dari SQS.

Batas waktu visibilitas default adalah 30 detik. Nilainya dapat diatur dari 0 detik hingga 12 jam. Aturlah agar sedikit lebih lama dari waktu pemrosesan maksimum yang diharapkan—jika pemrosesan memerlukan waktu hingga 2 menit, tetapkan batas waktu setidaknya 3–4 menit. Anda juga dapat mengubah batas waktu per receipt menggunakan change-message-visibility, yang berguna ketika konsumen mendeteksi bahwa waktu tambahan diperlukan untuk menyelesaikan pemrosesan pesan tertentu.

Menetapkan batas waktu yang terlalu singkat menyebabkan pesan muncul kembali sebelum konsumen selesai, sehingga terjadi pemrosesan duplikat. Menetapkannya terlalu lama menunda konsumen lain mengambil pesan jika konsumen awal gagal tanpa diketahui (misalnya, instans EC2 mengalami kerusakan tanpa pembersihan yang baik). Batas waktu optimal adalah sedikit lebih lama daripada waktu pemrosesan persentil ke-99 Anda, tetapi cukup singkat agar dapat pulih dengan cepat dari kegagalan konsumen. Pantau metrik CloudWatch ApproximateNumberOfMessagesNotVisible untuk menemukan masalah batas waktu.

Queue Huruf Mati (DLQ) adalah queue SQS terpisah tempat pesan dikirim setelah gagal diproses beberapa kali sesuai konfigurasi (maxReceiveCount). Ketika jumlah penerimaan pesan melebihi maxReceiveCount, SQS secara otomatis memindahkannya ke DLQ. DLQ mencegah pesan beracun (pesan yang selalu gagal) memblokir queue tanpa batas. Pesan di DLQ dapat diperiksa, diperbaiki masalahnya, dan diputar ulang setelah bug pemrosesan diperbaiki.

DLQ hanyalah queue SQS biasa (Standard untuk sumber Standard, FIFO untuk sumber FIFO). Anda mengonfigurasi Kebijakan Pengalihan pada queue sumber untuk menentukan queue mana yang menjadi DLQ serta ambang maxReceiveCount. Pastikan periode retensi DLQ lebih lama daripada periode retensi queue sumber—pesan tiba di DLQ dalam keadaan sudah tertunda, dan Anda memerlukan waktu untuk menyelidikinya sebelum pesan kedaluwarsa.

Tetapkan alarm CloudWatch pada metrik ApproximateNumberOfMessagesVisible milik DLQ. Setiap pesan yang tiba di DLQ menunjukkan kegagalan pemrosesan yang perlu ditangani. Konfigurasikan alarm agar memicu notifikasi SNS yang segera menghubungi teknisi yang sedang bertugas. Perlakukan setiap pesan DLQ sebagai bug yang perlu diselidiki—pesan DLQ tidak boleh menumpuk tanpa diketahui. Setelah bug diperbaiki, gunakan Pengalihan DLQ untuk mengirim pesan kembali ke queue sumber agar diproses ulang.

Setelah memperbaiki bug yang menyebabkan kegagalan pemrosesan, gunakan Pengalihan DLQ SQS untuk memindahkan pesan dari DLQ kembali ke queue sumber agar diproses ulang. Konsol menyediakan kemampuan pengalihan bawaan. Anda dapat memfilter berdasarkan atribut pesan untuk memutar ulang hanya pesan tertentu. Sebagai alternatif, tulislah fungsi Lambda untuk melakukan polling terhadap DLQ dan meneruskan pesan kembali ke queue sumber jika Anda memerlukan logika pemfilteran khusus.

Secara default, SQS menggunakan polling singkat: panggilan receive-message mengambil sampel acak dari sebagian server dan segera mengembalikan hasil—bahkan jika tidak ada pesan yang tersedia. Hal ini menghasilkan banyak respons kosong dan memboroskan panggilan API. Polling panjang menunggu hingga 20 detik agar pesan tiba sebelum mengembalikan respons kosong. Polling panjang mengurangi biaya secara signifikan (lebih sedikit panggilan API) dan menurunkan latensi (pesan diterima segera setelah tiba, hingga 20 detik lebih cepat daripada siklus polling berikutnya).

Aktifkan polling panjang pada tingkat queue (berlaku untuk semua panggilan penerimaan) atau per permintaan. Konfigurasi tingkat queue dengan ReceiveMessageWaitTimeSeconds bernilai 20 adalah pengaturan yang direkomendasikan untuk sebagian besar aplikasi. Saat Lambda menggunakan SQS sebagai sumber peristiwa, Lambda secara otomatis menggunakan polling panjang. Untuk konsumen berbasis EC2, tetapkan WaitTimeSeconds dalam panggilan receive-message.

Pesan SQS dapat membawa atribut pesan—metadata berupa pasangan kunci-nilai yang terpisah dari isi pesan. Atribut memiliki jenis (String, Number, Binary) dan nilai. Saat SQS berlangganan ke topik SNS, Anda dapat menggunakan kebijakan filter langganan SNS yang diterapkan pada atribut pesan untuk mengarahkan hanya pesan yang relevan ke setiap queue. Tanpa pemfilteran, setiap pelanggan SQS menerima setiap publikasi SNS tanpa memandang isinya.

Queue Penundaan membuat setiap pesan baru tidak terlihat selama periode penundaan (0 hingga 15 menit) setelah dikirim. Ini berguna untuk alur kerja ketika konsumen tidak boleh segera memproses pesan—misalnya, karena harus menunggu proses yang bergantung padanya selesai terlebih dahulu. Anda juga dapat menetapkan penundaan per pesan menggunakan DelaySeconds dalam panggilan pengiriman, yang menggantikan penundaan tingkat queue. Catatan: queue penundaan tidak tersedia untuk queue FIFO.

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

Dalam pelajaran ini Anda mempelajari: Visibility Timeout menyembunyikan pesan dari konsumen lain selama pemrosesan, sehingga memungkinkan pengiriman setidaknya sekali dengan pengiriman ulang otomatis jika konsumen gagal, Dead-Letter Queues menampung pesan yang berulang kali gagal untuk penelusuran kesalahan dan diproses ulang setelah bug diperbaiki, serta Long Polling (waktu tunggu hingga 20 detik) mengurangi biaya API dan latensi dibandingkan polling singkat. Selanjutnya, kita akan membahas topik SNS dan arsitektur fan-out.