Birçok startup bunu yaşadı: Her gün çok sayıda yeni kullanıcı kayıt oluyor ve geliştirme ekibi hizmeti çalışır durumda tutmakta zorlanıyor.
Bu hoş bir sorun, ancak web'de bir web uygulamasının sıfırdan yüzbinlerce kullanıcıya kadar dikkatli bir şekilde nasıl ölçeklendirileceği hakkında çok az net bilgi var. Tipik olarak ya yangın çözümleri ya da darboğaz çözümleri (ve çoğunlukla her ikisi) vardır. Bu nedenle insanlar amatör projelerini gerçekten ciddi bir şeye dönüştürmek için oldukça klişe teknikler kullanıyorlar.
Bilgileri filtrelemeye çalışalım ve temel formülü yazmaya çalışalım. Yeni fotoğraf paylaşım sitemiz Graminsta'nın kullanıcı sayısını adım adım 1'den 100'e çıkaracağız.
Hedef kitle 10, 100, 1000, 10 ve 000 kişiye çıktığında hangi spesifik aksiyonların alınması gerektiğini yazalım.
1 kullanıcı: 1 makine
İster web sitesi ister mobil uygulama olsun hemen hemen her uygulamanın üç temel bileşeni vardır:
- API
- база данных
- istemci (mobil uygulamanın kendisi veya web sitesi)
Veritabanı kalıcı verileri saklar. API, bu verilere ve bu verilere yönelik istekleri sunar. İstemci kullanıcıya veri iletir.
Mimari açıdan bakıldığında istemci ve API varlıkları tamamen ayrılmışsa, bir uygulamayı ölçeklendirmekten bahsetmenin çok daha kolay olduğu sonucuna vardım.
Bir uygulamayı ilk oluşturmaya başladığımızda, üç bileşenin tümü aynı sunucuda çalıştırılabilir. Bazı açılardan bu bizim geliştirme ortamımıza benziyor: bir mühendis veritabanını, API'yi ve istemciyi aynı makinede çalıştırıyor.
Teorik olarak, bunu aşağıda gösterildiği gibi bulutta tek bir DigitalOcean Droplet veya AWS EC2 örneğinde dağıtabiliriz:
Bununla birlikte, bir sitede birden fazla kullanıcı olacaksa, bir veritabanı katmanı tahsis etmek neredeyse her zaman mantıklıdır.
10 kullanıcı: veritabanını ayrı bir seviyeye taşıma
Veritabanını Amazon RDS veya Digital Ocean Managed Database gibi yönetilen hizmetlere bölmek uzun süre işimize yarayacaktır. Tek bir makinede veya EC2 örneğinde kendi kendini barındırmaktan biraz daha pahalıdır, ancak bu hizmetlerle gelecekte işinize yarayacak pek çok yararlı uzantıya sahip olursunuz: çok bölgeli yedekleme, okuma kopyaları, otomatik yedeklemeler ve daha fazlası.
Sistem şu anda böyle görünüyor:
100 kullanıcı: istemciyi ayrı bir düzeye taşıma
Neyse ki ilk kullanıcılarımız uygulamamızı çok beğendiler. Trafik daha istikrarlı hale geliyor, bu nedenle istemciyi ayrı bir düzeye taşımanın zamanı geldi. bu not alınmalı ayırma Varlıklar, ölçeklenebilir bir uygulama oluşturmanın önemli bir yönüdür. Sistemin bir kısmı daha fazla trafik aldığında, hizmetin belirli trafik kalıplarına göre nasıl ölçekleneceğini kontrol etmek için onu bölümlere ayırabiliriz.
Bu yüzden istemciyi API'den ayrı olarak düşünmeyi seviyorum. Bu, birden fazla platform için geliştirme yapmayı düşünmeyi çok kolaylaştırır: web, mobil web, iOS, Android, masaüstü uygulamaları, üçüncü taraf hizmetler vb. Bunların hepsi yalnızca aynı API'yi kullanan istemcilerdir.
Örneğin, artık kullanıcılarımız çoğunlukla bir mobil uygulamanın yayınlanmasını istiyor. İstemci ve API varlıklarını ayırırsanız bu daha kolay olur.
Böyle bir sistem şöyle görünür:
1000 kullanıcı: yük dengeleyici ekleyin
İşler iyiye gidiyor. Graminsta kullanıcıları giderek daha fazla fotoğraf yüklüyor. Kayıt sayısı da artıyor. Yalnız API sunucumuz tüm trafiğe ayak uydurmakta zorlanıyor. Daha fazla demire ihtiyacınız var!
Yük dengeleyici çok güçlü bir kavramdır. Ana fikir, API'nin önüne bir yük dengeleyici koymamız ve bunun trafiği bireysel hizmet örneklerine dağıtmasıdır. Yatay olarak bu şekilde ölçeklendiriyoruz; bu, aynı koda sahip daha fazla sunucu ekleyerek işleyebileceğimiz isteklerin sayısını artırdığımız anlamına gelir.
Web istemcisinin önüne ve API'nin önüne ayrı yük dengeleyiciler yerleştireceğiz. Bu, API kodunu ve web istemci kodunu çalıştıran birden fazla örneği çalıştırabileceğiniz anlamına gelir. Yük dengeleyici, istekleri daha az yüklü olan sunucuya yönlendirecektir.
Burada bir başka önemli avantaj daha elde ediyoruz: fazlalık. Bir örnek başarısız olduğunda (aşırı yüklendiğinde veya çöktüğünde), gelen isteklere yanıt vermeye devam eden diğer örneklerle baş başa kalırız. Çalışan tek bir örnek olsaydı, arıza durumunda tüm sistem çökerdi.
Yük dengeleyici ayrıca otomatik ölçeklendirme sağlar. Yoğun yükten önce örnek sayısını artıracak, tüm kullanıcılar uyurken azaltacak şekilde yapılandırabiliriz.
Bir yük dengeleyiciyle API düzeyi neredeyse süresiz olarak ölçeklendirilebilir; istek sayısı arttıkça yeni örnekler eklenebilir.
Not. Şu anda sistemimiz, AWS'deki Heroku veya Elastic Beanstalk gibi PaaS şirketlerinin kullanıma hazır sunduklarına çok benziyor (bu yüzden bu kadar popülerler). Heroku, veritabanını ayrı bir ana bilgisayara yerleştirir, otomatik ölçeklendirmeli bir yük dengeleyiciyi yönetir ve web istemcisini API'den ayrı olarak barındırmanıza olanak tanır. Bu, Heroku'yu erken aşamadaki projeler veya girişimler için kullanmak için harika bir neden; tüm temel hizmetleri kutudan çıkarırsınız.
10 kullanıcı: CDN
Belki de bunu en başından beri yapmalıydık. İsteklerin işlenmesi ve yeni fotoğrafların kabul edilmesi sunucularımıza çok fazla yük getirmeye başlıyor.
Bu aşamada, statik içeriği (görüntüler, videolar ve çok daha fazlası) depolamak için bir bulut hizmeti kullanmanız gerekir (AWS S3 veya Digital Ocean Spaces). Genel olarak API'miz, görüntülerin sunulması ve görüntülerin sunucuya yüklenmesi gibi işlemlerden kaçınmalıdır.
Bulut barındırmanın bir başka avantajı da CDN'dir (AWS bu eklentiye Cloudfront adını verir, ancak birçok bulut depolama sağlayıcısı bunu kutudan çıktığı gibi sunar). CDN, görüntülerimizi dünya çapındaki çeşitli veri merkezlerinde otomatik olarak önbelleğe alır.
Ana veri merkezimiz Ohio'da bulunsa da, birisi Japonya'dan bir görüntü talep ederse, bulut sağlayıcı bir kopya oluşturacak ve bunu kendi Japon veri merkezinde saklayacaktır. Japonya'da bu görüntüyü talep eden bir sonraki kişi, onu çok daha hızlı bir şekilde alacaktır. Fotoğraf veya video gibi indirilmesi ve tüm dünyaya iletilmesi uzun zaman alan büyük dosyalarla çalışırken bu önemlidir.
100 kullanıcı: veri katmanını ölçeklendirme
CDN'in çok faydası oldu: trafik tüm hızıyla artıyor. Ünlü video blog yazarı Mavid Mobrick aramıza yeni kaydoldu ve dedikleri gibi “hikayesini” yayınladı. Yük dengeleyici sayesinde API sunucularındaki CPU ve bellek kullanımı düşük tutuluyor (on API örneği çalışıyor), ancak isteklerde çok fazla zaman aşımı yaşamaya başlıyoruz... bu gecikmeler nereden geliyor?
Metrikleri biraz incelediğimizde veritabanı sunucusundaki CPU'nun %80-90 oranında yüklü olduğunu görüyoruz. Sınırdayız.
Veri katmanını ölçeklendirmek muhtemelen denklemin en zor kısmıdır. API sunucuları durum bilgisi olmayan isteklere hizmet eder, bu nedenle daha fazla API örneği ekleriz. Burun çoğunlukla veritabanları bunu yapamaz. Popüler ilişkisel veritabanı yönetim sistemlerinden (PostgreSQL, MySQL vb.) bahsedeceğiz.
Önbelleğe almak
Veritabanımızın performansını artırmanın en kolay yollarından biri yeni bir bileşeni eklemektir: önbellek katmanı. En yaygın önbelleğe alma yöntemi, Redis veya Memcached gibi bellek içi anahtar/değer kayıt deposudur. Çoğu bulutta şu hizmetlerin yönetilen bir sürümü bulunur: AWS'de Elasticache ve Google Cloud'da Memorystore.
Bir hizmet aynı bilgiyi almak için veritabanına çok sayıda tekrarlanan çağrı yaptığında önbellek kullanışlıdır. Temel olarak veritabanına yalnızca bir kez erişiriz, bilgileri önbellekte saklarız ve ona bir daha dokunmayız.
Örneğin Graminsta hizmetimizde birisi Mobrik yıldızının profil sayfasına her gittiğinde, API sunucusu bu kişinin profilinden bilgi almak için veritabanını sorgular. Bu tekrar tekrar oluyor. Mobrik'in profil bilgileri her istekte değişmediğinden önbellekleme için mükemmeldir.
Sonuçları Redis'teki veritabanından anahtarla önbelleğe alacağız user:id Geçerlilik süresi 30 saniyedir. Artık birisi Mobrik'in profiline gittiğinde öncelikle Redis'i kontrol ediyoruz ve eğer veri oradaysa doğrudan Redis'ten aktarıyoruz. Artık sitedeki en popüler profile yapılan istekler pratikte veritabanımızı yüklemiyor.
Çoğu önbellekleme hizmetinin bir diğer avantajı da ölçeklendirmenin veritabanı sunucularına göre daha kolay olmasıdır. Redis'in yerleşik bir Redis Küme modu vardır. Yük dengeleyiciye benzerRedis önbelleğinizi birden fazla makineye (gerekirse binlerce sunucuya) dağıtmanıza olanak tanır.
Hemen hemen tüm büyük ölçekli uygulamalar önbelleğe almayı kullanır; bu, hızlı bir API'nin kesinlikle ayrılmaz bir parçasıdır. Daha hızlı sorgu işleme ve daha verimli kod önemlidir, ancak önbellek olmadan bir hizmeti milyonlarca kullanıcıya ölçeklendirmek neredeyse imkansızdır.
Kopyaları Oku
Veritabanına yapılan sorguların sayısı büyük ölçüde arttığında yapabileceğimiz bir şey daha veritabanı yönetim sistemine okuma replikaları eklemektir. Yukarıda açıklanan yönetilen hizmetlerle bu, tek tıklamayla yapılabilir. Okuma kopyası ana veritabanında güncel kalacaktır ve SELECT ifadeleri için kullanılabilir olacaktır.
Şimdi sistemimiz şu şekilde:
Sonraki Adımlar
Uygulama ölçeklenmeye devam ettikçe hizmetleri bağımsız olarak ölçeklendirmek için ayırmaya devam edeceğiz. Örneğin Websockets kullanmaya başlarsak Websockets işleme kodunu ayrı bir hizmete çekmek mantıklı olacaktır. Bunu, açık Websockets bağlantılarına göre ve HTTP isteklerinin sayısına bakılmaksızın ölçeklendirebilen kendi yük dengeleyicimizin arkasındaki yeni örneklere yerleştirebiliriz.
Ayrıca veritabanı düzeyindeki kısıtlamalarla da mücadele etmeye devam edeceğiz. Bu aşamada veritabanı bölümleme ve parçalamayı incelemenin zamanı geldi. Her iki yaklaşım da ek yük gerektirir ancak veritabanını neredeyse süresiz olarak ölçeklendirmenize olanak tanır.
Ayrıca New Relic veya Datadog gibi bir izleme ve analiz hizmeti kurmak istiyoruz. Bu, yavaş sorguları belirlemenize ve nerede iyileştirme gerektiğini anlamanıza yardımcı olacaktır. Ölçeklendirirken, genellikle önceki bölümlerdeki bazı fikirleri kullanarak darboğazları bulmaya ve bunları ortadan kaldırmaya odaklanmak istiyoruz.
kaynaklar
Bu yazı bunlardan birinden ilham almıştır . Makaleyi projelerin ilk aşamalarına biraz daha spesifik hale getirmek ve onu tek bir satıcıdan ayırmak istedim. Bu konuya ilginiz varsa mutlaka okuyun.
dipnotları
- Birden çok örnekte yük dağıtımı açısından benzer olsa da Redis kümesinin temeldeki uygulaması, yük dengeleyiciden çok farklıdır.
Kaynak: habr.com