Aracılığıyla paylaş

Azure Cosmos DB SDK'ları ile dayanıklı uygulamalar tasarlama

  • Makale

UYGULANANLAR: NoSQL

Sdk'lardan herhangi biri aracılığıyla Azure Cosmos DB ile etkileşim kuran istemci uygulamaları yazarken, birkaç temel temel bilgiyi anlamak önemlidir. Bu makale, bu temelleri anlamanıza ve dayanıklı uygulamalar tasarlamanıza yardımcı olacak bir tasarım kılavuzudur.

Genel bakış

Bu makalede ele alınan kavramlara genel bakış videosu için bkz:

Bağlantı modları

Azure Cosmos DB SDK'ları hizmete iki bağlantı modunda bağlanabilir. .NET ve Java SDK'ları hizmete hem Ağ Geçidi hem de Doğrudan modunda bağlanabilirken, diğerleri yalnızca Ağ Geçidi modunda bağlanabilir. Ağ geçidi modu HTTP protokollerini, Doğrudan modu ise genellikle TCP protokollerini kullanır.

Ağ geçidi modu her zaman hangi mod SDK'sının kullanmak üzere yapılandırıldığına bakılmaksızın hesap, kapsayıcı ve yönlendirme bilgileri gibi meta verileri getirmek için kullanılır. Bu bilgiler bellekte önbelleğe alınır ve hizmet çoğaltmalarına bağlanmak için kullanılır.

Özetle, Ağ Geçidi modundaki SDK'lar için HTTP trafiği beklenirken, Doğrudan modda SDK'lar için farklı koşullar altında (başlatma, meta verileri getirme veya yönlendirme bilgileri gibi) HTTP ve TCP trafiğinin bir bileşimini bekleyebilirsiniz.

İstemci örnekleri ve bağlantılar

Bağlantı modundan bağımsız olarak, uygulama başına hesap başına SDK istemcisinin Singleton örneğini korumak kritik önem taşır. Hem HTTP hem de TCP bağlantılarının kapsamı istemci örneği olarak belirlenmiştir. Çoğu işlem ortamı, aynı anda açık olabilecek bağlantı sayısı açısından sınırlamalara sahiptir ve bu sınırlara ulaşıldığında bağlantı etkilenir.

Dağıtılmış uygulamalar ve ağlar

Dağıtılmış uygulamalar tasarlarken üç temel bileşen vardır:

  • Uygulamanız ve üzerinde çalıştığı ortam.
  • Uygulamanızla Azure Cosmos DB hizmet uç noktası arasındaki tüm bileşenleri içeren ağ.
  • Azure Cosmos DB hizmet uç noktası.

Hatalar oluştuğunda genellikle bu üç alandan birine girerler ve sistemin dağıtılmış yapısı nedeniyle bu bileşenlerden herhangi biri için %100 kullanılabilirlik beklemenin pratik olmadığını anlamak önemlidir.

Azure Cosmos DB kapsamlı bir kullanılabilirlik SLA'larına sahiptir ancak bunların hiçbiri %100 değildir. Uygulamanızı hizmet uç noktasına bağlayan ağ bileşenlerinde geçici donanım sorunları olabilir ve paketleri kaybedebilirsiniz. Uygulamanızın çalıştığı işlem ortamında bile işlemleri etkileyen bir CPU ani artışı olabilir. Bu hata koşulları SDK'ların işlemlerini etkileyebilir ve normalde belirli kodlarla ilgili hatalar olarak ortaya çıkar.

Uygulamanız, SDK'lar tarafından sağlanan yanıtlar üzerinde yeniden deneme ilkeleri uygulayarak bu bileşenler arasında belirli bir düzeyde olası hataya dayanıklı olmalıdır.

Uygulamam hatalarda yeniden denemeli mi?

Kısa cevap evet. Ancak tüm hataların yeniden denenmesi mantıklı değildir, bazı hata veya durum kodları geçici değildir. Aşağıdaki tabloda bunlar ayrıntılı olarak açıklanmıştır:

