Azure'da görev açısından kritik iş yükleri için veri platformunda dikkat edilmesi gerekenler

  • Makale

Etkili bir uygulama veri platformunun seçilmesi, diğer tasarım alanları arasında çok geniş etkilere sahip olan daha önemli bir karar alanıdır. Azure nihai olarak çok sayıda ilişkisel, ilişkisel olmayan ve analitik veri platformu sunar ve bu platformlar büyük ölçüde farklılık gösterir. Bu nedenle, temel işlevsel olmayan gereksinimlerin tutarlılık, çalışabilirlik, maliyet ve karmaşıklık gibi diğer karar faktörleriyle birlikte tam olarak dikkate alınması önemlidir. Örneğin, çok bölgeli yazma yapılandırmasında çalışma yeteneği, küresel olarak kullanılabilir bir platform için uygun olma konusunda kritik bir taşıyıcıya sahip olacaktır.

Bu tasarım alanı uygulama tasarımını genişleterek en uygun veri platformunun seçilmesini bilgilendirmek için önemli noktalar ve öneriler sağlar.

Önemli

Bu makale, Azure Well-Architected görev açısından kritik iş yükü serisinin bir parçasıdır. Bu seriyi bilmiyorsanız görev açısından kritik iş yükü nedir? ile başlamanızı öneririz.

Büyük Verilerin Dört Karşılaştırması

'Dört Büyük Veri Karşılaştırması', yüksek oranda kullanılabilir bir veri platformu için gerekli özellikleri ve verilerin iş değerini en üst düzeye çıkarmak için nasıl kullanılabileceğini daha iyi anlamak için bir çerçeve sağlar. Bu bölümde uygun veri teknolojilerini kullanarak bir veri platformu tasarlamaya yardımcı olmak için Birim, Hız, Çeşitlilik ve Veracity özelliklerinin kavramsal düzeyde nasıl uygulanabileceği araştırılacaktır.

  • Voluşturma: Depolama kapasitesi ve katmanlama gereksinimlerini (veri kümesinin boyutu) bilgilendirmek için ne kadar veri geldiği.
  • Vkonumluluğu: Verilerin toplu veya sürekli akış olarak işlenme hızıdır ve bu da akış hızıdır.
  • Vözelliği: Birden çok depo veya türdeki veriler olan yapılandırılmış, yarı yapılandırılmış ve yapılandırılmamış biçimleri yakalayan verilerin organizasyonu ve biçimi.
  • Veracity: verilerin doğruluğu olan idare ve veri kalitesi güvencesi için göz önünde bulundurulan veri kümelerinin kanıtlanmışlığını ve küratörünü içerir.

Tasarımda Dikkat Edilmesi Gerekenler

Birim

  • mevcut (varsa) ve gelecekteki beklenen veri hacimleri, iş hedeflerine ve planlarına uygun tahmin edilen veri büyüme oranlarına dayalıdır.

    • Veri hacmi, verilerin kendisini ve dizinleri, günlükleri, telemetri verilerini ve diğer geçerli veri kümelerini içermelidir.
    • İş açısından kritik ve görev açısından kritik büyük uygulamalar genellikle günlük olarak yüksek hacimler (GB ve TB) oluşturur ve depolar.
    • Veri genişletmeyle ilgili önemli maliyet etkileri olabilir.

  • Değişen iş koşulları veya temizlik prosedürleri nedeniyle veri hacminde dalgalanmalar olabilir.

  • Veri hacmi, veri platformu sorgu performansı üzerinde derin bir etkiye sahip olabilir.

  • Veri platformu hacim sınırlarına ulaşmakla ilgili derin bir etki olabilir.

    • Kapalı kalma süresine neden olacak mı? Ve öyleyse, ne kadar süreyle?
    • Risk azaltma yordamları nelerdir? ve azaltma için uygulama değişiklikleri gerekecek mi?
    • Veri kaybı riski olacak mı?

  • Yaşam Süresi (TTL) gibi özellikler, geçen bir süreden sonra kayıt oluşturma veya değiştirme kullanılarak kayıtları otomatik olarak silerek veri büyümesini yönetmek için kullanılabilir.

    • Örneğin, Azure Cosmos DB yerleşik bir TTL özelliği sağlar.

Hız

  • Verilerin çeşitli uygulama bileşenlerinden yayılma hızı ve verilerin ne kadar hızlı işlenmesi ve alınması gerektiğiyle ilgili aktarım hızı gereksinimleri, önemli iş yükü senaryoları için en uygun veri teknolojisini belirlemek için kritik öneme sahiptir.

    • Aktarım hızı gereksinimlerinin doğası, yoğun okuma veya yazma ağırlıklı olanlar gibi iş yükü senaryosuna göre farklılık gösterir.
      • Örneğin analitik iş yüklerinin genellikle büyük bir okuma aktarım hızına uygun olması gerekir.
    • Gerekli aktarım hızı nedir? Aktarım hızının nasıl büyümesi bekleniyor?
    • Başvuru yük düzeyleri altında P50/P99'da veri gecikme süresi gereksinimleri nelerdir?

  • Kilitsiz tasarım, dizin ayarlama ve tutarlılık ilkelerini destekleme gibi özellikler, yüksek aktarım hızına ulaşmak için kritik öneme sahiptir.

    • Yüksek aktarım hızı için yapılandırmanın iyileştirilmesi, tam olarak anlaşılması gereken dengelemelere neden olur.
    • Aktarım hızını daha da iyileştirmek için CQRS ve Olay Kaynağını Belirleme gibi yük dengeleme kalıcılığı ve mesajlaşma desenleri kullanılabilir.

  • Yük düzeyleri birçok uygulama senaryosunda doğal olarak dalgalanır ve doğal zirveler, aktarım hızını ve gecikme süresini korurken değişken talebi işlemek için yeterli düzeyde esneklik gerektirebilir.

    • Çevik ölçeklenebilirlik, kapasite düzeylerini fazla sağlamadan değişken aktarım hızını ve yük düzeylerini etkili bir şekilde desteklemek için önemlidir.
      • Hem okuma hem de yazma aktarım hızının uygulama gereksinimlerine ve yüküne göre ölçeklendirilmesi gerekir.
      • Değişen yük düzeylerine yanıt vermek için hem dikey hem de yatay ölçeklendirme işlemleri uygulanabilir.

  • Aktarım hızı düşüşlerinin etkisi iş yükü senaryosuna göre farklılık gösterebilir.

    • Bağlantı kesintisi olacak mı?
    • Kontrol düzlemi çalışmaya devam ederken tek tek işlemler hata kodları döndürecek mi?
    • Veri platformu azaltmayı etkinleştirecek mi ve etkinleştirecekse ne kadar süreyle etkinleştirilecek?

  • Etkin-etkin bir coğrafi dağıtımı kullanmaya yönelik temel uygulama tasarımı önerisi, veri tutarlılığıyla ilgili güçlükler doğurur.

    • Tam ACID işlem semantiği ve geleneksel kilitleme davranışı açısından tutarlılık ve performans arasında bir denge vardır.
      • Yazma gecikme süresini en aza indirmek, veri tutarlılığı maliyetine neden olur.

  • Çok bölgeli yazma yapılandırmasında, değişikliklerin tüm çoğaltmalar arasında eşitlenmesi ve birleştirilmesi gerekir ve gerektiğinde çakışma çözümü gerekir ve bu durum performans düzeylerini ve ölçeklenebilirliği etkileyebilir.

  • Salt okunur çoğaltmalar (bölge içi ve bölgeler arası) gidiş dönüş gecikme süresini en aza indirmek ve performansı, aktarım hızını, kullanılabilirliği ve ölçeklenebilirliği artırmak için trafiği dağıtmak için kullanılabilir.

  • Önbelleğe alma katmanı, kullanıcı deneyimini ve uçtan uca istemci yanıt sürelerini geliştirmek üzere okuma aktarım hızını artırmak için kullanılabilir.

    • Verilerin güncelliğini iyileştirmek için önbellek süre sonu sürelerinin ve ilkelerinin dikkate alınması gerekir.

Çeşitli

  • Veri modeli, veri türleri, veri ilişkileri ve hedeflenen sorgu modeli, veri platformu kararlarını önemli ölçüde etkiler.

    • Uygulama bir ilişkisel veri modeli gerektiriyor mu yoksa değişken şemasını veya ilişkisel olmayan bir veri modelini destekleyebilir mi?
    • Uygulama verileri nasıl sorgulayacak? Sorgular ilişkisel birleşimler gibi veritabanı katmanı kavramlarına mı bağlı olacak? Yoksa uygulama bu tür semantiği sağlıyor mu?

  • Uygulama tarafından dikkate alınan veri kümelerinin yapısı, görüntü ve video gibi yapılandırılmamış içerikten veya CSV ve Parquet gibi daha yapılandırılmış dosyalardan değişebilir.

    • Bileşik uygulama iş yükleri genellikle farklı veri kümelerine ve ilişkili gereksinimlere sahip olur.

  • İlişkisel veya ilişkisel olmayan veri platformlarına ek olarak, graf veya anahtar-değer veri platformları da belirli veri iş yükleri için uygun olabilir.

    • Bazı teknolojiler, veri öğelerinin birbirine benzediği ve/veya birlikte depolandığı ve sorgulandığı ancak yapısal olarak farklılık gösterdiği değişken şema veri modellerine uygundur.

  • Mikro hizmet mimarisinde tek tek uygulama hizmetleri, tek bir monolitik veri deposuna bağlı olarak değil senaryo için iyileştirilmiş ayrı veri depolarıyla oluşturulabilir.

    • Farklı veri depoları arasındaki tutarlılığı ve bağımlılıkları yönetmek için SAGA gibi tasarım desenleri uygulanabilir.
      • Veritabanları arası doğrudan sorgular ortak konum kısıtlamaları uygulayabilir.
    • Birden çok veri teknolojisinin kullanılması, kapsanan teknolojileri korumak için bir derece yönetim yükü ekler.

  • Her Azure hizmeti için özellik kümeleri diller, SDK'lar ve API'ler arasında farklılık gösterir ve bu da uygulanabilecek yapılandırma ayarlama düzeyini büyük ölçüde etkileyebilir.

  • Veri modeli ve kapsamış veri türleriyle iyileştirilmiş hizalama özellikleri, veri platformu kararlarını önemli ölçüde etkiler.

    • Saklı yordamlar ve nesne ilişkisel eşleyiciler gibi sorgu katmanları.
    • Güvenli REST API katmanı gibi dilden bağımsız sorgu özelliği.
    • Yedekleme ve geri yükleme gibi iş sürekliliği özellikleri.

  • Analitik veri depoları genellikle çeşitli veri yapısı türleri için çok teknolojili depolamayı destekler.

    • Apache Spark gibi analitik çalışma zamanı ortamlarının çok teknolojili veri yapılarını analiz etmek için tümleştirme kısıtlamaları olabilir.

  • Kurumsal bağlamda, mevcut süreçlerin ve araçların kullanımı ve becerilerin sürekliliği, veri platformunun tasarımı ve veri teknolojilerinin seçimi üzerinde önemli bir yaklaşıma sahip olabilir.

