Microsoft AZ-204: Azure Olay Tabanlı ve Mesaj Çözümleri — Çalışma kılavuzu

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Şunun bir parçası: Microsoft Azure Developer Associate AZ-204 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Microsoft sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Azure’nun olay ve mesajlaşma portföyü, birbirini tamamlayan dört hizmeti kapsar: Reaktif olay yönetimi için Event Grid, yüksek verimli akış alımı için Event Hubs, kurumsal mesajlaşma ve iş akışı koordinasyonu için Service Bus ve mobil anlık bildirimler için Notification Hubs. Bu hizmetlerde uzmanlaşmak; her birinin temel soyutlamalarını, teslimat ve yeniden deneme semantiğini, ölçeklendirme modellerini ve pub/sub, komut işleme, telemetri alımı, cihaz veya kullanıcı bildirimleri gibi tipik uygulama desenlerinde hangisinin ne zaman tercih edileceğini bilmeyi gerektirir.

Event Grid: Konular, Abonelikler, Şema, Filtreleme ve Dead-Lettering

Event Grid, ayrık olaylar için tam olarak yönetilen, push tabanlı bir pub/sub altyapısıdır. Yayıncılar olayları bir konuya (topic) gönderir; aboneler bir konu üzerinde olay abonelikleri (event subscription) kaydeder ve eşleşen olayları HTTPS webhook’ları, Azure Functions, Logic Apps, Service Bus, Storage Queues ve Event Hubs gibi desteklenen işleyicilerde (handler) alır. Event Grid, iki yayıncı modeli tanımlar. Sistem konuları (System topics), aboneliğiniz veya kaynak grubunuz içinde olay yayınlayan birinci taraf Azure hizmetlerini temsil eden, Azure tarafından yönetilen konu kaynaklarıdır (örneğin, Storage blobu oluşturuldu, Key Vault sırrı rotasyonu yapıldı veya Resource Manager olayları). Özel konular (Custom topics), uygulamalarınızın yayın yaptığı, kullanıcı tarafından oluşturulan konu uç noktalarıdır ve kendi hizmetleriniz ve etki alanlarınız arasında olay odaklı desenleri (event-driven patterns) mümkün kılar. Sistem konuları yayıncı kodu gerektirmez ve Azure kaynaklarını reaktif işleyicilere bağlamayı basitleştirir; özel konular ise olay sözleşmeleri (event contracts) ve yaşam döngüsü üzerinde tam kontrol sağlar.

Event Grid olayları, yerel Event Grid şemasını veya CloudEvents v1.0 spesifikasyonunu kullanabilir. Event Grid şemasıyla her olay; id (benzersiz tanımlayıcı), eventType (eylem), subject (filtrelemeyi destekleyen hiyerarşik yol), eventTime (UTC), data (yük), dataVersion, metadataVersion ve topic içerir. CloudEvents; id, source, type, time, subject ve data gibi standartlaştırılmış bir dizi öznitelik sağlar. CloudEvents’i seçmek platformlar arası birlikte çalışabilirliği (interop) kolaylaştırır; Event Grid şeması ise Azure kaynaklı olaylarla eşliği ve subject üzerinde zengin filtreleme imkanını korur.

Olay abonelikleri; yönlendirme, teslimat seçenekleri ve filtreleri tanımlar. Temel filtreler, hiyerarşik kaynak adlandırması için verimli olan olay türü dahil etme ve konu ön eki/son eki (subjectBeginsWith, subjectEndsWith) içerir. Gelişmiş filtreler, üst düzey olaydaki veya data içindeki alanlarla eşleşir (örneğin, sayısal aralık karşılaştırmaları, dize içinde büyük/küçük harfe duyarsız arama, boole eşitliği ve dizi içinde arama). Hassas fan-out kontrolü için filtreleri birleştirerek alt sistemlerdeki (downstream) iş yükünü ve giden trafiği (egress) en aza indirebilirsiniz.

