503 Service Unavailable: Aşırı Yüklenme, Bakım ve Retry-After

Canlı, ve işi reddediyor

Bir 503 döndürmek için bile, bir şeyin çalışıyor olması gerekir: TCP bağlantısını kabul etti, isteği ayrıştırdı, ve bir yanıt üretti. Bu tek gerçek, bir bütün sorun sınıfını eler. Ana bilgisayar çalışıyor, ağ yolu çalışıyor, TLS sonlandı, ve web sunucusu veya proxy işlev görüyor. Eksik olan kapasite veya isteklilik.

RFC 9110 bir uyarı ekler: bir sunucu aşırı yüklendiğinde 503 kullanmak zorunda değildir. Bazıları bunun yerine sadece bağlantıyı reddeder. Bu yüzden bir 503, aşırı yüklenmenin kibar biçimidir. Bir 503 yerine bir bağlantı reddedildi veya bir zaman aşımı alıyorsanız, farklı ve genellikle daha kötü bir hataya bakıyorsunuzdur.

İki komşu karıştırılması kolaydır. Bir 504 Gateway Timeout, arka ucun kabul edildiği ve sonra zamanında hiç yanıt vermediği anlamına gelir; istek denenmiştir. Bir 503, gerçek iş başlamadan önce isteğin reddedildiği anlamına gelir. Tüm aile, 5xx genel bakışında karşılaştırılır.

Retry-After, ve neden her zaman göndermelisiniz

RFC 9110, bir 503'ün iki biçimden birinde bir Retry-After başlığı taşımasına izin verir: beklenecek saniye sayısı, veya mutlak bir HTTP tarihi.

HTTP/1.1 503 Service Unavailable
Retry-After: 300
Content-Type: text/html

Hiçbir şeye mal olmaz. İyi davranan istemciler ve kütüphaneler, zaten zorlanan bir sunucuyu dövmek yerine belirtilen aralık kadar geri çekilir. Arama motoru tarayıcıları, URL'yi geçici olarak kullanılamaz olarak ele alır ve kesintiyi içerik kaldırma olarak değerlendirmek yerine daha sonra geri gelir. Kendi izleme ve durum araçlarınız, görüntülemek için açık bir beklenen kurtarma zamanı alır.

Bir 503 varsayılan olarak önbelleğe alınabilir değildir, bu yüzden aracılar hizmet kurtarıldıktan sonra onu sunmaya devam etmez.

Bir 503'e neden olan

• Aşırı yüklenme. Tüm işçi iş parçacıkları, süreçler veya bağlantı yuvaları meşguldür, bu yüzden yeni istekler süresiz olarak kuyruğa alınmak yerine reddedilir. Genellikle tepe zamanında aralıklı olarak başlar ve yük arttıkça sabit hale gelir.
• Bakım modu. Bir framework bayrağından, bir bakım dosyasından veya bir proxy kuralından kasıtlı bir geçiş. Bu, tam olarak yapması gerekeni yapan bir 503'tür.
• Bir bağımlılık çökük. Veritabanına, önbelleğine veya kuyruğuna ulaşamayan iyi yazılmış bir uygulama, bir yığın izi yerine 503 döndürmelidir, çünkü durum geçicidir ve isteğin hatası değildir.
• Sağlıklı arka uç yok. Her üyesi sağlık kontrolünde başarısız olan bir yük dengeleyicinin yönlendirecek hiçbir şeyi yoktur, ve birçoğu bu durumda 503 döndürür.
• Dağıtımlar ve yeniden başlatmalar. Eski sürecin boşaltılması ile yenisinin hizmet vermeye hazır hale gelmesi arasındaki pencere.
• Kasıtlı yük atma. Devre kesiciler ve kabul kontrolü, sistemin hâlâ çalışan kısımlarını korumak için kasıtlı olarak 503 döndürür.
• Ana bilgisayar düzeyinde kaynak tükenmesi. Bellek yetersizliği, dosya tanımlayıcısı yetersizliği veya dolu bir disk, ki bunlar yeni işin başlamasını engeller.

