SignalR ile Gerçek Zamanlı İletişim

Merhaba, bu yazıda signalR alt yapısını kullanarak kendi domainimiz içerisinde nasıl gerçek zamanlı (real time) veri transferi sağladığımızdan bahsedeceğim.

İş birimlerinden gelen ihtiyaçları değerlendirdiğimizde anlık haberleşmenin özellikle üretim gibi sahada yapılan işlerde ne kadar önemli olduğunu gördük. Saniyeler mertebesinde ortaya çıkacak gecikmelerin üretim hatalarına sebep olması ve üretimi yavaşlatması gibi riskler taşıdığını anladık.

Geliştirdiğimiz uygulamalar müşteriye değer yaratıyor ise anlamlıdır aksi durumda, sadece başarısız bir projenin tecrübesini cebimize koyabiliriz. Bizim Ford Otosan olarak birinci önceliğimiz iç ve dış müşterilerimiz için yarattığımız değerdir. Bu nedenle proje geliştirme metodolojisi olarak agile ve özellikle yazılım geliştirme noktasında ise scrum frameworkünü uyguluyoruz.

Peki signalR kullanmayı tercih ettiğimiz ihtiyaç neydi?
Bir önceki RabbitMQ yazımda üretim hatlarında bulunan PLC sistemlerden veriyi nasıl aldığımızı ve backend projelerine aktardığımızı anlatmıştım, dilerseniz bu link ile o yazıyı da okuyabilirsiniz.

İş birimimiz, araçların pozisyon bilgilerinin çok hızlı bir sürede milimetrik olarak ilgili kişilerin önüne gelmesini gerektiren bir senaryo ilettiler. Buna göre yürüyen bandın üzerindeki araçların kimlik bilgilerini ve militmetre cinsinden pozisyonlarını yakalamalı ve ilgili çalışma arkadaşlarımızın kullandığı mobil cihazlara iletmeliydik.

Yaklaşık olarak 1000 den fazla mobil cihazımız mevcut ve bu cihazları her vardiyada farklı arkadaşlarımız kullanıyor. Her arkadaşımız farklı operasyonlar yürütüyor. Bu nedenle bizim öncelikle doğru bir haritalama yapmamız gerekiyordu.

Operatör, mobil cihaz ve operasyon parametrelerini haritaladığımızda ise karşımıza bu verinin ilgili mobil cihazlara aktarılması problemi çıktı. PLC sistemlerden aldığımız veriler yüksek bir frekansa sahip (ortalama 150 ms) ve bir araç için 2 farklı mesaj dinlememiz gerekiyor (aracın kimlik bilgisi ve pozisyonu). Aktif olarak sahada 500 farklı aracın bulunduğunu düşünelim böylece saniyede ortalama 3500 adet mesajın sistemde gezmesi ve ilgili mobil cihazlara iletilmesi gerekiyor. Bu problem için farklı çözüm yolları düşündük ve kavramsal çizimlerini gerçekleştirdik.

1. Yöntem veriyi ortak bir alana yazarak bir zamanlayıcı (timer) kullanıp sürekli sorgulama yapabilirdik.

2. Yöntem olarak ortak noktada tuttuğumuz değişiklikleri algılayabilecek teknolojiler kullanabilir ve veri değiştiğinde ön yüzü güncelleyebilirdik.

3. Yöntem ise doğrudan veriyi yayınlayarak (broadcast) ilgili ön yüz projesine verileri yönlendirebilir ve kendisinin ekranı yenilemesine olanak tanıyabilirdik.

1 ve 2 nolu yöntemler verinin bir noktada saklanması ve cihazların bu verilere çeşitli şekillerde erişmesini baz alıyor. Yukarıda verdiğim sayısal değerler sadece bir alana ait. Bunun gibi onlarca alanımız mevcut bu nedenle verinin saklanması için ekstra efor sarf etmemiz gerekiyordu. Aynı zamanda bu verinin sadece değişiklik olduğundaki kısmı bizi ilgilendiriyordu yani büyük bir bölümünün saklanmasına gerek yoktu. Özellikle 1. yöntemde düşündüğümüz zamanlayıcı senaryosunda da sorunlar vardı, zamanlayıcının her bir tetiklenme anında verinin alıp gelinmesi uzun sürecek ve connection yönetim maliyetleri işin içine girecekti. Son olarak da ilk iki yöntemde mobile cihazların kendi işlemci gücünden yararlanmak yerine veritabanı sunucusunun ya da backend sunucusunun kaynaklarına yükleniyorduk.

Yukarıdaki nedenler dolayısı ile 3. yöntem ile ilerlemeye ve bir mvp yapmaya karar verdik. Verinin yayınlanabilmesi (stream) için teknolojileri ve alt yapıları araştırdığımızda karşımıza çeşitli konseptler ve teknolojiler çıktı.

Öncelikle konu frontend olunca http protokolünü kullanarak bu ihtiyacımızı karşılayabilir miyiz sorusuna cevap aradık ancak doğası gereği bize istediğimiz alt yapıyı sağlayamıyordu. Alternatif araştırmalarımız bizi long pooling ve websocket kavramları ile tanıştırdı.

Http ve websocket ile ilgili güzel bir karşılaştırma yazısına bu link ile erişebilirsiniz.

Long pooling ve websocket karşılaştırmasına ise bu link ulaşmanız mümkün.

Yukarıdaki gibi birçok makaleyi okuyup içerikleri tükettikten sonra bizim senaryomuza en çok uyan teknolojinin websocket olduğu kararını verdik ve araştırmalarımızı bu alt yapı özelinde ilerlettik. Soket.io, sock.js, signalR gibi teknolojilerin websocket alt yapısı için kullanıldığınız gördük ve çoğunlukla Microsoft teknolojileri kullandığımız için signalR ile mvp çalışmalarına devam ettik.

SignalR gruplama, yeniden deneme (retry policy) gibi alt yapılar sağladığı için işimizi oldukça kolaylaştırdı, verileri gerçek zamanlı olarak frontend tarafına aktarmamıza imkan sağladı. Gruplama özelliği sayesinde alanları gruplayarak mobile cihazların sadece kendileri ile alakalı grubu dinlemelerini sağladık. Cihazlara gelen veriler içerisinden kendi işlemci güçlerini kullanarak mesajları filtrelemelerini ve değişen veriyi yakalamalarını sağladık. Böylece işlem yükünü client cihazlara da dağıtmış olduk.

Buraya kadar olan kısımda bahsettiğim yöntem ve alt yapılar ile uygulamamız üretim sistemlerinde aktif olarak görev alıyor ve darboğaz yaşamadan ihtiyacı karşılayabiliyor.

Uygulamayı devreye aldıktan sonra araştırmalara devam ettik ve farklı teknolojiler ile yeni yaklaşımlar gözlemledik. Bu alt yapıları şu an için deneyimlemeye ve mevcut yapımıza nasıl entegre edebileceğimizi anlamaya çalışıyoruz.

1-) SSE (Server Send Events)
2-) Web Transport
3-) WebRTC

Ford Otosan — Dijital Ürünler ve Servisler
Plan 2 Delivery Tribe Liderliği — Software Development Chapter Lead
Mehmet Ali EROL