Bulut Bilişim ve Veri Merkezleri

Cloudflare, blogunu taşımadan önce EmDash platformunu üretim yükü altında nasıl test etti

Cloudflare Blog, Astro üzerine kurulu EmDash içerik yönetim sistemine taşınırken geçiş risklerini azaltmak için birden fazla önbellekleme katmanı, yük testleri ve kademeli dağıtım kullandı. Şirket, erken sonuçların saniyede 850 isteğe kadar karşılandığını ve içeriğe aracılar üzerinden erişmek ve içeriği yönetmek için MCP denemesini içerdiğini belirtiyor.

2026-08-24
5 dk okuma
10 görüntülenme
فريق تحرير certi.news
Cloudflare, blogunu taşımadan önce EmDash platformunu üretim yükü altında nasıl test etti

Cloudflare, 12 Ağustos'ta blogunu Astro ve Cloudflare ile çalışmak üzere geliştirilen bir içerik yönetim sistemi olan EmDash'e taşıdı. Bu proje yalnızca arayüzün yeniden tasarlanmasından ibaret değildi. Şirket, yeni platformu gerçek üretim trafiği üzerinde test etmek için blogunu «sıfırıncı müşteri» olarak kullandı ve ölçeklenebilirlik, yanıt hızı ve eski sistemden güvenli geçişe odaklandı.

Cloudflare, taşıma sürecinin blogun boyutu ve karmaşıklığıyla ilgili ihtiyaçları ortaya çıkardığını ve ekibin EmDash'i daha geniş ölçekte sunmadan önce geliştirmesine olanak sağladığını belirtiyor. Sonuçlar ve ölçümler şirketin kendisinden geldiği için bu çalışma, platformun bağımsız bir testi değil, tek taraflı olarak yayımlanmış bir operasyonel deneyimi temsil ediyor.

Performans testinden önce platformu test etmek

Ekip pratik bir soruyla başladı: EmDash gerçekten Cloudflare'ın ihtiyaçlarıyla çalışıyor mu? Bu nedenle gönderi oluşturma, yayımlama, yayından kaldırma ve zamanlama gibi temel akışların yanı sıra medya ekleme, içerik varlıklarında arama yapma ve yazar adlarını yönetme işlemlerini test etti.

En büyük boşluklar, büyük medya ve içerik hacmiyle çalışmada, çeviri ayrıntılarında, arama motoru optimizasyonunda ve içerik güvenliği politikalarında (CSP) ortaya çıktı. Yönetim editöründe ayrıca özel HTML bloklarını bulmaya, içerik editöründeki hataları ele almaya ve uzun gönderiler düzenlenirken biçimlendirme çubuğunu görünür tutmaya yönelik iyileştirmeler gerekti.

Zamanlanmış gönderiler, keşfedilen en önemli sorun oldu; EmDash'in 0.19.0 sürümüne kadar çalışmadılar. Bu nokta, yeni bir sisteme güvenmeden önce uçtan uca operasyon akışlarını test etmenin değerini gösteriyor; çünkü sorun, içeriği oluşturma veya hemen yayımlama testlerinde mutlaka ortaya çıkmayabilirdi.

Dalgalı trafiği taklit eden yük testleri

Cloudflare Blog'daki olağan trafik saniyede yaklaşık 75 istek düzeyindeydi, ancak yeni bir gönderinin yayılmasıyla eş zamanlı olarak veya belirli bir yayımlama zamanına bağlı olmayan ani artışlar nedeniyle saniyede 5.000 isteği aşabiliyordu. Bu nedenle ekip, açık kaynaklı k6 aracını kullanarak taban yükün üç katına kadar kademeli artışı, sıfırdan başlayıp on dakika içinde saniyede 100 isteğe ulaşan bir testi ve bir dakika boyunca saniyede 7.000 istekte gerçekleşen ani patlama testini kapsayan testler tasarladı.

Başarısızlık ölçütleri üç göstergeye dayanıyordu: HTTP 5xx sınıfı hataların %0,01'i aşmaması, isteklerin %95'inin yanıt süresinin 500 milisaniyeyi aşmaması ve %99'unun yanıt süresinin bir saniyeyi aşmaması. Bu sınırlar, «platform hızlı mı?» sorusunu ölçülebilir operasyonel koşullara dönüştürdü.

