Görev açısından kritik iş yükleri için uygulama platformunda dikkat edilmesi gerekenler

Görev açısından kritik mimarilerin önemli tasarım alanlarından biri uygulama platformudur. Platform, uygulamayı desteklemek için sağlanması gereken altyapı bileşenlerini ve Azure hizmetlerini ifade eder. Aşağıda bazı fazla arama önerileri bulabilirsiniz.

• Katmanlar halinde tasarla. Doğru hizmet kümesini, bunların yapılandırmasını ve uygulamaya özgü bağımlılıkları seçin. Bu katmanlı yaklaşım, mantıksal ve fiziksel segmentasyon oluşturmaya yardımcı olur. Rolleri ve işlevleri tanımlama, uygun ayrıcalıkları ve dağıtım stratejilerini atamada yararlıdır. Bu yaklaşım nihai olarak sistemin güvenilirliğini artırır.

• Görev açısından kritik bir uygulama, veri merkezi ve bölgesel hatalara karşı son derece güvenilir ve dayanıklı olmalıdır. Etkin-etkin bir yapılandırmada bölgesel ve bölgesel yedeklilik oluşturmak ana stratejidir. Uygulamanızın platformu için Azure hizmetlerini seçerken, birden çok Azure bölgesi kullanmak için Kullanılabilirlik Alanları destek ve dağıtım ve işlem desenlerini göz önünde bulundurun.

• Artan yükü işlemek için ölçek birimleri tabanlı bir mimari kullanın. Ölçek birimleri kaynakları mantıksal olarak gruplandırmanıza olanak tanır ve bir birim mimarideki diğer birim veya hizmetlerden bağımsız olarak ölçeklendirilebilir. Her birimin sınırlarını, sayısını ve temel ölçeğini tanımlamak için kapasite modelinizi ve beklenen performansı kullanın.

Bu mimaride uygulama platformu genel, dağıtım damgası ve bölgesel kaynaklardan oluşur. Bölgesel kaynaklar bir dağıtım damgasının parçası olarak sağlanır. Her damga pulu bir ölçek birimine eşit olur ve iyi durumda değilse tamamen değiştirilebilir.

Her katmandaki kaynakların farklı özellikleri vardır. Daha fazla bilgi için bkz . Tipik bir görev açısından kritik iş yükünün mimari düzeni.

Özellikler	Dikkat edilmesi gerekenler
Yaşam süresi	Çözümdeki diğer kaynaklara göre kaynağın beklenen ömrü nedir? Kaynak, sistemin veya bölgenin tamamıyla yaşam süresinden daha uzun mu yaşamalı yoksa yaşam süresiyle mi paylaşılmalıdır?
State	Bu katmandaki kalıcı durumun güvenilirlik veya yönetilebilirlik üzerindeki etkisi nedir?
Reach	Kaynağın genel olarak dağıtılması gerekiyor mu? Kaynak, genel olarak veya bölgelerdeki diğer kaynaklarla iletişim kurabilir mi?
Bağımlılıklar	Genel olarak veya diğer bölgelerdeki diğer kaynaklara bağımlılık nedir?
Ölçek sınırları	Bu katmandaki kaynak için beklenen aktarım hızı nedir? Kaynak tarafından bu talebe uygun ne kadar ölçek sağlanır?
Kullanılabilirlik/olağanüstü durum kurtarma	Bu katmandaki kullanılabilirlik veya olağanüstü durum üzerindeki etkisi nedir? Sistemsel bir kesintiye veya yalnızca yerelleştirilmiş kapasite veya kullanılabilirlik sorununa neden olur mu?

Genel kaynaklar

Bu mimarideki bazı kaynaklar, bölgelere dağıtılan kaynaklar tarafından paylaşılır. Bu mimaride, trafiği birden çok bölgeye dağıtmak, uygulamanın tamamı için kalıcı durumu depolamak ve genel statik verileri önbelleğe almak için kullanılır.

