Esnek Tüketimde Site Güncelleme Stratejileri

uygulamanızı Flex Consumption planında Azure Functions ile barındırdığınızda, güncelleştirmelerin çalışan örneklere nasıl dağıtılacağı denetlenebilir. Kod dağıttığınızda, uygulama ayarlarını değiştirdiğinizde veya diğer yapılandırma özelliklerini değiştirdiğinizde site güncelleştirmesi gerçekleşir. Flex Tüketim planı, işlev uygulamanızın bu güncelleştirmeler sırasında kapalı kalma süresi yaşayıp yaşamadığını ve devam eden yürütmelerin nasıl işleneceğini denetlemek için kullanabileceğiniz bir site yapılandırma ayarı (SiteUpdateStrategy) sağlar.

Flex Consumption planı şu anda şu güncelleştirme stratejilerini desteklemektedir:

• Yeniden oluşturma: İşlevler, kodunuzu en son sürümle değiştirdikten sonra çalışan tüm örnekleri yeniden başlatır. Bu yaklaşım, örnekler geri dönüştürülürken kısa bir kesinti süresine neden olabilir ve diğer Azure Functions barındırma planlarındaki varsayılan davranışı sürdürür.
• Sıralı güncelleştirme (önizleme): Örnekleri toplu olarak boşaltıp değiştirerek sıfır kapalı kalma süresi dağıtımları sağlar. Devam eden yürütmeler zorunlu sonlandırma olmadan doğal olarak tamamlanır.

Önemli

Sıralı güncelleştirme stratejisi şu anda önizleme aşamasındadır ve üretim uygulamaları için önerilmez. Bu stratejiyi herhangi bir üretim uygulamasında etkinleştirmeden önce geçerli sınırlamaları ve dikkate alınacak noktaları gözden geçirin.

Strateji karşılaştırması

Bu tablo iki site güncelleştirme stratejisini karşılaştırır:

Değerlendirme	Yeniden oluşturun	Sıralı güncelleştirme
Kesinti süresi	Yeniden başlattıktan sonra uygulamanız sıfırdan ölçeklenirken kısa bir kesinti süresi yaşanabilir.	Kapalı kalma süresi yok
Devam eden işlemler	Zorla sonlandırıldı	60 dakikalık ölçek küçültme geçiş süresi içinde tamamlanmasına izin verilir (230 saniyelik zaman aşımıyla sınırlı HTTP işlevleri)
Hız	Daha hızlı - örnekler hemen yeniden başlatılır	Daha yavaş - örnekler düzenli aralıklarla toplu olarak güncelleştirilir
Geriye dönük uyumluluk	Tek seferde bir sürüm çalıştığından gerekli değildir	Değişikliklerin, özellikle durum bilgisi olan iş yükleriyle ve kesintiye neden olan değişikliklerle geriye dönük uyumlu olması gerekir.
Nasıl ayarlanır?	Diğer barındırma planlarıyla tutarlı varsayılan davranış	Kabul etme yapılandırması
Ne zaman kullan...	✔ Hızlı dağıtımlara ihtiyacınız vardır. ✔ Kısa mola makuldür. ✔ Uyum sorunlarına yol açan değişiklikler dağıtıyorsunuz ve kesin bir yeniden başlatma yapmanız gerekiyor. ✔ İşlevleriniz durum bilgisizdir ve kesintileri işleyebilir.	✔ Sıfır kesinti süresi dağıtımlara ihtiyacınız var. Kesintiye uğratılamayacak uzun süre çalışan veya kritik işlevlere sahipsiniz. ✔ Değişiklikleriniz geriye dönük olarak uyumludur. ✔ Devam eden çalışmaları korumanız gerekir.

Strateji davranışlarını güncelleştirme

Bu tabloda iki stratejinin güncelleştirme işlemi karşılaştırılır:

Yeniden oluşturma stratejisi:

Sıralı güncelleştirme stratejisi:

1. İşlev uygulamanıza bir site güncelleştirmesi (kod veya yapılandırma değişiklikleri) uygulanır.
2. Yeni değişikliklerle çalışan örnekleri güncelleştirmek için yeniden oluşturma stratejisi tetikleniyor.
3. Platform, tüm canlı ve boşaltma durumlarını zorla yeniden başlatır.
4. Ölçeklendirme sistemi hemen güncellenmiş sürümle yenilerini sağlamaya başlar (mevcut örnekler arka planda devre dışı bırakılıyor olabilir).

