Görünürlük Zaman Aşımı, DLQ ve Uzun Yoklama

Bir tüketici SQS'den mesaj aldığında mesaj, görünürlük zaman aşımı adı verilen bir süre boyunca diğer tüm tüketicilerden gizlenir. Bu süre içinde tüketici mesajı işler ve ardından siler. Tüketici çöker veya mesajı zamanında tamamlayamazsa görünürlük zaman aşımı sona erer ve mesaj yeniden görünür hâle gelir; böylece başka bir tüketici mesajı alabilir. Bu, SQS'nin en az bir kez teslimat garantisinin temel mekanizmasıdır.

Varsayılan görünürlük zaman aşımı 30 saniyedir. Bu değer 0 saniye ile 12 saat arasında ayarlanabilir. Beklenen en uzun işleme süresini rahatça aşacak şekilde ayarlayın; işleme 2 dakikaya kadar sürüyorsa zaman aşımını en az 3-4 dakika olarak belirleyin. Ayrıca change-message-visibility kullanarak zaman aşımını makbuz başına değiştirebilirsiniz. Bu, tüketicinin belirli bir mesajın işlenmesini tamamlamak için daha fazla zamana ihtiyaç duyduğunu fark ettiği durumlarda kullanışlıdır.

Zaman aşımını çok kısa ayarlamak, tüketici işlemi tamamlamadan önce mesajların yeniden görünmesine ve yinelenen işlemeye neden olur. Zaman aşımını çok uzun ayarlamak ise özgün tüketici sessizce başarısız olduğunda (örneğin, düzgün bir temizlik işlemi gerçekleşmeden EC2 örneğinin çökmesi) başka bir tüketicinin mesajı almasını geciktirir. En uygun zaman aşımı, 99. yüzdelik dilimdeki işleme sürenizden biraz uzun, ancak tüketici hatalarından hızlıca kurtulmaya yetecek kadar kısa olmalıdır. Zaman aşımı sorunlarını belirlemek için ApproximateNumberOfMessagesNotVisible CloudWatch metriğini izleyin.

Ölü Harf Kuyruğu (DLQ), mesajların yapılandırılabilir sayıda başarısız işleme denemesinden sonra gönderildiği ayrı bir SQS kuyruğudur (maxReceiveCount). Bir mesajın alma sayısı maxReceiveCount değerini aştığında SQS, mesajı otomatik olarak DLQ'ya taşır. DLQ'lar, sürekli başarısız olan zehirli mesajların kuyruğu süresiz olarak engellemesini önler. DLQ'daki mesajlar incelenebilir, hataları ayıklanabilir ve işleme hatası düzeltildikten sonra yeniden oynatılabilir.

DLQ, yalnızca normal bir SQS kuyruğudur (Standard kaynak için Standard, FIFO kaynak için FIFO). Kaynak kuyrukta, hangi kuyruğun DLQ olduğunu ve maxReceiveCount eşiğini belirtmek üzere Yeniden Yönlendirme İlkesini yapılandırırsınız. DLQ'nın saklama süresinin daha uzun olmasını sağlayın; mesajlar DLQ'ya geç ulaşır ve süreleri dolmadan önce inceleme yapmak için zamana ihtiyacınız vardır.

DLQ'nın ApproximateNumberOfMessagesVisible metriği için bir CloudWatch alarmı ayarlayın. DLQ'ya ulaşan her mesaj, ilgilenilmesi gereken bir işleme hatasına işaret eder. Alarmı, nöbetçi mühendisinize hemen bildirim gönderen bir SNS bildirimi tetikleyecek şekilde yapılandırın. Her DLQ mesajını incelenmesi gereken bir hata olarak değerlendirin; DLQ mesajlarının sessizce birikmesine izin verilmemelidir. Hatayı düzelttikten sonra, mesajları yeniden işlenmek üzere kaynak kuyruğa göndermek için DLQ Yeniden Yönlendirme özelliğini kullanın.

