Aracılığıyla paylaş

Çok siteli ve çok bölgeli federasyon

  • Makale

Birçok gelişmiş çözüm, aynı olay akışlarının birden çok konumda kullanıma sunulmasını veya olay akışlarının birden çok konumda toplanıp belirli bir tüketim konumunda birleştirilmesini gerektirir. Ayrıca genellikle tek bir bölge ve çözüm içinde de olay akışlarını zenginleştirmeniz veya azaltmanız ya da olay biçimi dönüştürmeleri yapmanız gerekir.

Pratikte bu, çözümünüz genellikle farklı bölgelerde ve Event Hubs ad alanında birden çok Event Hub'ı tutacağı ve ardından olayları bunlar arasında çoğaltacağı anlamına gelir. Olayları Azure Service Bus, Azure IoT Hub veya Apache Kafka gibi kaynak ve hedeflerle de değiştirebilirsiniz.

Farklı bölgelerde birden çok etkin Event Hub'ın korunması, istemcilerin içerikleri birleştiriliyorsa bunları seçmesine ve aralarında geçiş yapmasına da olanak tanır ve bu da sistemin genel olarak bölgesel kullanılabilirlik sorunlarına karşı daha dayanıklı olmasını sağlar.

Bu "Federasyon" bölümünde, doğrudan olay akışı yolunda kendi dönüştürme veya zenginleştirme kodunuz olma seçeneğiyle, sunucusuz Azure Stream Analytics veya Azure İşlevleri çalışma zamanlarını kullanarak federasyon desenleri ve bu desenlerin nasıl gerçekleştirılabileceği açıklanmaktadır.

Federasyon Desenleri

Olayları farklı Event Hub'lar veya diğer kaynaklar ve hedefler arasında taşımak istemenize neden olabilecek birçok olası motivasyon vardır ve bu bölümdeki en önemli desenleri numaralandırır ve ilgili desen için daha ayrıntılı yönergelere bağlantı sağlarız.

Bölgesel kullanılabilirlik olaylarına karşı dayanıklılık

Bölgesel Kullanılabilirlik

Event Hubs için en yüksek kullanılabilirlik ve güvenilirlik en yüksek işletim öncelikleri olsa da, ağ veya ad çözümleme sorunları nedeniyle üreticinin veya tüketicinin atanmış "birincil" Event Hubs ile konuşmasının engellenmesi ya da Event Hubs'ın gerçekten geçici olarak yanıt vermemesi veya hata döndürmesi gibi birçok yol vardır.

Olağanüstü durum kurtarma durumunda olduğu gibi bölgesel dağıtımı tamamen bırakmak isteyeceğiniz gibi bu koşullar "felaket" değildir, ancak bazı uygulamaların iş senaryosu zaten birkaç dakika hatta saniyeyi geçmeyecek kullanılabilirlik olaylarından etkilenmiş olabilir.

Bu tür senaryoları ele almak için iki temel desen vardır:

  • Çoğaltma düzeni, birincil Event Hubs'ın içeriğini ikincil bir Event Hubs'a çoğaltmaktır. Burada birincil Event Hubs genellikle uygulama tarafından hem olay üretmek hem de kullanmak için kullanılır ve birincil Event Hubs'ın kullanılamaz duruma gelmesi durumunda ikincil bir geri dönüş seçeneği olarak kullanılır. Çoğaltma tek yönlü olduğundan, birincilden ikincilye doğru hem üreticilerin hem de tüketicilerin kullanılamayan birincilden ikincilye geçişi, eski birincilin artık yeni olaylar almamasına neden olur ve bu nedenle artık geçerli olmaz. Bu nedenle saf çoğaltma yalnızca tek yönlü yük devretme senaryoları için uygundur. Yük devretme gerçekleştirildikten sonra eski birincil terk edilir ve farklı bir hedef bölgede yeni bir ikincil Event Hubs oluşturulması gerekir.
  • Birleştirme düzeni, iki veya daha fazla Event Hub'ın içeriğinin sürekli birleştirilmesini gerçekleştirerek çoğaltma desenini genişletir. Başlangıçta şemaya dahil edilen Event Hubs'lardan birinde üretilen her olay diğer Event Hubs'a çoğaltılır. Olaylar çoğaltılırken, daha sonra çoğaltma hedefinin çoğaltma işlemi tarafından yoksayılması için bunlara açıklama eklenir. Birleştirme desenini kullanmanın sonuçları, sonunda tutarlı bir şekilde aynı olay kümesini içerecek iki veya daha fazla Event Hub'dır.

