Performans ayarlama senaryosu: birden çok arka uç hizmeti

Bu makalede, bir geliştirme ekibinin, performans sorunlarını bulmak ve dağıtılmış bir sistemin performansını geliştirmek için ölçümleri nasıl kullandığı açıklanır. Makale, örnek bir uygulama için gerçekleşen gerçek yük testini temel alır. uygulama, mikro hizmetler için Azure kubernetes hizmeti (aks) taban çizgisindenve sonuçları oluşturmak için kullanılan bir Visual Studio yük testi projesiyle birlikte bulunur.

Bu makale, bir serinin bir parçasıdır. Buradailk parçayı okuyun.

Senaryo: bilgileri almak ve ardından sonuçları toplamak için birden fazla arka uç hizmeti çağırın.

Bu senaryo, bir drone teslim uygulaması içerir. İstemciler, en son fatura bilgilerini almak için bir REST API sorgulayabilir. Fatura, müşterinin teslimleri, paketleri ve toplam drone kullanımının özetini içerir. Bu uygulama, AKS üzerinde çalışan bir mikro hizmet mimarisini kullanır ve fatura için gereken bilgiler birkaç mikro hizmet arasında yayılır.

Her hizmeti doğrudan çağıran istemci yerine, uygulama ağ geçidi toplama modelini uygular. Bu model kullanıldığında, istemci, bir ağ geçidi hizmetine tek bir istek yapar. İçindeki ağ geçidi, arka uç hizmetlerini paralel olarak çağırır ve sonuçları tek bir yanıt yükünde toplar.

Test 1: temel performans

Bir taban çizgisi oluşturmak için, geliştirme ekibi, bir grup yük testi ile başlatılır ve toplam 8 dakikalık bir süre boyunca, tek bir sanal kullanıcıdan 40 kullanıcıya kadar yük devri yapılır. Visual Studio alınan aşağıdaki grafik, sonuçları gösterir. Mor çizgi Kullanıcı yükünü gösterir ve turuncu çizgi aktarım hızını gösterir (saniye başına ortalama istek).

Grafiğin alt kısmındaki kırmızı çizgi, istemciye hiçbir hata döndürülmeyeceğini gösterir, bu teşvik. Ancak, ortalama aktarım hızı, test aracılığıyla yarım yönlü olarak artar ve sonra da yük artmaya devam ederken bile kalanı için devre dışı bırakılır. Bu, arka ucun devam edemediğini belirtir. Burada görülen kalıp, bir sistem kaynak sınırlarına ulaşıldıktan sonra, en fazla bir işlem performansı önemli ölçüde önemli ölçüde önemli olduğunda yaygın bir şeydir. Kaynak çakışması, geçici hatalar veya özel durum oranının bir artışı bu düzene katkıda bulunabilir.

Sistemin içinde neler olduğunu öğrenmek için izleme verilerine bakalım. sonraki grafik Application Insights alınmıştır. Ağ geçidinden arka uç hizmetlerine yapılan HTTP çağrılarının ortalama sürelerini gösterir.

Bu grafik, belirli bir işlemin bir ölçüde daha GetDroneUtilization uzun sürme olduğunu gösterir. Ağ Geçidi bu çağrıları paralel hale getirir, bu nedenle en yavaş işlem, isteğin tamamının tamamlanabilmesi için ne kadar sürdüğünü belirler.

Bir sonraki adım, işleme açık olup GetDroneUtilization herhangi bir performans sorunu olup olmadığına bakar. Kaynak tükenmesi bir olasılık. Bu özel arka uç hizmeti, CPU veya bellek dışında çalışıyor olabilir. AKS kümesi için bu bilgiler, kapsayıcılar Için Azure izleyici özelliği aracılığıyla Azure Portal sunulmaktadır. Aşağıdaki grafiklerde, küme düzeyinde kaynak kullanımı gösterilmektedir:

