Lansman Sonrası Bir SaaS'ı Ürünü Kırmadan Ölçeklemek

Herkes lansmanı kutlar. Neredeyse hiç kimse sonrasında geleni anlatmaz — ilk yüz müşterinizi getiren ürünün, sonraki binin ağırlığı altında bükülmeye başladığı o tuhaf, avuç terleten yıl. Dramatik bir şey olmaz. Şeyler sadece yavaşlar, kırılganlaşır, değiştirmesi zorlaşır. Bir salı günü, eskiden bir gün süren bir özelliğin artık bir hafta aldığını fark edersiniz ve kimse nedenini tam söyleyemez. Çoğu SaaS ürünü lansmanda değil, işte orada sessizce kazanılır ya da kaybedilir.

Tam bu noktada birçok kurucuyla oturduk. Başarısız değiller — kafa karıştıran da bu. Gelir artıyor, ekip büyüyor, demolar iyi geçiyor. Ama altta ürün inliyor. Destek talepleri kullanıcılardan hızlı tırmanıyor. Eskiden sıkıcı olan dağıtımlar artık nefes tutarak yapılıyor. Bir yıl önce zekice görünen kod tabanı, artık her değişikliğin başka bir şeyi tetikleme riski taşıdığı bir mayın tarlasına benziyor. Yanlış bir şey yapmadılar. Sadece inşa ettikleri şeyi aştılar ve kimse onlara bunun olması gerektiğini söylemedi.

İşte bu, çatlaklar belirmeden önce daha çok kurucunun keşke elinde olsaydı dediğimiz kılavuz. Aşırı ölçek, Kubernetes ya da bir tek boynuzlu atın elli milyon kullanıcıda ne yaptığıyla ilgili değil. Sıkıcı ve belirleyici orta kısımla ilgili — birkaç kişi için çalışıyor'dan çok kişi için çalışıyor'a geçmek — her şeyi baştan yazmadan, müşterilerinizi korkutmadan ya da ekibinizi tüketmeden. Amaç kusursuz bir mimari değil. Sessizce kırılmaya başlayan değil, büyümeye devam eden bir ürün.

Bir SaaS büyüdüğünde gerçekte ne kırılır

Kurucuları en çok şaşırtan kısım şu: ölçekleme sorunları neredeyse hiçbir zaman, kendinizi hazırladığınız dramatik kesinti olarak gelmez. Sunucu alev almaz. Bunun yerine ürün bir tür hafif ateş geçirir. Anında yüklenen sayfalar üç saniye almaya başlar. İlk müşteriler için sorunsuz çalışan bir rapor, yeni imza atan büyük müşteride zaman aşımına uğrar. Aynı hata sürekli geri döner çünkü kodun iki parçası, kimsenin belgelemediği bir biçimde gizlice birbirine bağlıdır.

Gerçekte kırılan nadiren sunucularınızdır — varsayımlarınızdır. Başta ilk kullanıcılarınızın şekline göre inşa ettiniz: birkaç hesap, küçük veri, basit iş akışları, herkes aşağı yukarı aynı. Büyüme yalnızca aynısından daha fazlasını eklemez. Çeşitlilik ekler. On kat verisi olan bir müşteri. Bir özelliği hiç hayal etmediğiniz biçimde kullanan bir ekip. Pazartesi sabah dokuzda herkesin aynı anda giriş yaptığı bir tepe. Her biri, bir yıl önce ihlal etmenin düşünülemez olduğu, koda gömülü bir varsayımı sessizce ihlal eder.

İlk olarak gösterdiği dört yer öngörülebilirdir. Veritabanı neredeyse her zaman maden kuşudur — küçük tablolarda anında çalışan sorgular, veri büyüdükçe sürünmeye başlar. Yavaş uç nokta: istek başına çok fazla iş yapan bir iki sayfa, trafik birikene kadar sorunsuz. Kırılgan dağıtım, kod akıl yürütülemeyecek kadar karmaşıklaştığı için herhangi bir şeyi göndermenin korkutucu hâle geldiği yer. Ve destek yükü, ki hiç altyapı değildir ama ürünün artık insanların onu gerçekte nasıl kullandığına uymadığının en doğru erken işaretidir.

Henüz sahip olmadığınız sorunları çözme tuzağı