Doğru -luğunu

  • Bir uygulamadaki verilerin doğruluğunu doğrulamak için çeşitli faktörler göz önünde bulundurulmalıdır ve bu faktörlerin yönetimi, veri platformunun tasarımını önemli ölçüde etkileyebilir.

    • Veri tutarlılığı.
    • Platform güvenliği özellikleri.
    • Veri idaresi.
    • Değişiklik yönetimi ve şema evrimi.
    • Veri kümeleri arasındaki bağımlılıklar.

  • Birden çok veri çoğaltması olan herhangi bir dağıtılmış uygulamada , CAP ve PACELC teoremlerinde belirtildiği gibi tutarlılık ve gecikme süresi arasında bir denge vardır.

    • Okuyucular ve yazıcılar ayrı bir şekilde dağıtıldığında, bir uygulama, veri öğesinin başka bir çoğaltmadaki yeni tamamlanan yazma (güncelleştirme) sürümüne veya veri öğesinin en güncel sürümüne kıyasla güncel olmasa bile veri öğesinin en hızlı kullanılabilir sürümünü veya en son durumu belirlemek ve elde etmek için ek gecikmeye neden olabilen veri öğesini döndürmeyi seçmelidir.
    • Tutarlılık ve kullanılabilirlik platform düzeyinde veya tek tek veri isteği düzeyinde yapılandırılabilir.
    • Veriler, kullanıcıya en yakın olan ve farklı bir çoğaltmanın en son durumunu yansıtmayan bir çoğaltmadan sunulacaksa kullanıcı deneyimi nedir? Örneğin uygulama güncel olmayan veriler sunma desteği sağlayabilir mi?

  • Çok bölgeli yazma bağlamında, her iki değişiklik de çoğaltılmadan önce aynı veri öğesi iki ayrı yazma çoğaltmasında değiştirildiğinde, çözülmesi gereken bir çakışma oluşturulur.

    • "Son Yazma Kazançları" gibi standartlaştırılmış çakışma çözümleme ilkeleri veya özel mantık içeren bir özel strateji uygulanabilir.

  • Güvenlik gereksinimlerinin uygulanması aktarım hızını veya performansı olumsuz etkileyebilir.

  • Bekleyen şifreleme, istemci tarafı şifrelemesi kullanılarak uygulama katmanında ve/veya gerekirse sunucu tarafı şifrelemesi kullanılarak veri katmanında uygulanabilir.

  • Azure, hizmet tarafından yönetilen anahtarları, Key Vault müşteri tarafından yönetilen anahtarları veya müşteri tarafından denetlenen donanımlarda müşteri tarafından yönetilen anahtarları kullanan sunucu tarafı şifreleme dahil olmak üzere çeşitli şifreleme modellerini destekler.

    • İstemci tarafı şifreleme ile anahtarlar Key Vault veya başka bir güvenli konumda yönetilebilir.

  • MACsec (IEEE 802.1AE MAC) veri bağlantısı şifrelemesi, Microsoft omurga ağındaki Azure veri merkezleri arasında hareket eden tüm trafiğin güvenliğini sağlamak için kullanılır.

    • Paketler gönderilmeden önce cihazlarda şifrelenir ve şifreleri çözülür, böylece fiziksel 'ortadaki adam' veya gözetleme/dinleme saldırıları engellenir.

  • Veri düzlemi ve kontrol düzlemi için kimlik doğrulaması ve yetkilendirme.

    • Veri platformu uygulama erişiminin ve işletimsel erişimin kimliğini nasıl doğrulayacak ve yetkilendirilecek?

  • Platform sistem durumunu ve veri erişimini izleme yoluyla gözlemlenebilirlik.

    • Kabul edilebilir operasyonel sınırların dışındaki koşullar için uyarı nasıl uygulanacak?

Tasarım Önerileri

Birim

  • Organik büyümeyle ilişkili gelecekteki veri hacimlerinin veri platformu özelliklerini aşmasını beklemediğinden emin olun.

    • İş planlarına uygun veri büyüme oranlarını tahmin edin ve devam eden kapasite gereksinimlerini bilgilendirmek için belirlenmiş oranları kullanın.
    • Toplama ve veri başına kayıt hacimlerini veri platformu sınırlarıyla karşılaştırın.
    • Olağanüstü durumlarda sınırlara ulaşılma riski varsa, kapalı kalma süresini ve veri kaybını önlemek için operasyonel azaltmaların uygulandığından emin olun.

  • Ölçek sınırlarını ve beklenen veri büyüme oranlarını göz önünde bulundurarak veri hacmini izleyin ve bir kapasite modeline göre doğrulayın.

    • Ölçeklendirme işlemlerinin depolama, performans ve tutarlılık gereksinimleriyle uyumlu olduğundan emin olun.
    • Yeni bir ölçek birimi kullanıma sunulduğunda, temel alınan verilerin çoğaltılması gerekebilir ve bu da zaman alabilir ve çoğaltma gerçekleşirken büyük olasılıkla bir performans cezasına neden olur. Bu nedenle bu işlemlerin mümkünse kritik iş saatleri dışında gerçekleştirildiğinden emin olun.

  • Eski verilerin kaldırılmasını veya boşaltılmasını kolaylaştırmak için veri kümelerini kullanıma ve kritikliğe göre sınıflandırmak için uygulama veri katmanlarını tanımlayın.

    • Veri kümelerini 'sık erişimli', 'sıcak' ve 'soğuk' ('arşiv') katmanlarına sınıflandırmayı göz önünde bulundurun.
      • Örneğin, temel başvuru uygulamaları uygulama tarafından etkin olarak kullanılan 'sık erişimli' verileri depolamak için Azure Cosmos DB'yi kullanırken, Azure Depolama ise analiz amacıyla "soğuk" işlem verileri için kullanılır.

  • Veri büyümesini iyileştirmek ve sorgu performansı ve veri genişletmeyi yönetme gibi veri verimliliklerini yönlendirmek için temizlik yordamlarını yapılandırın.

    • Artık gerekli olmayan ve uzun vadeli analitik değeri olmayan veriler için Yaşam Süresi (TTL) süre sonunu yapılandırın.
      • Eski verilerin ikincil depolama alanına güvenli bir şekilde katmanlanabildiğini veya uygulamayı olumsuz etkilemeden silinebildiğini doğrulayın.
    • Kritik olmayan verileri ikincil soğuk depolama alanına boşaltıp analiz değeri ve denetim gereksinimlerini karşılamak için bu verileri koruyun.
    • DevOps ekiplerinin temizlik gereksinimlerini ve 'doğru boyut' veri depolarını sürekli olarak değerlendirmesine olanak tanımak için veri platformu telemetri verilerini ve kullanım istatistiklerini toplayın.

  • Mikro hizmet uygulama tasarımına uygun olarak, belirli iş yükü senaryoları ve birim gereksinimleri için iyileştirilmiş veri çözümleriyle birden çok farklı veri teknolojisini paralel olarak kullanmayı göz önünde bulundurun.

    • Genişletmeden gelen veri hacminin yönetilmesinin zor olduğu tek bir monolitik veri deposu oluşturmaktan kaçının.

Hız

  • Veri platformu, senaryo için iyileştirilmiş veri çözümlerini kullanarak performansı en üst düzeye çıkarmak için farklı bağlamlara ayrılmış iş yükleriyle birlikte yüksek aktarım hızını destekleyecek şekilde doğal olarak tasarlanıp yapılandırılmalıdır.

    • Her veri senaryosu için okuma ve yazma aktarım hızının beklenen yük desenlerine göre ölçeklenebilmesini ve beklenmeyen varyans için yeterli toleransa sahip olmasını sağlayın.
    • İşlem ve analitik işlemler gibi farklı veri iş yüklerini ayrı performans bağlamlarına ayırın.

  • CQRS veya Olay Kaynağını Belirleme desenleri gibi zaman uyumsuz engelleyici olmayan ileti kullanımı aracılığıyla yük düzeyi.

    • Yazma istekleri ile yeni verilerin okunmaya uygun hale gelmesi arasında gecikme olabilir ve bu durum kullanıcı deneyimini etkileyebilir.
      • Bu etki, temel iş gereksinimleri bağlamında anlaşılmalı ve kabul edilebilir olmalıdır.

  • Değişken aktarım hızını ve yük düzeylerini desteklemek için çevik ölçeklenebilirlik sağlayın.

    • Yük düzeyleri yüksek oranda geçiciyse, aktarım hızının ve performansın korunmasını sağlamak için kapasite düzeylerini fazla sağlamayı göz önünde bulundurun.
    • Aktarım hızı korunamıyorsa bileşik uygulama iş yükleri üzerindeki etkisini test edin ve doğrulayın.

  • Yük düzeyinde volatiliteye hızlı yanıt verme işlemini kolaylaştırmak için otomatik ölçeklendirme işlemleriyle Azure'a özel veri hizmetlerinin önceliklerini belirleyin.

    • Hizmet içi ve uygulama kümesi eşiklerine göre otomatik ölçeklendirmeyi yapılandırın.
    • Ölçeklendirme, iş gereksinimleriyle tutarlı olarak zaman çerçevelerinde başlatılmalı ve tamamlanmalıdır.
    • El ile etkileşimin gerekli olduğu senaryolar için el ile işlem eylemleri gerçekleştirmek yerine tetiklenebilen otomatik operasyonel 'playbook'lar oluşturun.
      • Otomatik tetikleyicilerin sonraki mühendislik yatırımlarının bir parçası olarak uygulanıp uygulanamayacağını göz önünde bulundurun.

  • Uygulama verilerinin P50/P99 gecikme süresi gereksinimlerine göre okuma ve yazma aktarım hızını izleyin ve bir uygulama kapasitesi modeliyle uyumlu hale getirme.

  • Fazla aktarım hızı, veri platformu veya uygulama katmanı tarafından düzgün bir şekilde işlenmeli ve işletimsel gösterim için sistem durumu modeli tarafından yakalanmalıdır.

  • Yanıt sürelerini en aza indirmek için 'sık erişimli' veri senaryoları için önbelleğe alma uygulayın.

    • Önbellek süre sonu ve ev tutma için uygun ilkeleri uygulayarak verilerden kaçmasını önle.
      • Yedekleme verileri değiştiğinde önbellek öğelerinin süresinin dolması.
      • Önbellek süre sonu kesinlikle Yaşam Süresi (TTL) tabanlıysa, güncel olmayan verileri sunmanın etkisi ve müşteri deneyiminin anlaşılması gerekir.

Çeşitli

  • Bulut ve Azure'a özel tasarım ilkesine uygun olarak, operasyonel ve yönetim karmaşıklığını azaltmak ve Microsoft'un gelecekteki platform yatırımlarından yararlanmak için yönetilen Azure hizmetlerine öncelik vermek kesinlikle önerilir.

  • Gevşek bağlanmış mikro hizmet mimarilerinin uygulama tasarım ilkesine uygun olarak, tek tek hizmetlerin ayrı veri depolarını ve senaryo için iyileştirilmiş veri teknolojilerini kullanmasına olanak sağlar.

    • Uygulamanın belirli iş yükü senaryoları için işleyecek veri yapısı türlerini belirleyin.
    • Tek bir monolitik veri deposuna bağımlılık oluşturmaktan kaçının.
      • Veri depoları arasındaki bağımlılıkların bulunduğu SAGA tasarım desenini göz önünde bulundurun.

  • Seçili veri teknolojileri için gerekli özelliklerin kullanılabilir olduğunu doğrulayın.

    • Gerekli diller ve SDK özellikleri için destek olduğundan emin olun. Her dil/SDK için her özellik aynı şekilde kullanılamaz.