Her iki durumda da Event Hubs içeriği aynı olmayacaktır. Herhangi bir üreticiden gelen ve aynı bölüm anahtarına göre gruplandırılmış olaylar, başlangıçta gönderilenle aynı göreli sırada görünür, ancak olayların mutlak sırası farklı olabilir. Bu durum özellikle kaynak ve hedef Event Hubs'ın bölüm sayısının farklı olduğu senaryolar için geçerlidir. Bu durum, burada açıklanan genişletilmiş desenlerin birkaçı için tercih edilir. Bölücü veya yönlendirici , yüzlerce bölüme ve huniye sahip çok daha büyük bir Event Hubs dilimini yalnızca birkaç bölüm içeren daha küçük bir Event Hubs'a alabilir ve alt kümeyi sınırlı işlem kaynaklarıyla işlemeye daha uygundur. Buna karşılık bir birleştirme , birkaç küçük Event Hubs'daki verileri birleştirilmiş aktarım hızı ve işleme gereksinimleriyle başa çıkmak için daha fazla bölüme sahip tek ve daha büyük bir Event Hubs'a dönüştürebilir.

Olayları bir arada tutmaya yönelik ölçüt, özgün bölüm kimliği değil bölüm anahtarıdır. Göreli sıra ve aynı akış uzaklıkları kapsamına bağlı kalmadan bir Event Hubs'tan diğerine yük devretme gerçekleştirme hakkında diğer konular çoğaltma düzeni açıklamasında ele alınmalıdır.

Rehber:

Gecikme süresini iyileştirme

Gecikme Süresini İyileştirme

Olay akışları üreticiler tarafından bir kez yazılır, ancak olay tüketicileri tarafından birkaç kez okunabilir. Bir bölgedeki olay akışının birden çok tüketici tarafından paylaşıldığı ve farklı bir bölgede bulunan analiz işlemleri sırasında tekrar tekrar erişilmesi gereken senaryolarda veya eş zamanlı tüketicileri yetersiz bırakabilecek tüm taleplerde, gidiş dönüş gecikmesini azaltmak için olay akışının bir kopyasını analiz işlemcisinin yanına yerleştirmek yararlı olabilir.

Çoğaltmanın, bölgeler arasında olayları uzaktan tüketirken tercih edilmesi gereken durumlar için iyi örnekler, özellikle bölgelerin çok uzak olduğu bölgelerdir; örneğin Avrupa ve Avustralya neredeyse antipodlardır, coğrafi olarak ve ağ gecikme süreleri herhangi bir gidiş dönüş için 250 ms'yi kolayca aşabilir. Işık hızını hızlandıramazsınız, ancak verilerle etkileşime geçmek için yüksek gecikmeli gidiş dönüş sayısını azaltabilirsiniz.

Rehber:

Doğrulama, azaltma ve zenginleştirme

Doğrulama, azaltma, zenginleştirme

Olay akışları, kendi çözümünüz dışındaki istemciler tarafından bir Event Hubs'a gönderilebilir. Bu tür olay akışları, harici olarak gönderilen olayların belirli bir şemayla uyumluluğun denetlenmesi ve uyumlu olmayan olayların bırakılması gerektirebilir.

Bant genişliği tarifeli birçok "Nesnelerin İnterneti" senaryosunda olduğu gibi istemcilerin bant genişliğinin son derece kısıtlandığı veya olayların kısıtlanmış paket boyutlarına sahip IP olmayan ağlar üzerinden gönderildiği senaryolarda, olayların aşağı akış olay işlemcileri tarafından kullanılabilir hale getirmek için başvuru verileriyle zenginleştirilmesi gerekebilir.

Diğer durumlarda, özellikle de akışlar birleştirildiğinde, olay verilerinin karmaşıklığı azaltılmış veya bazı ayrıntıların atlanmasıyla büyük boyutlu olması gerekebilir.

Bu işlemlerden herhangi biri çoğaltma, birleştirme veya birleştirme akışlarının bir parçası olarak gerçekleşebilir.

Rehber:

Analiz hizmetleriyle tümleştirme

Analiz hizmetleriyle tümleştirme

Azure Stream Analytics veya Azure Synapse gibi Azure'ın buluta özel analiz hizmetlerinin çoğu Azure Event Hubs'dan sunulan akışlı veya önceden toplu verilerle en iyi şekilde çalışır ve Azure Event Hubs ayrıca Apache Samza, Apache Flink, Apache Spark ve Apache Storm gibi çeşitli açık kaynak analiz paketleriyle tümleştirmeye olanak tanır.

