Azure'da görev açısından kritik iş yükleri için veri platformu

Görev açısından kritik bir mimaride, her durum mümkün olduğunca işlem dışında depolanmalıdır. Teknoloji seçimi şu temel mimari özellikleri temel alır:

Özellikler Dikkat edilmesi gereken noktalar
Performans Ne kadar işlem gereklidir?
Gecikme süresi Kullanıcı ve veri deposu arasındaki uzaklık gecikme süresine ne etki eder? Gecikme süresinde dengeleme ile istenen tutarlılık düzeyi nedir?
Tepkisellik Veri deposunun her zaman kullanılabilir olması gerekiyor mu?
Ölçeklenebilirlik Bölümleme düzeni nedir?
Dayanıklılık Verilerin uzun sürmesi bekleniyor mu? Bekletme ilkesi nedir?
Dayanıklılık Bir hata durumunda veri deposu otomatik olarak yük devredebiliyor mu? Yük devretme süresini kısaltmak için hangi önlemler alınıyor?
Güvenlik Veriler şifreleniyor mu? Veri deposuna genel ağ üzerinden erişilebilir mi?

Bu mimaride iki veri deposu vardır:

  • Veritabanı

    İş yüküyle ilgili depolar. Tüm durumların bölgesel damgalardan ayrılmış bir veritabanında genel olarak depolanması önerilir. Veritabanını bölgeler arasında dağıtarak yedeklilik oluşturun. Görev açısından kritik iş yükleri için birincil sorun verilerin bölgeler arasında eşitlenmesidir. Ayrıca, bir hata durumunda veritabanına yazma istekleri hala işlevsel olmalıdır.

    Etkin-etkin bir yapılandırmada veri çoğaltması kesinlikle önerilir. Uygulamanın başka bir bölgeye anında bağlanabilmesi gerekir. Tüm örneklerin okuma ve yazma isteklerini işleyebilmesi gerekir.

  • İleti aracısı

    Bölgesel damgadaki durum bilgisi olan tek hizmet, kısa bir süre için istekleri depolayan ileti aracısıdır. Aracı, arabelleğe alma ve güvenilir mesajlaşma gereksinimini karşılar. İşlenen istekler genel veritabanında kalıcıdır.

Diğer verilerle ilgili dikkat edilmesi gerekenler için bkz . İyi tasarlanmış Çerçeve: Veri platformunda dikkat edilmesi gerekenler bölümünde eksik kritik yönergeler.

Veritabanı

Bu mimaride NoSQL için Azure Cosmos DB kullanılır. Bu seçenek, bu tasarımda gereken en fazla özelliği sağladığından seçilir:

  • Çok bölgeli yazma

    Çok bölgeli yazma, bir damganın dağıtıldığı her bölgeye dağıtılan çoğaltmalarla etkinleştirilir. Her damga yerel olarak yazabilir ve Azure Cosmos DB, damgalar arasında veri çoğaltmayı ve eşitlemeyi işler. Bu özellik, uygulamanın coğrafi olarak dağıtılmış son kullanıcıları için gecikme süresini önemli ölçüde düşürür. Azure Görev Açısından Kritik başvuru uygulaması, maksimum dayanıklılık ve kullanılabilirlik sağlamak için çok ana teknoloji kullanır.

    Alanlar arası yedeklilik, çoğaltılan her bölge içinde de etkinleştirilir.

    Çok bölgeli yazma işlemleriyle ilgili ayrıntılar için bkz . Azure Cosmos DB kullanan uygulamalarınızda çok bölgeli yazmaları yapılandırma.

  • Çakışma yönetimi

    Aynı anda yazma işlemleri kayıt çakışmalarına neden olabileceğinden, birden çok bölgede yazma gerçekleştirebilme özelliği, çakışma yönetimi modelini benimseme gereksinimini beraberinde getirir. Son Yazan Kazanır varsayılan modeldir ve Görev Açısından Kritik tasarımı için kullanılır. Kayıtların ilişkili zaman damgaları tarafından tanımlanan son yazıcı çakışmayı kazanır. NoSQL için Azure Cosmos DB, özel bir özelliğin tanımlanmasına da olanak tanır.

  • Sorgu iyileştirme

    Yüksek sayıda bölüme sahip okuma yoğunluklu kapsayıcılar için genel sorgu verimliliği önerilerinden biri, itemID'si tanımlanmış bir eşitlik filtresi eklemektir. Azure Cosmos DB kullanırken karşılaşılan sorgu sorunlarını giderme bölümünde sorgu iyileştirme önerilerinin ayrıntılı bir incelemesi bulunabilir.

  • Yedekleme özelliği

    Veri koruması için Azure Cosmos DB'nin yerel yedekleme özelliğini kullanmanız önerilir. Azure Cosmos DB yedekleme özelliği çevrimiçi yedeklemeleri ve isteğe bağlı veri geri yüklemeyi destekler.

Dekont

çoğu iş yükü yalnızca OLTP değildir. Raporları işletim sistemine karşı çalıştırma gibi gerçek zamanlı raporlamaya yönelik artan bir talep vardır. Bu, HTAP (Karma İşlemsel ve Analitik İşleme) olarak da adlandırılır. Azure Cosmos DB, Azure Cosmos DB için Azure Synapse Link aracılığıyla bu özelliği destekler.

İş yükü için veri modeli

Veri modeli, geleneksel ilişkisel veritabanları tarafından sunulan özelliklerin gerekli olmayacak şekilde tasarlanmalıdır. Örneğin, yabancı anahtarlar, katı satır/sütun şeması, görünümler ve diğerleri.

İş yükü şu veri erişim özelliklerine sahiptir:

  • Okuma düzeni:
    • Nokta okumaları - Tek bir kayıt getiriliyor. Öğe kimliği ve bölüm anahtarı doğrudan maksimum iyileştirme (istek başına 1 RU) için kullanılır.
    • Liste okumaları - Katalog öğelerinin listede görüntülenmesini sağlar. FeedIterator sonuç sayısı sınırıyla birlikte kullanılır.
  • Yazma düzeni:
    • Küçük yazmalar - İstekler genellikle bir işleme tek veya az sayıda kayıt ekler.
  • Son kullanıcılardan gelen yüksek trafiği, milyonlarca kullanıcı sırasına göre trafik talebini işleyecek şekilde ölçeklendirebilme özelliğiyle işlemek için tasarlanmıştır.
  • Küçük yük veya veri kümesi boyutu - genellikle KB sırasına göre.
  • Düşük yanıt süresi (milisaniye sırasına göre).
  • Düşük gecikme süresi (milisaniye sırasına göre).

Yapılandırma

Azure Cosmos DB aşağıdaki gibi yapılandırılır:

  • Tutarlılık düzeyi , tek bölge ve genel olarak dağıtılmış uygulamalar için en yaygın kullanılan düzey olduğundan varsayılan Oturum tutarlılığı olarak ayarlanır. Yazma işleminin zaman uyumsuz yapısı nedeniyle daha yüksek aktarım hızıyla daha zayıf tutarlılık gerekmez ve veritabanı yazmada düşük gecikme süresi gerektirmez.

    Dekont

    Oturum tutarlılığı düzeyi, bu uygulama için gecikme süresi, kullanılabilirlik ve tutarlılık garantileri için makul bir denge sağlar. Çok ana şablonlu yazma veritabanlarında Güçlü tutarlılık düzeyinin kullanılamadığını anlamak önemlidir.

  • Bölüm anahtarı tüm koleksiyonlar için olarak /id ayarlanır. Bu karar, çoğunlukla "KIMLIK olarak GUID ile yeni belgeler yazma" ve "kimlikler tarafından çok çeşitli belgeleri okuma" olan kullanım desenini temel alır. Uygulama kodunun kimlik benzersizliğini koruması sağlandığında yeni veriler Azure Cosmos DB tarafından bölümlere eşit olarak dağıtılır ve böylece sonsuz ölçek etkinleştirilir.

  • Dizin oluşturma ilkesi sorguları iyileştirmek için koleksiyonlarda yapılandırılır. RU maliyetini ve performansını iyileştirmek için özel bir dizin oluşturma ilkesi kullanılır. Bu ilke yalnızca sorgu koşullarında kullanılan özellikleri dizine alır. Örneğin, uygulama sorgularda filtre olarak açıklama metin alanını kullanmaz. Özel dizin oluşturma ilkesinden dışlandı.

Terraform kullanarak dizin oluşturma ilkesi ayarlarını gösteren uygulama örneğini aşağıda bulabilirsiniz:

indexing_policy {

  excluded_path {
    path = "/description/?"
  }

  excluded_path {
    path = "/comments/text/?"
  }

  included_path {
    path = "/*"
  }

}

Bu mimaride uygulamadan Azure Cosmos DB'ye bağlantı hakkında bilgi için bkz . Görev açısından kritik iş yükleri için uygulama platformunda dikkat edilmesi gerekenler

Mesajlaşma hizmetleri

Görev açısından kritik sistemler genellikle ileti veya olay işleme için mesajlaşma hizmetlerini kullanır. Bu hizmetler gevşek bağlamayı teşvik eder ve sistemi talepteki beklenmeyen ani artışlara karşı yalıtan bir arabellek görevi görür.

  • Azure Service Bus, yüksek değerli iletileri işlerken ileti tabanlı iş yükleri için önerilir.
  • Azure Event Hubs, yüksek hacimli olayları veya telemetri verilerini işleyen olay tabanlı sistemler için önerilir.

Aşağıda, görev açısından kritik bir mimaride Azure Service Bus premium ve Azure Event Hubs için tasarımla ilgili önemli noktalar ve öneriler yer alır.

İşle yükü

Mesajlaşma sisteminin gerekli aktarım hızını (saniyede MB cinsinden olduğu gibi) işleyebilmesi gerekir. Aşağıdakileri göz önünde bulundurun:

  • Sistemin işlevsel olmayan gereksinimleri (NFR) ortalama ileti boyutunu ve her damganın desteklemesi gereken en yüksek ileti/saniye sayısını belirtmelidir. Bu bilgiler, damga pulu başına gereken en yüksek MB/saniye değerini hesaplamak için kullanılabilir.
  • Damga pulu başına gerekli en yüksek MB/saniye hesaplanırken yük devretmenin etkisi dikkate alınmalıdır.
  • Azure Service Bus için NFR'ler oturumlar ve yinelenen iletilerin silinmesi gibi gelişmiş Service Bus özelliklerini belirtmelidir. Bu özellikler Service Bus'ın aktarım hızını etkiler.
  • Service Bus'ın gerekli özelliklere sahip aktarım hızı, Mesajlaşma Birimi (MU) başına MB/saniye olarak test edilerek hesaplanmalıdır. Bu konu hakkında daha fazla bilgi için bkz . Service Bus premium ve standart mesajlaşma katmanları.
  • Azure Event Hubs'ın aktarım hızı, standart katman için aktarım hızı birimi başına MB/saniye (TU) veya premium katman için işleme birimi (PU) olarak hesaplanmalıdır. Bu konu hakkında daha fazla bilgi için bkz . Event Hubs ile ölçeklendirme.
  • Yukarıdaki hesaplamalar, mesajlaşma hizmetinin damga başına gerekli yükü ve bu yükü karşılamak için gereken ölçek birimi sayısını işleyebildiğini doğrulamak için kullanılabilir.
  • İşlemler bölümünde otomatik ölçeklendirme ele alınacaktır.

Her ileti işlenmelidir

Azure Service Bus premium katmanı, işlemenin garanti edilmesi gereken yüksek değerli iletiler için önerilen çözümdür. Azure Service Bus premium kullanırken bu gereksinimle ilgili ayrıntılar aşağıdadır:

  • İletilerin aracıya düzgün bir şekilde aktarılmasını ve aracı tarafından kabul edilmesini sağlamak için, ileti üreticilerinin desteklenen Service Bus API istemcilerinden birini kullanması gerekir. Desteklenen API'ler yalnızca ileti kuyrukta/konu başlığında kalıcı hale getirildiğinde gönderme işleminden başarıyla döndürülecektir.

  • Veri yolu üzerindeki iletilerin işlenmesini sağlamak için PeekLock alma modunu kullanmanız gerekir. Bu mod en az bir kez işlemeyi etkinleştirir. Aşağıda işlem özetlenmiştir:

    • İleti tüketicisi işlenmek üzere iletiyi alır.
    • Tüketiciye belirli bir süre boyunca iletide özel bir kilit verilir.
    • Tüketici iletiyi başarıyla işlerse, aracıya bir bildirim gönderir ve ileti kuyruktan kaldırılır.
    • Ayrılan süre içinde aracı tarafından bir bildirim alınmazsa veya işleyici açıkça iletiyi bırakırsa, özel kullanım kilidi serbest bırakılır. İleti daha sonra diğer tüketicilerin iletiyi işlemesi için kullanılabilir.
    • Bir ileti yapılandırılabilir sayıda başarıyla işlenmezse veya işleyici iletiyi teslim edilemeyen ileti kuyruğuna iletir.
      • Teslim edilemeyen ileti kuyruğuna gönderilen iletilerin üzerinde işlem gerçekleştirildiğinden emin olmak için, teslim edilemeyen ileti kuyruğu izlenmeli ve uyarılar ayarlanmalıdır.
      • Sistem, işleçlerin iletileri inceleyebilmesi, düzeltebilmesi ve yeniden gönderebilmesi için araçlara sahip olmalıdır.
  • İletiler birden fazla kez işlenebileceği için, ileti işleyicileri bir kez etkili hale getirilmelidir.

Bir kez etkili ileti işleme

RFC 7231'de, Köprü Metni Aktarım Protokolü "A ... yöntemi, söz konusu yöntemle birden çok özdeş isteğin sunucusu üzerindeki amaçlanan etki, tek bir isteğin etkisiyle aynıysa, bir kez etkili olarak kabul edilir."

İleti işlemeyi bir kez etkili hale getirmenin yaygın tekniklerinden biri, iletinin zaten işlenip işlenmediğini veritabanı gibi kalıcı bir depoyu denetlemektir. İşlenmişse, yeniden işlemek için mantığı çalıştırmazsınız.

  • İletinin işlenmesinde veritabanı işlemlerinin, özellikle de veritabanı tarafından oluşturulan tanımlayıcılarla yeni kayıtların eklenmesinin yer aldığı durumlar olabilir. Aracıya bu tanımlayıcıları içeren yeni iletiler yayılabilir. Hem veritabanını hem de ileti aracısını kapsayan dağıtılmış işlemler olmadığından, kodu çalıştıran işlemin başarısız olması durumunda ortaya çıkabilecek bir dizi karmaşıklık olabilir. Aşağıdaki örnek durumlara bakın:
    • İletileri yayan kod, veritabanı işlemi işlenmeden önce çalıştırılabilir. Bu, kaç geliştiricinin İş Birimi desenini kullanarak çalıştığıdır. Aracıyı çağırma ve veritabanı işleminin işlenmesini isteme arasında hata oluşursa bu iletiler kaçabilir. İşlem geri alınırken, veritabanı tarafından oluşturulan kimlikler de geri alınır ve bu kimlikler aynı anda çalışıyor olabilecek diğer kodlar için kullanılabilir durumda kalır. Bu, kaçış iletileri alıcılarının yanlış veritabanı girdilerini işlemesine neden olabilir ve bu da sisteminizin genel tutarlılığını ve doğruluğunu zedeler.
    • Geliştiriciler, veritabanı işlemi tamamlandıktan sonra iletiyi yayan kodu koyarsa, işlem bu işlemler (işlem tamamlandı - ileti gönderildi) arasında yine başarısız olabilir. Böyle bir durumda, ileti yeniden işlemeden geçer, ancak bu kez idempotence guard yan tümcesi zaten işlendiğini (veritabanında depolanan verilere göre) görür. yan tümcesi, her şeyin son seferde başarıyla yapıldığına inanarak kod yayan iletiyi atlar. Tamamlanan işlem hakkında bildirim almayı bekleyen aşağı akış sistemleri hiçbir şey almaz. Bu durum yine genel bir tutarsızlık durumuna neden olur.
  • Yukarıdaki sorunların çözümü, giden iletilerin iş verileriyle aynı işlem deposunda depolandığı İşlem Giden Kutusu düzeninin kullanılmasını içerir. İletiler daha sonra ilk ileti başarıyla işlendiğinde ileti aracısı'na iletilir.
  • Birçok geliştirici bu sorunlara veya çözümlerine aşina olmadığından, bu tekniklerin görev açısından kritik bir sistemde tutarlı bir şekilde uygulandığını garanti etmek için, giden kutusunun işlevselliğine ve ileti aracısı ile etkileşime bir tür kitaplıkta sarmalanmış olarak sahip olduğunuzu öneririz. tüm kod işleme ve işlem açısından önemli iletiler gönderme, ileti aracısı ile doğrudan etkileşimde bulunmak yerine bu kitaplığı kullanmalıdır.

Yüksek kullanılabilirlik ve olağanüstü durum kurtarma