Doğru -luğunu

  • Çok bölgeli bir veri platformu tasarımı benimseyin ve verileri uygulama uç noktalarına yaklaştırarak en yüksek güvenilirlik, kullanılabilirlik ve performans için çoğaltmaları bölgeler arasında dağıtın.

    • Bölge içi kullanılabilirliği en üst düzeye çıkarmak için veri çoğaltmalarını bir bölge içindeki Kullanılabilirlik Alanları (AZ) arasında dağıtın (veya alanlar arası yedekli hizmet katmanları kullanın).

  • Tutarlılık gereksinimlerinin buna olanak sağladığı durumlarda, genel kullanılabilirliği ve güvenilirliği en üst düzeye çıkarmak için çok bölgeli yazma veri platformu tasarımını kullanın.

    • Aynı veri öğesi iki ayrı yazma çoğaltmasında değiştirildiğinde, her iki değişiklik de çoğaltılmadan ve dolayısıyla çakışma oluşturmadan önce çakışma çözümü için iş gereksinimlerini göz önünde bulundurun.
      • Mümkün olduğunda "Sonuncu kazanır" gibi standartlaştırılmış çakışma çözümleme ilkeleri kullanın
        • Özel mantık içeren bir özel strateji gerekiyorsa, özel mantığı yönetmek için CI/CD DevOps uygulamalarının uygulandığını doğrulayın.

  • Sürekli teslim süreçlerinde kaos testi aracılığıyla yedekleme ve geri yükleme özelliklerini ve yük devretme işlemlerini test edin ve doğrulayın.

  • Aktarım hızı ve performans gereksinimlerinin şifreleme gibi gerekli güvenlik özelliklerinin eklenmesinden etkilenmediğinden emin olmak için performans karşılaştırmalarını çalıştırın.

    • Sürekli teslim işlemlerinin bilinen performans karşılaştırmalarına karşı yük testi yapmayı göz önünde bulundurdığından emin olun.

  • Şifreleme uygularken, yönetim karmaşıklığını azaltmanın bir yolu olarak hizmet tarafından yönetilen şifreleme anahtarlarının kullanılması kesinlikle önerilir.

    • Müşteri tarafından yönetilen anahtarlar için belirli bir güvenlik gereksinimi varsa, kabul edilen tüm anahtarların kullanılabilirliğini, yedeklemesini ve döndürmesini sağlamak için uygun anahtar yönetimi yordamlarının uygulandığından emin olun.

Not

Daha geniş bir kurumsal uygulamayla tümleştirme yaparken, uygulama tasarımında veri platformu bileşenlerinin sağlanması ve çalıştırılması için uygulama merkezli bir yaklaşımın uygulanması kritik önem taşır.

Daha açık belirtmek gerekirse, güvenilirliği en üst düzeye çıkarmak için, tek tek veri platformu bileşenlerinin diğer uygulama bileşenlerini içerebilecek operasyonel eylemler aracılığıyla uygulama durumuna uygun şekilde yanıt vermesi kritik önem taşır. Örneğin, ek veri platformu kaynaklarının gerekli olduğu bir senaryoda, büyük olasılıkla ek ölçek birimlerinin sağlanması yoluyla veri platformunun ve diğer uygulama bileşenlerinin bir kapasite modeline göre ölçeklendirilmesi gerekecektir. Merkezi operasyon ekibinin veri platformuyla ilgili sorunları yalıtılmış olarak ele almak için zor bir bağımlılığı varsa, bu yaklaşım nihai olarak kısıtlanır.

Sonuç olarak, merkezi veri hizmetlerinin (Yani Merkezi BT DBaaS) kullanılması, büyük ölçüde metinsiz bir yönetim deneyimi aracılığıyla çevikliği önemli ölçüde engelleyen operasyonel performans sorunlarına yol açmıştır ve görev açısından kritik veya iş açısından kritik bir bağlamdan kaçınılmalıdır.

Ek başvurular

ek veri platformu kılavuzu, Azure Uygulaması Mimari Kılavuzu'nda bulunabilir.

Genel olarak dağıtılmış çok bölgeli yazma veri deposu

Bir uygulama tasarımının genel olarak dağıtılmış etkin-etkin hedeflerine tam olarak uyum sağlamak için, ayrı yazılabilir çoğaltmalarda yapılan değişikliklerin eşitlendiği ve tüm çoğaltmalar arasında birleştirildiği ve gerektiğinde çakışma çözümlemesiyle dağıtılmış çok bölgeli yazma veri platformunu dikkate almanız önemle önerilir.

Önemli

Mikro hizmetlerin tümü dağıtılmış çok bölgeli yazma veri deposu gerektirmeyebilir, bu nedenle her iş yükü senaryosunun mimari bağlamı ve iş gereksinimlerine dikkat edilmelidir.

Azure Cosmos DB, genel olarak dağıtılmış ve yüksek oranda kullanılabilir bir NoSQL veri deposu sağlayarak çok bölgeli yazma işlemleri ve ayarlanabilir tutarlılık sunar. Bu nedenle bu bölümdeki tasarım konuları ve önerileri en iyi Azure Cosmos DB kullanımına odaklanacaktır.

Tasarım konusunda dikkat edilmesi gerekenler

Azure Cosmos DB

  • Azure Cosmos DB verileri, milisaniye sırasına göre yanıt süreleriyle hızlı işlem okuma ve yazma işlemlerine olanak sağlamak için tasarlanmış dizine alınmış, satır tabanlı işlemsel depolar olan Kapsayıcılar içinde depolar.

  • Azure Cosmos DB, SQL, Cassandra ve MongoDB gibi farklı özellik kümelerine sahip birden çok farklı API'yi destekler.

    • NoSQL için birinci taraf Azure Cosmos DB, en zengin özellik kümesini sağlar ve genellikle yeni özelliklerin ilk kullanıma sunulacağı API'dir.

  • Azure Cosmos DB, Ağ Geçidi ve Doğrudan bağlantı modlarını destekler. Burada Direct, daha az ağ atlamasıyla performansı artırmak için arka uç Azure Cosmos DB çoğaltma düğümlerine TCP üzerinden bağlantıyı kolaylaştırırken, Ağ Geçidi ön uç ağ geçidi düğümlerine HTTPS bağlantısı sağlar.

    • Doğrudan mod yalnızca NoSQL için Azure Cosmos DB kullanıldığında kullanılabilir ve şu anda yalnızca .NET ve Java SDK platformlarında desteklenir.

  • Kullanılabilirlik Alanı özellikli bölgelerde Azure Cosmos DB, bölge içindeki bölgesel hatalara karşı yüksek kullanılabilirlik ve dayanıklılık için Kullanılabilirlik Alanı (AZ) yedekliliği desteği sunar.

  • Azure Cosmos DB, verilerin dört çoğaltmasını tek bir bölge içinde tutar ve Kullanılabilirlik Alanı (AZ) yedekliliği etkinleştirildiğinde Azure Cosmos DB, bölgesel hatalara karşı koruma sağlamak için veri çoğaltmalarının birden çok AZ'ye yerleştirilmesini sağlar.

    • Bölge içindeki çoğaltmalar arasında çekirdek elde etmek için Paxos konsensüs protokolü uygulanır.

  • Azure Cosmos DB hesabı, tek bir bölgenin kullanılamaz duruma gelmesi riskini azaltmak için verileri birden çok bölgede çoğaltacak şekilde kolayca yapılandırılabilir.

    • Çoğaltma, tek bölgeli yazmalar veya çok bölgeli yazmalarla yapılandırılabilir.
      • Tek bölge yazma işlemlerinde, tüm yazma işlemlerine hizmet vermek için birincil bir 'hub' bölgesi kullanılır ve bu 'hub' bölgesi kullanılamaz hale gelirse, başka bir bölgeyi yazılabilir olarak yükseltmek için bir yük devretme işlemi gerçekleştirilmelidir.
      • Çok bölgeli yazma işlemleriyle, uygulamalar yapılandırılmış herhangi bir dağıtım bölgesine yazabilir ve bu da değişiklikleri diğer tüm bölgeler arasında çoğaltır. Bir bölge kullanılamıyorsa, yazma trafiğini sunmak için kalan bölgeler kullanılır.

  • Çok bölgeli yazma yapılandırmasında, yazıcıların aynı öğeyi birden çok bölgede eşzamanlı olarak güncelleştirdiği güncelleştirme (ekleme, değiştirme, silme) çakışmaları oluşabilir.

  • Azure Cosmos DB, çakışmaları otomatik olarak gidermek için uygulanabilen iki çakışma çözümleme ilkesi sağlar.

    • Son Yazma Kazançları (LWW), çakışma çözümleme yolu olarak sistem tanımlı bir zaman damgası _ts özelliği kullanarak bir zaman eşitleme saat protokolü uygular. Bir çakışma durumunda, çakışma çözümleme yolu için en yüksek değere sahip olan öğe kazanan olur ve birden çok öğe aynı sayısal değere sahipse sistem bir kazanan seçer ve böylece tüm bölgeler taahhüt edilen öğenin aynı sürümüne yakınsanabilir.
      • Silme çakışmaları ile, silinen sürüm her zaman çakışma çözümleme yolu değerinden bağımsız olarak ekleme veya değiştirme çakışmalarını kazanır.
      • Son Yazma Galibiyeti, varsayılan çakışma çözümleme ilkesidir.
      • NoSQL için Azure Cosmos DB kullanılırken, çakışma çözümlemesi için özel zaman damgası tanımı gibi özel bir sayısal özellik kullanılabilir.
    • Özel çözümleme ilkeleri, uygulama tanımlı semantiğin çakışmalar algılandığında otomatik olarak çağrılan kayıtlı bir birleştirme saklı yordamını kullanarak çakışmaları uzlaştırmasına olanak sağlar.
      • Sistem, taahhüt protokolünün bir parçası olarak birleştirme yordamının yürütülmesi için tam olarak bir kez garanti sağlar.
      • Özel çakışma çözme ilkesi yalnızca NoSQL için Azure Cosmos DB ile kullanılabilir ve yalnızca kapsayıcı oluşturma zamanında ayarlanabilir.

  • Çok bölgeli yazma yapılandırmasında, tüm çakışma çözümlemelerini gerçekleştirmek için tek bir Azure Cosmos DB 'hub' bölgesine bağımlılık vardır ve hub bölgesi içindeki çoğaltmalar arasında çekirdek elde etmek için Paxos konsensüs protokolü uygulanır.

    • Platform, yük düzeyine ve geçici hatalar için yedeklilik sağlamaya yönelik hub bölgesindeki yazma çakışmaları için bir ileti arabelleği sağlar.
      • Arabellek, fikir birliği gerektiren birkaç dakikalık yazma güncelleştirmelerini depolayabiliyor.

Azure Cosmos DB platformunun stratejik yönü, küresel düzeyde ve bir bölge içinde çekirdek elde etmek için 2 aşamalı bir Paxos yaklaşımını kullanarak çok bölgeli yazma yapılandırmasında çakışma çözümü için bu tek bölge bağımlılığını kaldırmaktır.

  • Birincil 'hub' bölgesi, Azure Cosmos DB'nin içinde yapılandırıldığı ilk bölge tarafından belirlenir.

    • Yük devretme amacıyla ek uydu dağıtım bölgeleri için öncelik sıralaması yapılandırılır.

  • Mantıksal ve fiziksel bölümler arasında veri modeli ve bölümleme, en iyi performans ve kullanılabilirlik elde etmede önemli bir rol oynar.

  • Tek bir yazma bölgesiyle dağıtıldığında Azure Cosmos DB, tüm okuma bölgesi çoğaltmaları dikkate alınarak tanımlanmış bir yük devretme önceliğine göre otomatik yük devretme için yapılandırılabilir.

  • Azure Cosmos DB platformu tarafından sağlanan RTO yaklaşık 10-15 dakikadır ve merkez bölgesini etkileyen yıkıcı bir olağanüstü durum olduğunda Azure Cosmos DB hizmetinin bölgesel yük devretmesini gerçekleştirmek için geçen süreyi yakalar.

    • Bu RTO, çakışma çözümü için tek bir 'hub' bölgesine bağımlılık göz önüne alındığında çok bölgeli yazma bağlamında da geçerlidir.
      • 'Hub' bölgesi kullanılamaz duruma gelirse, çakışma çözümü hizmet yük devredilene ve yeni bir hub bölgesi kurulana kadar gerçekleşemeyeceğinden, ileti arabelleği dolduktan sonra diğer bölgelere yapılan yazma işlemleri başarısız olur.