Özellikler	KatmanLa İlgili Dikkat Edilmesi Gerekenler
Yaşam süresi	Bu kaynakların uzun ömürlü olması beklenmektedir. Yaşam süreleri sistemin ömrüne veya daha uzun bir süreye kadar sürer. Kaynaklar genellikle sıfır kapalı kalma süresi güncelleştirme işlemlerini desteklediği varsayılarak yerinde veri ve denetim düzlemi güncelleştirmeleriyle yönetilir.
State	Bu kaynaklar en azından sistemin ömrü boyunca mevcut olduğundan, bu katman genellikle genel, coğrafi olarak çoğaltılmış durumu depolamakla sorumludur.
Reach	Kaynaklar genel olarak dağıtılmalıdır. Bu kaynakların düşük gecikme süresi ve istenen tutarlılık ile bölgesel veya diğer kaynaklarla iletişim kurması önerilir.
Bağımlılıklar	Kullanılabilir olmamaları genel hatanın nedeni olabileceğinden kaynakların bölgesel kaynaklara bağımlılıktan kaçınması gerekir. Örneğin, tek bir kasada tutulan sertifikalar veya gizli diziler, kasanın bulunduğu yerde bölgesel bir hata olması durumunda genel olarak etkilenebilir.
Ölçek sınırları	Bu kaynaklar genellikle sistemdeki tekil örneklerdir ve bu nedenle sistemin bir bütün olarak aktarım hızını işleyebilmeleri için ölçeklendirilebilmeleri gerekir.
Kullanılabilirlik/olağanüstü durum kurtarma	Bölgesel kaynaklar ve damga kaynakları genel kaynakları tüketebileceğinden veya bunlar tarafından önlerine konabildiğinden, genel kaynakların tüm sistemin durumu için yüksek kullanılabilirlik ve olağanüstü durum kurtarma ile yapılandırılması kritik önem taşır.

Bu mimaride genel katman kaynakları, diğer genel katman kaynaklarından günlükleri ve ölçümleri depolamak için Azure Front Door, Azure Cosmos DB, Azure Container Registry ve Azure Log Analytics'tir.

Bu tasarımda Microsoft Entra Id ve Azure DNS gibi başka temel kaynaklar da vardır. Bu görüntüde kısa olduğu için atlanmışlardır.

Genel yük dengeleyici

Azure Front Door, kullanıcı trafiği için tek giriş noktası olarak kullanılır. Azure, Azure Front Door'un istenen içeriği %99,99 hatası olmadan sunacağını garanti eder. Diğer ayrıntılar için bkz . Front Door hizmet sınırları. Front Door kullanılamaz duruma gelirse, son kullanıcı sistemi devre dışı olarak görür.

Front Door örneği, API'yi barındıran işlem kümesi ve ön uç SPA'sı gibi yapılandırılmış arka uç hizmetlerine trafik gönderir. Front Door'daki arka uç yanlış yapılandırmaları kesintilere neden olabilir. Yanlış yapılandırmalardan kaynaklanan kesintileri önlemek için Front Door ayarlarınızı kapsamlı bir şekilde test etmelisiniz.

Yanlış yapılandırılmış veya eksik TLS sertifikalarından başka bir yaygın hata gelebilir ve bu da kullanıcıların ön ucu veya Front Door'un arka uçla iletişim kurmasını engelleyebilir. Azaltma el ile müdahale gerektirebilir. Örneğin, mümkünse önceki yapılandırmaya geri dönüp sertifikayı yeniden vermeyi seçebilirsiniz. Ne olursa olsun, değişiklikler etkili olurken kullanılamamasını bekleyin. Front door tarafından sunulan yönetilen sertifikaların kullanılması, süre sonunu işleme gibi operasyonel ek yükü azaltmak için önerilir.

Front Door, genel trafik yönlendirmenin yanı sıra birçok ek özellik sunar. Front Door geçen trafiği inceleyebildiğinden önemli bir özellik Web Uygulaması Güvenlik Duvarı (WAF) özelliğidir. Önleme modunda yapılandırıldığında, arka uçlardan herhangi birine ulaşmadan önce şüpheli trafiği engeller.

Front Door özellikleri hakkında bilgi için bkz . Azure Front Door için sık sorulan sorular.