Düzeltmeyi konuşmadan önce, herhangi bir optimizasyondan daha çok ürün kurtarmış bir uyarı. Büyüyen bir SaaS için en büyük tehdit ölçeği görmezden gelmek değildir — onu çok erken kovalamaktır. Bir kurucu ilk yavaşlamayı hisseder hissetmez, ünlü bir mühendislik blogunda okuduğu mimariye uzanma içgüdüsü duyar. Mikroservisler. Bir mesaj kuyruğu. Çok bölgeli bir kurulum. Veritabanını, içinde bir milyon satır olmadan parçalamak.

Ulaşmadığınız bir ölçek için altyapı inşa ederek altı ay ve bir servet harcarsınız, bu sırada asıl ürün durur. Daha kötüsü, her gelecekteki değişikliği zorlaştırmış olursunuz, çünkü dağıtık bir sistem, sahip olduğunuz basit olandan inşa ve hata ayıklama açısından çok daha karmaşıktır. Henüz sahip olmadığınız bir sorunu, bugün sahip olduğunuz garanti bir sorunla takas ettiniz: hiçbir şey gönderilmiyor.

Buradaki disiplin, en başta iyi ürünleri yapan disiplinin aynısıdır: önünüzdeki sorunu çözün, hayal etmekten gurur duyduğunuzu değil. Hızlıca değiştirebileceğiniz sıkıcı, iyi anlaşılmış bir monolit, dokunmaya korktuğunuz moda bir dağıtık sistemden ölçekte üstün gelecektir. Karmaşıklık her gün ödediğiniz bir maliyettir, tek seferlik bir alım değil.

Herhangi bir şeyi değiştirmeden önce ölçün

Bu aşamada karşılaştığımız neredeyse her kurucu sorunun nerede olduğunu bildiğine emindir. Yaklaşık yarı yarıya yanılırlar — dikkatsiz oldukları için değil, sezgi berbat bir profilleyici olduğu için. Yavaş hissettiren kod parçası genelde sorunsuzdur; gerçek suçlu, kimsenin düşünmediği bir sayfada kırk kez çalışan sessiz bir sorgudur. Ölçmediğiniz şeyi düzeltemezsiniz ve burada tahmin yürütmek, ekiplerin haftalarca yanlış şeyi optimize etmesinin yoludur.

Başlamak için süslü bir gözlemlenebilirlik yığınına ihtiyacınız yok. Önünüzde, her zaman, üç sıkıcı sayıya ihtiyacınız var. Hangi uç noktalar en yavaş ve gerçek trafik altında ne kadar yavaş. Hangi veritabanı sorguları en çok toplam zamanı alıyor — en yavaş tek sorgu değil, zamanı binlerce çağrı boyunca biriken sorgu. Ve hataların gerçekte nerede gerçekleştiği, onları yeniden üretmeye yetecek bağlamla. Bu üçüyle sis genelde bir gün içinde dağılır.

1. 1
   Temel izlemeyi açın

   Uç nokta başına yanıt süreleri, hata oranları ve veritabanında yavaş sorgu kaydı. Barındırılan araçlar bunu bir öğleden sonrada yapar. Göremediğiniz bir sayıyı iyileştiremezsiniz.
2. 2
   Gerçek ilk üçü bulun

   İçgüdüye göre değil, harcanan toplam zamana göre sıralayın. Üç suçlu neredeyse her zaman acının çoğunu oluşturur. Onları yazın — gerçek yol haritanız budur.
3. 3
   Birini düzeltin, tekrar ölçün

   Tek bir şeyi değiştirin, sonra sayıları yeniden kontrol edin. Devam etmeden önce yardımcı olduğunu doğrulayın. Aynı anda iki değişiklik yaparsanız hangisinin önemli olduğunu asla bilemezsiniz.
4. 4
   Yeterince iyi olduğunda durun

   Başlamadan önce 'yeterince hızlı'yı tanımlayın — diyelim ki mevcut yükte her sayfa bir saniyenin altında. Onun ötesinde optimizasyon bir zaman kaybıdır, kazanç değil.