Azure Cosmos DB platformunun stratejik yönü, bölüm düzeyinde yük devretmelere izin vererek RTO'yu yaklaşık 5 dakikaya düşürmektir.

  • Kurtarma Noktası Hedefleri (RPO) ve Kurtarma Süresi Hedefleri (RTO), tutarlılık düzeyleri aracılığıyla yapılandırılabilir ve veri dayanıklılığı ile aktarım hızı arasında denge sağlanır.

    • Azure Cosmos DB, çok bölgeli yazma işlemleriyle rahat bir tutarlılık düzeyi için en az 0 RTO veya tek yazma bölgesiyle güçlü tutarlılık için 0 RPO sağlar.

  • Azure Cosmos DB, birden çok Azure bölgesi yazılabilir olarak yapılandırılmış Veritabanı Hesapları için hem okuma hem de yazma kullanılabilirliği için %99,999 SLA sunar.

    • SLA, %100 - Ortalama Hata Oranı olarak hesaplanan Aylık Çalışma Süresi Yüzdesi ile temsil edilir.
    • Ortalama Hata Oranı, faturalama ayındaki her bir saat için Hata Oranlarının toplamının faturalama ayındaki toplam saat sayısına bölünmesi olarak tanımlanır; burada Hata Oranı, belirli bir saatlik aralıkta Başarısız İsteklerin Toplam İstek sayısına bölünür.

  • Azure Cosmos DB, beş Tutarlılık Düzeyinden herhangi biriyle yapılandırıldığında kapsamı tek bir Azure bölgesi olan Veritabanı Hesapları için aktarım hızı, tutarlılık, kullanılabilirlik ve gecikme süresi için %99,99 SLA sunar.

    • %99,99 SLA, dört gevşek Tutarlılık Düzeyinden herhangi biriyle yapılandırılmış birden çok Azure bölgesini kapsayan Veritabanı Hesapları için de geçerlidir.

  • Azure Cosmos DB'de sağlanabilir iki tür aktarım hızı vardır. Standart ve otomatik ölçeklendirme, saniye başına İstek Birimleri (RU/sn) kullanılarak ölçülür.

    • Standart aktarım hızı, belirtilen RU/sn değerini garanti etmek için gereken kaynakları ayırır.
      • Standart, sağlanan aktarım hızı için saatlik olarak faturalandırılır.
    • Otomatik ölçeklendirme en yüksek aktarım hızı değerini tanımlar ve Azure Cosmos DB, uygulama yüküne bağlı olarak maksimum aktarım hızı değeri ile maksimum aktarım hızı değerinin en az %10'unun arasında otomatik olarak ölçeği artırır veya küçültür.
      • Otomatik ölçeklendirme, tüketilen en yüksek aktarım hızı için saatlik olarak faturalandırılır.

  • Değişken iş yüküyle sağlanan statik aktarım hızı azaltma hatalarıyla sonuçlanabilir ve bu da algılanan uygulama kullanılabilirliğini etkiler.

    • Otomatik ölçeklendirme, Azure Cosmos DB'nin gerektiğinde ölçeği artırmasına olanak tanıyarak azaltma hatalarına karşı koruma sağlarken, yük azaldığında ölçeği azaltarak maliyet korumasını korur.

  • Azure Cosmos DB birden çok bölgede çoğaltıldığında, sağlanan İstek Birimleri (RU) bölge başına faturalandırılır.

  • Çok bölgeli yazma ile tek bölgeli yazma yapılandırması arasında önemli bir maliyet değişikliği vardır ve bu da çoğu durumda çok ana azure Cosmos DB veri platformlarının maliyetinin engelleyici olmasına neden olabilir.

Tek Bölge okuma/yazma Tek BölgeLi Yazma - İkili Bölge Okuma İkili Bölge Okuma/Yazma
1 RU 2 RU 4 RU

Tek bölgeli yazma ile çok bölgeli yazma arasındaki değişim aslında yukarıdaki tabloya yansıtılan 1:2 oranından daha azdır. Daha açık belirtmek gerekirse, çoklu bölge yazma yapılandırmasında olduğu gibi RU maliyetlerinde yakalanmayan tek yazma yapılandırmasında yazma güncelleştirmeleriyle ilişkili bölgeler arası veri aktarımı ücreti vardır.

  • Tüketilen depolama, belirli bir saat boyunca verileri ve dizinleri barındırmak için kullanılan toplam depolama (GB) miktarı için sabit bir fiyat olarak faturalandırılır.

  • Session , veriler yazma işlemleriyle aynı sırada alındığından varsayılan ve en yaygın kullanılan tutarlılık düzeyidir .

  • Azure Cosmos DB, çakışan özellikler sağlayan Microsoft Entra kimlik veya Azure Cosmos DB anahtarları ve kaynak belirteçleri aracılığıyla kimlik doğrulamayı destekler.