Teslimat, en az bir kez (at-least-once) semantiği ile push modelindedir. Event Grid, üssel geri çekilme (exponential back-off) ile yeniden denemeler yapar. Maksimum yeniden deneme sayısını ve olayın yaşam süresini (time-to-live) yapılandırabilirsiniz; teslimat nihayetinde başarısız olduğunda veya olayın süresi dolduğunda, Event Grid olayı abonelikte belirlediğiniz bir Blob Storage konteynerine dead-letter olarak gönderebilir. Dead-lettering, denetim veya yeniden işleme için yükleri (payload) ve meta verileri korur; gerekirse olayları yeniden canlandırmak ve tekrar oynatmak için ayrı bir süreç kullanın. Webhook uç noktaları, sahipliği kanıtlamak için bir doğrulama el sıkışmasına (validation handshake) katılır ve kısıtlı ağlar için, genel erişime açık olması gerekmeyen ve Azure AD destekli yetkilendirme kullanabilen yönetilen Azure uç noktalarını (Functions, Service Bus, Storage Queue) tercih edebilirsiniz.

Event Hubs: Bölümler, Tüketici Grupları, Aktarım Hızı, Yakalama ve Güvenilir Tüketim

Event Hubs, yüksek hacimli telemetri ve günlük akışlarını düşük gecikmeyle içeri alır. Veriler, bağımsız ve sıralı işlem günlükleri olan bölümlere eklenir. Bölümler, aktarım hızını paralelleştirmek için oluşturma zamanında seçilir; üreticiler anahtar başına sıralamayı korumak için bir bölüm anahtarı atar ve hizmet, anahtarları bölümlere hash’ler. Birden çok okuyucu, bölümleri paralel olarak işleyebilir; bir bölüm içinde sıralama garanti edilir.

Tüketici grupları, akışın bağımsız görünümlerini sunarak farklı işleme uygulamalarının birbirine müdahale etmeden kendi konumlarını korumalarına olanak tanır (örneğin, gerçek zamanlı bir anomali dedektörü ve bir arşivleme işlem hattı). Okuyucuları yatay olarak ölçeklendirmek, bölüm sahipliğinin dengelenmesini gerektirir; SDK’nın EventProcessorClient’ı, örnekler arasında bölüm atamasını ve yeniden dengelemeyi koordine eder.

Standard katmanındaki Aktarım Hızı Birimleri (TU’lar) kapasiteyi tanımlar: her TU, belirli giriş ve çıkış bant genişliği kotaları hakkı tanır. Otomatik şişirme (Auto-inflate), ani yükselen talepleri karşılamak için TU’ları otomatik olarak artırabilir. Premium katmanı, adanmış işlem gücü ve öngörülebilir gecikme süresi sunan İşlem Birimleri’ni (Processing Units) kullanır. Kaynak sağlamanın doğruluğunu kontrol etmek için kısıtlama (throttling) metriklerini izleyin. Event Hubs, aynı uç nokta üzerinde Kafka protokolünü destekleyerek, broker çalıştırmaya gerek kalmadan Kafka istemcilerinden lift-and-shift geçişini basitleştirir.

Üreticiler AMQP veya HTTPS kullanabilir. AMQP (443 numaralı bağlantı noktası üzerinden AMQP-over-WebSockets dahil), çoklanmış, kalıcı bağlantılar ve verimli toplu işleme sağlar ve hem gönderme hem de alma için önerilir. HTTPS, basit veya düzensiz gönderimler için uygundur ancak alma için desteklenmez; long-polling mevcut değildir ve verimlilik ile akış kontrolünden feragat edersiniz. Kısıtlı kurumsal ağlarda, AMQP-over-WebSockets, tipik giden proxy’lerden geçerken performansı korur.

Denetim noktası oluşturma (Checkpointing) ve ofset yönetimi, doğruluğun sağlanması için kritik öneme sahiptir. Her olayın bölüm başına bir sıra numarası ve bir ofseti vardır. Alıcılar akışta ilerler ve bir toplu işlemi başarıyla işledikten sonra konumlarını dayanıklı bir depolama alanına—genellikle EventProcessorClient aracılığıyla bir Azure Blob Storage kapsayıcısına—denetim noktası olarak kaydederler. Yeniden başlatma veya yük devretme durumunda, işlemci son denetim noktasından devam ederek idempotent işleyicilerle en az bir kez işleme (at-least-once processing) garantisi sağlar. Denetim noktaları olmadan, tüketiciler varsayılan bir konumdan (en son veya en eski) başlar ve olayları yeniden işleme veya atlama riskiyle karşı karşıya kalır.