Trafiğin genel dağıtımı hakkında dikkat edilmesi gereken diğer noktalar için bkz . İyi tasarlanmış Çerçeve: Genel yönlendirme bölümünde Misson açısından kritik yönergeler.

Container Registry

Azure Container Registry, Open Container Initiative (OCI) yapıtlarını, özellikle helm grafiklerini ve kapsayıcı görüntülerini depolamak için kullanılır. İstek akışına katılmaz ve yalnızca düzenli aralıklarla erişilir. Damga kaynakları dağıtılmadan önce kapsayıcı kayıt defterinin mevcut olması gerekir ve bölgesel katman kaynaklarına bağımlılığı olmamalıdır.

Görüntülere çalışma zamanı erişiminin hızlı ve hatalara dayanıklı olması için kayıt defterlerinin bölge yedekliliğini ve coğrafi çoğaltmasını etkinleştirin. Kullanım dışı olması durumunda örnek çoğaltma bölgelerine yük devredebilir ve istekler otomatik olarak başka bir bölgeye yeniden yönlendirilir. Yük devretme tamamlanana kadar görüntüleri çekerken geçici hatalar olmasını bekleyin.

Görüntüler yanlışlıkla silinirse de hatalar oluşabilir, yeni işlem düğümleri görüntüleri çekemez, ancak mevcut düğümler önbelleğe alınmış görüntüleri kullanmaya devam edebilir. Olağanüstü durum kurtarma için birincil strateji yeniden dağıtımdır. Kapsayıcı kayıt defterindeki yapıtlar işlem hatlarından yeniden oluşturulabilir. Kapsayıcı kayıt defteri, tüm dağıtımlarınızı desteklemek için birçok eşzamanlı bağlantıya dayanabilmelidir.

Coğrafi çoğaltmayı etkinleştirmek için Premium SKU'yu kullanmanız önerilir. Alanlar arası yedeklilik özelliği, belirli bir bölgede dayanıklılık ve yüksek kullanılabilirlik sağlar. Bölgesel bir kesinti durumunda, diğer bölgelerdeki çoğaltmalar veri düzlemi işlemleri için hala kullanılabilir. Bu SKU ile özel uç noktalar üzerinden görüntülere erişimi kısıtlayabilirsiniz.

Daha fazla ayrıntı için bkz . Azure Container Registry için en iyi yöntemler.

Veritabanı

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ğ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.

Daha fazla bilgi için bkz . Görev açısından kritik iş yükleri için veri platformu.

Genel izleme

Azure Log Analytics, tüm genel kaynaklardan tanılama günlüklerini depolamak için kullanılır. Depolamada günlük kotayı özellikle yük testi için kullanılan ortamlarda kısıtlamanız önerilir. Ayrıca bekletme ilkesini ayarlayın. Bu kısıtlamalar, bir sınırın ötesinde gerekli olmayan verileri depolayarak tahakkuk eden herhangi bir fazla masrafı önler.

Temel hizmetler için dikkat edilmesi gerekenler

Sistemin, azure DNS ve Microsoft Entra id gibi tüm sistemin risk altında olmasını sağlayan diğer kritik platform hizmetlerini kullanma olasılığı yüksektir. Azure DNS, geçerli DNS istekleri için %100 kullanılabilirlik SLA'sını garanti eder. Microsoft Entra en az %99,99 çalışma süresi garanti eder. Yine de, bir hata durumunda etkinin farkında olmanız gerekir.

Birçok Azure hizmeti bunlara bağlı olduğundan temel hizmetlere sıkı bağımlılık almak kaçınılmazdır. Kullanılamıyorlarsa sistemde kesinti olmasını bekleyebilirsiniz. Örneğin:

• Azure Front Door, arka uç ve diğer küresel hizmetlere ulaşmak için Azure DNS kullanır.
• Azure Container Registry, istekleri başka bir bölgeye devretmek için Azure DNS kullanır.

Her iki durumda da, Azure DNS kullanılamıyorsa her iki Azure hizmeti de etkilenir. Front Door'dan gelen kullanıcı istekleri için ad çözümlemesi başarısız olur; Docker görüntüleri kayıt defterinden çekilmez. Birçok Azure hizmeti bu tür bir yapılandırmaya izin vermediğinden ve iç DNS'ye bağlı olduğundan, yedekleme olarak bir dış DNS hizmeti kullanılması riski azaltmaz. Tam kesinti bekleniyor.

