Performans ayarlama senaryosu: dağıtılmış iş işlemleri

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 yaptığımız gerçek yük testini temel alır. Uygulama, mikro hizmetler Için Azure Kubernetes hizmeti (AKS) temelidir.

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

Senaryo: bir istemci uygulaması, birden çok adımdan oluşan bir iş işlemini başlatır.

Bu senaryo, AKS üzerinde çalışan bir drone gönderim uygulaması içerir. Müşteriler, kurutma teslimleri zamanlamak için bir Web uygulaması kullanır. Her işlem arka uçta ayrı mikro hizmetler tarafından gerçekleştirilen birden çok adım gerektirir:

• Teslimat hizmeti teslimleri yönetir.
• Drone Zamanlayıcı hizmeti, toplama için dronlarla 'yi zamanlar.
• Paket hizmeti paketleri yönetir.

İki farklı hizmet vardır: istemci isteklerini kabul eden ve bunları işlenmek üzere bir sıraya yerleştiren ve iş akışındaki adımları koordine eden bir Iş akışı hizmeti olan bir alma hizmeti.

Bu senaryo hakkında daha fazla bilgi için bkz. mikro hizmet mimarisi tasarlama.

Test 1: taban çizgisi

İlk yük testi için, takım altı düğümlü bir AKS kümesi oluşturup her mikro hizmetin üç çoğaltmasını dağıttı. Yük testi, iki sanal kullanıcının başlangıcında ve 40 benzetimi yapılan kullanıcılara kadar bir adım yük testi oldu.

Aşağıdaki grafikte, Visual Studio gösterildiği gibi, yük testinin sonuçları gösterilmektedir. Mor çizgi, Kullanıcı yükünü çizer ve turuncu çizgi toplam istekleri çizer.

Bu senaryoyu fark eden ilk şey, saniye başına istemci isteklerinin yararlı bir performans ölçümü olmaması olabilir. Bunun nedeni, uygulamanın zaman uyumsuz olarak istekleri işletiğinden, istemcinin hemen bir yanıt aldığından emin olur. Yanıt kodu her zaman HTTP 202 ' dir (kabul edilir), yani isteğin kabul edildiği ancak işlemenin tamamlanmamış olduğu anlamına gelir.

Gerçekten de arka ucun istek hızına sahip olup olmadığı hakkında bilgi sahibi olmak istiyoruz. Service Bus kuyruğu artışlarını devralarak, ancak arka uç sürekli yükü işleyemediğinde, işleme daha fazla ve daha sonra geri düşecek.

İşte daha bilgilendirici bir grafik. Service Bus sırasındaki gelen ve giden ileti sayısını çizer. Gelen iletiler açık mavi ve giden iletiler koyu mavi renkle gösterilir:

Bu grafik, gelen ileti hızının arttığı, en üst düzeye ulaşmasını ve sonra yük testinin sonunda sıfır olarak yeniden bırakılmasını gösterir. Ancak, giden ileti sayısı testte daha erken bir süre önce ve sonra bırakır. Bu, istekleri işleyen Iş akışı hizmeti 'nin güncel tutulmadığını gösterir. Yük testi sona erdikten sonra bile (grafikte 9:22 etrafında), Iş akışı hizmeti sırayı boşaltmaya devam ettiğinden iletiler hala işlenir.

İşlemin yavaşlatılıyor? Aranacak ilk şey hatalar veya özel bir sorunu gösterebilen özel durumlardır. Azure Izleyici 'de uygulama Haritası , bileşenler arasındaki çağrıların grafiğini gösterir ve daha fazla ayrıntı almak için, sorunları belirlemek için hızlı bir yoldur.

Yeterli olmadığından, uygulama haritasında Iş akışı hizmetinin teslim hizmetinden hata aldığı gösterilmektedir:

Daha fazla ayrıntı görmek için, grafikte bir düğüm seçebilir ve uçtan uca bir işlem görünümüne tıklayabilirsiniz. Bu durumda, teslim hizmetinin HTTP 500 hatalarını döndürdüğünü gösterir. Hata iletileri, Redsıs için Azure önbelleğindeki bellek sınırları nedeniyle bir özel durumun bulunduğunu gösterir.

Redsıs 'e yapılan çağrıların uygulama haritasında görünmediğine dikkat edebilirsiniz. bunun nedeni, Application Insights için .net kitaplığı 'nın reddir 'i bağımlılık olarak izleme için yerleşik desteği yoktur. (Kutudan hangilerinin desteklendiklerin bir listesi için bkz. bağımlılık otomatik koleksiyonu.) Geri dönüş olarak, herhangi bir bağımlılığı izlemek için trackdependency API 'sini kullanabilirsiniz. Yük testi genellikle telemetri içinde bu tür boşlukları ortaya çıkarır ve bu durum düzeltilebilir.