Yakalama (Capture) özelliği, yapılandırılabilir bir zaman veya boyut penceresine göre toplu hale getirilmiş, yalnızca ekleme yapılabilen Avro dosyalarını otomatik olarak Azure Blob Storage veya Azure Data Lake Storage Gen2’ye yazarak sunucu tarafı arşivleme sağlar. Bu, soğuk yol (cold-path) analitiği için özel toplu işleyicilere olan ihtiyacı ortadan kaldırır ve alt akış araçlarının (Spark, Synapse) yakalama işlem hattına göre tam olarak bir kez (exactly-once) semantiği ile değişmez akış segmentlerini tüketmesini sağlar.

Service Bus ve Queue Storage: Komutlar, İş Akışları, Oturumlar ve Zehirli Mesaj Yönetimi

Service Bus, zengin teslimat garantileri gerektiren komutlar, iş akışları ve entegrasyon senaryoları için kurumsal düzeyde bir mesaj aracısıdır. Kuyruklar (Queues) noktadan noktaya (point-to-point) mesajlaşmayı uygular; her mesajı rekabet eden tek bir tüketici (consumer) alır. Aboneliklere (subscriptions) sahip Konular (Topics), yayınla/abone ol (pub/sub) modelini etkinleştirir: yayıncılar (publishers) bir konuya gönderim yapar ve bağımsız abonelikler, kurallara göre kopyaları alır. Abonelik kuralları, her mesaj için dahil edilip edilmeyeceğini hesaplayan ve eylemler (actions) aracılığıyla mesaj özelliklerini ekleyebilen veya değiştirebilen SQL filtreleri, korelasyon filtreleri veya boole (boolean) true filtreleri olabilir.

Oturumlar (Sessions), ilişkili mesajlar için sıralı ve özel (exclusive) işleme sağlar. Birbirine ait olan mesajlara bir SessionId atayın (örneğin, Sipariş 123’teki tüm adımlar). Bir alıcı, oturum kilidini (session lock) kabul eder ve o oturum için mesajları geliş sırasına göre işler, isteğe bağlı oturum durumunu (session state) korur, ardından bir sonraki tüketicinin sahipliği almasına izin vermek için oturumu serbest bırakır. Bu, büyük ölçekte FIFO (İlk Giren İlk Çıkar) için tercih edilen modeldir. Oturumlar olmadan, rekabet eden tüketiciler arasında sıralama garanti edilmez.

Service Bus, PeekLock ve ReceiveAndDelete modlarını destekler. PeekLock, güvenilirlik için varsayılan moddur: bir tüketici, bir mesajı kilit süresi (lock duration) boyunca kilitler, işler, ardından Complete (tamamlandı) olarak işaretleyerek sonuçlandırır. İşlem başarısız olursa, tüketici mesajı Abandon (terk et) (tekrar kullanılabilir hale getirir), Defer (ertele) (sıra numarasına göre alımını sonraya bırakır) veya Dead-letter (hatalı mesaj kuyruğuna taşı) (varlığın ayrı hatalı mesaj alt kuyruğuna (dead-letter subqueue) sebep ve hata açıklamasıyla birlikte taşır) yapabilir. ReceiveAndDelete, mesajı alır almaz hemen kaldırarak güvenilirlikten feragat edip iş hacmini (throughput) artırır.

Temel özellikler yaşam döngüsünü kontrol eder. Yaşam Süresi (Time to Live - TTL), varlık varsayılanı olarak ayarlanabilir ve her mesaj için geçersiz kılınabilir; süresi dolan mesajlar, yapılandırmaya bağlı olarak hatalı mesaj kuyruğuna (dead-lettered) gönderilir veya silinir. Kilit süresi (Lock duration), bir mesajın işlenmek üzere ne kadar süre kilitli kalacağını kontrol eder; SDK, maksimum sınırlar dahilinde uzun süren işler için kilitleri otomatik olarak yenileyebilir. Maksimum teslimat sayısı (Max delivery count), her kuyruk veya abonelik için yapılandırılır; bu kadar teslimat denemesinden sonra (Abandon veya kilit kaybı), mesaj otomatik olarak hatalı mesaj kuyruğuna (dead-letter queue - DLQ) taşınır. Operatörler, tanılama (diagnostics) veya düzeltici mantıkla yeniden işleme için DLQ’yu boşaltır.