Benzer şekilde, Microsoft Entra Id yeni AKS düğümleri oluşturma, Container Registry'den görüntü çekme veya pod başlatma sırasında Key Vault'a erişme gibi denetim düzlemi işlemleri için kullanılır. Microsoft Entra Kimliği kullanılamıyorsa, mevcut bileşenler etkilenmemelidir, ancak genel performans düşebilir. Yeni podlar veya AKS düğümleri işlevsel olmayacaktır. Bu nedenle bu süre boyunca ölçeği genişletme işlemlerinin gerekli olması durumunda kullanıcı deneyiminin azalması beklenir.

Bölgesel dağıtım damgası kaynakları

Bu mimaride dağıtım damgası iş yükünü dağıtır ve iş işlemlerini tamamlamaya katılan kaynaklar sağlar. Damga pulu genellikle bir Azure bölgesine yapılan dağıtıma karşılık gelir. Her ne kadar bir bölgede birden fazla damga pulu olabilir.

Özellikler	Dikkat edilmesi gerekenler
Yaşam süresi	Kaynakların, damga damgası dışındaki bölgesel kaynaklar kalıcı olarak devam ederken dinamik olarak eklenip kaldırılma amacıyla kısa bir yaşam süresine (kısa ömürlü) sahip olması beklenir. Kısa ömürlü doğa, kullanıcılara daha fazla dayanıklılık, ölçek ve yakınlık sağlamak için gereklidir.
State	Damga pulları kısa ömürlü olduğundan ve herhangi bir zamanda yok edilebildiğinden, bir damga pulu mümkün olduğunca durum bilgisi olmadan olmalıdır.
Reach	Bölgesel ve küresel kaynaklarla iletişim kurabilir. Ancak, diğer bölgeler veya diğer damga pulları ile iletişimden kaçınılmalıdır. Bu mimaride, bu kaynakların genel olarak dağıtılması gerekmez.
Bağımlılıklar	Damga pulu kaynakları bağımsız olmalıdır. Başka bir deyişle, diğer bölgelerdeki diğer damga damgalarına veya bileşenlere güvenmemeleri gerekir. Bölgesel ve küresel bağımlılıkları olması beklenir. Ana paylaşılan bileşen, veritabanı katmanı ve kapsayıcı kayıt defteridir. Bu bileşen çalışma zamanında eşitleme gerektirir.
Ölçek sınırları	Aktarım hızı test yoluyla oluşturulur. Genel damganın aktarım hızı en düşük performanslı kaynakla sınırlıdır. Damga pulu aktarım hızının tahmini yüksek talep düzeyini ve bölgedeki başka bir damga damgasının kullanılamaz duruma gelmesi nedeniyle herhangi bir yük devretmeyi dikkate alması gerekir.
Kullanılabilirlik/olağanüstü durum kurtarma	Damga pullarının geçici yapısı nedeniyle, damga pulunun yeniden dağıtılmasıyla olağanüstü durum kurtarma gerçekleştirilir. Kaynaklar iyi durumda değilse, damga tüm olarak yok edilebilir ve yeniden dağıtılabilir.

Bu mimaride damga kaynakları Azure Kubernetes Service, Azure Event Hubs, Azure Key Vault ve Azure Blob Depolama'dır.

Ölçek birimi

Damga pulu ölçek birimi (SU) olarak da değerlendirilebilir. Belirli bir damga içindeki tüm bileşenler ve hizmetler, belirli bir aralıktaki isteklere hizmet vermek için yapılandırılır ve test edilir. Aşağıda uygulamada kullanılan bir ölçek birimi örneği verilmiştır.

Her ölçek birimi bir Azure bölgesine dağıtılır ve bu nedenle öncelikli olarak söz konusu alandan gelen trafiği işler (ancak gerektiğinde diğer bölgelerden gelen trafiği devralabilir). Bu coğrafi yayılma büyük olasılıkla bölgeden bölgeye farklılık gösterebilecek yük desenlerine ve iş saatlerine neden olur ve bu nedenle her SU boşta kaldığında ölçeği daraltacak/azaltacak şekilde tasarlanmıştır.