Bu ekran görüntüsünde, hem ortalama hem de en büyük değerler gösterilir. Ortalama, verilerdeki ani artışları gizleyebileceğinden, yalnızca ortalamaya daha fazla bakmak önemlidir. Burada, ortalama CPU kullanımı %50 oranında kalır, ancak %80 ' e kadar birkaç ani artış vardır. Bu, kapasiteye yakın ancak toleranslar dahilinde olmaya devam etmektedir. Başka bir şey soruna neden oluyor.

Sonraki grafik, doğru külün olduğunu gösterir. bu grafik, teslim hizmetinin arka uç veritabanındaki HTTP yanıt kodlarını gösterir, bu durumda Cosmos DB. Mavi çizgi başarı kodlarını (HTTP 2xx) temsil ederken yeşil çizgi ise HTTP 429 hatalarını temsil eder. bir HTTP 429 dönüş kodu, çağıranın, sağlanandan daha fazla kaynak birimi (RU) tükettiği için istekleri geçici olarak azaltma Cosmos DB anlamına gelir.

daha ayrıntılı bilgi almak için, geliştirme ekibi, bir istek örneği için uçtan uca telemetriyi görüntülemek üzere Application Insights kullandı. İşte bir örnek:

Bu görünüm, tek bir istemci isteğiyle ilgili, zamanlama bilgileri ve yanıt kodlarıyla birlikte yapılan çağrıları gösterir. Üst düzey çağrılar, ağ geçidinden arka uç hizmetlerine kadar yapılır. çağrısı, GetDroneUtilization dış bağımlılıklara yapılan çağrıları göstermek için genişletilir — bu durumda Cosmos DB. Red dosyasındaki çağrı bir HTTP 429 hatası döndürdü.

HTTP 429 hatası ve sonraki çağrı arasındaki büyük boşluğu aklınızda edin. Cosmos DB istemci kitaplığı bir HTTP 429 hatası aldığında, otomatik olarak kapanır ve işlemi yeniden denemeyi bekler. bu görünümün gösterdiği, bu işlemin büyük bir süre 672 içinde Cosmos DB yeniden deneme için harcanmayı beklerken bu işlemin ne kadar sürdüğünü gösterir.

Bu analize yönelik başka bir ilgi çekici grafik aşağıda verilmiştir. Fiziksel bölüm başına RU tüketimini, fiziksel bölüm başına sağlanan RUs 'yi gösterir:

bu grafiği anlamlı hale getirmek için Cosmos DB bölümleri nasıl yönettiğini anlamanız gerekir. Cosmos DB içindeki koleksiyonlar bir bölüm anahtarınasahip olabilir. Olası her anahtar değeri, koleksiyondaki verilerin mantıksal bir bölümünü tanımlar. Cosmos DB, bu mantıksal bölümleri bir veya daha fazla fiziksel bölüm arasında dağıtır. fiziksel bölümlerin yönetimi, Cosmos DB tarafından otomatik olarak işlenir. daha fazla veri depoladığınızda Cosmos DB, fiziksel bölümlerin yükünü yaymak için mantıksal bölümleri yeni fiziksel bölümlere taşıyabilir.

bu yük testi için Cosmos DB koleksiyonu 900 ru ile sağlandı. Grafik, Toplam dokuz fiziksel bölümden oluşan fiziksel bölüm başına 100 RU 'yi gösterir. Cosmos DB, fiziksel bölümlerin parçalarını otomatik olarak işleymekle birlikte, bölüm sayısının performansa ilişkin öngörüler verebilmesine de olanak sağlar. Geliştirme ekibi bu bilgileri daha sonra iyileştirmeye devam ederken kullanacaktır. Mavi çizgi mor yatay çizgiyi kesiştiği yerde RU tüketimi, sağlanan RU 'yı aşmış. Cosmos DB, çağrıların kısıtlanmayacak başlangıç noktasıdır.

Test 2: kaynak birimlerini artırma

ikinci yük testi için, takım Cosmos DB koleksiyonunu 900 ru 'dan 2500 ru 'a ölçeklendirin. İşlem hızı 19 istekten/saniye ile 23 istek/saniye artar ve 669 MS 'den 569 MS 'e bırakılan ortalama gecikme süresi.

