Azure Service Bus nedir? Queue ve Topic kullanımı.
Bir önceki makalede Azure Functions konusunu incelemiştik. Alttaki linkten ulaşabilirsiniz.
Serverless yazı dizisi.
- Serverless mimari nedir? Neden Serverless? Kimler serverless kullanmalı.
- Azure Functions Nedir? Trigger ve Bindings Nedir? Nasıl kullanılır?
- Azure Service Bus nedir? Queue ve Topic kullanımı?
- Azure Functions ile Serverless Sipariş Uygulaması Geliştirme
- Azure Functions Dependency Injection (DI) kullanımı
- Azure Functions Rest API ile Müşteri Talepleri Uygulaması
- Azure Storage Nedir? Blob Storage, File Storage, Table Storage, Queue Storage
- Azure Key/Vault Nedir?
Not: Yeni makaleler geldikçe bu bölümü güncelleyeceğim.
Haydi başlayalım…
Bu makalede, Azure’un mesajlaşma teknolojilerinden Azure Service Bus’ı inceleyeceğiz. Yazıda;
- Mesajlaşma nedir?
- Neden mesajlaşmaya ihtiyaç duyarız?
- Azure Service Bus
- Namespace, Queue, Topic Nedir?
- Projelerde Queue mu Topic mi kullanmalı?
- Dead Letter Queue (DLQ)
- Azure Servis Bus Katmanları
- Azure Servis Bus oluşturma konularından bahsedeceğim.
Not: Makalenin sonunda Queue ve Topic kullanımı için örnek bir console uygulaması hazırladım. Github reposundan inceleyebilirsiniz.
Mesajlaşma nedir?
Mesajlaşma, uygulamalar arası iletişimin mesajlar aracılığı ile gerçekleştirildiği bir yöntemdir. Bu yönteme göre mesajı oluşturan bir yayıncı, mesajın tüketicileri ve bu mesajın iletimine aracılık eden bir kuyruk (mesaj broker) bulunur. Mesaj içeriğinde kaynak, hedef ve meta verilerinden oluşan bir veri yapısıdır.
Neden mesajlaşmaya ihtiyaç duyarız?
Uygulamamızda belirli bir akış içerisinde gerçekleştirilmesi gereken birçok görev olabilir. Bu durum kullanıcıların ekranda çok uzun süreler beklemesine neden olur. Oysaki bazı işler arka planda asenkron olarak yapılabilir. Örneğin sipariş ekranında ödeme işleminden sonra arka planda fatura oluşturduğumuzu ve bilgilendirme mailleri attığımızı düşünelim. Bu işlemlerin aynı anda yapılması kullanıcının gereksiz ve uzun süre beklemesine neden olur. Mesajlaşma sistemi ile her mesaj ilgili modüle gönderilerek işlemler modüllerde asenkron olarak tamamlanabilir.
Bazı dönemlerde sistemler aşırı yük altında çalışabilirler. (Özel günler, kampanya dönemleri vs.) Böyle zamanlarda mesajlaşma sisteminin getirdiği en büyük avantaj yüksek performanstır. Mesajlaşma sistemi ile her mesaj hedef modül tarafından işlenir ve yük anında mesajları işleyen modüllerimiz scale olarak uygulamanın performanslı bir şekilde çalışmasını sağlar.
Azure Service Bus
Azure Service Bus, Azure platformunda çalışan ve uygulamaların ve hizmetlerin güvenilir bir şekilde birbiriyle haberleşebilmesi için geliştirilen kurumsal düzeyde bir mesajlaşma aracıdır. Serverless bir yapıdadır. Altyapı maliyetleri, bakımı gibi operasyonel işlerle uğraşmanıza gerek kalmaz. Çeşitli formatlardaki mesajlar farklı uygulamalar arasında iletişim sağlar. Bu mesajlar Json, XML ya da Text olabilirler. Her bir servis ve plan için farklı mesaj büyüklükleri bulunmaktadır. Mesaj servis bus’a gönderildiğinde eğer mesajın alıcısı çevrimiçi değilse mesajımız geçici olarak saklanır. Uygulama çevrimiçi olduğunda mesajı alır ve bu sayede hiçbir mesaj kaybolmaz.
Altta farklı fiyatlandırma katmanlarını inceleyebilirsiniz.
Namespace nedir?
Tüm mesajlaşma bileşenlerini barındırır. Birden fazla Queue ve Topic namespace içerisinde bulunabilir. Kuyruklar, konular, abonelikler, kurallar ve filtreler bir Namespace altında yer alır. Yeni bir servis bus hizmeti oluşturduğumuzda otomatik olarak bir namespace oluşmaktadır.
Queues Nedir
Mesajların gönderilip alınması için saklandığı kuyruk yapılarıdır. İlk giren ilk çıkar mantığına göre çalışır. (FIFO)
Bir kuyruk için birden fazla gönderici olabilir ama mesaj sadece bir alıcıya iletilir. Uygulama mesajı alana kadar mesaj kuyruk üzerinde saklanır. Kuyruktan bir mesaj alındığında Service Bus mesaja bir zaman damgası ataması yapar. Kuyruktaki mesajlar sadece uygulama talep ettiğinde teslim edilir. Queue mesajları genellikle noktadan noktaya iletişim için kullanılır.
Queue’nun bir diğer özelliği ise yenilenen kayıtların algılanmasıdır. (duplicate detection) Eğer kuyrukta yenilenen mesajları eklemek istemiyorsak bu özelliği aktifleştirebiliriz. Kısacası kuyrukta benzersiz mesajların oluşması için kullanılan bir özelliktir.
Servis Bus’da Queue mesajları okunduktan sonra silinebilir fakat alıcı mesajı alırken bir problem oluşursa mesaj kaybolabilir. Eğer Peek Lock seçeneğini seçersek mesaj alıcı tarafından kilitli hale gelir ve diğer alıcılara görünmez. Mesaj başarılı şekilde işlenirse Tamamlandı “Complated” olarak işaretlenir ve mesaj kuyruktan silinir. Mesaj işlerinirken bir problem oluşursa bu kez Service Bus’a mesajı işleyemediğinizi söyleyerek mesajın yeniden kullanılabilir hale gelmesini sağlayabilirsiniz. Kilitleme Süresi sona erdiğinde ise diğer alıcılar bu mesajı alabilecektir.
Topic Nedir?
Topic’ler sayesinden birden fazla alıcıya aynı mesajı iletebiliriz. Her alıcı için bir filtre ekleyebiliriz. Bu filtre, yalnızca filtre kuralına uyan mesajların söz konusu aboneliğe erişmesine izin verecektir. Bu şekilde, her abonelik belirli kurallara göre mesajları dinleyebilir.
Çalışma zamanında yeni bir abonelik ekleyebiliriz ve bunun için sistemi durdurmamıza gerek yoktur. Abonelik eklendikten sonra Topic için gönderilen mesajlar artık yeni aboneye gitmeye başlar. Bu yapı Publish/Subscribe mantığında çalışır. Her bir mesaj alıcılara ayrı ayrı gönderilir. Mesaj göndermek için kullanılan her konu maksimum 2.000 aboneye sahip olabilir. Bu, aynı mesajın 2.000 abone tarafından alınabileceği anlamına gelir.
Projelerde Queue mu Topic mi kullanmalı?
Geliştirdiğiniz uygulamalarda eğer bire bir modelde iletişim kuracaksak ve mesaj tek bir alıcıya ulaşması gerekiyorsa Queue tercih edilebilir.
Örneğin bir Yemek sipariş uygulaması geliştirdiğimizi düşünelim. Siparişlerin sıra ile işlenmesi gerekmektedir. Siparişleri bir kuyruğa atıp (Queue) sırası ile işleyebilir.
Birden çok sisteme aynı mesajı kullanmak isterseniz Topic kullanmanız daha doğru olacaktır.
Örneğin sipariş işlemi sonrası sipariş sonucunu E-Posta ve SMS ile kullanıcıyı bilgilendirmek isteyelim. Bunlar ayrı servisler olsun. Oluşturduğumuz Topic için bu servisler abone olarak (Subscribe) gönderdiğimiz mesajı ayrı ayrı işleyerek işlemlerini yerine getirecektir.
Dead Letter Queue (DLQ)
Bir queue oluşturduğumuzda otomatik olarak Dead Latter queue oluşur. Mesaj bir şekilde alıcıya teslim edilemezse veya mesajın süresi dolmuşsa DLQ’ya aktarılır. Ayrıca ağ hataları, kuyruğun silinmiş olması ve kimlik doğrulaması gibi problemlerle de mesaj iletilemeyebilir. Dead Letter’a taşınan mesajlar için sebep (DeadLetterReason) ve açıklama (DeadLetterDescription) olmak üzere iki özellik eklenir. Bu sayede mesaj bilgilerinden iletilememe problemini görebiliriz.
Azure Servis Bus Katmanları
Standart: Standart katmanda gecikme ve verim değişkendir bu nedenle test amaçlı olarak kullanılabilir. Dahili ölçeklendirme yoktur ve performans tahmin edilemez bu yüzden Production’a alacağınız uygulamalar için önerilmez. Kullandıkça Öde mantığında çalışır (Pay as you go) Maksimum mesaj boyutu 256 kb’dır.
Premium Tier: CPU’da ve bellek düzeyinde kaynak yalıtımına olanak sağladığından her müşterinin iş yükü yalıtımlı şekilde çalışır. Kritik uygulamalar için ölçeklendirme, performans ve kullanılabilirlik bakımından tercih edilir. Production ortamları için önerilir. Maksimum mesajlaşma boyutu 1mb’dır.
Standart ve Premium katman karşılaştırılması
Azure Service Bus oluşturma
Azure portalda oturum açın ve panel arama çubuğuna Azure Service Bus yazın ve ardından aşağıdaki resimde gösterildiği gibi Service Bus seçeneğine tıklayın
Azure Service Bus ekranında “Add” diyerek bir sonraki ekranda gerekli bilgileri giriyoruz.
Bu ekranda Resource Group, NameSpace, Location ve Pricing Tier bilgilerini giriyoruz. Eğer Topic kullanmak istiyorsak Standart veya Premium katmanını seçmemiz gerekmektedir.
Create butonuna basarak servis bus’ımızı oluşturabiliriz. Deployment tamamlanırken alttaki ekranı göreceksiniz.
İşlemler tamamlandığında artık Service Bus oluşmuş olacak. İşaretli alanda Queue ve Topic oluşturabiliriz.
Console uygulamasında kullanabilmek için OrderQueue isminde bir queue ve OrderNotificationTopic isminde bir topic oluşturuyorum.n
Topic oluşturduktan sonra topic için subscription tanımlaması yapmamız gerekiyor. OrderNotificationTopic altında emailsender ve smssender adında iki adet subsciption oluşturdum.
Ayrıca Service bus ile uygulama geliştirmek için Service Bus Connection string’e ihtiyaç duyacaksınız bunu Shared Access Policies altında bulabilirsiniz. Yeni bir access policy tanımlayıp istediğiniz gibi Claim tanımı yapabilirsiniz. Oluşturduğunuz policy içerisinden Connection String’e ulaşabilirsiniz.
Azure Service Bus Queue ve Topic kullanarak mesaj alıp gönderebileceğimiz örnek bir uygulama oluşturdum. Kaynak kodları incelemek isterseniz alttaki github reposundan ulaşabilirsiniz.
Sonuç
Bu yazıda Azure Service Bus’ın birçok özelliğini inceledik. Özetlemek gerekirse Azure Service Bus kurulumu kolay ve basit, yük anında otomatik ölçeklenen, güvenilir kurumsal düzeyde bir mesajlaşma aracıdır. Altyapı ihtiyaçlarından bizi tamamen soyutlayarak güçlü özelliklerini kullanabilmemize olanak sağlar. Diğer Azure servisleri ile kolayca entegre edilebilir. Serinin devamında Azure Service Bus’ı sıkça kullanacağız.
Bir sonraki makalede görüşmek üzere…