Azure Cosmos DB Erişim Özellikleri

  • Anahtarları ve kaynak belirteçlerini yalnızca veri işlemleriyle sınırlandırmak için anahtarlar veya kaynak belirteçleri kullanarak kaynak yönetimi işlemlerini devre dışı bırakmak mümkündür; böylece rol tabanlı erişim denetimi (RBAC) kullanılarak ayrıntılı kaynak erişim denetimi Microsoft Entra.

    • Anahtarlar veya kaynak belirteçleri aracılığıyla denetim düzlemi erişiminin kısıtlanması, Azure Cosmos DB SDK'larını kullanan istemciler için denetim düzlemi işlemlerini devre dışı bırakır ve bu nedenle kapsamlı bir şekilde değerlendirilip test edilmelidir.
    • Bu disableKeyBasedMetadataWriteAccess ayar ARM Şablonu IaC tanımları veya Yerleşik Azure İlkesi aracılığıyla yapılandırılabilir.

  • Azure Cosmos DB'de Microsoft Entra RBAC desteği hesap ve kaynak denetim düzlemi yönetim işlemleri için geçerlidir.

    • Uygulama yöneticileri, Azure Cosmos DB kaynaklarındaki kaynaklara ve işlemlere erişim vermek veya erişimi reddetmek için kullanıcılara, gruplara, hizmet sorumlularına veya yönetilen kimliklere rol atamaları oluşturabilir.
    • Rol ataması için kullanılabilen birkaç Yerleşik RBAC Rolü vardır ve özel RBAC rolleri belirli ayrıcalık bileşimleri oluşturmak için de kullanılabilir.
      • Cosmos DB Hesap Okuyucusu , Azure Cosmos DB kaynağına salt okunur erişim sağlar.
      • DocumentDB Hesabı Katkıda Bulunanı , anahtarlar ve rol atamaları dahil olmak üzere Azure Cosmos DB hesaplarının yönetilmesini sağlar, ancak veri düzlemi erişimini etkinleştirmez.
      • DocumentDB Hesabı Katkıda Bulunanı'na benzer ancak anahtarları veya rol atamalarını yönetme olanağı sağlamayan Cosmos DB İşleci.

  • Azure Cosmos DB kaynakları (hesaplar, veritabanları ve kapsayıcılar) Kaynak Kilitleri kullanılarak yanlış değişiklik veya silmeye karşı korunabilir.

    • Kaynak Kilitleri hesap, veritabanı veya kapsayıcı düzeyinde ayarlanabilir.
    • Bir kaynakta ayarlanan Kaynak Kilidi tüm alt kaynaklar tarafından devralınır. Örneğin, Azure Cosmos DB hesabındaki bir Kaynak Kilidi kümesi, hesaptaki tüm veritabanları ve kapsayıcılar tarafından devralınır.
    • Kaynak Kilitleri yalnızca denetim düzlemi işlemleri için geçerlidir ve veri oluşturma, değiştirme veya silme gibi veri düzlemi işlemlerini engellemez .
    • Denetim düzlemi erişimi ile disableKeyBasedMetadataWriteAccesskısıtlanmadıysa, istemciler hesap anahtarlarını kullanarak denetim düzlemi işlemleri gerçekleştirebilir.

  • Azure Cosmos DB değişiklik akışı, Bir Azure Cosmos DB kapsayıcısında verilerde yapılan değişikliklerin zaman sıralı akışını sağlar.

    • Değişiklik akışı yalnızca kaynak Azure Cosmos DB kapsayıcısına ekleme ve güncelleştirme işlemlerini içerir; silmeleri içermez.

  • Değişiklik akışı, kaynak Kapsayıcıdan gelen değişiklik akışı tarafından beslenen hedef veri deposunda devam eden güncelleştirmelerle birlikte uygulama tarafından kullanılan birincil Kapsayıcıdan ayrı bir veri deposu tutmak için kullanılabilir.

    • Değişiklik akışı, ek veri platformu yedekliliği veya sonraki analitik senaryolar için ikincil depoyu doldurmak için kullanılabilir.

  • Silme işlemleri kaynak Kapsayıcıdaki verileri düzenli olarak etkilerse, değişiklik akışı tarafından beslenen depo yanlış olur ve silinen veriler için geri başvurulmaz.

    • Veri kayıtlarının değişiklik akışına dahil edilmesi için Geçici Silme düzeni uygulanabilir.
      • Veri kayıtlarını açıkça silmek yerine, öğenin silinmiş olarak kabul edildiğini belirtmek için bir bayrak (örn. IsDeleted) ayarlanarak veri kayıtları güncelleştirilir.
      • Değişiklik akışı tarafından beslenen tüm hedef veri depolarının silinmiş bayrağı True olarak ayarlanmış öğeleri algılaması ve işlemesi gerekir; Geçici olarak silinen veri kayıtlarını depolamak yerine, hedef depodaki veri kaydının mevcut sürümünün silinmesi gerekir.
    • Geçici silme düzeniyle genellikle kısa bir Yaşam Süresi (TTL) kullanılır, böylece Azure Cosmos DB süresi dolan verileri otomatik olarak siler, ancak silinen bayrak True olarak ayarlandığında değişiklik akışına yansıtıldıktan sonra.
      • Özgün silme amacını gerçekleştirirken, silme işlemini de değişiklik akışına yayılır.

  • Azure Cosmos DB, geleneksel ETL işlem hatlarında ortaya çıkan karmaşıklık ve gecikme süresi zorluklarını gidermek için iyileştirilmiş analiz sorguları için bir sütun biçimi uygulayan bir analiz deposu olarak yapılandırılabilir.

  • Azure Cosmos DB, performansı veya kullanılabilirliği etkilemeden ve RU/sn kullanmadan düzenli aralıklarla verileri otomatik olarak yedekler.

  • Azure Cosmos DB iki ayrı yedekleme moduna göre yapılandırılabilir.

    • Periyodik , yedeklemelerin düzenli aralıklarla alındığı ve destek ekibiyle bir istek oluşturularak verilerin geri yüklendiği tüm hesaplar için varsayılan yedekleme modudur.
      • Varsayılan düzenli yedekleme saklama süresi sekiz saattir ve varsayılan yedekleme aralığı dört saattir; bu da varsayılan olarak yalnızca en son iki yedeklemenin depolandığı anlamına gelir.
      • Yedekleme aralığı ve saklama süresi hesap içinde yapılandırılabilir.
        • Maksimum saklama süresi, en az bir saat yedekleme aralığıyla bir aya kadar uzanır.
        • Yedek depolama yedekliliğini yapılandırmak için Azure "Cosmos DB Hesap OkuyucuSu Rolü"ne rol ataması gerekir.
      • İki yedek kopya ek ücret ödemeden dahil edilir, ancak ek yedeklemeler ek maliyete neden olur.
      • Varsayılan olarak, düzenli yedeklemeler doğrudan erişilebilir olmayan ayrı Geo-Redundant Depolama (GRS) içinde depolanır.
        • Yedekleme depolaması birincil 'hub' bölgesinde bulunur ve temel alınan depolama çoğaltması aracılığıyla eşleştirilmiş bölgeye çoğaltılır.
        • Temel alınan yedekleme depolama hesabının yedeklilik yapılandırması Alanlar Arası Yedekli Depolama veya Locally-Redundant Depolama için yapılandırılabilir.
      • Geri yükleme işlemi gerçekleştirmek için Destek İsteği gerekir çünkü müşteriler doğrudan geri yükleme gerçekleştiremez.
        • Destek bileti açmadan önce yedekleme saklama süresi, veri kaybı olayından sonraki sekiz saat içinde en az yedi güne yükseltilmelidir.
      • Geri yükleme işlemi, verilerin kurtarıldığı yeni bir Azure Cosmos DB hesabı oluşturur.
        • Mevcut bir Azure Cosmos DB hesabı Geri Yükleme için kullanılamaz
        • Varsayılan olarak, adlı <Azure_Cosmos_account_original_name>-restored<n> yeni bir Azure Cosmos DB hesabı kullanılır.
          • Bu ad, örneğin özgün hesap silinmişse mevcut adı yeniden kullanarak ayarlanabilir.
      • Aktarım hızı veritabanı düzeyinde sağlanırsa, yedekleme ve geri yükleme veritabanı düzeyinde gerçekleşir
        • Geri yükleneceği kapsayıcıların bir alt kümesini seçmek mümkün değildir.
    • Sürekli yedekleme modu, son 30 gün içinde herhangi bir noktaya geri yükleme yapılmasını sağlar.
      • Geri yükleme işlemleri, bir saniyelik ayrıntı düzeyine sahip belirli bir noktaya (PITR) dönmek için gerçekleştirilebilir.
      • Geri yükleme işlemleri için kullanılabilir pencere 30 güne kadardır.
        • Kaynak örnekleme durumuna geri yüklemek de mümkündür.
      • Sürekli yedeklemeler, Azure Cosmos DB hesabının bulunduğu her Azure bölgesinde alınır.
        • Sürekli yedeklemeler, Kullanılabilirlik Alanları destekleyen bölgelerde Locally-Redundant Depolama (LRS) veya Alanlar Arası Yedekli Depolama (ZRS) kullanılarak her Azure Cosmos DB çoğaltması ile aynı Azure bölgesinde depolanır.
      • ARM şablonları gibi Azure portal veya IaC yapıtları kullanılarak self servis geri yükleme gerçekleştirilebilir.
      • Sürekli Yedekleme ile ilgili çeşitli sınırlamalar vardır.
        • Sürekli yedekleme modu şu anda çok bölgeli yazma yapılandırmasında kullanılamaz.
        • Şu anda yalnızca NoSQL için Azure Cosmos DB ve MongoDB için Azure Cosmos DB Sürekli yedekleme için yapılandırılabilir.
        • Bir kapsayıcıda TTL yapılandırılmışsa, TTL'sini aşan geri yüklenen veriler hemen silinebilir
      • Geri yükleme işlemi, belirli bir noktaya geri yükleme için yeni bir Azure Cosmos DB hesabı oluşturur.
      • Sürekli yedeklemeler ve geri yükleme işlemleri için ek bir depolama maliyeti vardır.

  • Mevcut Azure Cosmos DB hesapları Periyodik'den Sürekli'ye geçirilebilir, ancak Sürekli'den Periyodik'e geçirilmez; geçiş tek yönlüdür ve geri alınamaz.

  • Her Azure Cosmos DB yedeklemesi verilerin kendisinden ve sağlanan aktarım hızı, dizin oluşturma ilkeleri, dağıtım bölgelerinin ve kapsayıcı TTL ayarlarının yapılandırma ayrıntılarından oluşur.

  • Periyodik ve Sürekli yaklaşımların uygun olmadığı senaryolar için özel bir yedekleme ve geri yükleme özelliği uygulamak mümkündür.

    • Özel bir yaklaşım, anlaşılması ve dikkatle değerlendirilmesi gereken önemli maliyetler ve ek yönetim ek yükü getirir.
      • Veri öğesinde bir hesabın, veritabanının, kapsayıcının bozulması veya silinmesi gibi yaygın geri yükleme senaryoları modellenmelidir.
      • Yedeklemenin yayılmasını önlemek için temizlik yordamları uygulanmalıdır.
    • Azure Depolama veya alternatif bir veri teknolojisi(örneğin, alternatif bir Azure Cosmos DB kapsayıcısı) kullanılabilir.
      • Azure Depolama ve Azure Cosmos DB, Azure İşlevleri ve Azure Data Factory gibi Azure hizmetleriyle yerel tümleştirmeler sağlar.

  • Azure Cosmos DB belgelerinde özel yedeklemeler uygulamak için iki olası seçenek gösterilir.

    • Ayrı bir depolama tesisine veri yazmak için Azure Cosmos DB değişiklik akışı.
    • Değişiklik akışı kullanılarak hem sürekli hem de düzenli (toplu) özel yedeklemeler uygulanabilir.
    • Azure Cosmos DB değişiklik akışı henüz silmeleri yansıtmadığından, boole özelliği ve TTL kullanılarak geçici silme düzeni uygulanmalıdır.
      • Değişiklik akışı tam uygunluk güncelleştirmeleri sağladığında bu düzen gerekli olmayacaktır.
    • Verileri kopyalamak için Azure Cosmos DB (NoSQL için Azure Cosmos DB veya MongoDB API bağlayıcıları) bağlayıcısını Azure Data Factory.
      • Azure Data Factory (ADF) el ile yürütmeyi ve Zamanlama, Atlayan pencere ve Olay tabanlı tetikleyicileri destekler.
        • Hem Depolama hem de Event Grid için destek sağlar.
      • ADF, toplu iş odaklı düzenlemesi nedeniyle periyodik özel yedekleme uygulamaları için öncelikli olarak uygundur.
        • Düzenleme yürütme ek yükü nedeniyle sık gerçekleşen olaylarla sürekli yedekleme uygulamaları için daha az uygundur.
      • ADF, yüksek ağ güvenlik senaryoları için Azure Özel Bağlantı destekler

Azure Cosmos DB birçok Azure hizmeti tasarımında kullanıldığından, Azure Cosmos DB için önemli bir bölgesel kesinti söz konusu bölgedeki çeşitli Azure hizmetlerinde basamaklı bir etkiye sahip olacaktır. Belirli bir hizmet üzerindeki kesin etki, temel alınan hizmet tasarımının Azure Cosmos DB'yi nasıl kullandığına bağlıdır.

Tasarım Önerileri

Azure Cosmos DB

  • Gereksinimlerin izin aldığı birincil veri platformu olarak Azure Cosmos DB'yi kullanın.

  • Görev açısından kritik iş yükü senaryoları için gecikme süresini azaltmak ve maksimum yedeklilik sağlamak için Azure Cosmos DB'yi her dağıtım bölgesi içinde bir yazma çoğaltması ile yapılandırın.

    • Uygulama yükünü, performansını ve bölgesel RU/sn tüketimini iyileştirmek amacıyla yazma ve okuma işlemleri için yerel Azure Cosmos DB çoğaltmasının kullanımına öncelik vermek üzere uygulamayı yapılandırın.
    • Çok bölgeli yazma yapılandırması önemli bir maliyetle gelir ve yalnızca en yüksek güvenilirlik gerektiren iş yükü senaryoları için önceliklendirilmelidir.

  • Daha az kritik iş yükü senaryoları için, genel olarak dağıtılmış okuma amaçlı çoğaltmalarla tek bölgeli yazma yapılandırmasının (Kullanılabilirlik Alanları kullanılırken) kullanımına öncelik sağlayın çünkü bu, daha cazip bir fiyat noktasında yüksek düzeyde veri platformu güvenilirliği (%99,999 okuma işlemleri için %99,999 SLA), yazma işlemleri için %99,995 SLA sunar.

    • Uygulamayı, okuma performansını iyileştirmek için yerel Azure Cosmos DB okuma çoğaltmasını kullanacak şekilde yapılandırın.

  • Çok bölgeli yazma yapılandırmasında çakışma çözümünün gerçekleşeceği ve tüm yazmaların tek bölgeli yazma yapılandırmasında gerçekleştirileceği en uygun 'hub' dağıtım bölgesini seçin.

    • Diğer dağıtım bölgelerine göre uzaklığı ve birincil bölgeyi seçerken ilgili gecikme süresini ve Kullanılabilirlik Alanları desteği gibi gerekli özellikleri göz önünde bulundurun.

  • Bir bölge içindeki bölgesel hatalara dayanıklılık sağlamak için Azure Cosmos DB'yi AZ desteğiyle tüm dağıtım bölgelerinde Kullanılabilirlik Alanı (AZ) yedekliliğiyle yapılandırın.

  • Özellikle performans ayarlama konusunda en kapsamlı özellik kümesini sunduğundan NoSQL için Azure Cosmos DB'yi kullanın.

    • Alternatif API'ler öncelikle geçiş veya uyumluluk senaryoları için dikkate alınmalıdır.
      • Alternatif API'leri kullanırken, en iyi yapılandırma ve performansı sağlamak için gerekli özelliklerin seçili dil ve SDK ile kullanılabilir olduğunu doğrulayın.

  • Ağ performansını arka uç Azure Cosmos DB düğümlerine doğrudan TCP bağlantısı aracılığıyla iyileştirmek için Doğrudan bağlantı modunu kullanın ve ağ 'atlama sayısı' azaldı.