Test 2: artan önbellek boyutu

İkinci yük testi için, geliştirme ekibi Redsıs için Azure önbelleğindeki önbellek boyutunu artırmıştır. (Bkz. redsıs Için Azure önbelleğini ölçeklendirme.) Bu değişiklik, bellek dışı özel durumları çözümledi ve artık uygulama eşlemesinde sıfır hata gösteriliyor:

Ancak, iletileri işlerken hala önemli bir gecikme vardır. Yük testinin en sonunda, gelen ileti oranı 5 × 'den fazla ve giden orandır:

aşağıdaki grafik, aktarım hızını ileti tamamlama açısından ölçer (diğer bir deyişle, iş akışı hizmetinin Service Bus iletilerini tamamlandı olarak işaretlediği ücret). Grafikteki her nokta, yaklaşık 16/sn en fazla üretilen işi gösteren 5 saniyelik verileri temsil eder.

Bu grafik, kusto sorgu dilikullanılarak Log Analytics çalışma alanında bir sorgu çalıştırılarak oluşturulmuştur:

let start=datetime("2020-07-31T22:30:00.000Z");
let end=datetime("2020-07-31T22:45:00.000Z");
dependencies
| where cloud_RoleName == 'fabrikam-workflow'
| where timestamp > start and timestamp < end
| where type == 'Azure Service Bus'
| where target has 'https://dev-i-iuosnlbwkzkau.servicebus.windows.net'
| where client_Type == "PC"
| where name == "Complete"
| summarize succeeded=sumif(itemCount, success == true), failed=sumif(itemCount, success == false) by bin(timestamp, 5s)
| render timechart

Test 3: arka uç hizmetlerini ölçeklendirme

Arka uç, performans sorununa göre görünür. Kolay bir sonraki adım, iş hizmetleri (paket, teslim ve kurutma zamanlayıcının) ölçeğini genişletmek ve üretilen iş hızının artmayı görmektir. Bir sonraki yük testi için, takım bu hizmetleri üç çoğaltmalardan altı çoğaltmaya ölçeklendirildi.

Ne yazık ki bu yük testinde yalnızca ila büyüklükteki iyileştirmesi gösteriliyor. Giden iletiler yine de gelen iletilerle birlikte tutulmaz:

Aktarım hızı daha tutarlıdır, ancak elde edilen en yüksek değer önceki sınamale aynı şekilde olur:

Üstelik, kapsayıcılar Için Azure izleyici'ye bakarak sorunun küme içindeki kaynak tükenmesi nedeniyle kaynaklanmadığını ortaya çıkan bir sorun görüntülenir. İlk olarak, düğüm düzeyi ölçümleri, CPU kullanımının yüzde 40 ' de, yaklaşık 95. yüzdede ve bellek kullanımının %20 ' si altında kaldığını gösterir.

Bir Kubernetes ortamında, düğümler olmasa bile tek tek yığınların kaynak sınırlandırmaları mümkündür. Ancak Pod düzeyinde görünüm tüm yığınların sağlıklı olduğunu gösterir.

Bu testten, arka uca daha fazla sayıda yük eklememeye yardımcı olmayacaktır. Sonraki adım, iletileri işlerken ne olduğunu anlamak için Iş akışı hizmetinden daha yakından bakabilmenizdir. Application Insights, iş akışı hizmeti işleminin ortalama süresinin Process 246 ms olduğunu gösterir.

Her işlem içindeki bireysel işlemler hakkında ölçümleri almak için de bir sorgu çalıştırabiliriz:

bu tablodaki ilk satır Service Bus kuyruğu temsil eder. Diğer satırlar, arka uç hizmetlerine yapılan çağrılardır. Başvuru için, bu tablo için Log Analytics sorgusu aşağıda verilmiştir:

let start=datetime("2020-07-31T22:30:00.000Z");
let end=datetime("2020-07-31T22:45:00.000Z");
let dataset=dependencies
| where timestamp > start and timestamp < end
| where (cloud_RoleName == 'fabrikam-workflow')
| where name == 'Complete' or target in ('package', 'delivery', 'dronescheduler');
dataset
| summarize percentiles(duration, 50, 95) by target

Bu gecikme süreleri makul bir şekilde görünür. Ancak buradaki temel bilgiler aşağıda verilmiştir: toplam işlem süresi ~ 250 ms ise, hızlı iletilerin seri olarak nasıl işlenebilmesi için katı bir üst sınır koyar. Bu nedenle, üretilen işi iyileştirmeye yönelik anahtar daha büyük paralellik.

Bu senaryoda, iki nedenden dolayı olası olması gerekir:

• Bunlar ağ çağrılardır, bu nedenle çoğu zaman g/ç tamamlanmasını beklerken harcanacak
• İletiler bağımsızdır ve sırasıyla işlenmek zorunda değildir.