İşleme hatalarına neden olan hatayı düzelttikten sonra, mesajları DLQ'dan kaynak kuyruğa yeniden işlenmek üzere taşımak için SQS DLQ Yeniden Yönlendirme özelliğini kullanın. Konsol, yerleşik bir yeniden yönlendirme özelliği sunar. Yalnızca belirli mesajları yeniden oynatmak için mesaj özniteliklerine göre filtreleme yapabilirsiniz. Alternatif olarak, özel filtreleme mantığına ihtiyacınız varsa DLQ'yu yoklayıp mesajları kaynak kuyruğa geri iletmek üzere bir Lambda işlevi yazabilirsiniz.

Varsayılan olarak SQS, kısa yoklama kullanır: Bir receive-message çağrısı sunucuların rastgele bir alt kümesini örnekler ve hiç mesaj olmasa bile hemen yanıt verir. Bu, çok sayıda boş yanıta yol açar ve API çağrılarını boşa harcar. Uzun yoklama, boş yanıt vermeden önce bir mesajın gelmesini 20 saniyeye kadar bekler. Uzun yoklama maliyetleri önemli ölçüde azaltır (daha az API çağrısı) ve gecikmeyi düşürür (mesaj, sonraki yoklama döngüsünden 20 saniyeye kadar daha erken, gelir gelmez alınır).

Uzun yoklamayı kuyruk düzeyinde (tüm alma çağrılarına uygulanır) veya istek başına etkinleştirebilirsiniz. Çoğu uygulama için ReceiveMessageWaitTimeSeconds değerinin 20 olduğu kuyruk düzeyi yapılandırması önerilen ayardır. Lambda, olay kaynağı olarak SQS'yi kullandığında uzun yoklamayı otomatik olarak kullanır. EC2 tabanlı tüketiciler için receive-message çağrısında WaitTimeSeconds değerini ayarlayın.

SQS mesajları, mesaj gövdesinden ayrı meta veri anahtar-değer çiftleri olan mesaj özniteliklerini taşıyabilir. Özniteliklerin bir türü (String, Number, Binary) ve bir değeri vardır. SQS bir SNS konusuna abone olduğunda, yalnızca ilgili mesajları her kuyruğa yönlendirmek için mesaj özniteliklerine uygulanan SNS abonelik filtre ilkelerini kullanabilirsiniz. Filtreleme olmadan, içeriğinden bağımsız olarak her SQS abonesi her SNS yayınını alır.

Bir Gecikme Kuyruğu, her yeni mesajı gönderildikten sonra bir gecikme süresi boyunca (0 ila 15 dakika) görünmez hâle getirir. Bu, bir tüketicinin mesajı hemen işlememesi gereken iş akışlarında, örneğin önce bağımlı bir işlemin tamamlanmasını beklerken kullanışlıdır. Ayrıca gönderme çağrısında DelaySeconds kullanarak mesaj başına gecikme ayarlayabilirsiniz; bu değer kuyruk düzeyindeki gecikmeyi geçersiz kılar. Not: Gecikme kuyrukları FIFO kuyruklarında kullanılamaz.

Bu dersteki AWS Solutions Architect (SAA-C03) kavramlarını anlayıp anlamadığınızı test edin.

Bu derste şunları öğrendiniz: Visibility Timeout, işleme sırasında bir mesajı diğer tüketicilerden gizleyerek en az bir kez teslimi mümkün kılar ve tüketici başarısız olursa otomatik yeniden teslimat gerçekleştirir; Dead-Letter Queues, hata ayıklandıktan sonra hata ayıklama ve yeniden oynatma için tekrar tekrar başarısız olan mesajları yakalar; Long Polling (20 saniyeye kadar bekleme süresi), kısa yoklamaya kıyasla API maliyetlerini ve gecikmeyi azaltır. Sırada SNS konularını ve fan-out mimarisini inceleyeceğiz.