Azure Cosmos DB SLA'sı, %99,999 güvenilirlik katmanı hata bütçesiyle doğrudan uyumlu olmayan başarısız isteklerin ortalaması ile hesaplanır. %99,999 SLO için tasarım yaparken bölgesel ve çok bölgeli Azure Cosmos DB yazmanın kullanılamaması için planlama yapmak çok önemlidir. Bu nedenle, sonraki yeniden yürütme için kalıcı ileti kuyruğu gibi bir hata durumunda geri dönüş depolama teknolojisinin konumlandırıldığından emin olun.

  • Veri modeline göre veri dağıtımını iyileştirmek için hem mantıksal hem de fiziksel bölümler arasında bir bölümleme stratejisi tanımlayın.

    • Bölümler arası sorguları en aza indirin.
    • En iyi performansı sağlamak için bölümleme stratejisini yinelemeli olarak test edin ve doğrulayın .

  • En uygun bölüm anahtarını seçin.

    • Bölüm anahtarı koleksiyon içinde oluşturulduktan sonra değiştirilemez.
    • Bölüm anahtarı değişmeyen bir özellik değeri olmalıdır.
    • Çok çeşitli olası değerlere sahip yüksek kardinaliteye sahip bir bölüm anahtarı seçin.
    • Bölüm anahtarı, RU tüketimini ve veri depolamasını tüm mantıksal bölümlere eşit olarak yayarak fiziksel bölümler arasında RU tüketimi ve depolama dağılımının eşit olmasını sağlamalıdır.
    • RU tüketimini ve gecikme süresini azaltmak için bölümlenmiş sütunda okuma sorguları çalıştırın.

  • Dizin oluşturma performans açısından da çok önemlidir, bu nedenle RU/sn ve depolama gereksinimlerini azaltmak için dizin dışlamalarının kullanıldığından emin olun.

    • Yalnızca sorgular içinde filtreleme için gereken alanların dizinini oluşturun; en çok kullanılan koşullar için tasarım dizinleri.

  • Azure Cosmos DB SDK'sının yerleşik hata işleme, yeniden deneme ve daha geniş güvenilirlik özelliklerinden yararlanın.

  • Yönetim karmaşıklığını azaltmak için hizmet tarafından yönetilen şifreleme anahtarlarını kullanın.

    • Müşteri tarafından yönetilen anahtarlar için belirli bir güvenlik gereksinimi varsa yedekleme ve döndürme gibi uygun anahtar yönetimi yordamlarının uygulandığını doğrulayın.

  • Yerleşik Azure İlkesi uygulayarak Azure Cosmos DB anahtar tabanlı meta veri yazma erişimini devre dışı bırakın.

  • Sağlanan aktarım hızı (RU/sn) gibi önemli ölçümleri ve tanılama günlüklerini toplamak için Azure İzleyici'yi etkinleştirin.

    • Azure İzleyici işletimsel verilerini Azure Cosmos DB'ye ve uygulama tasarımındaki diğer genel kaynaklara ayrılmış bir Log Analytics çalışma alanına yönlendirin.
    • Uygulama trafiği desenlerinin otomatik ölçeklendirme için uygun olup olmadığını belirlemek için Azure İzleyici ölçümlerini kullanın.

  • Sağlanan aktarım hızı türleri için en uygun seçeneği seçmek için uygulama trafiği desenlerini değerlendirin.

    • Sağlanan aktarım hızını, iş yükü talebini otomatik olarak dengelemek için otomatik olarak ölçeklendirmeyi göz önünde bulundurun.

  • geliştirilmiş gecikme süresi ve aktarım hızı için istemci tarafı ve sunucu tarafı yapılandırmasını iyileştirmek için Azure Cosmos DB için Microsoft performans ipuçlarını değerlendirin.

  • İşlem platformu olarak AKS kullanırken: Yoğun sorgu kullanan iş yükleri için gecikme süresini ve CPU değişimlerini azaltmak için hızlandırılmış ağ etkinleştirilmiş bir AKS düğümü SKU'su seçin.

  • Tek yazma bölgesi dağıtımları için Azure Cosmos DB'nin otomatik yük devretme için yapılandırılması önemle önerilir.

  • Güncelleştirmeleri Azure Cosmos DB'ye yazan sistem akışları içinde zaman uyumsuz engelleyici olmayan ileti kullanımı aracılığıyla yük düzeyi.

  • Son 30 gün içinde kurtarma noktalarının ayrıntılı bir ayrıntı düzeyini elde etmek için Azure Cosmos DB hesabını sürekli yedeklemeler için yapılandırın.

    • Kapsanan verilerin veya Azure Cosmos DB hesabının silindiği veya bozulduğu senaryolarda Azure Cosmos DB yedeklemelerinin kullanımını göz önünde bulundurun.
    • Kesinlikle gerekli olmadıkça özel bir yedekleme yaklaşımı kullanmaktan kaçının.

  • Standart iş sürekliliği operasyon hazırlığı kapsamında üretim dışı kaynaklar ve veriler üzerinde kurtarma yordamları uygulamanız kesinlikle önerilir.

  • Azure Cosmos DB yedekleme geri yüklemesinin yapılandırma ayarlarını ve özelliklerini yeniden oluşturmak için IaC yapıtlarını tanımlayın.

  • Azure Cosmos DB Yedekleme ve Kurtarma için Azure Güvenlik Temeli denetim kılavuzunu değerlendirin ve uygulayın.

  • Çok bölgeli kullanılabilirlik gerektiren analitik iş yükleri için, iyileştirilmiş analiz sorguları için bir sütun biçimi uygulayan Azure Cosmos DB Analiz Deposu'nı kullanın.

İlişkisel veri teknolojileri

Yüksek düzeyde ilişkisel veri modeline veya mevcut ilişkisel teknolojilere bağımlılıklara sahip senaryolar için Azure Cosmos DB'nin çok bölgeli yazma yapılandırmasında kullanılması doğrudan geçerli olmayabilir. Böyle durumlarda, kullanılan ilişkisel teknolojilerin bir uygulama tasarımının çok bölgeli etkin-etkin hedeflerini destekleyecek şekilde tasarlanması ve yapılandırılması çok önemlidir.

Azure; MySQL, PostgreSQL ve MariaDB gibi yaygın OSS ilişkisel çözümleri için Azure SQL Veritabanı ve Azure Veritabanı gibi birçok yönetilen ilişkisel veri platformu sağlar. Bu bölümdeki tasarım konuları ve önerileri, güvenilirliği ve genel kullanılabilirliği en üst düzeye çıkarmak için Azure SQL Veritabanı ve Azure Veritabanı işletim sistemi türlerinin en uygun kullanımına odaklanacaktır.

Tasarım konusunda dikkat edilmesi gerekenler

  • İlişkisel veri teknolojileri okuma işlemlerini kolayca ölçeklendirecek şekilde yapılandırılsa da, yazma işlemleri genellikle tek bir birincil örnekten geçecek şekilde kısıtlanır ve bu da ölçeklenebilirlik ve performans açısından önemli bir kısıtlama oluşturur.

  • Parçalama , verileri ve işlemeyi birden çok özdeş yapılandırılmış veritabanına dağıtmak ve platform kısıtlamalarına gitmek için veritabanlarını yatay olarak bölümlendirmek için uygulanabilir.

    • Örneğin, parçalama genellikle kiracı gruplarını ayrı veri platformu yapılarına ayırmak için çok kiracılı SaaS platformlarında uygulanır.

Azure SQL Veritabanı

  • Azure SQL Veritabanı, her zaman SQL Server veritabanı altyapısının ve temel işletim sisteminin en son kararlı sürümünde çalışan tam olarak yönetilen bir veritabanı altyapısı sağlar.

    • Performans ayarlama, tehdit izleme ve güvenlik açığı değerlendirmeleri gibi akıllı özellikler sağlar.

  • Azure SQL Veritabanı, okuma amaçlı çoğaltmaları Azure bölgeleri arasında dağıtmak için yerleşik bölgesel yüksek kullanılabilirlik ve anahtar teslimi coğrafi çoğaltma sağlar.

    • Coğrafi çoğaltma ile, yük devretme başlatılana kadar ikincil veritabanı çoğaltmaları salt okunur kalır.
    • Aynı veya farklı bölgelerde en fazla dört ikincil desteklenir.
    • İkincil çoğaltmalar, okuma performansını iyileştirmek için salt okunur sorgu erişimi için de kullanılabilir.
    • Yük devretme el ile başlatılmalıdır ancak otomatik işlem yordamlarında sarmalanabilir.

  • Azure SQL Veritabanı, veritabanlarını ikincil bir sunucuya çoğaltan ve bir hata durumunda saydam yük devretmeye olanak tanıyan Otomatik Yük Devretme Grupları sağlar.

    • Otomatik yük devretme grupları, gruptaki tüm veritabanlarının yalnızca bir ikincil sunucuya veya farklı bir bölgedeki örneğe coğrafi çoğaltmasını destekler.
    • Otomatik yük devretme grupları şu anda Hiper Ölçek hizmet katmanında desteklenmiyor.
    • İkincil veritabanları okuma trafiğini boşaltmak için kullanılabilir.

  • Premium veya İş Açısından Kritik hizmet katmanı veritabanı çoğaltmaları ek ücret ödemeden Kullanılabilirlik Alanları arasında dağıtılabilir.

    • Denetim halkası aynı zamanda birden çok bölgede üç ağ geçidi halkası (GW) olarak çoğaltılır.
      • Belirli bir ağ geçidi kademesine yönlendirme, Azure Traffic Manager tarafından denetlenilir.
    • İş Açısından Kritik katmanı kullanılırken alanlar arası yedekli yapılandırma yalnızca Gen5 işlem donanımı seçildiğinde kullanılabilir.

  • Azure SQL Veritabanı, tüm hizmet katmanları genelinde temel %99,99 kullanılabilirlik SLA'sı sunar, ancak kullanılabilirlik alanlarını destekleyen bölgelerdeki İş Açısından Kritik veya Premium katmanları için %99,995 daha yüksek bir SLA sağlar.

    • Azure SQL Veritabanı İş Açısından Kritik veya Bölgesel Yedekli Dağıtımlar için yapılandırılmamış Premium katmanları %99,99 kullanılabilirlik SLA'sı sunar.

  • Coğrafi çoğaltma ile yapılandırıldığında, Azure SQL Veritabanı İş Açısından Kritik katmanı dağıtılan saatlerin %100'ünün 30 saniyelik bir Kurtarma Süresi Hedefi (RTO) sağlar.

  • Coğrafi çoğaltma ile yapılandırıldığında, Azure SQL Veritabanı İş Açısından Kritik katmanının dağıtılan saatlerin %100'ünün 5 saniyelik bir Kurtarma noktası Hedefi (RPO) vardır.

  • Azure SQL Veritabanı Hiper Ölçek katmanı, en az iki çoğaltmayla yapılandırıldığında %99,99 kullanılabilirlik SLA'sı içerir.

  • Azure SQL Veritabanı ile ilişkili işlem maliyetleri Rezervasyon İndirimi kullanılarak azaltılabilir.

    • DTU tabanlı veritabanları için ayrılmış kapasite uygulamak mümkün değildir.

  • Belirli bir noktaya geri yükleme , veritabanını ve içerdiği verileri zamanın önceki bir noktasına döndürmek için kullanılabilir.

  • Coğrafi geri yükleme , veritabanını coğrafi olarak yedekli bir yedeklemeden kurtarmak için kullanılabilir.