Azure Queue Storage, temel ayrıştırma (decoupling), yüksek yayılma (high fan-out) ve maliyete duyarlı iş yükleri için en uygun, REST arayüzüne sahip, daha basit ve büyük ölçüde ölçeklenebilir bir kuyruk hizmetidir. En az bir kez teslimat (at-least-once delivery), işleme sırasında mesajları gizlemek için bir görünürlük zaman aşımı (visibility timeout) ve mesaj başına TTL (varsayılan 7 gün, yapılandırılabilir, süresiz dahil) sağlar. Tekil mesajların boyutu sınırlıdır ve oturumlar, işlemler (transactions), sıralama garantileri, yinelenen mesaj tespiti (duplicate detection), hatalı mesaj alt kuyrukları (dead-letter subqueues) ve gelişmiş filtreler gibi özellikler mevcut değildir. Basit arka plan işleri ve düşük maliyetle çok yüksek iş hacmi için Queue Storage’ı seçin. Gelişmiş yönlendirme (konular/abonelikler), oturumlar aracılığıyla FIFO, zamanlanmış teslimat, erteleme, varlıklar arası işlemler, yinelenen mesaj tespiti pencereleri, AMQP desteği gibi ihtiyaçlarınız olduğunda veya entegrasyon güvenilirliği ve yönetişim önemli olduğunda Service Bus’ı seçin. Yaygın bir model, Event Grid veya Queue Storage aracılığıyla hafif olayları bir araya toplamak (fan in) ve iş açısından kritik komutları ve durum geçişlerini Service Bus üzerinde koordine etmektir.

Notification Hubs: Anında İleti Yönlendirme ve Platform Kimlik Bilgisi Yönetimi

Notification Hubs, büyük ölçekte cihaz kayıtlarını yöneten ve Apple (APNs), Android (FCM), Windows (WNS) ve diğer platformlara hedeflenmiş bildirimleri yönlendiren platformlar arası bir anında ileti motorudur. Uygulamalar, etiketler ve etiket ifadeleri kullanarak cihazları kaydeder ve bu sayede hassas hedef kitle seçimi (örneğin, user:42 AND region:emea OR topic:promotions) mümkün olur. Şablonlar, platforma özgü oluşturucuların genişlettiği tek bir yerelleştirilmiş yük göndermenize olanak tanır, bu da sunucu mantığını azaltır ve minimum arka uç dallanmasıyla cihaz başına kişiselleştirme sağlar. Installation modeli, platform tanıtıcısını, etiketleri ve şablonları cihaz başına tek bir kaynakta kapsayarak cihaz yaşam döngüsü yönetimini kolaylaştırır.

Platform kimlik bilgisi yönetimi, güvenilir teslimatın merkezinde yer alır. APNs için, sertifika tabanlı veya token tabanlı kimlik bilgilerini (Key ID, Team ID ve .p8 token ile) yükleyin ve ortamları ayırmak için hub veya ad alanı başına sandbox ya da production uç noktalarını seçin. FCM için, uygun sunucu kimlik bilgilerini yapılandırın (HTTP v1 için, OAuth2 kapsamlarına sahip bir Google hizmet hesabı kullanın). WNS için, Package SID ve istemci gizli anahtarını (client secret) almak üzere uygulamayı kaydedin. Kimlik bilgileri periyodik olarak yenilenir; yenilemeyi zamanlayın ve geçersiz cihaz tanıtıcıları için geri bildirim kanallarını izleyin. Notification Hubs, uygulama sunucunuzdan hub düzeyinde kimlik doğrulaması için SAS kullanırken, Azure AD rolleri yönetim operasyonlarını korur. Çok kiracılı uygulamaları bölümlere ayırmak için etiketleme kurallarını kullanın ve platform kotalarını karşılamak için gönderimleri zamanlanmış veya toplu anında iletilerle yavaşlatın.

Pratik Problem Senaryosu

Starbucks, siparişler hazır olduğunda müşterileri bilgilendirmesi, barista iş akışı adımlarını güvenilir bir şekilde işlemesi ve proaktif bakım için ekipman telemetrisini analiz etmesi gereken küresel bir mobil sipariş deneyimi sunuyor.

Olay güdümlü sipariş yaşam döngüsünü Event Grid ile bağlama

OrderEvents adında özel bir Event Grid topic’i oluşturun ve OrderPlaced, PaymentAuthorized ve OrderReady gibi ayrık domain olaylarını yayımlayın. Mağazaya göre ön ek filtrelemesini etkinleştirmek için /stores/{storeId}/orders/{orderId} gibi konu yolları kullanın. Abonelikleri yapılandırın: biri iş akışı işleme için bir Service Bus topic’ine ve diğeri hafif zenginleştirme için bir Azure Function’a. Event Grid, düşük gecikmeli fan-out, şema normalizasyonu (CloudEvents) ve gereksiz alt sistem çağrılarını önleyen verimli filtreleme için seçilmiştir.

