Data Distribution Service (DDS) Nerede Kullanılır ve Kullanılmaz

Giriş

Bu yazıda bazı genel prensipler var. Bu prensipler bana "doğal" gelen kullanımlara göre yazıldı. Bazı durumlarda farklı teknolojileri kullanarak aynı sonuca erişmek mümkün olsa da, "doğal" hissiyatını vermiyor. 

DDS Hangi İşlere Uygun Değil

Bence DDS şu durumlara uygun değil

1. Merkezi bir broker gerektiren durum

2. Event Replay gerektiren durum

3. Consumer Group gerektiren durum

4. Çok yoğun mesaj geldiği durum

5. Remote Procedure Call gerektiren durum

1. Merkezi Broker Gerektiren Durum - Mesaj Kaybı Olmamalı

Genellikle bir event'in mutlaka bunu işleyen tüketiciye ulaşması durumudur. Tüketici taraf event'in oluştuğu anda, çalışıyor veya çalışmıyor olabilir. 

Örneğin bir para transferi yapmak isteyelim. Burada para örneğini kaybolursa çok yaygara çıkacağı için seçtim :) Merkezi bir broker varsa - mesela RabbitMQ - bu broker üzerindeki durable (kalıcı) kuyruklar sayesinde, hem kuyruğun kendisini, hem de içindeki event'leri saklayabiliyor.

Tüketici tarafın mesajı işlediğine dair acknowledgement (onay) gelinceye kadar, mesaj broker'da saklanabilir, hata oluşması durumunda tekrar gönderilebilir. 

DDS mesaj kaybı olmayacağını "Durability Service" kullanılmıyorsa tam olarak garanti edemiyor.

"Durability Service" kullanılmayan bir durumda, eğer DataWriter ve DataReader birbirlerini bulmadıysa (discover) veya eşleşmediyse mesajlar rahatlıkla kaybolabilir. Ve hatta discovery için bir miktar da beklemek gerekebilir. DataWriter yazına bakabilirsiniz.

2. Transaction Gerektiren Durum

Açıklaması şöyle

JMS offers some capabilities not offered by DDS. Distinctive JMS capabilities include point-to-point delivery to exactly one of many consumers, message priority, and enterprise specific features such as full transactional support, and application level acknowledgements. 

3. Event Replay Gerektiren Durum

Event replay gerektiren durumlar, genellikle bir merkezi broker'ın event'leri belli bir süre boyunca saklaması şeklinde çözülüyor. Örneğin Apache Kafka bu şekilde çalışıyor. Eğer saklama süresi sonsuz olarak seçilirse, aslında sürekli ekleme yapılan bir veri tabanına dönüşebilir. Bu teknoloji Time Series Database olarak anılıyor

4. Consumer Group Gerektiren Durum

Consumer group, elimizde çok fazla sayıda event varsa ve bu event'leri tek bir uygulama ile tüketemiyorsak gerekiyor. Amacımız bu event'leri tüm tüketicilere dağıtmak. Yine Apache Kafka ve benzeri teknolojiler Consumer Group oluşturmaya, bu grubun otomatik olarak yönetilmesini imkan tanıyor. 

5. Çok yoğun mesaj Gerektiren Durum

Dakikada gelen mesaj sayısı 20K-30K ve üstü ise bana göre yoğun mesaj geliyordur. Bu sayılar benim gözlemlerim. Yoğun mesajları işleyebilmek için, sharding yapmak gerekiyor. Yani yükün birden fazla broker'a dağıtılması. 

5. Remote Procedure Call Gerektiren Durum

 Remote Message Call (RPC) karşı sisteme bir çağrı yapmak ve cevap beklemek anlamına gelir. Dağıtık ve senkron çalışan sitemlerde RPC yapmak gerekiyor. Asenkron çalışan mesaj kuyrukları bu işlevi yerine getirebiliyor. Örneğin JMS broker'ları bu yöntemi destekliyor.

DDS Hangi İşlere Uygun

Bence DDS şu durumlara uygun

1. Mesaj broadcast edildiği durum

2. QoS parametresi gerektiği durum

1. Mesaj Broadcast Edildiği Durum

Bu kullanım şekline özellikle "broadcast" dedim ama "fire and forget" olarak ta isimlendirilebilir. 

Elimizde bir alıcı yani sensör olsun. Bu alıcı ürettiği bilgiyi belli aralıklarda yayınlıyor olsun. Kapalı bir sistemde - gemi, uçak vs - bir çok başka birim bu alıcının gönderdiği bilgiye ihtiyaç duyar. 

Bu gibi sistemlerde merkezi bir broker kullanılmak istenmeyebilir. Çünkü broker sistemin tam kalbine yerleşecek ve "Single Point of Failure" oluşturacaktır. 

Bu kullanım şeklinde iletişim yine merkezi bir broker olmaması yüzünden, daha da hızlı olacaktır. Zaten bu yüzden DDS için "Near Realtime" deniliyor. Tabii Realtime çok genel bir gelime :) 

Ancak buradaki vurgu iletişimde, broker'ın getirdiği maliyetlerin azalması.

2. QoS Parametresi Gerekiyorsa

DDS'in tanımladığı bir sürü QoS var. Eğer bunlardan bir tanesi lazımsa, tabii ki DDS kolay çözümler sunabiliyor. 

En çok kullanılan QoS parametrelerinden bir tanesi bence DDS'in "Sampling" yapabilme yeteneği. Bu yetenek "History QoS" olarak biliniyor.  Örneğin her "key" değeri için kaç tane "sample" saklamak istediğimizi belirtmek ve bu key'in geçmişine gidebilmek kolaylaşıyor.

Diğer güzel QoS'ler Deadline Qos ve Liveliness Qos.  Yukarıdaki alıcı örneğinde alıcıların yedeklenmesi primary sensor, secondary sensor şeklinde çalışabilme imkanı elde edilebilir.