Üretim Süreçlerinde RabbitMQ

Merhaba, bu yazıda, üretim domaini içerisinde kuyruk yapısına ihtiyaç duyduğumuz senaryoları, bu senaryolar için neden RabbitMQ alt yapsını tercih ettiğimizi ve hangi özelliklerini kullandığımızı paylaşacağım.

Üretim hattında çeşitli araçların sıralandığını gösteren bir çizim yapmasını istediğimde MidJourney yapay zekası bana aşağıdaki görseli üretti. Bu yazının konusu değil ancak ben denerken oldukça eğlendim size de tavsiye ederim :)

Midjourner AI Kullanılarak Oluşturulmuştur

Bu görsel üzerinden devam edelim. Gördüğünüz gibi üretim hattı aslında başlı başına bir sıra yönetimidir. Birbirinden farklı araçların müşterilere ulaştırılabilmesi için akıllıca bir sıralama yapılması ve o sıra ile üretim adımlarının ilerletilmesi gerekir. Yürüyen bant üzerinde hareket eden araç, ilerledikçe üzerine yeni parçalar eklenir ve bu işlemler araç tüm fonksiyonları ile çalışacak hale gelene kadar devam eder.

Araç üretimi, çok çeşitli parçalar, operasyonlar ve yöntemler kullanılarak yapılır. Seri üretim yapılırken tek tip araçlar değil, yüzlerce varyasyonu bulunan özelleştirilmiş araçlar üretilir.

Bu karmaşıklığı yönetebilmek için;
* Her bir aracın üretim hattındaki yerinin
* Yapılacak operasyonların neler olduğunun
*Hangi parçaların kullanılması gerektiğinin, doğru zamanda doğru adreslere teslim edilmesi önemlidir.

Örnek olarak üretim sahasında operasyonlar yürüten bir çalışma arkadaşımız biraz sonra önüne gelecek araç için yukarıdaki bilgileri tam zamanında ve eksiksiz görebilmelidir. Bu sayede araca özel operasyonlar başarı ile uygulanır, müşterilere özelleştirilmiş ve kaliteli araçlar teslim edilir.

İlk olarak yürüyen bant üzerine hareket eden aracın tam olarak nerede, hangi pozisyonda olduğunu bulmamız gerekiyordu. Bunun için PLC (programmable logic controller) sistemler üzerinden veri okumaya ve okuduğumuz verileri birden fazla uygulama ile paylaşmaya ihtiyacımız olduğunu gördük.

PLC üzerinden verileri alınması ve birden fazla uygulamaya dağıtılması

Yukarıdaki şekilde görüldüğü gibi ilerlemek için her bir uygulamamız alt seviye bir sistem olan PLC sistemi ile haberleştirmeliydik, üretim için kritik olan bu sisteme ayrı ayrı bağlanmak oldukça maliyetli ve değişiklik yönetimi için ileride karşımıza sorunlar çıkaracağının da farkındaydık. Bu nedenle yöntemler araştırırken queue yapılarını ve SPOC (single point of contact) yapıları inceledik. Aşağıdaki özellikleri dolayısı ile RabbitMQ ile MVP yapmaya karar verdik.

• Exchange yapısı sayesinde tek noktadan giren mesajları istenilen sayıda bağımsız kuyruklara yönlendirebilmesi
• Open source olması
• Kolay yönetim sağlayan management plugini olması
• Cluster çalışabilmesi, izlenebilir ve ölçeklenebilir olması

RabbitMQ ile yapılan yeni tasarım

Yukarıdaki şekilde de görüldüğü üzere ortaya RabbitMQ çözümünü ekleyerek sadece tek bir uygulamanın PLC üzerinden dinleme yapmasını ve diğer uygulamaların queue üzerinden bu verileri almasını sağladık. Bunun ek bir faydası da farklı bir PLC markası ya da teknolojisi geldiğinde consumer olarak isimlendirdiğim uygulamalarımızda değişiklik ihtiyacı olmayacak olmasıdır.

Yukarıdaki çizimi baz alarak geliştirdiğimiz alt yapılar ile sağlıklı şekilde verileri alabildik ancak 7/24 yaşaması ve sorunsuz çalışması gereken bir çözüm ortaya koymamız gerekiyordu. Geliştirdiğimiz sistemin durması, sağlıklı çalışmaması doğrudan maddi kayıp yaşatacağı için bu konuda araştırmalar yaptık. İlk olarak en az 3 node ile bir cluster yapı kurmamız gerektiğini öğrendik ve 3 farklı sanal makine üzerine aynı versiyona sahip 3 farklı RabbitMQ kurulumu yaptık. Kolay bir şekilde bu 3 kurulumumuzu tek bir cluster olarak çalışacak şekilde yapılandırdık.

Cluster yapı kurmak herhangi bir node üzerinde RabbitMQ sorunu yaşadığımız senaryolarda elimizi güçlendirdi. Aynı anda 2 node da kaybetsek kalan tek node ile işlemlerimizi sağlıklı şekilde yapacak duruma geldik.

