Backend Ölçekleme

Ölçekleme sunucu eklemek değildir; sistemin nerede tıkandığını bulmak, o tek noktayı açmak ve açıldığını ölçmek demektir. Sunucu eklemek bu sıranın en sonundaki adımdır ve çoğu zaman gerekmez, çünkü yavaşlığın kaynağı makinenin kapasitesi değil, o makinede çalışan tek bir sorgu, kullanıcının beklemek zorunda bırakıldığı tek bir senkron adım ya da hiç kurulmamış bir önbellek katmanı oluyor. Ölçmeden yapılan optimizasyon ise bir tahmindir ve tahmin bazen tutsa da, tuttuğunda bile neden tuttuğu bilinmediği için bir sonraki yükte tekrarlanamaz. Bu yüzden ölçekleme işi profil çıkarmakla başlıyor, mimari tartışmasıyla değil.

Ölçekleme, performans ve dayanıklılık farkı

Birbirine karışan üç ayrı iş var: performans optimizasyonu aynı yükü daha az kaynakla karşılamak, ölçekleme yük arttığında yanıt süresinin nasıl davrandığı, dayanıklılık ise bir parça düştüğünde sistemin ayakta kalmasıdır. Bir sayfa tek kullanıcıda hızlı olup binlerce eşzamanlı kullanıcıda kilitlenebilir; tersi de olur, yavaş ama yük altında kararlı sistemler de vardır. Üçünün maliyeti, süresi ve çözümü farklı olduğu için bir talep geldiğinde ilk yaptığımız şey sorunun hangisi olduğunu yazmaktır. Bu ayrım yapılmadan başlanan işler genellikle en pahalı çözümü en küçük soruna uygular. Konunun mimari tarafını ölçeklenebilir ve sürdürülebilir yazılım mimarisi yazımızda ayrıca ele aldık.

Bir ölçekleme işini nasıl kuruyoruz

Aşağıdaki altı başlık bir ölçekleme projesinde verilen kararların tamamını kapsıyor. İlki teşhis: neyin ölçüleceği ve hangi rakamın hedef sayılacağı. Sonraki üçü müdahalenin yapıldığı katmanlar, yani veritabanı, önbellek ve kuyruk. Beşincisi mimarinin bölünüp bölünmeyeceği, altıncısı ise işin başında yapılması gereken kapasite ölçümü.

Darboğaz teşhisi ve ölçüm

Teşhis, ortalama yanıt süresine bakarak yapılmaz. Ortalama, yavaş isteklerin çoğunluk tarafından gizlendiği bir rakamdır; bakılması gereken uç dilimlerdir, çünkü sistemi terk eden kullanıcı ortalamayı değil kendi isteğini yaşar. Uç noktalar tek tek ele alınır ve her birinin süresi nerede geçtiği ayrıştırılır: veritabanında mı, dış servis beklemesinde mi, uygulama kodunda mı. Yanına dört rakam daha konur: yavaş sorgu kayıtları, önbellek isabet oranı, kuyruk derinliği ve sunucunun bellek ve işlemci doygunluğu. Bu tablo çıkmadan hiçbir mimari değişiklik önermiyoruz, çünkü değişikliğin işe yaradığını gösterecek karşılaştırma noktası ancak buradan çıkar.

Veritabanı tasarımı ve sorgu optimizasyonu

Yük altında ilk kırılan yer neredeyse her zaman veritabanıdır ve kırılmanın sebebi genellikle makine değil, indekssiz bir sorgu, döngü içinde tekrarlanan sorgular veya listeleme ekranında sınırsız büyüyen bir sonuç kümesidir. Sorgu planı okunmadan indeks eklemek de tahmindir; yanlış indeks yazma işlemlerini yavaşlatır ve sorunu yer değiştirtir. Anneekspres pazar yeri Python ve Django tarafında PostgreSQL üzerine sıfırdan kuruldu; kategori bazlı filtreleme, arama ve satıcı panelindeki stok ile sipariş yönetimi aynı altyapının üzerinde çalışıyor. Filtrelemenin ağır bastığı katalog sistemlerinde maliyet sunucuda değil sorgudadır: World Summer Schools yaş, ülke, program türü ve tarihe göre filtreleme yapılan yüzlerce programı tek bir aranabilir katalogda topluyor.

Önbellek katmanları ve geçersizleştirme

Önbellek eklemek kolaydır, zor olan neyin önbelleğe girmeyeceğine karar vermektir. Bayat veri gösteren bir sistem, yavaş bir sistemden daha pahalıya mal olur; bu yüzden her önbellek kaydının ömrü ve hangi olayda düşeceği önceden yazılır. Biletico bunun somut örneği: platform devralınıp arayüz, oturma planı ve ödeme akışı yeniden kurulurken teknik altyapı tarafında Next.js ve Node.js üzerine Redis ile önbellekleme yerleştirildi, veri tarafında MongoDB kullanıldı. Aynı platformda canvas tabanlı oturma planı gerçek zamanlı doluluk durumunu yansıtabiliyor. Bizde önbelleğin kapsamı ve kapsam dışında bırakılan, ayrı bir karar olarak yazılır. Welldone ve Tegoly tarafında da önbellek yapıları performans işinin parçasıydı.

