Bir çox startaplar bundan keçdi: hər gün yeni istifadəçilərin izdihamı qeydiyyatdan keçir və inkişaf komandası bu xidməti davam etdirmək üçün mübarizə aparır.

Bu, gözəl problemdir, lakin internetdə bir veb tətbiqini heç bir şeydən yüz minlərlə istifadəçiyə qədər diqqətlə miqyası ilə necə genişləndirmək barədə çox az aydın məlumat var. Tipik olaraq ya yanğın həlləri, ya da darboğaz həlləri (və çox vaxt hər ikisi) var. Buna görə də, insanlar həvəskar layihələrini həqiqətən ciddi bir şeyə çevirmək üçün kifayət qədər klişe üsullardan istifadə edirlər.

Gəlin məlumatları süzgəcdən keçirməyə və əsas düsturu yazmağa çalışaq. Yeni şəkil paylaşma saytımız Graminsta-nı addım-addım 1-dən 100 istifadəçiyə qədər genişləndirəcəyik.

Tamaşaçıların sayı 10, 100, 1000, 10 və 000 min nəfərə yüksəldikdə konkret hansı tədbirlərin görülməsi lazım olduğunu yazaq.

1 istifadəçi: 1 maşın

Demək olar ki, hər bir proqram, istər veb-sayt, istərsə də mobil proqram, üç əsas komponentdən ibarətdir:

• API
• verilənlər bazası
• müştəri (mobil tətbiqin özü və ya veb sayt)

Verilənlər bazası davamlı məlumatları saxlayır. API bu dataya və onun ətrafında sorğulara xidmət edir. Müştəri məlumatı istifadəçiyə ötürür.

Belə nəticəyə gəldim ki, arxitektura baxımından müştəri və API obyektləri tamamilə ayrılarsa, tətbiqin miqyası haqqında danışmaq daha asandır.

Biz ilk dəfə proqram qurmağa başladığımız zaman hər üç komponent eyni serverdə işlədilə bilər. Bəzi cəhətdən bu, bizim inkişaf mühitimizə bənzəyir: bir mühəndis verilənlər bazası, API və müştərini eyni maşında idarə edir.

Teorik olaraq, biz onu buludda bir DigitalOcean Droplet və ya AWS EC2 nümunəsində aşağıda göstərildiyi kimi yerləşdirə bilərik:

Bununla belə, bir saytda birdən çox istifadəçi olacaqsa, verilənlər bazası qatını həsr etmək demək olar ki, həmişə məna kəsb edir.

10 istifadəçi: verilənlər bazasını ayrı səviyyəyə köçürmək

Verilənlər bazasını Amazon RDS və ya Digital Ocean Managed Database kimi idarə olunan xidmətlərə bölmək bizə uzun müddət yaxşı xidmət edəcəkdir. Bu, tək maşında və ya EC2 instansiyasında özünü hostinqdən bir qədər bahadır, lakin bu xidmətlərlə siz gələcəkdə lazımlı olacaq bir çox faydalı uzantılar əldə edirsiniz: çox regionlu ehtiyat nüsxə, oxunmuş replikalar, avtomatik ehtiyat nüsxələri və s.

Sistem indi belə görünür:

100 istifadəçi: müştərini ayrı səviyyəyə köçürmək

Xoşbəxtlikdən, ilk istifadəçilərimiz tətbiqimizi çox bəyəndilər. Trafik getdikcə sabitləşir, buna görə də müştərini ayrı bir səviyyəyə köçürməyin vaxtı gəldi. Qeyd etmək lazımdır ki ayrılıq obyektlər miqyaslana bilən tətbiqin qurulmasının əsas aspektidir. Sistemin bir hissəsi daha çox trafik aldığından, xüsusi trafik nümunələri əsasında xidmətin miqyasına nəzarət etmək üçün onu bölmək olar.

Buna görə müştərini API-dən ayrı hesab etməyi xoşlayıram. Bu, çoxsaylı platformalar üçün inkişaf haqqında düşünməyi çox asanlaşdırır: veb, mobil veb, iOS, Android, masaüstü proqramlar, üçüncü tərəf xidmətləri və s. Onların hamısı eyni API-dən istifadə edən müştərilərdir.

Məsələn, indi istifadəçilərimiz ən çox mobil proqram buraxmağı xahiş edirlər. Müştəri və API obyektlərini ayırsanız, bu daha asan olur.

Belə bir sistem belə görünür:

1000 istifadəçi: yük balanslaşdırıcı əlavə edin

İşlər yuxarıya doğru gedir. Graminsta istifadəçiləri getdikcə daha çox şəkil yükləyirlər. Qeydiyyatdan keçənlərin sayı da artır. Bizim tək API serverimiz bütün trafiklə ayaqlaşmaqda çətinlik çəkir. Daha çox dəmir lazımdır!