1. İşlev uygulamanıza bir site güncelleştirmesi (kod veya yapılandırma değişiklikleri) uygulanır.
2. Çalışan örnekleri yeni değişikliklerle güncelleştirmek için sıralı güncelleştirme stratejisi tetikleniyor.
3. Platform, tüm canlı örnekleri gruplara atar.
4. Platform düzenli aralıklarla bir grup örneği boşaltıyor. Boşaltma, örneklerin yeni olayları kabul etmesini engellerken devam eden yürütmelerin tamamlanmasına izin verir (en fazla bir saatlik yürütme süresi).
5. Aynı anda ölçeklendirme platformu, boşaltılan kapasiteyi değiştirmek için güncelleştirilmiş sürümü çalıştıran yeni örnekler sağlar.
6. Bu işlem, tüm canlı örnekler güncelleştirilmiş sürümü çalıştırana kadar devam eder.

Bu tablo, iki stratejinin temel özelliklerini karşılaştırır:

Yeniden oluşturma stratejisi:

Sıralı güncelleştirme stratejisi:

• Kısa kapalı kalma süresi: Örnekler yeniden başlatılırken ve ölçeği genişletilirken uygulamanız kullanılamaz
• Yürütme kesintisi: Devam eden yürütmeler hemen sonlandırılıyor
• Tamamlanma sinyali yok: Orijinal örneklerinin günlük çıkışını ne zaman durdurduğunu izlemek için örnek günlüklerini kontrol edin.

• Sıfır kapalı kalma süresi: Dağıtımlar toplu olarak yapılır, böylece işlemler zorunlu sonlandırma olmaksızın tamamlanır.
• Zaman uyumsuz işlemler: Boşaltma ve ölçek genişletme birbirinin tamamlanmasını beklemeden aynı anda gerçekleşir. Ölçeği genişletme işleminin bir sonraki boşaltma aralığından önce gerçekleşmesi garanti değildir.
• Çakışan güncellemeler: Devam eden bir sıralı güncelleme sırasında ek güncellemeler başlatabilirsiniz. En son olmayan tüm örnekler boşaltılır ve yalnızca en yeni sürümün ölçeği genişletilir.
• Dinamik ölçeklendirme: Platform, güncelleştirme sırasında geçerli talebe göre örnek sayısını ayarlar.
• Platform tarafından yönetilen kapasite: Talep arttığında platform, tükettiğinden daha fazla örnek sağlar. Talep azaldığında, yalnızca geçerli ihtiyaçları karşılamak için gerekli örnekleri oluşturur. Bu yaklaşım, kaynak kullanımını iyileştirirken sürekli kullanılabilirlik sağlar.

Sıralı güncelleştirme stratejisiyle ilgili dikkat edilmesi gerekenler

Sıralı güncelleştirme stratejisini kullanırken bu geçerli davranışları ve sınırlamaları göz önünde bulundurun. Bu liste önizleme döneminde korunur ve özellik genel kullanılabilirliğe (GA) yaklaştıkça değişebilir.

• Platform tarafından yönetilen parametreler: Platform, sıralı güncelleştirme davranışlarını belirleyen parametreleri (toplu iş sayısı, toplu iş başına örnekler, toplu iş sayısı ve boşaltma aralıkları gibi) denetler. Bu parametreler, performansı ve güvenilirliği iyileştirmek için GA öncesinde değişebilir.
• Gerçek zamanlı izleme yok: Şu anda kaç örneğin tükettiğine, kaç toplu işlemin kaldığına veya geçerli ilerleme yüzdelerine ilişkin görünürlük yoktur.
• Tamamlanma sinyali yok: Ancak, bir güncelleştirmenin ne zaman tamamleneceğini tahmin etmek için örnek günlüklerini izleyebilirsiniz.
• Tek örnekli senaryolar: Bir örnek üzerinde çalışan uygulamalar, devam eden yürütmeler tamamlanırken yeniden oluşturma işlemine benzer kısa bir kesinti yaşar.
• Durable Functions: Güncelleştirmeler sırasında sürümleri karıştırmak Dayanıklı orkestrasyonda beklenmeyen davranışlara neden olabileceği için, açık bir orkestrasyon sürüm eşleştirme stratejisi kullanın.
• Kod Olarak Altyapı: Kod ve yapılandırma değişikliklerini birlikte dağıtmak, çakışabilecek birden çok sıralı güncelleştirmesi tetikler.
• Geriye dönük uyumluluk: Sıralı güncelleştirme geçiş döneminde değişikliklerinizin önceki sürümle çalıştığından emin olun.