Çözümünüz öncelikli olarak Service Bus veya Event Grid kullanıyorsa, bu olayları bu tür analiz sistemleri için ve event hubs'a hunilerseniz Event Hubs Capture ile arşivleme için kolayca erişilebilir hale getirebilirsiniz. Event Grid bunu Event Hubs tümleştirmesiyle yerel olarak yapabilir. Service Bus için Service Bus çoğaltma yönergelerini izlersiniz.

Azure Stream Analytics , Event Hubs ile doğrudan tümleşir.

Rehber:

Olay akışlarını birleştirme ve normalleştirme

Olay akışlarını birleştirme ve normalleştirme

Küresel çözümler genellikle kendi analiz özelliklerine sahip olmak da dahil olmak üzere büyük ölçüde bağımsız bölgesel ayak izlerinden oluşur, ancak supra-bölgesel ve küresel analiz perspektifleri tümleşik bir perspektif gerektirir ve bu nedenle yerel perspektif için ilgili bölgesel ayak izlerinde değerlendirilen aynı olay akışlarının merkezi bir şekilde birleştirilmesi gerekir.

Normalleştirme, iki veya daha fazla gelen olay akışının aynı tür olayları taşıdığı, ancak farklı yapılar veya farklı kodlamalarla birlikte en çok olayların tüketilmeden önce dönüştürüldüğü veya dönüştürüldüğü birleştirme senaryosunun bir çeşididir.

Normalleştirme ayrıca uçtan uca şifrelenmiş yüklerin şifresini çözme ve aşağı akış tüketici kitlesi için farklı anahtarlar ve algoritmalarla yeniden şifreleme gibi şifreleme çalışmalarını da içerebilir.

Rehber:

Olay akışlarını bölme ve yönlendirme

Olay akışlarını bölme ve yönlendirme

Azure Event Hubs bazen alınan olaylardan oluşan gelen bir torrentin Azure Service Bus veya Azure Event Grid kapasitesini aştığı ve her ikisi de yerel yayımlama-abone olma filtreleme ve dağıtım özelliklerine sahip olan ve bu desen için tercih edilen "yayımla-abone ol" stili senaryolarda kullanılır.

Gerçek bir "yayımla-abone ol" özelliği abonelere istedikleri olayları seçmeleri için bırakırken, bölme düzeninde üretici olayları önceden belirlenmiş bir dağıtım modeline göre bölümlere eşler ve belirlenen tüketiciler daha sonra yalnızca "kendi" bölümünden çeker. Event Hubs genel trafiği arabelleğe alırsa, özgün aktarım hızı hacminin bir bölümünü temsil eden belirli bir bölümün içeriği, güvenilir, işlemsel ve rakip tüketici tüketimi için bir kuyruğa çoğaltılabilir.

Event Hubs'ın öncelikli olarak bir bölgedeki bir uygulama içindeki olayları taşımak için kullanıldığı birçok senaryoda, yalnızca tek bir bölümden gelen belirli olayların başka bir yerde de kullanılabilir duruma getirilmesi gerekir. Bu senaryo bölme senaryosuna benzer, ancak bir Event Hubs'a gelen tüm iletileri dikkate alan ölçeklenebilir bir yönlendirici kullanabilir ve ileriye doğru yönlendirme için yalnızca birkaç tane seçer ve yönlendirme hedeflerini olay meta verilerine veya içeriğe göre ayırt edebilir.

Rehber:

Günlük projeksiyonları

Günlük projeksiyonu

Bazı senaryolarda, bir olayın herhangi bir alt akışı için gönderilen ve genellikle bölüm anahtarıyla ayırt edilen en son değere erişim sahibi olmak istersiniz. Apache Kafka'da bu genellikle herhangi bir benzersiz anahtarla etiketlenmiş en son olayı atan bir konu üzerinde "günlük sıkıştırma" etkinleştirilerek elde edilir. Günlük sıkıştırma yaklaşımının üç bileşik dezavantajı vardır:

  • Sıkıştırma, günlüğün sürekli olarak yeniden düzenlenmesini gerektirir. Bu, yalnızca ekleme iş yükleri için iyileştirilmiş bir aracı için aşırı pahalı bir işlemdir.
  • Sıkıştırma yıkıcıdır ve aynı akışın sıkıştırılmış ve sıkıştırılmamış bir perspektife izin vermez.
  • Sıkıştırılmış bir akışın hala sıralı erişim modeli vardır; başka bir deyişle günlükte istenen değeri bulmak için en kötü durumda günlüğün tamamının okunması gerekir ve bu da genellikle burada sunulan tam deseni uygulayan iyileştirmelere yol açar: günlük içeriğini bir veritabanına veya önbelleğe yansıtma.