Barista iş akışını Service Bus topic’leri ve session’ları ile koordine etme

Her biri eventType üzerinde korelasyon veya SQL filtreleri olan, işleme aşaması başına (Preparation, Handoff) aboneliklere sahip bir Orders adlı Service Bus topic’i tanımlayın. Sipariş başına FIFO’yu garanti etmek için komutları SessionId = {orderId} ile mesaj olarak yayımlayın. Tüketiciler, otomatik kilit yenilemeli PeekLock kullanır ve başarı durumunda Complete yapar; geçici bir hatada Abandon yeniden denemeyi tetikler; kalıcı hata veya zehirli mesajlarda, Max delivery count bunları daha sonra incelenmek üzere DLQ’ya taşır. Aşamaya özgü mesajlardaki TTL, mağaza kapandıktan sonra bayatlamış işleri önler. Service Bus, sıralı, güvenilir komut işleme, zengin sonuçlandırma seçenekleri ve kural tabanlı pub/sub için seçilmiştir.

Ekipman telemetrisini Event Hubs ile alma ve arşivleme

deviceId’ye göre paralelleştirmek için yeterli bölüm (partition) içeren bir Event Hub Telemetry sağlayın ve ani yükselişleri karşılamak için otomatik şişirilen TU’ları (auto-inflate TUs) etkinleştirin. Cihaz ağ geçitleri, kurumsal proxy’leri verimli bir şekilde aşmak için AMQP-over-WebSockets üzerinden gönderim yapar. Gerçek zamana yakın anomali tespiti ve uyarı çalıştırmak için Blob Storage checkpointing ile EventProcessorClient’ı kullanın. Synapse’de çevrimdışı analitiği destekleyen değişmez Avro arşivleri için ADLS Gen2’ye Capture özelliğini etkinleştirin. Event Hubs, dayanıklı offset’ler ve kolay cold-path dışa aktarımı ile sürekli, yüksek verimli alım için seçilmiştir.

Anında iletileri Notification Hubs ile hedefleme

Mobil cihazları Installation modelini kullanarak kaydedin ve her birini user:{userId}, store:{storeId} ve platform etiketleriyle etiketleyin. iOS için APNs token kimlik bilgilerini ve Android için FCM hizmet hesabını yükleyin; kimlik bilgilerini ve geri bildirimi izole etmek için dev ve prod hub’larını ayırın. OrderReady olayları geldiğinde, Azure Function, Notification Hubs’a user:{userId} AND store:{storeId} etiketlerine adreslenmiş tek bir şablon bildirimi gönderir. Notification Hubs, platformdan bağımsız yönlendirme, etiket ifadeleri ve küresel ölçekte merkezi kimlik bilgisi yönetimi için seçilmiştir.

Gözlemlenebilirlik ve dayanıklılık sağlama

Teslim edilemeyen olayları denetim ve yeniden oynatma için saklamak üzere Event Grid dead-lettering’i bir Blob container’ına yapılandırın. Service Bus DLQ’larını izleyin ve düzeltilmiş mesajları ayıklamak ve yeniden kuyruğa almak için bir operatör iş akışı sunun. Checkpointing’i doğrulamak ve birikim (backlog) arttığında işlemcileri yatayda ölçeklendirmek (scale out) için metrikler aracılığıyla Event Hubs tüketici gecikmesini (consumer lag) takip edin. Bu kombinasyon uçtan uca dayanıklılık sağlar: sorunsuz yolu (happy path) hızlı ve uygun maliyetli tutarken, istisnai durumlar için yeniden oynatma yolları ile en az bir kez teslimat.

Bu mimari, sorumlulukları net bir şekilde ayırır: Event Grid reaktif orkestrasyonu yönlendirir, Service Bus iş akışı doğruluğunu ve sıralamasını garanti eder, Event Hubs büyük ölçekte sürekli telemetriyi yönetir ve Notification Hubs, minimum arka uç karmaşıklığı ile hassas, platforma özgü müşteri bildirimleri sunar.

← Azure API Yönetimi · Tüm alanlar · Azure Önbelleğe Alma →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →