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

  • Makale

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 gerekenler
Performans Ne kadar işlem gereklidir?
Gecikme süresi Kullanıcı ile veri deposu arasındaki uzaklık gecikme süresi üzerinde ne gibi bir etki yaratacaktır? Gecikme süresinden elde edilen denge ile istenen tutarlılık düzeyi nedir?
Yanıt 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 Hata durumunda veri deposu otomatik olarak yük devredebiliyor mu? Yük devretme süresini kısaltmak için hangi ölçüler var?
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 eyaletlerin bölgesel damgalardan ayrılmış bir veritabanında küresel 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 verilerin bölgeler arasında eşitlenmesi birincil konu olmalıdır. Ayrıca, bir hata durumunda veritabanına yazma istekleri hala işlevsel olmalıdır.

    Etkin-etkin bir yapılandırmada veri çoğaltma 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 damga pulundaki 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 ortadan kaldırır. İşlenen istekler genel veritabanında kalıcıdır.

Verilerle ilgili dikkat edilmesi gereken diğer noktalar için bkz. İyi tasarlanmış Çerçeve: Veri platformunda dikkat edilmesi gerekenler bölümünde misson açısından 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 Mission-Critical başvuru uygulaması, maksimum dayanıklılık ve kullanılabilirlik sağlamak için çok ana kaynak teknolojisini 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ştirme özelliği, çakışma yönetimi modelini benimseme gereksinimini beraberinde getirir. Son Yazıcı 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 izin verir.

  • Sorgu iyileştirme

    Yüksek sayıda bölüme sahip yoğun okuma içeren kapsayıcılar için genel sorgu verimliliği önerisi, itemID'nin tanımlandığında bir eşitlik filtresi eklenmesidir. Azure Cosmos DB kullanırken 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.

Not

Çoğu iş yükü yalnızca OLTP değildir. Raporları işletim sisteminde ç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 kaydı getirme. Öğe kimliği ve bölüm anahtarı doğrudan maksimum iyileştirme için kullanılır (istek başına 1 RU).
    • Liste okumaları - Katalog öğelerinin listede görüntülenmesini sağlar. FeedIterator sonuç sayısı sınırı ile 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 işlemek için, trafik talebini milyonlarca kullanıcı sırasına göre işleyecek şekilde ölçeklendirme özelliğine sahip olacak şekilde 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ıyla).
  • Düşük gecikme süresi (milisaniye sırasıyla).

Yapılandırma

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

  • Tutarlılık düzeyi , tek bölgeli 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ı yazma işleminde düşük gecikme süresi gerektirmez.

    Not

    Oturum tutarlılığı düzeyi, bu belirli 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 ayarlanır /id . Bu karar, çoğunlukla "KIMLIK olarak GUID ile yeni belgeler yazma" ve "kimliklerle ç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ılarak sonsuz ölçeklendirmeye olanak tanır.

  • 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 uygulamadan bir örnek aşağıda verilmiştir:

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 beklenmeyen talep artışlarına 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 telemetriyi 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.

Yükü işleme

Mesajlaşma sisteminin gerekli aktarım hızını işleyebilmesi gerekir (mb/saniye cinsinden). Aşağıdaki topluluklara bir göz atın:

  • 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/saniyeyi 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 yinelenenleri kaldırma iletileri gibi tüm 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 aktarım hızı, standart katman için aktarım hızı birimi (TU) başına MB/saniye veya premium katman için işleme birimi (PU) olarak test edilerek 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. İşlemin ana hatları aşağıdadır:

    • İleti tüketicisi işlenmek üzere iletiyi alır.
    • Tüketiciye belirli bir süre boyunca ileti üzerinde özel bir kilit verilir.
    • Tüketici iletiyi başarıyla işlerse, aracıya bir onay 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 iletiden vazgeçerse, ö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.

  • İletiler birden çok 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, aynı yönteme sahip birden çok özdeş isteğin sunucusu üzerindeki amaçlanan etki, bu tür 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 ve bu da 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 bu 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çış iletilerinin 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 yerleştirirse, işlem bu işlemler arasında başarısız olmaya devam edebilir (yürütülen işlem - ileti gönderildi). Bu durumda, ileti yeniden işlemeden geçer, ancak bu kez idempotence guard yan tümcesi zaten işlendiğini görür (veritabanında depolanan verilere göre). yan tümcesi, her şeyin son seferde başarıyla yapıldığına inanarak kodu 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 sorunları veya çözümlerini tanımadığından, bu tekniklerin görev açısından kritik bir sistemde tutarlı bir şekilde uygulanmasını garanti etmek için, giden kutusunun işlevselliğine ve ileti aracısı ile etkileşimin bir tür kitaplıkta sarmalanmış olmasını öneririz. tüm kod işleme ve işlem açısından önemli iletiler gönderme, doğrudan ileti aracısı ile etkileşime girme 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ı alabilmesi için kullanılabilir olmalıdır. Bu gereksinimle ilgili ayrıntılar şunlardır:

  • Service Bus ile en yüksek kullanılabilirliği sağlamak için destek bölgelerindeki kullanılabilirlik alanları için destek sunan 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ğaltma veya aktif-pasif çoğaltma desenlerini göz önünde bulundurun.

Not

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 görevi 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ış isteklerin izlenmesini 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. Kuyruk derinliği, işleyicilerin otomatik ölçeklendirme mantığını bilgilendirmek için 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 son sıraya alınan 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 bir teslim edilemeyen ileti kuyruğuna ve DeadLetteredMessages ölçümüne sahiptir.
    • Event Hubs için bu işlevin tüketicide yerleşik olarak bulunan özel bir 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 üzerine çıkan CPU ve bellek, yapılandırılmış yeterli MU olmadığını gösterirken diğer eşiklerin altına düşmek yapılandırılmış ç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 katman aktarım hızı birimlerini (TU) kullanır. Bu katmanlar, PU'ları veya TU'ları otomatik olarak şişirmek için CPU/Bellek ile etkileşim gerektirmez.

Sistem durumu 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 faktörleri göz önünde bulundurun:

  • Mesajlaşma sistemi, ileti üreticileri ve tüketiciler arasında bir arabellek görevi görür. Üreticiler aracıya başarıyla ileti gönderebiliyorsa ve tüketiciler aracıdan gelen iletileri başarıyla işleyebilirse 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.

Uygulama: Mission-Critical Online