Güncelleştirme stratejinizi yapılandırma

Uygulamanızın güncelleştirme stratejisini, SiteUpdateStrategy öğesinin alt öğesi olan functionAppConfig site ayarını kullanarak ayarlayabilirsiniz. varsayılan olarak, SiteUpdateStrategy.typeRecreateolarak ayarlanır. Şu anda yalnızca API sürümü 2023-12-01 veya sonraki sürümlere sahip Bicep ve ARM şablonları bu özelliği değiştirmeyi destekler.

Bicep

functionAppConfig: {
  ...
  siteUpdateStrategy: {
    type: 'RollingUpdate'
  }
  ...
}

ARM Şablonu

"functionAppConfig": {
  ...
  "siteUpdateStrategy": {
    "type": "RollingUpdate"
  }
  ...
}

Site güncelleştirme stratejisindeki değişiklikler bir sonraki site güncelleştirmesinde geçerli olur. Örneğin, type'yi Recreate'den RollingUpdate'ye değiştirmek, bu güncelleştirme için yeniden oluşturma stratejisini kullanır. Sonraki tüm site güncelleştirmeleri sıralı güncelleştirmeleri kullanır.

Site güncelleştirmelerini izleme

Genel önizleme sırasında site güncelleştirmeleri için yerleşik tamamlama sinyali yoktur. Sıralı güncelleştirme ilerleme durumunu tahmin etmek için en iyi çaba yaklaşımı olarak Application Insights'ta KQL sorgularını kullanabilirsiniz.

Sıralı güncelleştirme ilerleme durumunu izleme

Bu KQL sorguları, Application Insights günlüklerinde örnek devir şeklini izleyerek sürekli güncelleştirme ilerlemesi için en iyi çabayı gösteren bir tahmin sağlar. Bu yaklaşımın önemli sınırlamaları vardır ve üretim otomasyonu için bu yaklaşıma bağlı olmamalıdır:

// Rolling update completion check
let deploymentStart = datetime('2025-10-30T19:00:00Z'); // Set to your deployment start time
let checkInterval = 10s; // How often you run this query
let buffer = 30s; // Safety buffer for instance detection
//
// Get original instances (active before deployment)
let originalInstances = 
    traces
    | where timestamp between ((deploymentStart - buffer) .. deploymentStart)
    | where cloud_RoleInstance != ""
    | summarize by InstanceId = cloud_RoleInstance;
//
// Get currently active instances
let currentInstances = 
    traces
    | where timestamp >= now() - checkInterval
    | where cloud_RoleInstance != ""
    | summarize by InstanceId = cloud_RoleInstance;
//
// Check completion status
currentInstances
| join kind=leftouter (originalInstances | extend IsOriginal = true) on InstanceId
| extend IsOriginal = isnotnull(IsOriginal)
| summarize 
    OriginalStillActiveInstances = make_set_if(InstanceId, IsOriginal),
    NewInstances = make_set_if(InstanceId, not(IsOriginal)),
    OriginalStillActiveCount = countif(IsOriginal),
    NewCount = countif(not(IsOriginal)),
    TotalOriginal = toscalar(originalInstances | count)
| extend 
    RollingUpdateComplete = iff(OriginalStillActiveCount == 0, "YES", "NO"),
    PercentComplete = round(100.0 * (1.0 - todouble(OriginalStillActiveCount) / todouble(TotalOriginal)), 1)
| project RollingUpdateComplete, PercentComplete, OriginalStillActiveCount, NewCount

Tahmin için bu sorgu nasıl kullanılır:

1. Bu sorguyu işlev uygulamanızla ilişkilendirilmiş Application Insights kaynağının Günlükler dikey penceresine yapıştırın.
2. Site güncelleştirmenizin başarı döndürdüğü zaman damgasını deploymentStart ayarlayın.
3. İlerleme durumunu tahmin etmek için sorguyu düzenli aralıklarla çalıştırın. Yoklama aralığını en az ortalama işlev yürütme süreniz kadar olacak şekilde ayarlayın ve sorgudaki değişkenin checkInterval bu yoklama sıklığıyla eşleştiğinden emin olun.
4. Sorgu yaklaşık değerler döndürür:
   • RollingUpdateComplete: Tüm özgün örneklerin değiştirilip değiştirilmediğine ilişkin en iyi tahmin
   • PercentComplete: Değiştirilen özgün örneklerin tahmini yüzdesi
   • OriginalStillActiveCount: Hala çalışan özgün örneklerin tahmini sayısı
   • NewCount: Şu anda etkin olan yeni örneklerin sayısı