Dağıtım sırasındaki 503 örüntüsü

Bu, gerçek bir olay olmayan en yaygın 503'tür, ve tanınabilir bir şekli vardır: tam olarak bir sürümde başlayan ve kendi kendine biten, saniyelerden birkaç dakikaya kadar süren kısa bir 503 patlaması. Başka bir şeyi araştırmadan önce zaman damgalarını dağıtım geçmişinizle ilişkilendirin.

İyi ele alındığında, bir bakım 503'ü şunları yapmalıdır:

1. Gerçek durum kodunu döndürmeli. 200 ile sunulan bir bakım sayfası, tarayıcılara içeriğinizin artık bir bakım bildirimi olduğunu söyler, ki bu planlanmış bir pencere için mümkün olan en kötü sonuçtur.
2. Pencerenin gerçekçi bir tahminiyle Retry-After içermeli.
3. Statik ve ucuz kalmalı. Bakım sayfası, az önce çevrimdışı bıraktığınız veritabanına veya uygulamaya bağımlı olmamalıdır.
4. Ekibin yeniden açmadan önce yeni sürümü doğrulayabilmesi için kendi adreslerinizin geçmesine izin vermeli.
5. Planlanmış bir kesintinin nöbetçi olan kişiyi çağırmaması için izlemede bir bakım penceresi olarak zamanlanmalı.

Planlanmamış dağıtım 503'lerinin düzeltmesi sağlık kapılı bir kademeli güncellemedir: yeni süreci başlatın, bir hazırlık kontrolünü geçmesini bekleyin, sonra eskisini boşaltın ve durdurun. Düzgün yapıldığında, hiçbir şeyin hizmet veremediği bir pencere olmaz.

Planlanmamış bir 503 nasıl düzeltilir

1. Kodu doğrulayın ve başlıkları okuyun, bir Retry-After'ın gönderilip gönderilmediği ve hangi bileşenin yanıtı imzaladığı dahil:

   curl -sS -o /dev/null -D - https://example.com/

2. Önce bakım modunu eleyin. Bir sürümden sonra yerinde kalmış bir bakım bayrağı veya dosyasını kontrol edin. Kimsenin kabul ettiğinden daha sık olur.
3. Arka uç sağlığını kontrol edin. Bir yük dengeleyicide, kaç üyenin kontrolleri geçtiğine bakın. Sıfır sağlıklı üye anında bir yanıttır.
4. Doygunluğa bakın. İşçi ve bağlantı havuzu kullanımı, bellek, veritabanı bağlantıları ve kuyruk derinliği. Yük altında her şey tavanındayken bir 503, kapasitedir, bir hata değil.
5. Bağımlılıkları kontrol edin. Veritabanı, önbellek veya kritik bir API çökükse, web katmanı yerine onu düzeltin.
6. Yükü hafifletin, sonra nedeni bulun. Ölçeklendirmek veya sınırları yükseltmek hizmeti geri getirir, ama bir trafik artışı olmadan görünen bir 503, genellikle geri dönecek yavaş bir sorgu veya bir sızıntıyı gizler.

Tepe saati 503'leri ve zamanlanmış bakım pencereleri

Aşırı yüklenme 503'leri genellikle sabit hale gelmeden çok önce aralıklıdır, tepe saatlerinde görünür ve kendi kendine temizlenir. O erken aşama bir tarayıcıdan kaçırılması kolay ve sürekli bir kayıtta bariz olur. Beklenen durum kodunu onaylayan zamanlanmış bir HTTP kontrolü, o dağınık başarısızlıkları zamanlarıyla birlikte görünür bir eğilime dönüştürür, böylece aralıklı aşama bir kesintiye dönüşmeden önce harekete geçebilirsiniz. Bakım pencerelerini aynı araçta zamanlamak, planlanmış 503'lerin uyarı üretmesini önler.