Bunlar çok büyük kazanç değildir ancak grafiğe zaman içinde bakmak daha kapsamlı bir resim gösterir:

Önceki testte bir başlangıç ani ve sonra keskin bir bırakma gösterilirken, bu test daha tutarlı işleme gösterir. Ancak, en yüksek aktarım hızı önemli ölçüde daha yüksektir.

Cosmos DB tüm istekleri 2xx durumu döndürdü ve HTTP 429 hataları dışarıda oldu:

RU tüketimi ve sağlanan RUs grafiğinde çok sayıda yer vardır. Fiziksel bölüm başına 275 ru ve saniye başına yaklaşık 100 ru ile kullanılan yük testi vardır.

diğer bir ilginç ölçüm, başarılı işlem başına Cosmos DB çağrısı sayısıdır:

Hata olmadığını varsayarak, çağrı sayısı gerçek sorgu planıyla eşleşmeli. Bu durumda işlem, dokuz fiziksel bölüme de isabet alan bölümler arası bir sorgu içerir. İlk yük testinde daha yüksek değer, 429 hatası döndürülen çağrı sayısını gösterir.

Bu ölçüm, özel bir Log Analytics sorgusu çalıştırarak hesaplandı:

let start=datetime("2020-06-18T20:59:00.000Z");
let end=datetime("2020-07-24T21:10:00.000Z");
let operationNameToEval="GET DroneDeliveries/GetDroneUtilization";
let dependencyType="Azure DocumentDB";
let dataset=requests
| where timestamp > start and timestamp < end
| where success == true
| where name == operationNameToEval;
dataset
| project reqOk=itemCount
| summarize
    SuccessRequests=sum(reqOk),
    TotalNumberOfDepCalls=(toscalar(dependencies
    | where timestamp > start and timestamp < end
    | where type == dependencyType
    | summarize sum(itemCount)))
| project
    OperationName=operationNameToEval,
    DependencyName=dependencyType,
    SuccessRequests,
    AverageNumberOfDepCallsPerOperation=(TotalNumberOfDepCalls/SuccessRequests)

Özetlemek gerekirse, ikinci yük testi geliştirme gösteriyor. Ancak, GetDroneUtilization işlem yine de bir sonraki en yavaş işlemden daha uzun bir büyüklük sırası alır. 1.00.000 işlemlere bakarak şu işlemlerin nedenlerini açıklamaya yardımcı olur:

Daha önce belirtildiği gibi, GetDroneUtilization işlemi veritabanına çapraz bölümleme sorgusu Cosmos içerir. Bu, Cosmos DB istemcisinin sorguyu her fiziksel bölüme toplaması ve sonuçları toplaması anlamına gelir. Bitişli işlem görünümünde de olduğu gibi, bu sorgular seri olarak gerçekleştiriliyor. İşlem tüm sorguların toplamı kadar sürer ve verilerin boyutu arttıkça ve daha fazla fiziksel bölüm eklendikçe bu sorun daha da kötüye gider.

Test 3: Paralel sorgular

Önceki sonuçlara göre gecikme süresini azaltmanın belirgin bir yolu sorguları paralel olarak yapmaktır. Veritabanı Cosmos SDK'sı, en yüksek paralellik derecesini kontrol eden bir ayara sahiptir.

Üçüncü yük testi için bu ayar 0'dan -1'e değiştirildi. Aşağıdaki tabloda sonuçlar özetlenmiştir:

Yük testi grafı yalnızca genel aktarım hızının çok daha yüksek (turuncu çizgi) yanı sıra aktarım hızı da yüke (mor çizgi) ayak uydurarak devam ediyor.

Cosmos DB istemcisinin paralel olarak sorgular yaparken uzlamlı işlem görünümüne bakarak doğrulayabilirsiniz:

İlginç olan, aktarım hızını artırmanın yan etkisi, saniye başına tüketilen RU sayısının da artmasıdır. Bu Cosmos DB hiçbir isteği kısıtlamamış olsa da, tüketim sağlanan RU sınırına yakındı:

Bu grafik, veritabanının ölçeğini daha da fazla ölçeklendirmeye işaret olabilir. Ancak bunun yerine sorguyu iyileştirebilirsiniz.

4. Adım: Sorguyu iyileştirme

Önceki yük testi gecikme süresi ve aktarım hızı açısından daha iyi performans gösterdi. Ortalama istek gecikme süresi %68 azaltıldı ve aktarım hızı %220 arttı. Ancak bölümler arası sorgu önemli bir konudur.

Bölümler arası sorgularla ilgili sorun, her bölüm için RU için ödemesi yapılan bir sorundur. Sorgu yalnızca belirli aralıklarla (örneğin, saatte bir) çalıştırabiliyorsa önemli değildir. Ancak bölümler arası sorgu içeren yoğun okuma içeren bir iş yükü gördüğünüzde, bölüm anahtarı dahil olmak üzere sorgunun iyileştirilmiş olup olmadığını görmelisiniz. (Koleksiyonu farklı bir bölüm anahtarı kullanmak üzere yeniden tasarlamaniz gerekir.)

Bu senaryonun sorgusu şöyledir:

SELECT * FROM c
WHERE c.ownerId = <ownerIdValue> and
      c.year = <yearValue> and
      c.month = <monthValue>

Bu sorgu, belirli bir sahip kimliği ve ay/yıl ile eşanlı kayıtları seçer. Özgün tasarımda, bu özelliklerin hiçbiri bölüm anahtarıdır. Bunun için istemcinin sorguyu her fiziksel bölüme toplaması ve sonuçları toplaması gerekir. Sorgu performansını artırmak için geliştirme ekibi tasarımını, sahip kimliğinin koleksiyon için bölüm anahtarı olacak şekilde değiştirmiştir. Bu şekilde sorgu belirli bir fiziksel bölümü hedefleyebilirsiniz. (Cosmos DB bunu otomatik olarak ele alır; bölüm anahtarı değerleri ile fiziksel bölümler arasındaki eşlemeyi yönetmenize gerek yok.)

Koleksiyonu yeni bölüm anahtarına değiştirdikten sonra RU tüketiminde önemli bir artış oldu ve bu da doğrudan daha düşük maliyetlere neden oldu.

Bitişli işlem görünümü, tahmin edilen şekilde sorgunun yalnızca bir fiziksel bölümü okuduğuyu gösterir:

Yük testi, geliştirilmiş aktarım hızını ve gecikme süresini gösterir:

Gelişmiş performansın bir sonucu, düğüm CPU kullanımının çok yüksek hale geldiği bir sonucudur:

Yük testinin sonuna doğru, %90 ile ortalama CPU 'ya ulaşıldı ve en fazla CPU %100 ' dir. Bu ölçüm, CPU 'nun sistemde bir sonraki performans sorunu olduğunu gösterir. Daha yüksek aktarım hızı gerekiyorsa, bir sonraki adım teslimat hizmetini daha fazla örneğe ölçeklendirebilirsiniz.

Özet

Bu senaryo için aşağıdaki performans sorunları tanımlanmıştır:

• yetersiz ru tarafından sağlanan azaltma isteklerini Cosmos DB.
• Seri olarak birden çok veritabanı bölümünün sorgulanmasından kaynaklanan yüksek gecikme süresi.
• Sorgu Bölüm anahtarını içermediği için verimsiz çapraz bölüm sorgusu.

Ayrıca CPU kullanımı, daha yüksek ölçekte olası bir performans sorunu olarak tanımlanmıştır. Bu sorunları tanılamak için, geliştirme ekibi şu adreste bakıyordu:

• Yük testinin gecikme süresi ve aktarım hızı.
• hataları ve RU tüketimini Cosmos DB.
• Uygulama öngörüleri içindeki uçtan uca işlem görünümü.
• Kapsayıcılar için Azure Izleyici 'de CPU ve bellek kullanımı.

Sonraki adımlar

Performans önleme düzenlerini gözden geçirme