Bu sorguları kullanırken bu sınırlamaları göz önünde bulundurun:

1. Zamanlama aralığı: deploymentStart zamanı, site güncelleştirmenizin başarılı bir şekilde tamamlandığı zamanı temsil eder, ancak gerçek aşamalı güncelleme hemen başlamayabilir. Bu boşluk sırasında, ölçeklenme olayları orijinal sürümde çalışan örnekleri etkinleştirir. Sorgu yalnızca konumunda deploymentStartetkin olan örnekleri izlediğinden, bu yeni özgün sürüm örneklerini izlemez ve hatalı tamamlama sinyallerine neden olabilir.

2. Günlük tabanlı algılama: Bu yaklaşım, doğrudan örnek durumunu sorgulamak yerine örnek durumunu çıkarsamak için uygulama günlüklerine dayanır. Örnekler çalışıyor olabilir ancak etkin olarak günlüğe kaydetmeyebilir ve özgün örnekler hala etkinken pencere içinde checkInterval günlükleri yaymadığında hatalı tamamlama sinyallerine yol açar.

Üretim önerisi: Kesintisiz dağıtımlar kritik olduğunda kademeli güncellemeleri kullanın. Sonraki adımlara geçmeden önce dağıtım işlem hatlarınızın güncelleştirmenin tamamlanmasını beklemesini gerektirmediğinden emin olun. Daha hızlı ve daha öngörülebilir güncelleştirme zamanlamasına ihtiyacınız olduğunda yeniden oluşturma özelliğini kullanın ve kısa kapalı kalma sürelerini tolere edebilirsiniz.

FAQ

Alışkınım, kesinti yaşanmayan dağıtımlar için dağıtım yuvalarını kullanmaya. Sıralı güncelleştirmelerin farkı nedir?

• Dağıtım yuvalarından farklı olarak, sıralı güncelleştirmeler ek altyapı gerektirmez. Sıfır kesinti süresi dağıtımları için siteUpdateStrategy.type"RollingUpdate" olarak ayarlayın.
• Sıralı güncelleştirmeler devam eden yürütmeleri korurken dağıtım yuvaları bunları değiştirme işlemleri sırasında sonlandırır. Bazı site özellikleri ve yapışkan ayarlar değiştirilemez ve üretim yuvasının doğrudan değiştirilmesini gerektirir.
• Aşamalı güncellemeler, dağıtım yuvalarının aksine, canary test değişikliklerini uygulamak veya canlı trafiğin bir yüzdesini yönlendirmek için ayrı bir ortam sağlamaz. Bu özelliklere ihtiyacınız varsa, Elastic Premium gibi dağıtım yuvalarını destekleyen bir plan kullanın veya bir trafik yöneticisinin arkasında ayrı Flex Consumption uygulamalarını yönetin.

Site güncelleştirmesini nasıl geri aebilirim?

• Şu anda site güncelleştirmesini geri alma özelliği yoktur. Geri alma gerekiyorsa, önceki kod veya yapılandırma durumuyla başka bir site güncelleştirmesi başlatın.

Zamanlayıcı tetikleyicilerle nasıl baş edilir?

• Zamanlayıcı tetikleyicileri tekil doğalarını korurlar. Zamanlayıcıyla tetiklenen bir işlev uygulaması, drenaj için işaretlendiğinde, yeni zamanlayıcı işlevleri son sürümde işleme konur.

Sıralı güncelleştirme sırasında çalışma zamanı hataları görüyorum... Ne oldu?

• Yeni örnekler başlatılamazsa veya çalışma zamanı hatalarıyla karşılaşırsa, sorun büyük olasılıkla değiştirdiğiniz uygulama kodunda, bağımlılıklarda, yapılandırma ayarlarında veya ortam değişkenlerindedir.
• Sorunu çözmek için bilinen son iyi durumdaki sürümünüzü yeniden dağıtarak çalışma zamanını geri yükleyin. Ardından yeniden denemeden önce önerilen değişikliklerinizi geliştirme veya hazırlama ortamında test edin. Soruna hangi değişikliğin neden olduğunu belirlemek için hata günlüklerini gözden geçirin.

Sonraki Adımlar

• Flex Tüketim planı hakkında daha fazla bilgi edinin
• Flex Tüketiminde dağıtımların nasıl farklılık gösterdiği hakkında daha fazla bilgi edinin
• Kod olarak altyapı şablonları yazmayı öğrenin