Ölçeklendirmek için yeni bir damga pulu dağıtabilirsiniz. Bir damganın içinde tek tek kaynaklar da ölçek birimleri olabilir.

Bir ünitede Azure hizmetlerini seçerken ölçeklendirme ve kullanılabilirlik konusunda dikkat edilmesi gereken bazı noktalar şunlardır:

• Ölçek birimindeki tüm kaynaklar arasındaki kapasite ilişkilerini değerlendirin. Örneğin, Azure Cosmos DB'de 100 gelen isteği işlemek için 5 giriş denetleyicisi podu ve 3 katalog hizmeti podu ve 1000 RU gerekir. Bu nedenle giriş podlarını otomatik olarak ölçeklendirdiğinizde, bu aralıklar göz önüne alındığında katalog hizmetinin ve Azure Cosmos DB RU'larının ölçeklendirilmesini bekleyebilirsiniz.

• İsteklerin sunılacağı aralığı belirlemek için hizmetleri yük testi yapın. Sonuçlara göre en düşük ve en yüksek örnekleri ve hedef ölçümleri yapılandırın. Hedefe ulaşıldığında tüm ünitenin ölçeklendirmesini otomatikleştirmeyi seçebilirsiniz.

• İş gereksinimlerine göre ayarlanan kapasite ve maliyet modelini desteklemek için Azure aboneliği ölçek sınırlarını ve kotalarını gözden geçirin. Ayrıca, göz önünde bulundurulan tek tek hizmetlerin sınırlarını da denetleyin. Birimler genellikle birlikte dağıtıldığından, kanarya dağıtımları için gereken abonelik kaynak sınırlarını dikkate alır. Daha fazla bilgi için bkz . Azure hizmet sınırları.

• Yedeklilik oluşturmak için kullanılabilirlik alanlarını destekleyen hizmetleri seçin. Bu, teknoloji seçeneklerinizi sınırlayabilir. Ayrıntılar için bkz. Kullanılabilirlik Alanları.

Bir birimin boyutu ve kaynakların birleşimi hakkında dikkat edilmesi gereken diğer noktalar için bkz . İyi tasarlanmış Çerçeve: Ölçek birimi mimarisinde Misson açısından kritik yönergeler.

İşlem kümesi

İş yükünü kapsayıcıya almak için her damganın bir işlem kümesi çalıştırması gerekir. Kubernetes modern, kapsayıcılı uygulamalar için en popüler işlem platformu olduğundan bu mimaride Azure Kubernetes Service (AKS) seçilir.

AKS kümesinin ömrü, damganın kısa ömürlü doğasına bağlıdır. Küme durum bilgisi yok ve kalıcı birimlere sahip değil. Uygulama veya sistem düzeyinde bakım almaları beklenmiyorsa yönetilen diskler yerine kısa ömürlü işletim sistemi diskleri kullanır.

Güvenilirliği artırmak için küme, belirli bir bölgedeki üç kullanılabilirlik alanında da kullanılacak şekilde yapılandırılır. Bu, kümenin AKS denetim düzleminin %99,95 SLA kullanılabilirliğini garanti eden AKS Çalışma Süresi SLA'sını kullanmasını mümkün kılar.

Ölçek sınırları, işlem kapasitesi, abonelik kotası gibi diğer faktörler de güvenilirliği etkileyebilir. Yeterli kapasite yoksa veya sınırlara ulaşılırsa ölçeği genişletme ve ölçeği artırma işlemleri başarısız olur ancak mevcut işlemin çalışması beklenir.

Kümede, gerekirse düğüm havuzlarının ölçeğinin otomatik olarak genişletilmesi için otomatik ölçeklendirme etkinleştirilmiştir ve bu da güvenilirliği artırır. Birden çok düğüm havuzu kullanılırken tüm düğüm havuzları otomatik olarak ölçeklendirilmelidir.