Test 4: paralellik artırma

Bu test için, takım paralellik arttırmaya odaklanılmıştır. bunu yapmak için, iş akışı hizmeti tarafından kullanılan Service Bus istemcisinde iki ayarı ayarlaırlar:

bu ayarlar hakkında daha fazla bilgi için bkz. Service Bus mesajlaşma kullanarak performans iyileştirmeleri için en iyi uygulamalar. Testi bu ayarlarla çalıştırmak aşağıdaki grafiği üretti:

Gelen iletilerin açık mavi renkli olduğunu ve giden iletilerin koyu mavi renkle gösterildiğini anımsayın.

İlk bakışta, bu çok tuhaf bir grafiktir. Bir süre boyunca giden ileti oranı gelen oranı tam olarak izler. Ancak, 2:03 işaretiyle, gelen ileti seviyelerinin oranı kapalı olsa da, giden ileti sayısı artmaya devam ederken, gelen ileti sayısının toplamı aşılıyor. Bu mümkün olmayan bir şekilde görünür.

bu gizlik 'e yapılan clue Application Insights içindeki bağımlılıklar görünümünde bulunabilir. Bu grafik, Service Bus Iş akışı hizmetinin yaptığı tüm çağrıları özetler:

İçin girişinin olduğuna dikkat edin DeadLetter . bu çağrı, iletilerin Service Bus atılacak ileti sırasınagidiyor olduğunu gösterir.

Neler olduğunu anlamak için Service Bus 'teki Peek-kilit semantiğini anlamanız gerekir. istemci, Peek-kilit kullandığında, Service Bus bir iletiyi otomatik olarak alır ve kilitler. Kilit tutulurken, ileti diğer alıcılar için teslim edilemez garanti edilir. Kilidin süresi dolarsa ileti diğer alıcılar tarafından kullanılabilir hale gelir. en fazla teslim girişimi sayısı (yapılandırılabilir), Service Bus iletileri daha sonra incelenebilir bir atılacak ileti kuyruğunakoyar.

Iş akışı hizmetinin büyük toplu işlem (3000 ileti) önceden aldığını unutmayın. Diğer bir deyişle, her iletiyi işlemek için toplam süre daha uzundur, bu da iletiler zaman aşımına uğrar ve sonunda atılacak ileti kuyruğuna gönderilir.

Ayrıca, bu davranışı çok sayıda özel durum kaydedildiği durumlarda de görebilirsiniz MessageLostLockException :

Test 5: kilit süresini artırma

Bu yük testi için, kilit zaman aşımlarını engellemek üzere ileti kilit süresi 5 dakikaya ayarlanmıştır. Gelen ve giden ileti grafiğinde artık sistem, gelen ileti hızıyla birlikte tutulduğunda gösterilmektedir:

8 dakikalık yük testinin toplam süresi boyunca uygulama, en yüksek aktarım hızında %400 artışı temsil eden 72 işlem/sn en yüksek aktarım hızı ile 25 K işlem tamamlandı.

Ancak, aynı testi daha uzun bir süre çalıştırmak uygulamanın bu oranı karşıbir şekilde sürdürememesi gerektiğini gösterdi:

Kapsayıcı ölçümleri maksimum CPU kullanımının %100 ' a yakın olduğunu gösterir. Bu noktada, uygulama CPU ile bağlantılı olarak görünür. Önceki ölçeklendirme denemesinden farklı olarak kümenin ölçeklendirilmesi Şu anda performansı iyileştirebilir.

Test 6: arka uç hizmetlerini genişletme (yeniden)

Serideki son yük testi için, takım Kubernetes kümesini ve pod 'yi aşağıdaki şekilde ölçeklendirdi:

Bu test, iletileri işlemede önemli bir lags olmadan daha yüksek sürekli bir işleme ile sonuçlandı. Üstelik, düğüm CPU kullanımı %80 oranında aşağıda verilmiştir.

Özet

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

• Redsıs için Azure önbelleğindeki bellek yetersiz özel durumları.
• İleti işlemede paralellik olmaması.
• İleti kilit süresi yetersiz, kilitlenme zaman aşımları ve iletileri atılacak ileti kuyruğuna yerleştirdi.
• CPU tükenmesi.

Bu sorunları tanılamak için, geliştirme ekibi aşağıdaki ölçümlere güvendi:

• gelen ve giden Service Bus iletilerinin oranı.
• Application Insights 'de uygulama haritası.
• Hatalar ve özel durumlar.
• Özel Log Analytics sorguları.
• Kapsayıcılar için Azure Izleyici 'de CPU ve bellek kullanımı.

Sonraki adımlar

Bu senaryonun tasarımı hakkında daha fazla bilgi için bkz. mikro hizmet mimarisi tasarlama.