Hizmetinizin Ölçeklenmesini Geciktiren Gizli Tasarım Hatası: Gecikmeyi Ölçmek Değil, Tasarlamak

Geçmişte yaptığım en önemli hatalardan biri, paydaşlara sunduğum bir sistemin gecikme bütçesinin üretimde nasıl paramparça olduğunu izlemekti. Test ortamında her bileşenin performansını dikkatle ölçmüştük: Kimlik doğrulama servisi 15 milisaniye, iş mantığı 30 milisaniye, veri tabanı sorgusu 40 milisaniyeydi. Toplamda 200 milisaniyelik bütçeyi rahatlıkla karşılıyordu. Güçlü olduğumuzu hissediyordum. Sayılarımız vardı. Ardından sistemi canlıya aldık. Üretimdeyse kimlik doğrulama çağrısının 15 milisaniyeden 200 milisaniyeye kadar çıktığını gördük. Panik yaptım, profil araçları çalıştırdım, hatta o dönemde henüz LLM ajanlarının yaygınlaşmadığı bir zamanda yeni araçlar da ekledim. Veritabanına yazma, okuma, API çağrıları... Her şeyi kontrol ettim. Sonunda acı gerçeği gördüm: kimlik doğrulama servisi yavaş değildi. Çünkü dört farklı servisle paylaşılan bu kaynak, aynı anda yoğunlaşan taleplerle baş edemiyordu. Kimse — ben de dahil — bu servisin kapasitesini rezerve etmemişti. 15 milisaniyelik tahsisimiz, 200 milisaniyeye ulaşmıştı. Geriye kalan bütçe artık hiçbir işe yaramazdı.

O andan itibaren gecikmeyi sadece bir ölçüm meselesi olarak değil, bir tasarım sorunu olarak görmeye başladım. Ölç ve optimize et yaklaşımı mühendislik disiplini gibi görünse de uygulamada genellikle mimari kısıtlarımızı çok geç keşfedip, onları değiştirmenin maliyetinin arttığı bir duruma dönüşüyordu. Bu, sistemlerin ölçeklenmesini engelleyen varsayımlar üzerine yazdığım bir dizi makalenin dördüncü bölümü.

İyi bir mimariyi iyileştirmek mümkün değil, ancak kötü bir mimariyi kurtarmak zor

Yeni mühendislerin sıkça yaptığı gibi, sistemi inşa ettikten sonra yük testleriyle gecikmeyi ölçüp yavaş olan kısımları optimize etmek akla yatkın bir yaklaşımdır. Ancak üretimde ölçüm yapmaya başladığınızda, gecikmeye neden olan kararlar mimarinin derinliklerine gömülmüş oluyor. Bu kararları değiştirmek, diğer bileşenlere bağımlı olan sistemleri yeniden yazmak anlamına geliyor — ve bunu kullanıcıların beklediği bir anda yapmak zorunda kalıyorsunuz. Bu optimizasyon değil, yeniden inşa etmektir. Üstelik en kötü zamanda: Ürünü kullanıma sunmaya üç gün kala, baskı altında.

Yük testleri de genellikle gerçek sorunu yakalayamıyor. Testler, hayal ettiğiniz trafiği modeller. Üretimse, paylaşılan bağımlılıkları, eşzamanlı artışları ve test paketlerinizin hiç düşünmediği kullanım desenlerini ortaya çıkarır. Neden derseniz, test ettiğiniz şeyleri bilirsiniz. Üretimse, bilmediklerinizi — en uygunsuz zamanda — öğretir.

Gecikmenin asıl adresi neresi? (İpucu: Düşündüğünüz yer değil)

Açıkça yavaş olan sorgular, optimize edilmemiş döngüler, kötü zaman aşımı ayarlarına sahip API çağrıları — bunları düzeltmek elbette değerlidir. Ancak genellikle asıl sorun bu değildir. İlginç gecikme sorunları yapısaldır; sistem organize edilirken kod yazılmadan önce ortaya çıkar.

• Konuşkanlık (Chattiness): Kullanıcıdan gelen bir istek sekiz iç hizmet çağrısı gerektiriyorsa, gecikme tabanınız bu çağrıların toplamına eşittir. Bu tabanın altına inemezsiniz. Ne önbellekleme ne bağlantı havuzu ne de indeks optimizasyonu bu matematiksel gerçeği değiştirebilir. Çağrı yapısını yeniden tasarlamanız gerekir.

• Sınırsız yayılım (Unbounded fanout): Geliştirme ortamında 20 milisaniyede çalışan bir sorgu, üretimde kullanıcının girdiği değere bağlı olarak on bin kat yavaşlayabilir. Ve genellikle en önemli müşterileriniz bu duruma maruz kalır. "Sınır eklemeliyiz" tartışması hızla politik bir hal alır.

• Eşzamanlı beklemeler (Synchronous waits on async work): Sistem, temelde asenkron olan bir işlem için — örneğin bir yazının yayılması, bir hizmetin onay vermesi ya da önbelleğin ısınması — eşzamanlı olarak bekliyorsa, yanıt süreniz için sert bir tavan koymuş olursunuz. Hiçbir optimizasyon bu tavanı kaldıramaz. Sınırı senkron ile asenkron arasında değiştirmeniz gerekir ki bu, daha önce de belirttiğim gibi, tersine çevrilmesi zor bir karar.

Gecikme bütçesi: inşa etmeden karar verin, sonrasında değil

Gerçekten işe yarayan şey, sistemi inşa etmeden önce gecikme bütçenizi belirlemektir — ve biraz da esneklik ekleyin, çünkü emin olun ihtiyacınız olacak. Hedef yanıt sürenizi alın, her kritik bileşene bütçeyi dağıtın ve her birine ayrı bir sayı atayın. Bunları bir yere yazın. İnsanların görebileceği bir yere.

Bu basit egzersiz, paylaşılan bağımlılıkları hemen ortaya çıkarır. İki bileşen aynı kaynağı paylaşıyorsa, bütçeleri birbirinden bağımsız değildir. İzole edilmiş kapasiteye sahip olmayan bir kaynak, her iki bileşen de aynı anda yoğunlaşınca bütçe hesaplarını çökertir. Tam da bizim kimlik doğrulama servisinde yaşadığımız gibi.

Bütçeyi yazmak ayrıca kod yazılmadan önce açık ticaretleri de ortaya çıkarır. Kritik yolda yer alan pahalı işlemler belki asenkron olarak hesaplanabilir. Veriyi denormalize etmek zorunda kalabilirsiniz. Bunlar, kod var olmadan önce yapılması gereken gerçek konuşmalar.

Biliyorum, bu bir süreç adına süreçmiş gibi görünebilir. Öyle değil. Bu, "bu ticareti seçtik" ile "gece yarısı bir olay sırasında bu ticareti keşfettik" arasındaki farktır.

Sizi korkutması gereken sayı

Saniyede 100.000 istekle çalışan bir sistemde, gereksiz 10 milisaniyelik gecikme her saniye 1.000 saniyelik kullanıcı bekleme süresine denk gelir. Bu gerçeği bir düşünün. Sistem çalıştığı her saniyede, her saniye 1.000 saniyelik boşa harcanmış insan zamanı. Bu bir performans sorunu değil, müşteri sorunudur. Bu yüzden gerçek hacimlere ulaşan ekipler, gecikmeyi tasarımın ilk adımında ele alırlar — ölçümün sonrasında değil.