Pod düzeyinde Yatay Pod Otomatik Ölçeklendiricisi (HPA), podları yapılandırılmış CPU, bellek veya özel ölçümlere göre ölçeklendirir. Yük testi, otomatik ölçeklendirici ve HPA değerleri için bir temel oluşturmak üzere iş yükünün bileşenlerini test eder.

Küme ayrıca otomatik düğüm görüntüsü yükseltmeleri ve bu yükseltmeler sırasında uygun şekilde ölçeklendirilecek şekilde yapılandırılır. Bu ölçeklendirme, yükseltmeler yapılırken kapalı kalma süresinin sıfır olmasına olanak tanır. Yükseltme sırasında bir damgadaki küme başarısız olursa, diğer damga damgalarındaki diğer kümeler etkilenmemelidir, ancak kullanılabilirliği korumak için farklı zamanlarda damga pulları arasında yükseltmeler yapılmalıdır. Ayrıca, küme yükseltmeleri aynı anda kullanılamamaları için düğümler arasında otomatik olarak yuvarlanır.

cert-manager ve ingress-nginx gibi bazı bileşenler, dış kapsayıcı kayıt defterlerinden kapsayıcı görüntüleri gerektirir. Bu depolar veya görüntüler kullanılamıyorsa, yeni düğümlerdeki yeni örnekler (görüntünün önbelleğe alınmadığı) başlatılamayabilir. Bu görüntüler ortamın Azure Container Registry'sine aktarılarak bu risk azaltılabilir.

Damgalar kısa ömürlü olduğundan gözlemlenebilirlik bu mimaride kritik öneme sahiptir. Tanılama ayarları, tüm günlük ve ölçüm verilerini bölgesel bir Log Analytics çalışma alanında depoacak şekilde yapılandırılır. Ayrıca AKS Container Analizler, küme içi OMS Aracısı aracılığıyla etkinleştirilir. Bu aracı, kümenin izleme verilerini Log Analytics çalışma alanına göndermesine olanak tanır.

İşlem kümesi hakkında dikkat edilmesi gereken diğer noktalar için bkz . İyi tasarlanmış Çerçeve: Container Orchestration ve Kubernetes'te Misson açısından kritik yönergeler.

Anahtar Kasası

Azure Key Vault, veritabanında bağlantı dizesi gibi genel gizli dizileri depolamak ve Event Hubs bağlantı dizesi gibi gizli dizileri damgalama amacıyla kullanılır.

Bu mimari, Key Vault'tan gizli dizileri almak için işlem kümesindeki Gizli Dizi Deposu CSI sürücüsünü kullanır. Yeni podlar oluşturulduğunda gizli diziler gereklidir. Key Vault kullanılamıyorsa yeni podlar başlatılmayabilir. Sonuç olarak, kesinti olabilir; ölçeği genişletme işlemleri etkilenebilir, güncelleştirmeler başarısız olabilir, yeni dağıtımlar yürütülemez.

Key Vault'un işlem sayısı sınırı vardır. Gizli dizilerin otomatik olarak güncelleştirilmesi nedeniyle, çok sayıda pod varsa sınıra ulaşılabilir. Bu durumdan kaçınmak için güncelleştirmelerin sıklığını azaltmayı seçebilirsiniz.

Gizli dizi yönetimiyle ilgili diğer önemli noktalar için bkz . İyi tasarlanmış Çerçeve: Veri bütünlüğü koruması bölümünde Misson açısından kritik yönergeler.

Event Hubs

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

Bu mimaride Standart SKU kullanılır ve yüksek kullanılabilirlik için alanlar arası yedeklilik etkinleştirilir.

Event Hubs sistem durumu, işlem kümesinde çalışan HealthService bileşeni tarafından doğrulanır. Çeşitli kaynaklarda düzenli aralıklarla denetimler gerçekleştirir. Bu, iyi durumda olmayan koşulları algılamada yararlıdır. Örneğin, olay hub'ına ileti gönderilemiyorsa, damga herhangi bir yazma işlemi için kullanılamaz. HealthService bu durumu otomatik olarak algılamalı ve iyi durumda olmayan durumu Front Door'a bildirmelidir ve bu durum damgayı döndürmeden çıkarır.