O son adım göründüğünden daha önemlidir. Performans çalışması gerçekten bağımlılık yapar; tıraşlanacak başka bir milisaniye hep vardır. Ama müşterileriniz 200 ms ile 120 ms arasındaki farkı hissetmez ve onu kovalamak için harcadığınız saatler, işi gerçekten büyütecek özelliğe harcanmayan saatlerdir. Ölçün, ilk üçü düzeltin, zaferi ilan edin, devam edin.

Veritabanı neredeyse her zaman ilk duvardır

Büyüyen bir SaaS'ın ilk gerçek tavanına nerede çarpacağına para yatırmamız gerekseydi, her seferinde veritabanına yatırırdık. Küçük erken kararların en sert biçimde biriktiği tek sistem parçası odur. İndeksi olmayan bir sorgu, bin satırda göz açıp kapayıncaya kadar çalışır ve bir milyonda durma noktasına gelir. Kod değişmedi. Veri değişti — ve veri yalnızca büyür.

İyi haber şu ki veritabanı aynı zamanda en ucuz, en yüksek etkili düzeltmelerin yaşadığı yerdir. Klasik olanı eksik indekstir: çok saniyelik bir sorguyu anında yapan tek bir satır, çünkü veritabanı ihtiyaç duyduğu birkaçı bulmak için her satırı taramayı bırakır. Hemen arkasında N+1 sorgu sorunu gelir — bir soru sormak yerine veritabanına aynı küçük soruyu bir döngüde yüzlerce kez sessizce soran bir sayfa. İkisi de yaygındır, ikisi de bakana kadar görünmezdir ve ikisi de bulduğunuzda genelde bir günlük düzeltmedir.

Burada güvenilecek bir sıra vardır ve sona atlamak yerine sırayla izlemek işe yarar. Önce sorguları düzeltin — indeksler, N+1'ler, yavaş rapor. Sonra sürekli okunan ama nadiren değişen veri için önbellekleme ekleyin. Ancak ondan sonra okuma kopyaları, daha büyük örnekler ya da veriyi ayırmak hakkında konuşmak mantıklı olur. Çoğu SaaS ürünü sonraki adımlara hiç ihtiyaç duymaz. Sadece ilklerin düzgün yapılmasına ihtiyaçları vardı.

Ürünü ölçeklemek, onu nasıl değiştirdiğinizi ölçeklemektir

Kurucuları gafil avlayan değişim şu: belli bir noktadan sonra ölçekleme, ürünün daha çok kullanıcıyı kaldırmasıyla ilgili olmaktan çıkar ve ekibinizin daha çok değişimi kaldırmasıyla ilgili olmaya başlar. Siz ve bir geliştirici olduğunuzda, herkes tüm sistemi kafasında tutardı. Her şeyi değiştirebilirdiniz çünkü neye dokunacağını biliyordunuz. Beş ya da on kişide bu zihinsel model paramparça olur — ve herkesin her şeyi bildiğini varsayan kod bir yüke dönüşür.

Dağıtımların korkutucu hâle gelmesinin asıl nedeni budur. Kod bir gecede kötüleşmedi; artık kimse bir değişikliğin patlama yarıçapını tam tahmin edemiyor. Çözüm kahramanlık ya da göndermeyi dondurmak değildir. Daha büyük bir ekibin birbirine basmadan hareket etmesini sağlayan o gösterişsiz iskeleye yatırım yapmaktır: bariz bozulmayı yakalayan otomatik bir test paketi, tören değil rutin olan dağıtımlar ve kötü bir sürümü telaşlanmak yerine saniyeler içinde kapatmanın bir yolu.

• Kırılırsa felaket olacak az sayıda akışı kapsayan bir test paketi — giriş, ödeme, çekirdek eylem. Her şey değil; kritik birkaçı.
• Tören değil bir düğmeyle çalışan dağıtımlar, böylece küçük ve sık göndermek sinir bozucu yerine güvenli olur.
• Geri almanın hızlı bir yolu, böylece kötü bir sürüm bir gece boyu süren olay değil, beş dakikalık bir olay olur.
• Özellik bayrakları, böylece kodu önce birkaç müşteriye gönderip yanlış davranırsa anında kapatabilirsiniz.
• Bir kişinin tatilinin ürünün tüm bir alanını dondurmamasına yetecek kadar belgeleme.