Kuyruk ve olay tabanlı asenkron işleme

Kullanıcının isteği yalnızca kullanıcının o an gerçekten beklediği işi yapmalıdır. Fatura üretimi, bildirim gönderimi, rapor hesaplama ve dış servis çağrıları bu işten değildir; bunlar istek hattından çıkarılıp, sırayla işlenmek üzere kuyruğa alındığında yanıt süresi düşer ve dış servis çöktüğünde bile sipariş akışı ayakta kalır. Anneekspres altyapısında mesaj kuyruğu RabbitMQ ile kuruldu ve vaka sayfası bu altyapıyla sistemin yüksek trafik altında kesintisiz çalıştığını yazıyor. Lextum AI ise mikro servis mimarisi ve RabbitMQ ile asenkron işlem yapısı üzerine kuruldu; vaka sayfası bu yapıyı yüksek trafikli kurumsal kullanıma hazır sayıyor. Kuyruk bedava değildir: mesajın kaybolması, iki kez işlenmesi ve sıraya girmesi ayrı ayrı ele alınması gereken durumlardır.

Monolitten mikroservise kademeli geçiş

Mikroservis, tek kod tabanındaki uygulamayı (monoliti) ağ üzerinden konuşan küçük servislere bölmektir; bir hedef değil bir maliyettir: fonksiyon çağrısının yerini ağ çağrısı alır, hata ayıklama, veri tutarlılığı, sürüm uyumu ve izleme bir anda zorlaşır. Lextum AI mikro servis mimarisiyle kuruldu, yani bir monolitten taşınmadı, o yapıda teslim edildi. Çoğu sistemin buna ihtiyacı yoktur ve düzgün ayrılmış modüllere sahip tek bir uygulama uzun süre yeterlidir. Bölme kararı gerektiğinde tek seferde yapılmıyor: yükü veya yayın ritmi geri kalanından belirgin biçimde farklı olan tek bir parça seçilir, sınırı yazılır, önce okuma tarafı ayrılır, çalıştığı ölçüldükten sonra yazma tarafı taşınır. Aynı anda ikinci parçaya başlanmaz.

Yük testi ve kapasite planlama

Yük testi yuvarlak bir rakama göre değil, iş takviminizdeki gerçek olaya göre kurulur: bilet satışının açıldığı dakika, kampanya başlangıcı, sezon açılışı, bordro günü. Hedef önceden yazılır, yoksa test sonucu sonradan her yönden iyi anlatılabilir. Ölçülen şey yalnızca sistemin dayanıp dayanmadığı değil, hangi noktada ve hangi belirtiyle kırıldığıdır; kırılma noktası bilinmiyorsa kapasite planı da yoktur. Anneekspres için yüksek trafiği kaldırabilen bir platform gereksinimi işin başında konmuştu. Togodo tarafında yapılan performans iyileştirmeleri yüksek trafik altında sorunsuz çalışmayı sağladı. World Summer Schools için kurulan altyapı ise artan program ve kullanıcı hacmine hazır olacak şekilde ölçeklenebilir tasarlandı.

Sistemler gerçekte nerede kırılıyor

Kırılma noktası nadiren işlemci gücüdür. Pratikte dört yerden biri çıkıyor. Birincisi veritabanı: tek bir indekssiz sorgu, yük arttığında bağlantı havuzunu doldurup sistemin tamamını bekletir. İkincisi senkron yol: kullanıcının beklemediği bir işin istek hattında durması, dış servisin yavaşladığı anda sizin sisteminizi de yavaşlatır. Üçüncüsü önbelleğin yokluğu ya da yanlış kurulması; ikincisi birincisinden daha tehlikelidir çünkü sessizce yanlış veri gösterir. Dördüncüsü yayın hattıdır: canlıya çıkmak bir olaysa, bulunan sorun saatler veya günler boyunca canlıda kalır. Anneekspres, Biletico, Lextum AI, Welldone ve World Summer Schools projelerinde CI/CD otomasyonu Jenkins ile kuruldu. Yayın hattının kurulması ayrı bir iştir ve DevOps ve CI/CD tarafında ele alınır.

Ölçeklemenin maliyeti ve nerede durmak gerekir

Eklenen her katman işletilmesi gereken bir katmandır. Önbellek geçersizleştirme hatalarını, kuyruk mesaj kaybı ve tekrar işleme durumlarını, servis bölmesi ağ üzerinden gelen bir hata sınıfını beraberinde getirir. Bu yüzden her ölçekleme kararının yanına iki rakam yazıyoruz: beklenen kazanç ve o katmanın aylık işletme yükü. Durma noktası da baştan tanımlanıyor. Ölçüm hedefi tutturduğunda duruyoruz; darboğaz teknik değil de iş hacmiyse duruyoruz; ve daha ucuz bir müdahale işi görüyorsa büyük olana geçmiyoruz. Bir indeks ya da tek bir sorgu düzeltmesi çoğu zaman mimari değişiklikten hem hızlı hem kalıcıdır. Dikey büyüme, yani daha büyük tek makine, dağıtık bir mimariden ucuza gelebilir ve bunu söylemekten çekinmiyoruz. Ürün henüz doğrulanmamışsa doğru cevap ölçekleme değildir; o iş MVP Geliştirme tarafına aittir.