Ancak cluster yapı kurmamız tek başına yeterli olmadı, varsayılan queue tipi olan classic queue yapısı tek bir node üzerinde çalışacak şekilde davranış gösteriyordu. Yani 3 farklı nodumuz olsa dahi oluşturduğumuz queue tek bir node üzerinde koştuğu için o node gittiğinde elimizde 2 tane sağlıklı node olsa dahi sistemimiz çalışmaz hale geliyordu. Yaptığımız araştırmalar sonucunda bu durumu 2 farklı şekilde çözebileceğimizi gördük.

• Classic queue üzerinde policy ler uygulayarak multi node queuelar oluşturmak
• Quorrum tipinde queuelar kullanmak

İki queue yapısını detaylı karşılaştırdığımızda bizim senaryomuz için quorrum queue tipinin daha uygun olduğunu gördük. Quorrum queue lar varsayılan olarak tüm nodelar üzerinde koşacak şekilde davranış sergiliyor. Arka planda tüm nodelar üzerinden erişilebilir olmak için kullandığı algoritmanın daha verimli olması da tercih nedenlermizden birisi oldu.

Artık herhangi bir node üzerinde sorun olması sistemimiz hiç etkilemiyor böylece hata toleransımızı bu sayede yükseltmiş olduk.

Daha sonrasında uygumalarımızın anlık network kesintisi gibi nedenlerden dolayı RabbitMq ile bağlantısının kopması gibi durumları göz önüne almamız gerektiğine karar verdik ve yine bir araştırma içerisine girerek iyi uygulamaları inceledik. Sonuç olarak retry policy patterni uygulamamız gerektiğini anladık, burada retry policy uygulamasını sadece bağlantı aşamasında değil mesajın gönderilmesi ve alınması konularında da ele almamız gerektiğini gördük.

Amerikayı yeniden keşfetmek biz yazılımcıların gelişime açık yönlerinden birisidir :) Bunun farkında olarak benzer ihtiyaca sahip insanların kullandığı teknolojileri inceledik ve MassTransit alt yapısını kullanmaya karar verdik. MassTransit mesajlaşma yapılarında defacto olmuş bir teknoloji ve bu alanda birçok işlemi az kod ile yapmanızı sağlıyor. Projelerimizde producer ve consumer olarak çalışacak uygulamalarımıza bu alt yapıyı dahil ettik ve bu uygulama sayesinde hata toleransımızı bir seviye daha iyileştirmiş olduk.

Biz yukarıdaki senaryo dışında farklı alanlarda da kuyruk yapısı ihtiyacımızı RabbitMQ ürünü ile çözüyoruz ve neredeyse bu yapıyı kullanan tüm servislerimiz mission critical olarak düşünülebilir. Yüksek erişilebilirlik değerleri sayesinde gözümüz arkada kalmadan rebust yapılar oluşturmamıza olanak sağlıyor.

Sonuç olarak RabbitMQ kullanmak istiyorsanız özellikle cluster yapıların nasıl oluşturulduğuna, queue tiplerinin neler olduğuna ve aralarındaki farklara, exchange stratejilerine, yedekleme ve yedeklerden geri dönme gibi konulara önem vermenizi ve araştırmanızı öneriyorum. Tabii ki en önemli konulardan birisi eğer gerçekten ihtiyacınız yok ise bu tarz alt yapıları kullanmak ekstra maliyet anlamına geliyor.

Yukarıdaki konuları araştırdınız ve iyi bir alt yapı kurdunuz diyelim sonrasında mesaj boyutunuzu, frekansınızı ve consumer stratejilerinizi iyi belirlemeli ve amacına uygun yapılar tasarlamalısınız. Yük testleri yaparak throutput değerlerinizi incelemeli ve dar boğaz yaşanan yerlerde stratejinizi değiştirmelisiniz.

Her şeyi kurgulayıp sistemi çalışır hale getirdikten sonra da versiyon geçişlerini takip etmeli ve kurulumlarınızı belli aralıklarla güncellemelisiniz. Alarm mekanizmalarını verimli kullanmalı ve daha sorun ortaya çıkmadan gerek management plugin üzerinden gerekse RabbitMQ api üzerinden sorun yaşayabileceğiniz (memory, cpu, connection .. vs) konuları önden görmeli ve gerekli aksiyonlar almalısınız.

Ortamlar oluşturmak için fiziki kurulumlar yapabileceğiniz gibi RabbitMQiçerisinde bulunan virtual host özelliğini de kullanabilirsiniz. Biz bu noktada virtual host özelliğini kullanarak dev, test, uat ve prod ortamlarını uygulama bazlı ayırarak ilerledik.

Hedef olarak kurulumları sanal makinelerden Redhat Openshift alt yapısına taşımayı ve ölçeklenebilirlik noktasında daha fazla yeteneğe kavuşmayı planlıyor ve plan doğrultusunda çalışmalar yürütüyoruz.

Buraya kadar sabrederek okuduğunuz için teşekkür ederim. Ekip olarak bu yolculukta öğrendiğimiz konuları paylaşmaktan oldukça keyif alıyoruz aynı zamanda yukarıda yazanlara katılmadığınız noktalar var ise ya da daha iyi bir yol önermek istiyorsanız memnuniyetle dinlemek isteriz.

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