İleti aracısı, üreticilerin ileti gönderebilmesi ve tüketicilerin bunları alması için kullanılabilir olması gerekir. Bu gereksinimle ilgili ayrıntılar şunlardır:

  • Service Bus ile en yüksek kullanılabilirliği sağlamak için, destekleyici bölgelerdeki kullanılabilirlik alanlarını destekleyen premium katmanı kullanın. Kullanılabilirlik alanlarıyla, iletiler ve meta veriler aynı bölgedeki üç farklı veri merkezinde çoğaltılır.
  • Okuma veya yazma hatalarını otomatik olarak yeniden denemek için desteklenen Service Bus veya Event Hubs SDK'larını kullanın.
  • Bölgesel olağanüstü durumlara karşı yalıtmak için etkin-etkin çoğaltmayı veya aktif-pasif çoğaltma desenlerini göz önünde bulundurun.

Dekont

Azure Service Bus Coğrafi olağanüstü durum kurtarma, meta verileri yalnızca bölgeler arasında çoğaltır. Bu özellik iletileri çoğaltmaz.

İzleme

Mesajlaşma sistemi, ileti üreticileri ve tüketiciler arasında bir arabellek işlevi görür. Aşağıda açıklanan değerli içgörüler sağlayan görev açısından kritik bir sistemde izlemeniz gereken önemli gösterge türleri vardır:

  • Azaltma - Azaltma, sistemin isteği işlemek için gerekli kaynaklara sahip olmadığını gösterir. Hem Service Bus hem de Event Hubs kısıtlanmış istekleri izlemeyi destekler. Bu göstergede uyarı vermelisiniz.
  • Kuyruk derinliği - Büyüyen bir kuyruk derinliği, ileti işlemcilerinin çalışmadığını veya geçerli yükü işlemek için yeterli işlemci olmadığını gösterebilir. İşleyicilerin otomatik ölçeklendirme mantığını bilgilendirmek için kuyruk derinliği kullanılabilir.
    • Service Bus için kuyruk derinliği ileti sayısı olarak gösterilir
    • Event Hubs için tüketicilerin bölüm başına kuyruk derinliğini hesaplaması ve ölçümü izleme yazılımınıza göndermesi gerekir. Her okuma için tüketici geçerli olayın sıra numarasını ve en son sıralanan olayın olay özelliklerini alır. Tüketici uzaklığı hesaplayabilir.
  • Teslim edilemeyen ileti kuyruğu - Teslim edilemeyen ileti kuyruğundaki iletiler işlenemeyen iletileri temsil eder. Bu iletiler genellikle el ile müdahale gerektirir. Uyarılar, teslim edilemeyen ileti kuyruğunda ayarlanmalıdır.
    • Service Bus'ın teslim edilemeyen bir kuyruğu ve DeadLetteredMessages ölçümü vardır.
    • Event Hubs için bu işlevin tüketicide yerleşik olarak bulunan özel mantık olması gerekir.
  • CPU/Bellek kullanımı - mesajlaşma sisteminin geçerli yükü işlemek için yeterli kaynağa sahip olduğundan emin olmak için CPU ve bellek izlenmelidir. Hem Service Bus premium hem de Event Hubs premium, CPU ve bellek Kullanımını kullanıma sunar.
    • Mesajlaşma birimleri (MU) Service Bus'ta bir ad alanı için CPU ve bellek gibi kaynakları yalıtmak için kullanılır. Bir eşiğin üzerinde yükselen CPU ve bellek, yapılandırılmış yeterli MU olmadığını gösterirken diğer eşiklerin altına düşmek yapılandırılan çok fazla MU olduğunu gösterebilir. Bu göstergeler, MU'ları otomatik ölçeklendirmek için kullanılabilir.
    • Event Hubs premium katmanı, kaynakları yalıtmak için işlem birimlerini (PU) kullanırken standart katmanda aktarım hızı birimleri (TU) kullanılır. Bu katmanlar, CPU'ları veya TU'ları otomatik olarak şişirmek için CPU/Bellek ile etkileşime ihtiyaç duymaz.

Durum denetimi

Görev açısından kritik bir uygulama için sistem durumu denetimlerinde mesajlaşma sisteminin sistem durumu dikkate alınmalıdır. Aşağıdaki etmenleri inceleyin:

  • Mesajlaşma sistemi, ileti üreticileri ve tüketiciler arasında bir arabellek işlevi görür. Üreticiler aracıya başarıyla ileti gönderebiliyorsa ve tüketicilerin aracıdan gelen iletileri başarıyla işleyebiliyorsa damga iyi durumda olarak görüntülenebilir.
  • Sistem durumu denetimi, iletilerin ileti sistemine gönderilebildiğinden emin olmalıdır.

Sonraki adımlar

Bu mimaride kullanılan kaynakları ve yapılandırmalarını tam olarak anlamak için başvuru uygulamasını dağıtın.