Kesintisiz geçiş nasıl yapılır

Ölçekleme çalışması yaşayan bir sistemin üzerinde yapılır, o yüzden her adımın geri alınabilir olması gerekir. Sıra şu: önce yayın hattı ve izleme kurulur, çünkü geri alma mekanizması olmayan bir değişiklik denenmez. Şema değişiklikleri iki aşamada yürütülür; yeni alan eklenir, iki yapı bir süre birlikte yaşar, eski alan ancak kullanılmadığı ölçüldükten sonra kaldırılır. Okuma yolları yazma yollarından önce taşınır, çünkü okuma tarafındaki hatanın geri dönüşü vardır. Değişiklikler bayrak arkasında açılır ve önce trafiğin küçük bir kısmına verilir. Geri dönüş planı, değişiklik canlıya çıkmadan önce yazılır ve kimin hangi eşikte geri alacağı isimle bellidir. Biletico tarafında her güncellemenin test edilip canlıya alınabilmesini sağlayan yapı, Anneekspres tarafında ise hızlı dağıtımı mümkün kılan hat bu ritmin ön koşuludur.

Teknoloji seçim kriterlerimiz

Seçim, üretimde çalıştırdığımız ve devrettiğimizde başkasının sürdürebileceği araçlarla sınırlı. Veritabanında varsayılan tercih ilişkisel tarafta: Anneekspres, Lextum AI ve World Summer Schools PostgreSQL, Welldone MySQL, Tegoly MSSQL, Togodo ise MSSQL ve PostgreSQL kullanıyor. Şemanın değişken olduğu yerlerde belge tabanlı tarafa geçiyoruz; Biletico ve Tegoly bu kümede MongoDB ile çalışıyor. Uygulama tarafında iş yükü G/Ç ağırlıklıysa Node.js, veri modeli ve yönetim ekranları ağır basıyorsa Python ve Django, kurumsal entegrasyon ve rol yapısı belirleyiciyse .NET kullanıyoruz. Önbellek katmanı Redis, kuyruk RabbitMQ, sunucular Ubuntu, yayın hattı Jenkins tarafında kurulu. Seçimi belirleyen üç ölçüt teknik moda değil: devirden sonra bakımı kimin yapacağı, o teknolojide eleman bulunup bulunmadığı ve barındırmanın sizin hesabınızda kalabilmesi.

Bu hizmetin yer aldığı işler

Aşağıdaki işlerin hepsinde Backend Ölçekleme hizmeti yer aldı. Her birinin ayrıntısı Başarı Hikayeleri bölümündeki kendi sayfasında duruyor.

• Anneekspres: Anne ve çocuk ürünleri pazar yeri sıfırdan kuruldu. RabbitMQ ile mesaj kuyruğu, PostgreSQL ile veri yönetimi ve Jenkins hatları; sistem yüksek trafik altında kesintisiz çalışıyor.
• Lextum AI: Hukuk ekipleri için belge üretimi, sözleşme incelemesi ve eş zamanlı düzenleme. Mikro servis mimarisi ve RabbitMQ ile asenkron işlem yapısı, AWS üzerinde yönetilen SaaS altyapısı.
• Biletico: Devralınan biletleme platformunda arayüz, canvas tabanlı oturma planı ve ödeme akışı işlevsel hale getirildi. Next.js ve Node.js üzerinde Redis ile önbellekleme, veri tarafında MongoDB.
• Togodo: Sosyal etkinlik uygulamasına yeni ekranlar, gerçek zamanlı mesajlaşma ve bildirimler eklendi; performans iyileştirmeleri yüksek trafik altında sorunsuz çalışmayı sağladı.
• Welldone: Endüstriyel çamaşırhane operasyonu için .NET servisleri, MySQL, önbellek yapıları ve Ubuntu tabanlı ölçeklenebilir sunucu altyapısı kuruldu.
• World Summer Schools: Yüzlerce yaz okulu programı tek bir aranabilir katalogda toplandı. Next.js, .NET ve PostgreSQL üzerinde bulut tabanlı altyapı, artan program ve kullanıcı hacmine hazır.
• Tegoly: Dijital imza platformunda önbellek mekanizmaları ve Azure üzerinde optimize sunucu yapılandırmalarıyla hız iyileştirildi; performans çalışması sayfa yükleme sürelerini düşürdü.
• Terazzi: Yapı ve dekorasyon platformunda backend ve performans tarafında optimizasyonlar yapıldı; bu çalışma site performansını artırdı.