Durum Kodu Yeniden deneme eklenmeli SDK'lar yeniden denendi Açıklama
400 Hayır Hayır Hatalı istek
Kategori 401 Hayır Hayır Yetkilendirilmedi
403 İsteğe bağlı Hayır Yasak
404 Hayır Hayır Kaynak bulunamadı
408 Yes Yes İstek zaman aşımına uğradı
409 Hayır Hayır Çakışma hatası, yazma işlemindeki bir kaynak için sağlanan kimlik (kimlik ve bölüm anahtarı) mevcut bir kaynak tarafından alındığında veya benzersiz bir anahtar kısıtlamasının ihlal edildiğinde ortaya çıkar.
410 Yes Yes Giden özel durumlar (SLA'yı ihlal etmemesi gereken geçici hata)
412 Hayır Hayır Önkoşul hatası, işlemin sunucudaki sürümden farklı bir eTag belirttiği yerdir. İyimser bir eşzamanlılık hatasıdır. Kaynağın en son sürümünü okuyup istekteki eTag’i güncelleştirdikten sonra isteği yeniden deneyin.
413 Hayır Hayır İstek Varlığı Çok Büyük
Kategori 429 Yes Yes 429'da yeniden denemek güvenlidir. HTTP 429 sorunlarını gidermek için kılavuzu gözden geçirin.
449 Yes Yes Yalnızca yazma işlemlerinde oluşan ve yeniden denemenin güvenli olduğu geçici hata. Bu, çok fazla eşzamanlı işlemin Azure Cosmos DB'de aynı nesneyi güncelleştirmeye çalıştığı bir tasarım sorununa işaret edebilir.
500 Hayır Hayır İşlem beklenmeyen bir hizmet hatası nedeniyle başarısız oldu. Azure desteği sorunu bildirerek desteğe başvurun.
503 Yes Yes Hizmet kullanılamıyor

Yukarıdaki tabloda, ikinci sütunda Evet olarak işaretlenmiş tüm durum kodlarının uygulamanızda bir derece yeniden deneme kapsamı olmalıdır.

HTTP 403

Azure Cosmos DB SDK'ları genel olarak HTTP 403 hatalarında yeniden denemez, ancak http 403 ile ilişkili, uygulamanızın tepki verme kararı verebileceği bazı hatalar vardır. Örneğin, Bölüm Anahtarı'nın dolu olduğunu belirten bir hata alırsanız, yazmaya çalıştığınız belgenin bölüm anahtarını bazı iş kuralına göre değiştirmeye karar vekleyebilirsiniz.

HTTP 429

Azure Cosmos DB SDK'ları, istemci yapılandırmasından sonra varsayılan olarak HTTP 429 hatalarını yeniden dener ve belirtilen süreyi bekleyip sonra yeniden deneyerek hizmetin yanıt x-ms-retry-after-ms üst bilgisini uygular.

SDK yeniden denemeleri aşıldığında, hata uygulamanıza döndürülür. İdeal olarak yanıttaki x-ms-retry-after-ms üst bilgiyi incelemek, isteği yeniden denemeden önce ne kadar bekleyeceğinize karar vermek için ipucu olarak kullanılabilir. Diğer bir alternatif de üstel geri alma algoritması veya istemciyi HTTP 429'da yeniden denemeleri genişletecek şekilde yapılandırmak olabilir.

HTTP 449

Azure Cosmos DB SDK'ları, çoğu senaryoyu karşılamak için sabit bir süre boyunca artımlı geri alma ile HTTP 449'da yeniden dener.

Otomatik SDK yeniden deneme sayısı aşıldığında, uygulamanıza bu hata döndürülür. HTTP 449 hataları güvenli bir şekilde yeniden denenebilir. Yazma işlemlerinin yoğun eş zamanlılık yapısı nedeniyle, belirli bir aralıktan sonra aynı eş zamanlılık derecesinin tekrar edilmesini önlemek açısından bir rastgele geri çekme algoritması kullanmanız önerilir.

Ağ zaman aşımları ve bağlantı hataları en yaygın hatalar arasındadır. Azure Cosmos DB SDK'ları kendileri dayanıklıdır ve yeniden deneme mümkünse HTTP ve TCP protokolleri genelinde zaman aşımlarını ve bağlantı sorunlarını yeniden dener:

  • Okuma işlemleri için SDK'lar zaman aşımı veya bağlantıyla ilgili tüm hataları yeniden dener.
  • Yazma işlemleri için SDK'lar yeniden denemez çünkü bu işlemler bir kez etkili değildir. Yanıt beklenirken zaman aşımı oluştuğunda, isteğin hizmete ulaşıp ulaşmadığını bilmek mümkün değildir.

Hesapta birden çok bölge varsa SDK'lar bölgeler arası yeniden deneme de dener.

Zaman aşımlarının ve bağlantı hatalarının doğası gereği, bunlar yalnızca hizmet tarafında oluşan hataları kapsadığından hesap ölçümlerinizde görünmeyebilir.

Uygulamaların bu senaryolar için kendi yeniden deneme ilkelerine sahip olması ve yazma zaman aşımlarının nasıl çözüleceğini dikkate alması önerilir. Örneğin, oluşturma zaman aşımında yeniden deneme, önceki istek hizmete ulaştıysa HTTP 409 (Çakışma) verebilir, ancak ulaşmadıysa başarılı olur.

Dile özgü uygulama ayrıntıları

Bir dille ilgili daha fazla uygulama ayrıntısı için bkz:

Yeniden denemeler gecikme süremi etkiler mi?

İstemci perspektifinden bakıldığında, tüm yeniden denemeler işlemin uçtan uca gecikme süresini etkiler. Uygulamanızın P99 gecikme süresi etkilendiğinde, gerçekleşen yeniden denemeleri ve bunların nasıl ele alındığını anlamak önemlidir.

Azure Cosmos DB SDK'ları günlüklerinde ve tanılamalarında hangi yeniden denemelerin gerçekleştirildiğini belirlemeye yardımcı olabilecek ayrıntılı bilgiler sağlar. Daha fazla bilgi için bkz . .NET SDK tanılamalarını toplama ve Java SDK tanılamalarını toplama.

Yeniden deneme gecikme süresini nasıl azaltabilirim?

Koşullara bağlı olarak, çoğu durumda SDK istekleri yerel bölgeye, yazma bölgesine (tek bölgeli yazma senaryosunda) veya tercih edilen bölgeler listesindeki ilk bölgeye yönlendirir. Bu öncelik belirleme, öncelikle en yakın veya en uygun veri merkezine bağlanarak iyi durumdaki senaryolarda gecikme süresini en aza indirir.

Ancak bu öncelik belirleme, hataya neden olacak isteklerin belirli bir hata senaryosu için her zaman belirli bir bölgede deneneceği anlamına da gelir. Bu senaryoda başka bir bölgeye yük devretme tercih edilirse, bu genellikle SDK düzeyinde değil altyapı (traffic manager) katmanında işlenir. Altyapınızın düzgün şekilde ayarlanması ve yapılandırılması, bölgesel kesintiler sırasında trafiğin verimli bir şekilde yeniden yönlendirilmesini sağlayabilir ve bu sayede kesinti senaryosunda bölgeler arası yeniden denemelerle birlikte gelebilen gecikme süresini azaltabilirsiniz. Altyapı düzeyinde yük devretmeyi ayarlama hakkında daha ayrıntılı bilgi için Azure Traffic Manager belgelerine göz atın. Bazı SDK'lar, benzer yük devretme stratejilerinin doğrudan SDK düzeyinde uygulanmasını destekler. Örneğin bkz . Java SDK'sı için yüksek kullanılabilirlik.

Bölgesel kesintiler ne olacak?

Azure Cosmos DB SDK'ları bölgesel kullanılabilirliği kapsar ve başka hesap bölgelerinde yeniden denemeler gerçekleştirebilir. Hangi senaryoların diğer bölgeleri içerdiğini anlamak için çok bölgeli ortamlar yeniden deneme senaryoları ve yapılandırmalar makalesine bakın.

Müşteri desteğine ne zaman başvurabilirsiniz?

Müşteri desteğine başvurmadan önce şu adımları izleyin:

  • Başarılı olan işlemlerle karşılaştırıldığında etkilenen işlemlerin hacmi cinsinden ölçülen etki nedir? Hizmet SLA'ları içinde mi?
  • P99 gecikme süresi etkilendi mi?
  • Hatalar, uygulamamın yeniden denemesi gereken hata kodlarıyla ilgili mi ve uygulama bu tür yeniden denemeleri kapsıyor mu?
  • Hatalar tüm uygulama örneklerinizi mi yoksa bunların yalnızca bir alt kümesini mi etkiliyor? Sorun örneklerin bir alt kümesine indiriliyorsa, genellikle söz konusu örneklerle ilgili bir sorun söz konusudur.
  • Uygulama ortamındaki bir sorunu elememek için yukarıdaki tabloda yer alan ilgili sorun giderme belgelerini gözden geçirdiniz mi?

Tüm uygulama örnekleri etkileniyorsa veya etkilenen işlemlerin yüzdesi hizmet SLA'larının dışındaysa veya kendi uygulama SLA'larınızı ve P99'larınızı etkiliyorsa müşteri desteğine başvurun.

Sonraki adımlar