Sonuçta sıkıştırılmış günlük bir anahtar-değer deposudur ve bu nedenle, bu tür bir depo için mümkün olan en kötü uygulama seçeneğidir. Aramalar ve sorguların günlüğün düzgün bir anahtar-değer deposuna veya başka bir veritabanına kalıcı bir projeksiyonunu oluşturması ve kullanması çok daha verimlidir.

Olaylar sabit olduğundan ve sıra her zaman bir günlükte korunduğu için, bir günlüğün anahtar-değer deposuna yansıtılması her zaman aynı olay aralığı için aynı olur, yani güncel tuttuğunuz bir projeksiyon her zaman yetkili bir görünüm sağlar ve oluşturulduktan sonra günlük içeriğinden yeniden oluşturmak için hiçbir zaman iyi bir neden yoktur.

Rehber:

Çoğaltma uygulaması teknolojileri

Yukarıdaki desenlerin uygulanması, yapılandırmak ve çalıştırmak istediğiniz çoğaltma görevleri için ölçeklenebilir ve güvenilir bir yürütme ortamı gerektirir. Azure'da bu tür görevler için en uygun çalışma zamanı ortamları durum bilgisi olmayan görevlerdir. Durum bilgisi olan akış çoğaltma görevleri için Azure Stream Analytics ve durum bilgisi olmayan çoğaltma görevleri için Azure İşlevleri.

Azure Stream Analytics'te durum bilgisi olan çoğaltma uygulamaları

Olaylar arasındaki ilişkileri göz önünde bulundurması, bileşik olaylar oluşturması, olayları zenginleştirmesi veya azaltması, veri toplamaları oluşturması ve olay yüklerini dönüştürmesi gereken durum bilgisi olan çoğaltma uygulamaları için Azure Stream Analytics en iyi uygulama seçeneğidir.

Azure Stream Analytics'te girdileri ve çıkışları tümleştirip girişlerdeki verileri sorgular aracılığıyla tümleştirerek çıkışlarda kullanılabilir hale gelen bir sonuç elde eden işler oluşturursunuz.

Sorgular SQL sorgu dilini temel alır ve akış verilerini belirli bir süre boyunca kolayca filtrelemek, sıralamak, toplamak ve birleştirmek için kullanılabilir. Bu SQL dilini JavaScript ve C# kullanıcı tanımlı işlevler (UDF) ile de genişletebilirsiniz. Basit dil yapıları ve/veya yapılandırmaları aracılığıyla toplama işlemleri gerçekleştirirken olay sıralama seçeneklerini ve zaman pencerelerinin süresini kolayca ayarlayabilirsiniz.

Her işin dönüştürülmüş veriler için bir veya birkaç çıkışı vardır ve analiz ettiğiniz bilgilere yanıt olarak ne olacağını denetleyebilirsiniz. Örneğin, şunları yapabilirsiniz:

  • İletişimleri veya özel iş akışlarını aşağı akış tetikleme amacıyla Azure İşlevleri, Service Bus Konuları veya Kuyruklar gibi hizmetlere veri gönderin.
  • Gerçek zamanlı pano oluşturmak için Power BI panosuna veri gönderme.
  • Toplu analiz gerçekleştirmek veya çok büyük, dizine alınan geçmiş veri havuzlarına dayalı makine öğrenmesi modellerini eğitmek için verileri diğer Azure depolama hizmetlerinde (örneğin, Azure Data Lake, Azure Synapse Analytics vb.) depolayın.
  • Projeksiyonları ("gerçekleştirilmiş görünümler" olarak da adlandırılır) veritabanlarında (SQL Veritabanı, Azure Cosmos DB) depolayın.

Azure İşlevleri'de durum bilgisi olmayan çoğaltma uygulamaları

Olayları yüklerini dikkate almadan iletmek veya olayların ilişkilerini (göreli düzenleri dışında) dikkate almak zorunda kalmadan tek tek işlemesini istediğiniz durum bilgisi olmayan çoğaltma görevleri için, muazzam esneklik sağlayan Azure İşlevleri kullanabilirsiniz.

