En az bir düzine kez oynanışını izlediğim bir desen var. Bir ekip hızlı geliştirme yapar, ilk müşterileri kazanır ve kurucu bana planın "oraya vardığımızda ölçeği dert etmek" olduğunu söyler. Sonra oraya varırlar. Bir lansman hafta sonunda trafik üçe katlanır, veritabanı zaman aşımına uğramaya başlar ve birdenbire üç mühendis gece 2'de uyanık, şemanın asla desteklemek üzere tasarlanmadığı bir önbellek katmanını üzerine cıvatalamaya çalışır. Ardından gelen yeniden yazım, altı aya ve ekibin birbirine olan güveninin bir kısmına mal olur.
Ölçeklenebilirlik, sayılar korkutucu hâle geldiğinde çevirdiğiniz bir anahtar değildir. Sistem hâlâ ucuza değiştirilebilecek kadar küçükken verdiğiniz — ya da veremediğiniz — bir dizi karardır.
"Sonradan ekleriz" efsanesi
Rahatlatıcı hikâye şöyle gider: basit sürümü şimdi inşa et, talep ortaya çıktığında yeniden mimari kuracak gelire ve iş gücüne sahip olacaksın. Sorun şu ki ölçek kibarca gelmez. Bir olay olarak gelir. Ve siz yangınla boğuşurken, sizi kıstıran kararların ta kendileri — her servisin uzandığı paylaşılan bir veritabanı, istek yollarına dikilmiş senkron çağrılar, tek bir sunucuya yapıştırılmış durum bilgisi (state) — taşıyıcı hâle gelmiştir. Onları, her şey yerinden oynamadan çekip çıkaramazsınız.
Açık olmak gerekirse, spekülatif karmaşıklığı savunmuyorum. 40 kullanıcılı bir uygulama için Kubernetes ve olay kaynaklama (event sourcing) inşa etmek, kendine has bir tür kötü uygulamadır. Mesele, daha ilk gün ölçek için inşa etmek değildir. Mesele, o seçeneği baştan kapatmaktan kaçınmaktır. Bunlar çok farklı disiplinlerdir ve onları karıştırmak, ekiplerin nasıl olup da ya aşırı mühendislikle ya da kıstırılmış hâlde son bulduğunun cevabıdır.
Boyut için değil, dikişler için tasarlayın
Bir sistemin büyüyüp büyüyemeyeceğini belirleyen kararlar neredeyse hiçbir zaman ham beygir gücüyle ilgili değildir. Sınırları nereye koyduğunuzla ilgilidir. Danışmanlık çalışmalarımda, işin çoğunu birkaç seçimin yaptığını gördüm:
- Kenarlarda durumsuzluk (statelessness). Bir istek, bir öncekini hangisinin işlediğini umursamadan herhangi bir örnek tarafından karşılanabiliyorsa, makineler ekleyerek yatay olarak ölçekleyebilirsiniz. Bir kullanıcının oturumunu belirli bir sunucuya sabitlerseniz, tavanınızı sessizce sınırlamış olursunuz.
- Veri sınırlarınıza sahip çıkın. Gördüğüm en pahalı tek hata, birçok servisin tek bir veritabanını paylaşması ve birbirinin tablolarına uzanmasıdır. Bir yıl boyunca verimli hisseder. Sonra kimse ekipler arası bir toplantı olmadan bir şema değiştiremez ve veritabanı, hiçbir şeyin geçemeyeceği darboğaz hâline gelir.
- Yavaş işleri erkenden asenkron yapın. Bir e-posta göndermek, bir rapor üretmek, bir videoyu dönüştürmek — eğer isteğin içinde gerçekleşmesi gerekmiyorsa, onu bir kuyruğa itin. Bir kuyruğu iş işten geçtikten sonra sonradan eklemek, her şeyin anlık olduğunu varsayan bir mantığı çözmek demektir.
- Bir alışkanlık olarak idempotentlik. Yeniden denemeleriniz, kuyruklarınız ya da birden fazla örneğiniz olduğu an, işlemler iki kez çalışacaktır. Yazma işlemlerini, iki kez çalıştırılmaları zararsız olacak biçimde tasarlayın; böylece bütün bir ölçekleme hatası kategorisi asla yazılmamış olur.
Sistem küçükken bunların hiçbiri anlamlı bir zamana mal olmaz. Trafik mevcut davranışa bağımlı hâle geldiğinde ise hepsini devreye sokmak acımasızca pahalıdır.
Darboğaz neredeyse her zaman veritabanıdır
Uygulama sunucuları kolaydır — daha fazlasını eklersiniz. Veritabanı ise büyümenin ölmeye gittiği yerdir ve ekiplerin üzerinde en az düşündüğü katmandır. İhtiyaç duymadan çok önce yerinde olmasını isteyeceğim birkaç şey:
Modelinizi seçmeden önce erişim desenlerinizi bilin
Çoğu ölçekleme sıkıntısı, verinin nasıl okunduğuna değil, nasıl göründüğüne göre optimize edilmiş bir şemaya dayanır. Gerçek sorgularınız için dizin oluşturun. Okumaların baskın olduğu yerlerde bilinçli olarak normalizasyonu bozun (denormalize). Ve belirli bir veri parçasının bir doğruluk kaynağı mı yoksa onun bir önbelleği mi olduğuna erkenden karar verin — bu ikisini birbirine karıştırmak, yeniden üretemediğiniz hataları nasıl elde ettiğinizin cevabıdır.
Okumalar ve yazmalar aynı şekilde ölçeklenmez
Okuma kopyaları (read replica), önbellekleme ve CDN'ler size ucuza muazzam bir okuma alanı kazandırır. Yazmalar ise daha zordur ve eninde sonunda gerçek seçimler dayatır — parçalama (sharding), bölümleme (partitioning) ya da neyin güçlü tutarlı olması gerektiğini yeniden düşünme. Önce hangi baskıya çarpacağınızı bilmek, dikkatinizi nereye harcayacağınızı size söyler.
Ölçeklenebilirlik nadiren bir performans sorunudur. O, bir performans sorununun kılığına girmiş bir bağımlılık (coupling) sorunudur.
Pazartesi nereden başlamalı
Yeniden bir mimariye ihtiyacınız yok. Yük, dikişlerinizi sizin yerinize bulmadan önce onların nerede olduğunu bilmeniz gerekiyor. Üç somut hamle:
- Gerçek bağımlılık haritasını çizin. Hangi servisler hangi veri depolarına dokunuyor? Paylaşılan her tablo, gelecekteki bir bağımlılık sorunudur — onları çözmek ucuzken şimdi işaretleyin.
- Bir kez, çökene kadar yük testi yapın. Bir kıyaslamayı (benchmark) geçmek için değil — kırılan ilk şeyi bulmak için. Bu, neredeyse hiçbir zaman ekibin tahmin ettiği şey değildir. Artık kaygı yerine, gerçek ve sıralanmış bir listeniz var.
- Büyüme varsayımınızı yazın. "18 ayda 10 kat kullanıcı" ile "ara sıra ani yükselmelerle istikrarlı" tamamen farklı mimariler gerektirir. Çoğu ekip kendisininkini hiç yüksek sesle söylememiştir, bu yüzden hiçbiri için tasarlamazlar.
Büyüme için mimari kurmak, gereksiz süsleme (gold-plating) değildir. Bugün, gelecekteki hâlinizin geri alamayacağı kararları vermeyi reddetmektir. O seçenekliliği satın almak için en iyi zaman, neredeyse bedava olduğu andır — yani, şimdi.
Sisteminize bakın ve tek bir soru sorun: Pazartesi 10 kat trafik getirseydi ilk ne kırılırdı — ve bunu gerçekten biliyor musunuz, yoksa tahmin mi ediyorsunuz?