Daugelis pradedančiųjų tai išgyveno: kiekvieną dieną registruojasi minios naujų vartotojų, o kūrėjų komanda stengiasi, kad paslauga veiktų.
Tai gera problema, tačiau žiniatinklyje yra mažai aiškios informacijos apie tai, kaip kruopščiai padidinti žiniatinklio programos mastelį nuo nieko iki šimtų tūkstančių vartotojų. Paprastai yra arba priešgaisrinių, arba kliūčių problemų sprendimo būdų (ir dažnai abu). Todėl žmonės naudoja gana klišes metodus, kad savo mėgėjų projektą paverstų tikrai rimtu.
Pabandykime filtruoti informaciją ir užrašyti pagrindinę formulę. Žingsnis po žingsnio padidinsime savo naujos dalijimosi nuotraukomis svetainę Graminsta nuo 1 iki 100 000 vartotojų.
Surašykime, kokių konkrečių veiksmų reikia imtis, kai auditorija padidėja iki 10, 100, 1000, 10 000 ir 100 000 žmonių.
1 vartotojas: 1 mašina
Beveik kiekviena programa, nesvarbu, ar tai svetainė, ar programa mobiliesiems, turi tris pagrindinius komponentus:
- API
- duomenų bazėje
- klientas (pati programa mobiliesiems arba svetainė)
Duomenų bazėje saugomi nuolatiniai duomenys. API teikia užklausas šiems duomenims ir aplink juos. Klientas perduoda duomenis vartotojui.
Padariau išvadą, kad daug lengviau kalbėti apie programos mastelio keitimą, jei architektūriniu požiūriu klientas ir API objektai yra visiškai atskirti.
Kai pirmą kartą pradedame kurti programą, visi trys komponentai gali būti paleisti tame pačiame serveryje. Tam tikra prasme tai panašu į mūsų kūrimo aplinką: vienas inžinierius paleidžia duomenų bazę, API ir klientą tame pačiame kompiuteryje.
Teoriškai galėtume jį įdiegti debesyje viename DigitalOcean Droplet arba AWS EC2 egzemplioriuje, kaip parodyta toliau:
Atsižvelgiant į tai, jei svetainėje bus daugiau nei vienas vartotojas, beveik visada prasminga skirti duomenų bazės sluoksnį.
10 vartotojų: duomenų bazės perkėlimas į atskirą lygį
Duomenų bazės padalijimas į valdomas paslaugas, tokias kaip „Amazon RDS“ arba „Digital Ocean Managed Database“, mums puikiai tarnaus ilgą laiką. Tai šiek tiek brangesnis nei savarankiškas priegloba viename kompiuteryje ar EC2 egzemplioriuje, tačiau naudodamiesi šiomis paslaugomis gausite daug naudingų plėtinių, kurie pravers ateityje: kelių regionų atsarginių kopijų kūrimas, kopijų skaitymas, automatinis. atsarginės kopijos ir kt.
Štai kaip dabar atrodo sistema:
100 vartotojų: kliento perkėlimas į atskirą lygį
Laimei, pirmiesiems vartotojams mūsų programa labai patiko. Eismas tampa stabilesnis, todėl laikas perkelti klientą į atskirą lygį. Reikėtų pažymėti, kad atskyrimas subjektai yra pagrindinis aspektas kuriant keičiamo dydžio programą. Kadangi viena sistemos dalis gauna daugiau srauto, galime ją padalinti, kad galėtume valdyti, kaip paslauga keičiasi pagal konkrečius srauto modelius.
Štai kodėl man patinka galvoti apie klientą kaip atskirą nuo API. Dėl to labai lengva galvoti apie kūrimą kelioms platformoms: žiniatinkliui, žiniatinkliui mobiliesiems, iOS, Android, darbalaukio programoms, trečiųjų šalių paslaugoms ir kt. Jie visi yra tik klientai, naudojantys tą pačią API.
Pavyzdžiui, dabar mūsų vartotojai dažniausiai prašo išleisti mobiliąją programą. Jei atskirsite kliento ir API objektus, tai bus lengviau.
Štai kaip atrodo tokia sistema:
1000 vartotojų: pridėkite apkrovos balansavimo priemonę
Reikalai kyla aukštyn. „Graminsta“ vartotojai įkelia vis daugiau nuotraukų. Taip pat auga registracijų skaičius. Mūsų vieninteliam API serveriui sunku neatsilikti nuo viso srauto. Reikia daugiau geležies!
Apkrovos balansavimo priemonė yra labai galinga koncepcija. Pagrindinė idėja yra ta, kad prieš API įdedame apkrovos balansavimo priemonę, kuri paskirsto srautą į atskirus paslaugų egzempliorius. Taip keičiame horizontalų mastelį, tai reiškia, kad pridedame daugiau serverių su tuo pačiu kodu, padidindami užklausų, kurias galime apdoroti, skaičių.
Mes ketiname įdėti atskirus apkrovos balansavimo įrenginius prieš žiniatinklio klientą ir prieš API. Tai reiškia, kad galite paleisti kelis atvejus, kuriuose veikia API kodas ir žiniatinklio kliento kodas. Apkrovos balansavimo priemonė nukreips užklausas į mažiau apkrautą serverį.
Čia gauname dar vieną svarbų pranašumą – atleidimą. Kai vienas egzempliorius sugenda (galbūt perkraunamas arba sugenda), liekame su kitais, kurie ir toliau atsako į gaunamas užklausas. Jei veiktų tik vienas egzempliorius, gedimo atveju sudužtų visa sistema.
Apkrovos balansavimo priemonė taip pat suteikia automatinį mastelio keitimą. Galime jį sukonfigūruoti taip, kad padidėtų atvejų skaičius prieš didžiausią apkrovą ir sumažintų, kai visi vartotojai miega.
Naudojant apkrovos balansavimo priemonę, API lygis gali būti keičiamas beveik neribotą laiką, tiesiog pridedant naujų egzempliorių, kai didėja užklausų skaičius.
Pastaba. Šiuo metu mūsų sistema yra labai panaši į tai, ką „PaaS“ įmonės, pvz., „Heroku“ ar „Elastic Beanstalk“ siūlo AWS (todėl jos tokios populiarios). „Heroku“ įkelia duomenų bazę į atskirą pagrindinį kompiuterį, valdo automatinio mastelio keitimo apkrovos balansavimo priemonę ir leidžia žiniatinklio klientą priglobti atskirai nuo API. Tai puiki priežastis naudoti „Heroku“ ankstyvosios stadijos projektams ar startuoliams – visas pagrindines paslaugas gausite iš karto.
10 000 vartotojų: CDN
Galbūt mes turėjome tai daryti nuo pat pradžių. Užklausų apdorojimas ir naujų nuotraukų priėmimas pradeda per daug apkrauti mūsų serverius.
Šiame etape turite naudoti debesies paslaugą statiniam turiniui – vaizdams, vaizdo įrašams ir dar daugiau – saugoti (AWS S3 arba Digital Ocean Spaces). Apskritai, mūsų API turėtų vengti tokių dalykų kaip vaizdų pateikimas ir vaizdų įkėlimas į serverį.
Kitas debesies prieglobos pranašumas yra CDN (AWS šį priedą vadina „Cloudfront“, tačiau daugelis debesies saugyklos paslaugų teikėjų siūlo jį iš karto). CDN automatiškai saugo mūsų vaizdus įvairiuose duomenų centruose visame pasaulyje.
Nors pagrindinis mūsų duomenų centras gali būti Ohajo valstijoje, jei kas nors paprašys vaizdo iš Japonijos, debesies paslaugų teikėjas padarys kopiją ir išsaugos jį savo Japonijos duomenų centre. Kitas asmuo, kuris paprašys šio vaizdo Japonijoje, gaus jį daug greičiau. Tai svarbu, kai dirbame su dideliais failais, pvz., nuotraukomis ar vaizdo įrašais, kurių atsisiuntimas ir perdavimas visoje planetoje trunka ilgai.
100 000 vartotojų: duomenų sluoksnio mastelio keitimas
CDN labai padėjo: srautas auga visu greičiu. Garsusis vaizdo įrašų tinklaraštininkas Mavidas Mobrickas ką tik užsiregistravo pas mus ir paskelbė savo pasakojimą, kaip sakoma. Dėl apkrovos balansavimo procesoriaus ir atminties naudojimas API serveriuose yra mažas (veikia dešimt API egzempliorių), tačiau pradedame gauti daug užklausų skirtojo laiko... iš kur tokie vėlavimai?
Šiek tiek pasigilinus į metrikas matome, kad duomenų bazės serveryje CPU yra apkrautas 80-90%. Esame ties riba.
Duomenų sluoksnio mastelio keitimas yra tikriausiai pati sunkiausia lygties dalis. API serveriai teikia užklausas be būsenos, todėl tiesiog pridedame daugiau API egzempliorių. Nosis dauguma duomenų bazės to negali padaryti. Kalbėsime apie populiarias reliacinių duomenų bazių valdymo sistemas (PostgreSQL, MySQL ir kt.).
talpykloje
Vienas iš paprasčiausių būdų padidinti mūsų duomenų bazės našumą – įdiegti naują komponentą: talpyklos sluoksnį. Labiausiai paplitęs talpyklos metodas yra rakto vertės įrašų saugykla atmintyje, pvz., Redis arba Memcached. Dauguma debesų turi valdomą šių paslaugų versiją: „Elasticache“ sistemoje AWS ir „Memorystore“ sistemoje „Google Cloud“.
Talpykla yra naudinga, kai paslauga atlieka daug pakartotinių skambučių į duomenų bazę, kad gautų tą pačią informaciją. Iš esmės prie duomenų bazės pasiekiame tik vieną kartą, informaciją saugome talpykloje ir daugiau jos neliečiame.
Pavyzdžiui, mūsų „Graminsta“ paslaugoje kiekvieną kartą, kai kas nors patenka į žvaigždės Mobriko profilio puslapį, API serveris užklausia duomenų bazėje informacijos iš jo profilio. Tai nutinka vėl ir vėl. Kadangi Mobriko profilio informacija nesikeičia su kiekviena užklausa, ji puikiai tinka talpyklai.
Rezultatus iš „Redis“ duomenų bazės talpykloje saugosime pagal raktą user:id kurių galiojimo laikas yra 30 sekundžių. Dabar, kai kas nors nueina į Mobriko profilį, pirmiausia patikriname Redį, o jei duomenys yra, tiesiog perkeliame tiesiai iš Redis. Dabar užklausos į populiariausią svetainės profilį praktiškai neįkelia mūsų duomenų bazės.
Kitas daugumos talpyklos paslaugų pranašumas yra tas, kad jas lengviau keisti nei duomenų bazių serverius. Redis turi įmontuotą Redis Cluster režimą. Panašus į apkrovos balansavimo įrenginį, tai leidžia platinti Redis talpyklą keliuose kompiuteriuose (jei reikia, tūkstančiuose serverių).
Beveik visos didelės programos naudoja talpyklą; tai yra absoliučiai neatsiejama greitos API dalis. Spartesnis užklausų apdorojimas ir produktyvesnis kodas yra svarbūs, tačiau be talpyklos beveik neįmanoma pritaikyti paslaugos milijonams vartotojų.
Skaitykite kopijas
Kai duomenų bazės užklausų skaičius labai išaugo, dar vienas dalykas, kurį galime padaryti, yra įtraukti skaitymo kopijas į duomenų bazės valdymo sistemą. Naudojant aukščiau aprašytas valdomas paslaugas, tai galima padaryti vienu paspaudimu. Nuskaityta kopija išliks aktuali pagrindinėje duomenų bazėje ir yra prieinama SELECT sakiniams.
Štai dabar mūsų sistema:
Kitas žingsnis
Kadangi programa ir toliau plečiasi, mes ir toliau skirsime paslaugas, kad jas būtų galima keisti atskirai. Pavyzdžiui, jei pradedame naudoti „Websockets“, prasminga „Websockets“ apdorojimo kodą įtraukti į atskirą paslaugą. Galime įdėti jį į naujus egzempliorius už savo apkrovos balansavimo priemonės, kuri gali padidėti ir mažėti pagal atvirus „Websockets“ ryšius ir neatsižvelgiant į HTTP užklausų skaičių.
Taip pat toliau kovosime su apribojimais duomenų bazės lygiu. Būtent šiame etape atėjo laikas ištirti duomenų bazių skaidymą ir dalijimąsi. Abu metodai reikalauja papildomų išlaidų, tačiau leidžia keisti duomenų bazę beveik neribotą laiką.
Taip pat norime įdiegti stebėjimo ir analizės paslaugą, pvz., New Relic arba Datadog. Tai padės nustatyti lėtas užklausas ir suprasti, kur reikia tobulinti. Kurdami mastelį, norime sutelkti dėmesį į kliūčių radimą ir jų pašalinimą – dažnai pasitelkiame kai kurias ankstesnių skyrių idėjas.
Informacijos šaltiniai
Šis įrašas įkvėptas vieno iš . Norėjau šiek tiek sukonkretinti straipsnį apie pradinius projektų etapus ir atsieti jį nuo vieno pardavėjo. Būtinai perskaitykite, jei jus domina ši tema.
Išnašos
- Nors apkrovos paskirstymas keliuose egzemplioriuose yra panašus, pagrindinis Redis klasterio diegimas labai skiriasi nuo apkrovos balansavimo priemonės.
Šaltinis: www.habr.com