PostgreSQL için Azure Veritabanı

  • PostgreSQL için Azure Veritabanı üç farklı dağıtım seçeneğiyle sunulur:

    • Tek Sunucu, SLA %99,99
    • Kullanılabilirlik Alanı yedekliliği sunan Esnek Sunucu, SLA %99,99
    • Yüksek Kullanılabilirlik modu etkinleştirildiğinde Hiper Ölçek (Citus), SLA %99,95.

  • Hiper Ölçek (Citus), uygulama değişikliği olmadan parçalama aracılığıyla dinamik ölçeklenebilirlik sağlar.

    • Tablo satırlarını birden çok PostgreSQL sunucusuna dağıtmak, Hiper Ölçek'te (Citus) ölçeklenebilir sorgular sağlamak için çok önemlidir.
    • Birden çok düğüm, geleneksel bir veritabanından daha fazla veriyi topluca tutabilir ve çoğu durumda maliyetleri iyileştirmek için çalışan CPU'larını paralel olarak kullanabilir.

  • Otomatik ölçeklendirme , değişen trafik desenlerine yanıt olarak esneklik sağlamak için runbook otomasyonu aracılığıyla yapılandırılabilir.

  • Esnek sunucu, sunucuyu durdurma/başlatma özelliği sayesinde üretim dışı iş yükleri için maliyet verimliliği ve sürekli işlem kapasitesi gerektirmeyen iş yükleri için uygun bir seri işlem katmanı sağlar.

  • Toplam sağlanan sunucu depolama alanının %100'ünün yedek depolaması için ek ücret alınmaz.

    • Yedek depolama alanı ek tüketimi, tüketilen GB/ay'a göre ücretlendirilir.

  • PostgreSQL için Azure Veritabanı ile ilişkili işlem maliyetleri, Tek Sunuculu Rezervasyon İndirimi veya Hiper Ölçek (Citus) Rezervasyon İndirimi kullanılarak azaltılabilir.

Tasarım Önerileri

  • İlişkisel veritabanlarını farklı uygulama ve veri bağlamlarına göre bölümleme, platform kısıtlamalarında gezinmeye, ölçeklenebilirlik ve kullanılabilirliği en üst düzeye çıkarma ve hata yalıtımına yardımcı olma amacıyla parçalama yapmayı göz önünde bulundurun.

    • İlişkisel teknoloji kısıtlamaları küresel olarak dağıtılmış veri platformlarını önemli ölçüde engelleyebileceğinden, bu öneri özellikle uygulama tasarımında üç veya daha fazla Azure bölgesi dikkate alındığında yaygındır.
    • Parçalama tüm uygulama senaryoları için uygun olmadığından bağlamsal değerlendirme gerekir.

  • Azure platformundaki olgunluğu ve çok çeşitli güvenilirlik özellikleri nedeniyle ilişkisel gereksinimlerin bulunduğu Azure SQL Veritabanı'nın kullanımına öncelik verme.

Azure SQL Veritabanı

  • Kritik dayanıklılık özelliklerine erişim de dahil olmak üzere güvenilirlik ve kullanılabilirliği en üst düzeye çıkarmak için Business-Critical hizmet katmanını kullanın.

  • İşlem ve depolama kaynaklarının iş yükü hacmi ve aktarım hızı gereksinimlerine göre bağımsız olarak seçilmesini kolaylaştırmak için sanal çekirdek tabanlı tüketim modelini kullanın.

    • İşlem ve depolama kaynak gereksinimlerini bilgilendirmek için tanımlı kapasite modelinin uygulandığını doğrulayın.

  • Zone-Redundant dağıtım modelini, aynı bölgedeki İş Açısından Kritik veritabanı çoğaltmalarını Kullanılabilirlik Alanları yaymak için yapılandırın.

  • Tüm dağıtım bölgelerinde (en fazla dört) okunabilir çoğaltma dağıtmak için Etkin Coğrafi Çoğaltma kullanın.

  • İkincil bölgeye saydam yük devretme sağlamak için Otomatik Yük Devretme Gruplarını kullanın; okuma iyileştirmesi ve veritabanı yedekliliği için ek dağıtım bölgelerine çoğaltma sağlamak için coğrafi çoğaltma uygulanır.

    • Yalnızca iki dağıtım bölgesiyle sınırlı olan uygulama senaryolarında Otomatik Yük Devretme Gruplarının kullanımına öncelik verilmelidir.

  • Otomatik Yük Devretme Grubu içindeki birincil ve ikincil örnekleri etkileyen bir hata durumunda coğrafi olarak çoğaltılan örneklere yük devretme gerçekleştirmek için uygulama sistem durumu modeline uygun uyarıya dayalı otomatik işlem tetikleyicilerini göz önünde bulundurun.

Önemli

Dörtten fazla dağıtım bölgesi dikkate alan uygulamalarda, Azure Cosmos DB gibi çok bölgeli yazma teknolojilerini desteklemek için uygulama kapsamlı parçalama veya uygulamayı yeniden düzenleme konusunda ciddi dikkate alınması gerekir. Ancak, uygulama iş yükü senaryosunda bu mümkün değilse, tek bir coğrafya içindeki bir bölgeyi coğrafi olarak çoğaltılmış bir örneği daha eşit dağıtılmış okuma erişimine kapsayan birincil bir duruma yükseltmeniz önerilir.

  • Okuma performansını iyileştirmek amacıyla okuma sorguları için çoğaltma örneklerini sorgulamak için uygulamayı yapılandırın.

  • Güvenilirlik olaylarının algılanması için Azure SQL DB'de neredeyse gerçek zamanlı operasyonel içgörüler için Azure İzleyici ve Azure SQL Analytics'i kullanın.

  • Uygun boyutlandırılıp boyutlandırıldıklarını belirlemek üzere tüm veritabanlarının kullanımını değerlendirmek için Azure İzleyici'yi kullanın.

    • CD işlem hatlarının uygun veri platformu davranışını doğrulamak için temsili yük düzeyleri altında yük testi yapmayı göz önünde bulundurdığından emin olun.

  • Veritabanı bileşenlerinin iş gereksinimlerine ve kaynak kullanımına göre sistem durumunu gözlemlemek için bir sistem durumu ölçümü hesaplayın; uygun durumlarda otomatik işlem eylemlerini yönlendirmek için izleme ve uyarılar kullanın.

    • Hizmet düşüşü oluştuğunda hızlı işlem yapılabilmesi için anahtar sorgu performansı ölçümlerinin dahil edildiğinden emin olun.

  • Sorgu Performansı İçgörüleri ve Microsoft tarafından sağlanan yaygın performans önerilerini kullanarak sorguları, tabloları ve veritabanlarını iyileştirin.

  • Azure SQL Veritabanı bağlantısını etkileyen geçici hataları azaltmak için SDK kullanarak yeniden deneme mantığını uygulayın.

  • Bekleyen şifreleme için sunucu tarafı Saydam Veri Şifrelemesi (TDE) uygularken hizmet tarafından yönetilen anahtarların kullanımına öncelik verme.

    • Müşteri tarafından yönetilen anahtarlar veya istemci tarafı (AlwaysEncrypted) şifrelemesi gerekiyorsa, anahtarların yedeklemeler ve otomatik döndürme olanaklarıyla uygun şekilde dayanıklı olduğundan emin olun.

  • Ciddi yapılandırma hatalarından kurtarmak için belirli bir noktaya geri yüklemenin operasyonel bir playbook olarak kullanılmasını göz önünde bulundurun.

PostgreSQL için Azure Veritabanı

  • Esnek Sunucunun Kullanılabilirlik Alanı desteği nedeniyle iş açısından kritik iş yükleri için kullanılması önerilir.

  • İş açısından kritik iş yükleri için Hiper Ölçek (Citus) kullanırken %99,95 SLA garantisi almak için Yüksek Kullanılabilirlik modunu etkinleştirin.

  • Birden çok düğümde kullanılabilirliği en üst düzeye çıkarmak için Hiper Ölçek (Citus) sunucu yapılandırmasını kullanın.

  • Veri platformundaki işlem ve depolama kaynağı gereksinimlerini bilgilendirmek için uygulama için bir kapasite modeli tanımlayın.

Sık Erişimli Katman Verileri için Önbelleğe Alma

Bellek içi önbelleğe alma katmanı, okuma aktarım hızını önemli ölçüde artırarak ve sık erişim katmanı veri senaryoları için uçtan uca istemci yanıt sürelerini iyileştirerek veri platformunu geliştirmek için uygulanabilir.

Azure, anahtar veri yapılarını önbelleğe almak için uygun özelliklere sahip çeşitli hizmetler sunar ve Redis için Azure Cache veri platformu okuma erişimini soyutlayıp iyileştirmek üzere konumlandırılır. Bu nedenle bu bölüm, ek okuma performansının ve veri erişimi dayanıklılığının gerekli olduğu senaryolarda en uygun Redis için Azure Cache kullanımına odaklanacaktır.

Tasarımda Dikkat Edilmesi Gerekenler

  • Önbelleğe alma katmanı ek veri erişimi dayanıklılığı sağlar, çünkü temel alınan veri teknolojilerini etkileyen bir kesinti olsa bile, önbellek katmanı üzerinden uygulama verileri anlık görüntüsüne yine erişilebilir.

  • Bazı iş yükü senaryolarında, bellek içi önbelleğe alma uygulama platformunun kendi içinde uygulanabilir.

Redis için Azure Önbelleği

  • Redis cache, açık kaynak bir NoSQL bellek içi anahtar-değeri depolama sistemidir.

  • Kurumsal ve Kurumsal Flash katmanları, coğrafi çoğaltma aracılığıyla bir bölge içindeki Kullanılabilirlik Alanları ve farklı Azure bölgelerinde etkin-etkin bir yapılandırmada dağıtılabilir.

    • Tüm Önbellek örnekleri için etkin coğrafi çoğaltma etkinleştirilerek her bölgede en az üç Azure bölgesi ve üç veya daha fazla Kullanılabilirlik Alanları dağıtıldığında Redis için Azure Cache, bir bölgesel önbellek uç noktasına bağlantı için %99,999 SLA sağlar.
    • Tek bir Azure bölgesinde üç Kullanılabilirlik Alanları dağıtıldığında %99,99 bağlantı SLA'sı sağlanır.

  • Kurumsal Flash katmanı, RAM ve flash geçici olmayan bellek depolamasının bir bileşiminde çalışır ve bu küçük bir performans cezasına neden olsa da kümeleme ile 13 TB'a kadar çok büyük önbellek boyutları sağlar.

  • Coğrafi çoğaltma ile, önbellek örnekleriyle ilişkili doğrudan maliyetlere ek olarak bölgeler arasında veri aktarımı ücretleri de geçerli olacaktır.

  • Zamanlanmış Güncelleştirmeler özelliği, temel alınan VM işletim sistemine uygulanan Azure güncelleştirmelerini veya güncelleştirmelerini içermez.

  • Veriler yeni örneklere geçirilirken ölçeği genişletme işlemi sırasında CPU kullanımında bir artış olacaktır.

Tasarım Önerileri

  • Okuma aktarım hızını artırmak ve yanıt sürelerini iyileştirmek için 'sık erişimli' veri senaryoları için iyileştirilmiş bir önbelleğe alma katmanını göz önünde bulundurun.

  • Önbellek süre sonu ve temizlik için uygun ilkeleri uygulayarak verilerin kaçmasını önle.

    • Yedekleme verileri değiştiğinde önbellek öğelerinin süresi dolmayı göz önünde bulundurun.