Ölçeklenebilirlik için otomatik şişirme özelliğinin etkinleştirilmesi önerilir.

Daha fazla bilgi için bkz . Görev açısından kritik iş yükleri için mesajlaşma hizmetleri.

Mesajlaşmayla ilgili diğer önemli noktalar için bkz . İyi tasarlanmış Çerçeve: Zaman uyumsuz mesajlaşmada Misson kritik kılavuzu.

Depolama hesapları

Bu mimaride iki depolama hesabı sağlanır. Her iki hesap da alanlar arası yedekli modda (ZRS) dağıtılır.

Event Hubs denetim noktası oluşturma için bir hesap kullanılır. Bu hesap yanıt vermiyorsa damga damgası Event Hubs'dan gelen iletileri işleyemez ve damga kutusundaki diğer hizmetleri bile etkileyebilir. Bu koşul, işlem kümesinde çalışan uygulama bileşenlerinden biri olan HealthService tarafından düzenli aralıklarla denetlenmektedir.

Diğeri, ui tek sayfalı uygulamayı barındırmak için kullanılır. Statik web sitesinin sunulmasında herhangi bir sorun varsa, Front Door sorunu algılar ve bu depolama hesabına trafik göndermez. Bu süre boyunca Front Door önbelleğe alınmış içeriği kullanabilir.

Kurtarma hakkında daha fazla bilgi için bkz . Olağanüstü durum kurtarma ve depolama hesabı yük devretme.

Bölgesel kaynaklar

Bir sistemde bölgeye dağıtılan ancak damga kaynaklarının uzun süre devam eden kaynakları olabilir. Bu mimaride, damga kaynakları için gözlemlenebilirlik verileri bölgesel veri depolarında depolanır.

Özellikler	Dikkat edilmesi gereken noktalar
Yaşam süresi	Kaynaklar bölgenin ömrünü paylaşır ve damga kaynaklarını canlı olarak kullanır.
State	Bir bölgede depolanan durum, bölgenin kullanım ömründen uzun süre yaşayamaz. Eyaletlerin bölgeler arasında paylaşılması gerekiyorsa genel veri deposu kullanmayı göz önünde bulundurun.
Reach	Kaynakların genel olarak dağıtılması gerekmez. Diğer bölgelerle doğrudan iletişimden ne pahasına olursa olsun kaçınılmalıdır.
Bağımlılıklar	Kaynakların genel kaynaklara bağımlılıkları olabilir, ancak damga pullarının kısa süreli olması amaçlandığından damga kaynaklarına bağımlılıkları yoktur.
Ölçek sınırları	Bölge içindeki tüm damgaları birleştirerek bölgesel kaynakların ölçek sınırını belirleyin.

Damga kaynakları için izleme verileri

İzleme kaynaklarını dağıtmak, bölgesel kaynaklar için tipik bir örnektir. Bu mimaride, her bölgenin damga kaynaklarından yayılan tüm günlük ve ölçüm verilerini depolamak için yapılandırılmış tek bir Log Analytics çalışma alanı vardır. Bölgesel kaynaklar damgalama kaynaklarının daha uzun olduğu için, damga silindiğinde bile veriler kullanılabilir.

Azure Log Analytics ve Azure Uygulaması Analizler platformdaki günlükleri ve ölçümleri depolamak için kullanılır. Depolamada günlük kotayı özellikle yük testi için kullanılan ortamlarda kısıtlamanız önerilir. Ayrıca, tüm verileri depolamak için bekletme ilkesini ayarlayın. Bu kısıtlamalar, bir sınırın ötesinde gerekli olmayan verileri depolayarak tahakkuk eden herhangi bir fazla masrafı önler.

Benzer şekilde, Application Analizler tüm uygulama izleme verilerini toplamak için bölgesel bir kaynak olarak da dağıtılır.

İzleme hakkında tasarım önerileri için bkz . İyi tasarlanmış Çerçeve: Sistem durumu modellemesi bölümünde Misson açısından kritik yönergeler.

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: Görev Açısından Kritik Çevrimiçi