Messaging Konsepti

Kullanıcıların video yüklediği ve bu videoların encode edilip farklı platformlarda resolution edilmesi gerektiği bir sisteminiz olduğunu varsayalım. Bir api gatewayimiz olsun bir de encode işlemini yapan encoder servisimiz. Api gateway clienttan requesti alıp S3 gibi bir file store’a upload eder ve arkasından enconding service’e dosyayı process etmesi için request atar. Enconding işleminin tamamlanması dakikalar alabileceği için apigatewayin bu noktada response beklemeden request göndermesini isteriz. Ancak naive yaklaşım olan fire-and-forget kullanıldığı takdirde, encoding servis bu requesti işlerken crash olursa requesting kaybolması gibi durumlarla karşı karşıya kalabiliriz.

Daha sağlam bir çözüm api gateway ile encoding service arasında message channel koymaktır. Producer message’ı channela yazar consumer da bu channeldan mesajı okur. Async bir iletişim vardır. Bu yüzden alıcı tarafın ayakta olup olmaması da sistemi aksatmaz.

Message channela bırakılan mesajlar command ya da event olarak ikiye ayrılır. Command daha çok receiver tarafında belirlenen bir operasyonu tetiklemek iken event ise receiverın bir olaydan haberdar olması ve buna karşın alması gereken aksiyon varsa alması içindir.

Apı gateway videoyu file store’a upload ettiğinde kanala uploaded file’ın linkini attach ettiği bir message fırlatır ve 202 accepted döner ki bu da clienta request alındı ancak tam olarak işlenmediyi belirtir. Bir noktada encoder bu message’ı okuyup işlemeye başlacaktır. Message sadece consumer tarafından alınıp başarılı bir şekilde işlendikten sonra silineceği için, tekrar tekrar  channeldan alınıp retry edilebilir durumdadır. Bu noktada artık sağlıklı bir yapımız var diyebiliriz.

Message channel kullanmanın sisteme katacağı faydaları bu linkteki yazımdan okuyabilirsiniz

Genel olarak chanellara birden fazla producer message bırakabilir ve birden fazla consumer bunu consume edebilir. Ancak channelin message’ı deliver ediliş şekline göre iletişim point-to-point ya da publish-subscribe olarak adlandırılır. Point-to-point iletişimde message sadece bir consumer’a teslim edilirken, publish and subscribe iletişimde birden fazla consumer messagein copyasını kendine alabilir.

Bunun yanında tabiki message broker maintain ve operate edilmesi gereken bir yapı olacağı için sisteme ek complexity getirir. Ayrıca servisler arasında yeni bir bağlantı-hop olduğu için communication latency de olacaktır. 

One-Way Messaging 

Producerın mesajı point-to-point bir chanella yazdığı ve consumerin da okuduğu iletişim şeklidir.

Request-Response Messaging 

Producer mesaji bir mesaj id si ile channela yazar. Consumer da bu mesajı okuyup işledikten sonra bir response channela aynı id ile mesajı producerin alıp işlemesi için geri yollar.

Broadcast messaging 

Publish-subscribe temeline dayanır. Bir grup processi event için haberdar etmek için kullanılır. Mesaj broadcast olarak birden fazla consumera yayılabilir.

Message Guarantees

Message chanellar belli message servisleri ya da brokerları tarafından implemente edilir. Farkı brokerlar tradeofflara göre farklı özellikler sunarlar. Bunlar

• Ordering
• At-most-once ve at-least-once gibi Delivery guarantee’leri
• Latency
• AMQP gibi Messaging standartları
• Desteklenen maximum message size’i gibi Broker limitleri

Exactly-once Processing Konsepti

Önceden de bahsettiğim gibi, consumer bir mesajı okuyup işledikten sonra tekrar okumamak için channeldan silmeli. Ancak consumer mesajı alır almaz işlemeden silerse, crash olması durumunda mesaj kaybolabilir ya da process ettikten sonra silerse de mesajın process edildikten sonra tam silinme aşamasında crash olursa tekrar mesajı okuma gibi bir duruma gidebilir.

Bu sebeple exactly-once message delivery gibi bir durum asla sağlanamaz ancak yapılabilecek en iyi şey idempotent consumerlar tasarlayarak exactly-once message processingi simule etmek ve process edildikten sonra silmektir.

Failure’lar

Consumer mesajı process ederken fail oldugunda mesaj retrya girerek tekrar tekrar tetiklenebilir. Peki sürekli aynı hatayı aldığı durumda ne olur. Bu noktada retry sayısını limitlemek gereklidir. Sonrasında da bu retry sayısına ulaşıldığında ne yapılacağına karar verilmelidir. Her ne olursa olsun consumer mesajı process etmeden mesaj silinmemelidir. Ancak channeldan silip dead letter queue’ya atabilirz. Bu sayede sürekli fail olan mesajlar kaybolmamış ve aynı zamanda main chaneli tüketip consumer resourceindan yememiş olur . Ayrıca Developerlar da hatayı debug etmek için bu mesajları inceleyip fixleyebilir sonrasında da tekrar işlemeye gönderebilir.

Fault isolation

Producer hatalı ve sürekli olarak fail olan mesajlar yollayarak consumerin performansını düşürebilir ve bir backlog yaratabilir. Backlog olması demek message channelda messageların yığılarak birikmesi veya işlenememesi durumudur. Bu gibi durumların tespitinde consumer bu mesajlara daha farklı yaklaşabilir. Örneğin hatalı gelen bir mesaj bir kullanıcıdan geliyorsa consumer  bunu alternatif low pritority channela yazabilir ve main chaneldan işlemeden silebilir. Consumer slow chaneldan mesajları okur ancak main chanel göre daha az sıklıkla. Bu da bir tane hatalı userin diğerlerini etkilemesini önler

Bunun yanında backlog oluşmasına consumer performansının düşmesi, producerın consumer hızından daha hızlı publish etmesi ya da consumerın down olması da sebep olabilir.