Bunların hiçbiri bir demoda görünmez. Hiçbiri doğrudan bir özellik eklemez. Ve hızlanmaya devam eden bir ürünü, her yeni işe alımla yavaşlayan birinden ayıran tam da bu iştir. İyi ölçeklenen ekipler, ürünü güvenle değiştirme yeteneklerini başlı başına bir özellik olarak ele alanlardır — çünkü ölçekte o tam olarak budur.

Çatlama noktasından kısa bir hikâye

Bunu somutlaştırmak için, yaptığımız bir işten derlenmiş bir örnek — ayrıntılar bulanıklaştırılmış, biçim gerçeğe sadık. Saha hizmet ekiplerini yönetmek için küçük bir SaaS, iyi bir lansman yapmış ve birkaç yüz ücretli şirkete büyümüştü. Kurucular aynı ölçüde hem mutlu hem bitkindi. Sonra şimdiye dek en büyük müşterileri imza attı: önceki on müşterisinin toplamından daha çok kullanıcısı ve daha çok geçmiş verisi olan bir firma.

Bir hafta içinde, herkesin içinde yaşadığı kontrol paneli o müşteri için — ve tuhaf biçimde herkes için de — sürünmeye yavaşladı. Destek talepleri fırladı. Kurucular çok daha büyük bir sunucuya ihtiyaçları olduğunu varsaydılar ve acılı, pahalı bir yeniden mimariye hazırlanıyorlardı. Bizim devreye girdiğimiz an buydu ve içgüdü anlaşılırdı ama yanlıştı.

Mimariye dokunmadık. Yavaş sorgu kaydını açtık ve bir öğleden sonra izledik. Suçlu neredeyse utandıracak kadar küçüktü: ana kontrol paneli her kullanıcının iş listesini klasik bir N+1 deseniyle, iş başına bir sorgu ateşleyerek yüklüyordu. Küçük bir müşteri için bu birkaç düzine zararsız sorgu demekti. Yeni dev için ise sayfa yüklemesi başına binlerce demekti — ve bu, paylaşımlı altyapıda tüm sistemi herkes için aşağı çekti.

Kurucuların çıkardığı ders teknik değildi. Hayal ettikleri o korkunç ölçekleme sorununun — yeniden inşa ve fon turu gerektiren — ölçüldüğünde, korkutucu bir belirtinin ardına saklanan iki günlük bir düzeltme olduğuydu. Aylarca yanlış sorunu çözmek üzereydiler. Hayal edilen kriz ile ölçülen arasındaki o boşluk, çoğu ölçekleme parasının boşa harcandığı yerdir.

Bir parçayı yeniden inşa etmenin gerçekten zamanı geldiğinde

Erken ölçekleme konusundaki tüm bu temkin, asla yeniden düzenleme, asla yeniden inşa etme gibi okunabilir. Mesele bu değil. Bazen ürünün bir parçası gerçekten ömrünün sonuna gelmiştir ve onu tekrar yamamak pahalı seçenektir. İşin püf noktası, gerçek bir yapısal sınır ile ölçülü bir düzeltmenin hallolacağı sıradan büyüme sancılarını ayırt etmektir.

Dürüst işaret şudur: bir bileşeni, onu değiştirme maliyeti değiştirme maliyetinden tutarlı biçimde yüksek hâle geldiğinde yeniden inşa edin. Çirkin olduğunda değil — kararlı ve nadiren dokunulan çirkin kod sorun değildir. Her değişikliğin yavaş ve riskli olduğu, aynı hataların geri döndüğü, yeni geliştiricilerin güvenle çalışamadığı ve daha ucuz düzeltmeleri zaten denediğiniz ve bir duvara çarptığınız bir sistem parçası arıyorsunuz. Bunlardan birkaçı aynı anda doğruysa, o tek parçanın odaklı bir yeniden yazımı doğru karardır.

Ve yeniden inşa ettiğinizde, bir parçayı yeniden inşa edin — ürünü değil. Sıfırdan tam yeniden yazma, ölçeklemenin siren şarkısıdır; temiz hissettiren ama rakipler gönderirken bir yılı batırmakla biten şey. Tek çürük bileşeni, net bir sınırın ardında, ürünün geri kalanı çalışıp kazanmaya devam ederken değiştirin. Cerrahi, kahramanca değil.

Sık sorulan sorular