Cloudflare Origin Range Requests, range boyutu ayarını sabit cache parçalarıyla değiştiriyor

Cloudflare range caching'i baştan kuruyor

Cloudflare, tüm planlarda kullanılabilen self-service bir cache özelliği olan Origin Range Requests'i duyurdu; bu özellik, edge'in HTTP range isteklerini karşılama biçimini değiştiriyor. Zone başına ayarlanmış bir range boyutu gerektirmek yerine, Cloudflare artık origin verisini, Pingora tabanlı cache'inin depolama için halihazırda kullandığı sabit boyutlu parçalarla hizalanmış aralıklarla çekiyor. Cloudflare bloguna göre özelliği etkinleştirmek tek bir Cache Rule ile yapılıyor; ne ayarlanacak bir boyut var ne de bir destek talebi açmak gerekiyor. Şirket, object storage servisi R2'de p99 ilk bayt süresinin kabaca yarıya düştüğünü, ardından gelen bir değişikliğin de R2 benzeri iş yükleri için tiered cache trafiğini yaklaşık %6 azalttığını bildiriyor.

Eski range caching neden bant genişliği israf ediyordu

Bir range isteği, bir kaynağın bir bölümünü ister: istemci, içinde bir Range başlığı bulunan normal bir GET gönderir ve bunu destekleyen sunucu, döndürülen baytları tanımlayan bir Content-Range başlığıyla 206 Partial Content yanıtı verir. Video oynatıcılar bunları atlama (seek) için, indirme yöneticileri kesilen aktarımları sürdürmek için, paket yöneticileri ise bir artifact'in bir bölümünü çekmek için kullanır.

Cloudflare'ın önceki uygulaması — ki şirket bunu bir nginx blog yazısında açıklanan cache-slicing yaklaşımına benzetiyor — her istemci isteğini, zone başına yapılandırılan range boyutu ve geçerli dosya uzantılarıyla, dosyanın sabit boyutlu aralıklarına eşliyordu. Bu boyut bir dengesizlik yaratıyordu: küçük aralıklar çok sayıda küçük origin pull anlamına geliyor ve istekleri bellekte birleştirmek bellek baskısı yaratıyordu; büyük aralıklar ise Cloudflare'ın istemcinin istediğinden çok daha fazlasını indirmesine yol açıyordu. Birkaç megabyte'lık bir istek, 128 MiB'lik bir origin pull tetikleyebiliyor ve bu veri daha sonra, bazen izleyici çoktan ayrıldıktan sonra, veri merkezleri arasında taşınıyordu. Boyut cache anahtarının (cache key) parçası olduğundan, boyutu değiştirmek cache kayıtlarını da geçersiz kılıyordu.

Eşzamanlılık da zarar görüyordu. Aynı yapılandırılmış aralığın içine denk gelen istekler, ne kadar uzakta olurlarsa olsunlar birbirlerini bloke edebiliyordu ve nginx tabanlı cache, range caching'i eşzamanlı akışla (concurrent streaming) birleştiremediği için her aralığın, biri onu okuyabilmeden önce indirilmesini tamamlaması gerekiyordu. İsraf her atlama noktasında katlanıyordu: origin'den veri merkezine, cache katmanları arasında ve ardından istemciye. Cloudflare'a göre üretim ortamında yapılandırılan boyutlar onlarca kilobyte'tan onlarca gigabyte'a kadar uzanıyordu.

Sabit parçalar ayarın yerini alıyor

Çözüm, Cloudflare'ın cache katmanında nginx'in yerini almak için geliştirdiği proxy olan Pingora'dan geldi. Pingora, kesilen indirmelerin sürdürülebilmesi için önbelleğe alınan her dosyayı zaten sabit boyutlu parçalar halinde diskte saklıyor; Origin Range Requests ise bu parçayı fetch birimi yapıyor. Edge, halihazırda cache'lenmiş istenen baytları servis ediyor, eksik baytları parça sınırlarına hizalanmış aralıklarla origin'den çekiyor, bunları normal caching'de kullanılan parçalara kaydediyor ve istemciye yalnızca istediğini döndürüyor. Bayt 150–250 için yapılan bir istek, bunları içeren整个 parçanın tamamını çekebilir, ancak yanıt yine de tam olarak 150–250 baytlarını taşır.

Fazla veri çekme (over-fetch) ortadan kalkmış değil: bir parçadan küçük bir istek hâlâ parçanın tamamını çekebilir. Cloudflare'a göre fark şu: ek yükün artık sabit bir üst sınırı var ve CDN ile origin üzerinde öngörülemeyen etkileri olan, müşteri tarafından seçilen bir boyuta bağlı değil.

Cache'lenmiş, aktarılmakta olan ve çekilen baytların koordinasyonu

Cloudflare'a göre gerçekten zor olan kısım, istenen baytlar diskteki cache'lenmiş verilere, hâlihazırda devam eden bir indirmeye ve yeni bir origin fetch'ine yayıldığında tek bir doğru yanıt üretmektir. Edge, hangi aralıkların tam olduğunu açıklayan metaveriyi okur, yapabildiğini servis eder, kalanı için hizalanmış aralıklar çeker, yazılanları kaydeder ve nihai yanıtı doğru Content-Range ve Content-Length başlıklarıyla oluşturur. Tek bir istek, cache'lenmiş bir önek, ona eklenmiş devam eden bir indirme ve yeni çekilmiş bir soneki birleştirebilir; devam eden bir indirmenin kapsadığı baytlara sahip ikinci bir istek, başka bir origin fetch tetiklemek yerine bu indirmeye eklenebilir.

Birleştirme yalnızca tüm baytlar aynı temsilden (representation) geldiğinde yapılabilir. Cloudflare, her origin alt-yanıtının istenen aralıkla eşleştiğini, kaynağın toplam boyutunun istikrarlı kaldığını ve entity tag'in alt istekler arasında tutarlı olduğunu doğrular. If-Range uyuşmazlıklarında tam temsil döndürülür ve sıkıştırılmak üzere olan içerik bütün halinde servis edilir, çünkü sıkıştırılmış veri üzerindeki bayt konımları, sıkıştırılmamış gövdeninkinden farklıdır. Karşılanabilir aralıklar 206 alır, karşılanamayanlar ise 416 Range Not Satisfiable.

Genel lansmandan önce Cloudflare, eski özelliğin mevcut kullanıcılarını, en ağır vakilerden başlayarak taşıdı: dalgalı trafik altında çok büyük dosyalara yönelik yüksek hacimli eşzamanlı range istekleri.

Neden önemli

Büyük dosyalar range istekleriyle teslim edilir ve eski model, hiçbir istemcinin tüketmediği baytlar için origin'lere ve cache katmanlarına bedel ödetiyordu. Fazla çekimi (over-fetch) parça düzeyinde sınırlamak, kısmi içerik teslimini tüm erişim biçimlerinde verimli hale getiriyor — küçük bir atlama, sıralı bir indirme ve çok gigabyte'lık bir medya dosyası artık farklı ayarlar gerektirmiyor. Cloudflare üzerinden büyük dosya servis eden herkes için bu özellik, daha önce CDN'in iç işlerini anlamayı gerektiren bir yapılandırma sorununu ortadan kaldırıyor ve R2 rakamları, gecikme ve bant genişliği tasarrufunun ölçekte önemli olduğunu gösteriyor.