Redis için Azure Önbelleği

  • Güvenilirliği ve performansı en üst düzeye çıkarmak için Premium veya Kurumsal SKU'yu kullanın.

    • Son derece büyük veri hacimlerine sahip senaryolar için Kurumsal Flash katmanı dikkate alınmalıdır.
    • Yalnızca pasif coğrafi çoğaltmanın gerekli olduğu senaryolar için Premium katmanı da göz önünde bulundurulabilir.

  • Değerlendirilen tüm dağıtım bölgelerinde etkin bir yapılandırmada coğrafi çoğaltma kullanarak çoğaltma örneklerini dağıtın.

  • Çoğaltma örneklerinin her bir Azure bölgesi içinde Kullanılabilirlik Alanları dağıtıldığından emin olun.

  • Redis için Azure Cache değerlendirmek için Azure İzleyici'yi kullanın.

    • bölgesel önbellek bileşenlerinin iş gereksinimlerine ve kaynak kullanımına göre sistem durumunu gözlemlemek için sistem durumu puanını hesaplayın.
    • Önbelleğin ölçeklendirilmesi gereken içgörüler için yüksek CPU, yüksek bellek kullanımı, yüksek sunucu yükü ve çıkarılan anahtarlar gibi önemli ölçümleri gözlemleyin ve uyarın.

  • Yeniden deneme mantığı, zaman aşımları uygulayarak ve Redis bağlantı çoklayıcısının tekil bir uygulamasını kullanarak bağlantı dayanıklılığını iyileştirin.

  • Redis Server güncelleştirmelerinin önbelleğe uygulandığı gün ve saatleri önceden belirlemek için zamanlanmış güncelleştirmeleri yapılandırın.

Analitik Senaryolar

Görev açısından kritik uygulamaların analiz senaryolarını kapsamış veri akışlarından ek değer sağlama aracı olarak değerlendirmesi giderek yaygın hale gelir. Bu nedenle uygulama ve işletimsel (AIOps) analiz senaryoları, son derece güvenilir veri platformunun önemli bir yönünü oluşturur.

Analitik ve işlemsel iş yükleri, kendi bağlamları içinde kabul edilebilir performans için farklı veri platformu özellikleri ve iyileştirmeleri gerektirir.

Description Analitik İşlem
Kullanım Örneği Çok büyük hacimli verileri analiz etme ("büyük veri") Çok büyük hacimli bireysel işlemleri işleme
Şunun için iyileştirildi: Birçok kayıt üzerinde sorguları ve toplamaları okuma Birkaç kayıt üzerinde neredeyse gerçek zamanlı Oluşturma/Okuma/Güncelleştirme/Silme (CRUD) sorguları
Temel Özellikler - Kaydın veri kaynaklarından birleştirme
- Sütun tabanlı depolama
- Dağıtılmış depolama
- Paralel işleme
-Normalleştirilmemiş
- Düşük eşzamanlılık okuma ve yazma işlemleri
- Sıkıştırma ile depolama birimi için iyileştirme		 - Uygulama için kayıt veri kaynağı
- Satır Tabanlı Depolama
- Bitişik depolama
- Simetrik işleme
-Normalleştirilmiş
- Yüksek eşzamanlılık okuma ve yazma işlemleri, dizin güncelleştirmeleri
- Bellek içi depolama ile hızlı veri erişimi için iyileştirme

Azure Synapse, büyük veri analizini kolaylaştırmak için Azure Cosmos DB gibi Azure hizmetleriyle yerleşik tümleştirmeyi kullanarak ilişkisel ve ilişkisel olmayan verileri Spark teknolojileriyle bir araya getiren kurumsal bir analiz platformu sağlar. Bu nedenle bu bölümdeki tasarım konuları ve önerileri analiz senaryoları için en uygun Azure Synapse ve Azure Cosmos DB kullanımına odaklanacaktır.

Tasarımda Dikkat Edilmesi Gerekenler

  • Geleneksel olarak, büyük ölçekli analitik senaryolar verileri sonraki analiz sorguları için iyileştirilmiş ayrı bir veri platformuna ayıklayarak kolaylaştırılır.
    • Verileri ayıklamak için kullanılan Ayıklama, Dönüştürme ve Yükleme (ETL) işlem hatları aktarım hızını tüketir ve işlem yükü performansını etkiler.
    • Aktarım hızını ve performans etkilerini azaltmak için ETL işlem hatlarının seyrek çalıştırılması analiz verilerinin daha az güncel olmasıyla sonuçlanır.
    • Veri dönüşümleri daha karmaşık hale geldikçe ETL işlem hattı geliştirme ve bakım ek yükü artar.
      • Örneğin, kaynak veriler sık sık değiştiriliyor veya siliniyorsa ETL işlem hatlarının analitik sorgular için hedef verilerdeki değişiklikleri, ekli/sürümlü bir yaklaşım, döküm ve yeniden yükleme veya analiz verilerindeki yerinde değişiklikleri hesaba katması gerekir. Bu yaklaşımların her biri dizin yeniden oluşturma veya güncelleştirme gibi türev etkilerine sahip olacaktır.

Azure Cosmos DB

  • Azure Cosmos DB işlem verileri üzerinde çalıştırılan analitik sorgular genellikle büyük hacimlerdeki veriler üzerinde bölümler arasında toplanır ve bu da çevresindeki işlem iş yüklerinin performansını etkileyerek önemli bir İstek Birimi (RU) aktarım hızı kullanır.

  • Azure Cosmos DB Analiz Deposu, Azure Cosmos DB işlem iş yüklerini etkilemeden Azure Synapse Azure Cosmos DB verileri üzerinde büyük ölçekli analize olanak tanıyan, şemaya ayrılmış, tamamen yalıtılmış bir sütun odaklı veri deposu sağlar.

    • Bir Azure Cosmos DB Kapsayıcısı Analiz Deposu olarak etkinleştirildiğinde, Kapsayıcıdaki işletimsel verilerden dahili olarak yeni bir sütun deposu oluşturulur. Bu sütun deposu, kapsayıcının satır odaklı işlem deposundan ayrı olarak kalıcıdır.
    • İşletimsel verilerde Oluşturma, Güncelleştirme ve Silme işlemleri analiz deposuyla otomatik olarak eşitlenir, bu nedenle değişiklik akışı veya ETL işlemesi gerekmez.
    • İşlemden analiz deposuna veri eşitleme, Kapsayıcı veya Veritabanında sağlanan aktarım hızı İstek Birimlerini (RU) kullanmaz. İşlem iş yükleri üzerinde performans etkisi yoktur. Analiz Deposu, Azure Cosmos DB Veritabanı veya Kapsayıcısı üzerinde ek RU'ların ayrılmasını gerektirmez.
    • Otomatik Eşitleme, işlemsel veri değişikliklerinin Analiz Deposu'na otomatik olarak eşitlendiği işlemdir. Otomatik Eşitleme gecikme süresi genellikle iki (2) dakikadan kısadır.
      • Paylaşılan aktarım hızına ve çok sayıda Kapsayıcıya sahip bir Veritabanı için Otomatik Eşitleme gecikme süresi beş (5) dakikaya kadar sürebilir.
      • Otomatik Eşitleme tamamlandıktan sonra en son veriler Azure Synapse sorgulanabilir.
    • Analiz Deposu depolama alanı, veri hacmi ve okuma ve yazma işlemlerinin sayısı için ücretlendirilen tüketim tabanlı bir fiyatlandırma modeli kullanır. Analiz deposu fiyatlandırması, işlemsel mağaza fiyatlandırmasından ayrıdır.

  • Azure Synapse Link kullanılarak Azure Cosmos DB Analiz Deposu doğrudan Azure Synapse sorgulanabilir. Bu, Synapse'ten ETL olmayan Karma Transactional-Analytical İşlemesi 'ni (HTAP) etkinleştirir, böylece Azure Cosmos DB verileri Synapse'ten gelen diğer analiz iş yükleriyle birlikte neredeyse gerçek zamanlı olarak sorgulanabilir.

  • Azure Cosmos DB Analiz Deposu varsayılan olarak bölümlenmez.

    • Belirli sorgu senaryolarında, sorgu koşullarında sık kullanılan anahtarları kullanarak Analiz Deposu verilerini bölümleyerek performans artar.
    • Bölümleme, azure Cosmos DB Analiz Deposu'ndan verileri yükleyen ve Synapse çalışma alanının birincil depolama hesabındaki Synapse bölümlenmiş deposuna yazan Synapse Link kullanarak Spark not defteri çalıştıran Azure Synapse bir iş tarafından tetiklenir.

  • Azure Synapse Analytics SQL Sunucusuz havuzları analiz deposunu otomatik olarak güncelleştirilen görünümler veya komutlar aracılığıyla SELECT / OPENROWSET sorgulayabilir.

  • Azure Synapse Analytics Spark havuzları analiz deposunu otomatik olarak güncelleştirilen Spark tabloları veya komutuyla spark.read sorgulayabilir.

  • Sağlanan Azure Synapse SQL havuzu kaynaklarının kullanılabilmesi için veriler Azure Cosmos DB Analiz Deposu'ndan Spark kullanılarak ayrılmış bir Synapse SQL havuzuna da kopyalanabilir.

  • Azure Cosmos DB Analiz Deposu verileri Azure Synapse Spark ile sorgulanabilir.

    • Spark not defterleri , Spark veri çerçevesi birleşimlerinin Azure Cosmos DB analiz verilerini diğer veri kümeleriyle toplamasına ve dönüştürmesine ve dönüştürülmüş verileri diğer depolara yazma veya AIOps Machine Learning modellerini eğitmek gibi diğer gelişmiş Synapse Spark işlevlerini kullanmasına olanak tanır.

Azure Cosmos DB Analiz Sütun Deposu

Azure Synapse

  • Azure Synapse, SQL veri ambarı, Spark büyük verisi ve günlük ve zaman serisi analizi için Veri Gezgini gibi analiz özelliklerini bir araya getirir.

    • Azure Synapse, Azure Depolama gibi diğer hizmetlerle bağlantıları tanımlamak için bağlı hizmetleri kullanır.
    • Veriler desteklenen kaynaklardan Kopyalama etkinliği aracılığıyla Synapse Analytics'e alınabiliyor. Bu, Synapse'te kaynak veri depoyu etkilemeden veri analizine izin verir, ancak veri aktarımı nedeniyle zaman, maliyet ve gecikme süresi ek yükü ekler.
    • Veriler ayrıca desteklenen dış depolarda yerinde sorgulanabilir ve veri alımı ve hareket yükünden kaçınılabilir. Data Lake 2. Nesil ile Azure Depolama Synapse için desteklenen bir depodur ve Log Analytics'ten dışarı aktarılan veriler Synapse Spark aracılığıyla sorgulanabilir.

  • Azure Synapse Studio alma ve sorgulama görevlerini birleştirir.

    • Azure Cosmos DB Analiz Deposu verileri ve Log Analytics Dışarı Aktarma verileri de dahil olmak üzere kaynak veriler, iş zekası ve diğer toplu analitik kullanım örneklerini desteklemek için sorgulanır ve işlenir.

Azure Synapse Analytics

Tasarım Önerileri

  • İşlem performansını korumak için analitik iş yüklerinin işlem uygulaması iş yüklerini etkilemediğinden emin olun.

Application Analytics

AIOps ve operasyonel analiz

  • Kaynaklardan işletimsel verilerin gönderildiği her kaynak Azure Depolama hesabı için bağlı hizmetler ve veri kümeleri içeren tek bir Azure Synapse çalışma alanı oluşturun.

  • Synapse çalışma alanı kataloğu verilerini ve meta verilerini depolamak için ayrılmış bir Azure Depolama hesabı oluşturun ve bunu çalışma alanı birincil depolama hesabı olarak kullanın. Azure Data Lake 2. Nesil'i etkinleştirmek için hiyerarşik ad alanıyla yapılandırın.

    • Kaynak analiz verileri ile Synapse çalışma alanı verileri ve meta verileri arasında ayrım yapın.
      • İşletimsel verilerin gönderildiği bölgesel veya genel Azure Depolama hesaplarından birini kullanmayın.

Sonraki adım

Ağ ile ilgili dikkat edilmesi gereken noktaları gözden geçirin.

Ağ ve bağlantı