Yük balanslaşdırıcısı çox güclü bir konsepsiyadır. Əsas ideya ondan ibarətdir ki, biz API-nin qarşısına yük balanslaşdırıcısı qoyuruq və o, trafiki fərdi xidmət nümunələrinə paylayır. Bu, biz üfüqi şəkildə miqyaslandırırıq, yəni eyni kodla daha çox server əlavə edirik və emal edə biləcəyimiz sorğuların sayını artırırıq.

Biz veb müştərinin qarşısında və API qarşısında ayrı yük balanslaşdırıcıları yerləşdirəcəyik. Bu o deməkdir ki, siz API kodu və veb müştəri kodu ilə işləyən bir neçə nümunəni işlədə bilərsiniz. Yük balanslaşdırıcısı sorğuları daha az yüklənmiş serverə yönləndirəcək.

Burada başqa bir vacib üstünlük əldə edirik - artıqlıq. Bir nümunə uğursuz olduqda (bəlkə də həddən artıq yükləndikdə və ya qəzaya uğradıqda), gələn sorğulara cavab verməyə davam edən digərləri ilə qalırıq. Yalnız bir instansiya işləsəydi, uğursuzluq halında bütün sistem çökərdi.

Yük balanslaşdırıcısı avtomatik miqyaslaşdırmanı da təmin edir. Biz onu pik yüklənmədən əvvəl nümunələrin sayını artırmaq və bütün istifadəçilər yatarkən azaltmaq üçün konfiqurasiya edə bilərik.

Yük balanslaşdırıcısı ilə API səviyyəsi demək olar ki, qeyri-müəyyən müddətə ölçülə bilər, sadəcə olaraq sorğuların sayı artdıqca yeni nümunələr əlavə edilir.

Qeyd. Hal-hazırda sistemimiz AWS-də Heroku və ya Elastic Beanstalk kimi PaaS şirkətlərinin qutudan kənar təklif etdiyinə çox bənzəyir (buna görə də onlar bu qədər populyardırlar). Heroku verilənlər bazasını ayrı bir hosta qoyur, avtomatik miqyaslı yük balanslaşdırıcısını idarə edir və veb müştərini API-dən ayrıca yerləşdirməyə imkan verir. Bu, Heroku-dan ilkin mərhələ layihələri və ya startaplar üçün istifadə etmək üçün əla səbəbdir - siz bütün əsas xidmətləri qutudan çıxarırsınız.

10 istifadəçi: CDN

Bəlkə də bunu əvvəldən etməliydik. Sorğuların işlənməsi və yeni fotoşəkillərin qəbul edilməsi serverlərimizi həddən artıq gərginləşdirməyə başlayır.

Bu mərhələdə statik məzmunu - şəkilləri, videoları və daha çox şeyləri (AWS S3 və ya Digital Ocean Spaces) saxlamaq üçün bulud xidmətindən istifadə etməlisiniz. Ümumiyyətlə, API-miz şəkillərə xidmət etmək və şəkilləri serverə yükləmək kimi işlərdən çəkinməlidir.

Bulud hostinqinin başqa bir üstünlüyü CDN-dir (AWS bu əlavəni Cloudfront adlandırır, lakin bir çox bulud saxlama təminatçıları onu qutudan kənarda təklif edir). CDN şəkillərimizi avtomatik olaraq dünyanın müxtəlif məlumat mərkəzlərində yaddaşda saxlayır.

Əsas məlumat mərkəzimiz Ohayoda yerləşsə də, kimsə Yaponiyadan şəkil tələb edərsə, bulud provayderi onun surətini çıxaracaq və onun Yapon məlumat mərkəzində saxlayacaq. Yaponiyada bu şəkli tələb edən növbəti şəxs onu daha tez alacaq. Bu, fotoşəkillər və ya videolar kimi böyük fayllarla işləyərkən vacibdir ki, onları yükləmək və bütün planetə ötürmək çox vaxt aparır.

100 istifadəçi: məlumat qatının miqyası

CDN çox kömək etdi: trafik tam sürətlə artır. Məşhur videoblogger Mavid Mobrick yenicə qeydiyyatdan keçərək, necə deyərlər, öz “hekayəsini” yerləşdirdi. Yük balanslaşdırıcısı sayəsində API serverlərində CPU və yaddaş istifadəsi aşağı səviyyədə saxlanılır (on API nümunəsi işləyir), lakin biz sorğularda çoxlu fasilələr almağa başlayırıq... bu gecikmələr haradan qaynaqlanır?

Metrikləri bir az qazsaq, verilənlər bazası serverində CPU-nun 80-90% yükləndiyini görürük. Biz limitdəyik.

Məlumat qatının miqyası, ehtimal ki, tənliyin ən çətin hissəsidir. API serverləri vətəndaşlığı olmayan sorğulara xidmət edir, ona görə də biz sadəcə olaraq daha çox API nümunələri əlavə edirik. Burun əksəriyyət verilənlər bazası bunu edə bilməz. Populyar əlaqəli verilənlər bazası idarəetmə sistemləri (PostgreSQL, MySQL və s.) haqqında danışacağıq.

önbelleğe alma

Verilənlər bazamızın performansını artırmağın ən asan yollarından biri yeni komponenti təqdim etməkdir: keş qatı. Ən çox yayılmış keşləmə üsulu Redis və ya Memcached kimi yaddaşdaxili açar-dəyər qeydləri anbarıdır. Əksər buludlarda bu xidmətlərin idarə olunan versiyası var: AWS-də Elasticache və Google Cloud-da Memorystore.

Keş, xidmət eyni məlumatı əldə etmək üçün verilənlər bazasına çoxlu təkrar zənglər etdikdə faydalıdır. Əslində, biz verilənlər bazasına yalnız bir dəfə daxil oluruq, məlumatları keşdə saxlayırıq və ona bir daha toxunmuruq.

Məsələn, Graminsta xidmətimizdə kimsə hər dəfə ulduz Mobrikin profil səhifəsinə daxil olanda API serveri onun profilindən məlumat almaq üçün verilənlər bazasını sorğulayır. Bu, təkrar-təkrar baş verir. Mobrik-in profil məlumatları hər sorğu ilə dəyişmədiyi üçün keşləmə üçün əladır.

Nəticələri Redis-də verilənlər bazasından açarla keş edəcəyik user:id etibarlılıq müddəti 30 saniyə ilə. İndi kimsə Mobrikin profilinə girəndə biz ilk növbədə Redis-i yoxlayırıq və əgər məlumatlar oradadırsa, sadəcə olaraq onu birbaşa Redis-dən ötürürük. İndi saytdakı ən populyar profilə edilən sorğular praktiki olaraq verilənlər bazamızı yükləmir.

Əksər keşləmə xidmətlərinin digər üstünlüyü verilənlər bazası serverlərinə nisbətən onların miqyasının daha asan olmasıdır. Redis-də daxili Redis Cluster rejimi var. Yük balanslaşdırıcısına bənzəyir1, bu, Redis önbelleğinizi birdən çox maşın arasında (lazım olduqda minlərlə server arasında) yaymağa imkan verir.

Demək olar ki, bütün irimiqyaslı proqramlar keşləmədən istifadə edir; bu, sürətli API-nin tamamilə ayrılmaz hissəsidir. Sorğunun daha sürətli işlənməsi və daha məhsuldar kodun hamısı vacibdir, lakin önbellek olmadan bir xidməti milyonlarla istifadəçi üçün genişləndirmək demək olar ki, mümkün deyil.

Replikaları oxuyun

Verilənlər bazasına sorğuların sayı xeyli artdıqda, edə biləcəyimiz başqa bir şey verilənlər bazası idarəetmə sisteminə oxunan replikaları əlavə etməkdir. Yuxarıda təsvir edilən idarə olunan xidmətlərlə bunu bir kliklə etmək olar. Oxunan replika əsas verilənlər bazasında cari olaraq qalacaq və SELECT ifadələri üçün əlçatandır.

Budur bizim sistemimiz:

Sonrakı addımlar

Tətbiq miqyasını genişləndirməyə davam etdikcə, biz onları müstəqil şəkildə genişləndirmək üçün xidmətləri ayırmağa davam edəcəyik. Məsələn, əgər biz Websockets-dən istifadə etməyə başlasaq, onda Websockets emal kodunu ayrı bir xidmətə çəkməyin mənası var. Biz onu açıq Websockets əlaqələri əsasında və HTTP sorğularının sayından asılı olmayaraq böyüyə və aşağı sala bilən öz yük balanslaşdırıcımızın arxasında yeni nümunələrə yerləşdirə bilərik.

Biz həmçinin verilənlər bazası səviyyəsində məhdudiyyətlərlə mübarizə aparmağa davam edəcəyik. Məhz bu mərhələdə verilənlər bazasının bölmələrini və parçalanmasını öyrənmək vaxtıdır. Hər iki yanaşma əlavə məsrəf tələb edir, lakin verilənlər bazasını demək olar ki, qeyri-müəyyən müddətə genişləndirməyə imkan verir.

Biz həmçinin New Relic və ya Datadog kimi monitorinq və analitika xidmətini quraşdırmaq istəyirik. Bu, yavaş sorğuları müəyyən etməyə və təkmilləşdirmənin lazım olduğu yeri anlamağa kömək edəcək. Ölçəyərkən, biz darboğazları tapmağa və onları aradan qaldırmağa diqqət yetirmək istəyirik - tez-tez əvvəlki bölmələrdəki bəzi fikirlərdən istifadə edirik.

İnformasiya qaynaqları

Bu yazı onlardan birindən ilhamlanıb yüksək miqyaslılıq haqqında sevimli yazılarım. Mən məqaləni layihələrin ilkin mərhələləri üçün bir az daha konkretləşdirmək və onu bir satıcıdan ayırmaq istədim. Bu mövzu ilə maraqlanırsınızsa, mütləq oxuyun.

Dipnotlar

1. Bir çox hallarda yük paylanması baxımından oxşar olsa da, Redis klasterinin əsas tətbiqi yük balanslaşdırıcısından çox fərqlidir. [qayıtmaq]

Mənbə: www.habr.com