Çok katmanlı mimari ve net bir geri dönüş yolu

Cloudflare, EmDash'i Workers Cache'in arkasında bir Cloudflare Worker üzerinde çalıştırmayı seçti. Ayrıca EmDash'te Workers KV üzerine kurulu yeni bir nesne önbelleği ve PlanetScale ile Hyperdrive entegrasyonu kullandı. Şirkete göre önbellekleme katmanları, sabit dosyaların %99,5'inin ve toplam isteklerin yaklaşık %70'inin önbellekten sunulmasını sağladı; bu da veritabanı üzerindeki yükü azalttı.

Geçiş sırasında hizmet kesintisini önlemek için ekip, istekleri eski blog ile yeni site arasında dağıtan bir Proxy Worker oluşturdu. Deneme sürümünü bir çerez üzerinden belirliyor ve yeni sitede 500 hataları ortaya çıktığında istekleri eski sisteme geri yönlendirebiliyordu. Ayrıca genel bir alan adından, DNS ve TLS işlemlerinden ve harici bir HTTP bağlantısından geçişi önlemek için NEW_BLOG hizmet bağlama özelliğini kullanarak Workers arasında doğrudan bağlantı kurdu.

Kademeli dağıtım trafiğin %1'iyle başladı, ardından %5 ve %15'e yükseldi ve günün sonunda %100'e ulaştı. Bu yöntem, gerçek yükün izlenmesine ve okuyucuların çoğunu kararsız bir değişikliğe maruz bırakmadan uç durumların keşfedilmesine olanak sağladı.

Pratikte ne değişti?

Cloudflare, yeni mimarinin önceki platforma kıyasla daha istikrarlı bir yanıt süresini koruduğunu, saniyede 850 isteğe kadar hizmet verirken performans kazanımları elde edildiğini ve hataların sınırlı kaldığını belirtiyor. Agents Week sırasında dokuz günde 18 blog yazısı yayımlandı ve yaklaşık 3 milyon görüntüleme elde edildi; yeni Worker, kayda değer sorunlar olmadan saniyede 450 isteğe kadar hizmet verdi. Şirkete göre yerleşik DDoS koruması da 10 Ağustos'ta saniyede 28.000 isteğe ulaşan bir saldırıyı emdi.

Değişiklik arayüzü de kapsıyordu. Arayüz, Kumo tasarım sistemi kalıplarına göre yeniden oluşturuldu ve sistem tercihleri ile manuel geçiş anahtarına dayalı olarak açık ve koyu modlar için yerel destek eklendi. E-posta aboneliği çağrısı makalenin sonuna taşındı; gezinmeyi ve paylaşımı iyileştirmek için «Bu sayfada» içindekiler bölümü ile «Çevrimiçi tartış» seçeneği eklendi.

EmDash'in yeni arayüzleri ve yapay zekâ arama uç noktaları, Cloudflare blogu için birkaç saat içinde bir MCP sunucusu oluşturulmasını sağladı. Bu sunucu, gönderileri aramak, listelemek ve geri getirmek ve etiketleri listelemek için araçlar içeriyor. Kaynağa göre EmDash'in kendi MCP sunucusu, yazarlara ek ücret olmadan içeriğe göz atma, içerik oluşturma, düzenleme, yayımlama, zamanlama ve dosyaları kaldırma olanağı da sunuyor.

Düzenleme deneyimi ise hâlâ tamamlanmış değil. Cloudflare, küçük sorunları ve zamanlanmış gönderilerle ilgili hataları kaydetmeye devam ettiğini, bunları EmDash ekibine ilettiğini ve Birthday Week'ten önce düzeltilmelerini beklediğini söyledi. Bu nedenle söz konusu durum, platformun sınırlamalardan yoksun olduğuna dair kanıt sunmuyor; ancak uygulanabilir bir yaklaşımı gösteriyor: performans testinden önce içerik akışlarını test etmek, açık başarısızlık eşikleri belirlemek, bir geri dönüş yolu oluşturmak ve tek seferde kapsamlı bir geçiş yapmak yerine dağıtımı kademeli olarak genişletmek.

Haber kaynağı
Cloudflare Blog
Özgün kaynağı aç ↗
ف
Yazar

فريق تحرير certi.news

Aynı kategoride

Bunlar da ilginizi çekebilir

Tüm haberleri gör