Azure İşlevleri için önceden oluşturulmuş, ölçeklenebilir tetikleyiciler ve çıkış bağlamaları vardırAzure Event Hubs, Azure IoT Hub, Azure Service Bus, Azure Event Grid ve Azure Kuyruk Depolama yanı sıra RabbitMQ ve Apache Kafka için özel uzantılar. Tetikleyicilerin çoğu, belgelenen ölçümlere göre eşzamanlı olarak yürütülen örneklerin sayısını artırıp azaltarak aktarım hızı gereksinimlerine dinamik olarak uyarlanır.

Günlük projeksiyonları oluşturmak için Azure İşlevleri, Azure Cosmos DB ve Azure Tablo Depolama için çıkış bağlamalarını destekler.

Azure İşlevleriAzure tarafından yönetilen kimlik ve bu kimlikle, Kimlik bilgileri için yapılandırma değerlerini Azure Key Vault'un içinde sıkı erişim denetimli depolama alanında tutabilir.

Azure İşlevleri ayrıca çoğaltma görevlerinin tüm Azure mesajlaşma hizmetleri için Azure sanal ağları ve hizmet uç noktalarıyla doğrudan tümleştirilmesine olanak tanır ve Azure İzleyici ile kolayca tümleştirilir.

Azure İşlevleri tüketim planıyla, önceden oluşturulmuş tetikleyiciler çoğaltma için kullanılabilir ileti olmadığında bile ölçeği sıfıra düşürebilir. Başka bir deyişle yapılandırmayı ölçeği artırmaya hazır tutmanın maliyeti yoktur; tüketim planını kullanmanın en önemli dezavantajı, çoğaltma görevlerinin bu durumdan "tetiklenmesi" için gecikme süresinin altyapının çalıştırıldığı barındırma planlarından önemli ölçüde yüksek olmasıdır.

Tüm bunların aksine, Apache Kafka'nın MirrorMaker'ı gibi mesajlaşma ve olay oluşturma için en yaygın çoğaltma altyapıları bir barındırma ortamı sağlamanızı ve çoğaltma altyapısını kendiniz ölçeklendirmenizi gerektirir. Buna güvenlik ve ağ özelliklerini yapılandırma ve tümleştirme ile izleme verilerinin akışını kolaylaştırma dahildir ve ardından akışa özel çoğaltma görevleri ekleme fırsatınız olmaz.

Azure İşlevleri ile Azure Stream Analytics arasında seçim

Azure Stream Analytics (ASA), olayları çoğaltırken yüklerini işlemeniz gerektiğinde en iyi seçenektir. ASA olayları birer birer kopyalayabilir veya iletmeden önce olay akışlarının bilgilerini daraltan toplamalar oluşturabilir. Bu tür verileri bir akışa aktarmak zorunda kalmadan Azure Blob Depolama veya Azure SQL Veritabanı içinde tutulan başvuru verilerini tamamlamaya kolayca dayanabilir.

ASA ile hiper ölçekli veritabanlarında akışların kalıcı, gerçekleştirilmiş görünümlerini kolayca oluşturabilirsiniz. Apache Kafka'nın hantal "günlük sıkıştırma" modeline ve Kafka Akışlar'nin geçici, istemci tarafı tablo projeksiyonlarına çok daha üstün bir yaklaşımdır.

ASA, yükleri CSV, JSON ve Apache Avro biçimlerinde kodlanmış olan olayları kolayca işleyebilir ve başka herhangi bir biçim için özel seri durumdan çıkarıcıları takabilirsiniz.

Olay akışlarını "olduğu gibi" kopyalamak ve yüklere dokunmadan kopyalamak istediğiniz tüm çoğaltma görevleri için veya bir yönlendirici uygulamanız, şifreleme çalışması yapmanız, yüklerin kodlamasını değiştirmeniz veya veri akışı içeriği üzerinde tam denetime ihtiyaç duymanız durumunda en iyi seçenek Azure İşlevleri.

Sonraki Adımlar

Bu makalede, bir dizi federasyon desenini inceledik ve Azure İşlevleri Azure'da olay ve mesajlaşma çoğaltma çalışma zamanı olarak rolünü açıkladık.

Ardından, Azure Stream Analytics veya Azure İşlevleri ile bir çoğaltıcı uygulamasını ayarlamayı ve ardından Event Hubs ile diğer çeşitli olay ve mesajlaşma sistemleri arasında olay akışlarını çoğaltmayı okumak isteyebilirsiniz: