Hajutatud süsteemid: millal peaksite need üles ehitama ja kuidas skaleerida. Üksikasjalik juhend.

Foto autor Jeremy McKnight saidil Unsplash

Mulle tekitab alati muret, kui palju nooremaid arendajaid oma toote loomise ajal põeb impostori sündroomi.

Saan aru, on palju tähelepanelikke näiteid tippfirmadest, kus on uskumatult keerulised hajutatud süsteemid, mis suudavad lahendada miljardeid taotlusi, uuendada graatsiliselt sadu rakendusi ilma seisakuidta, toibuda katastroofist sekunditega, vabastada iga 60 minuti järel ja omada kiiret kiirust reageerimisajad kõikjal maailmas.

Need ootused võivad projekti alustamisel olla üsna ülekaalukad. Kuid nagu paljud teist juba teavad, on enamik neist ettevõtetest alustanud minimaalselt elujõulise süsteemiga ja väga viletsa tehnoloogiaga. Sellel on lihtne põhjus: nad ei vajanud seda alustades. Kui kulutate kodeerimise asemel rohkem aega oma süsteemi kujundamisele, võib see teie tõrke põhjustada.

See artikkel on samm-sammult, kuidas juhendada. Ma näitan teile, kuidas Visage'is alustasime kõigi aegade väikseima süsteemiga ja ehitasime üles kõrge kättesaadavusega skaleeritava jaotussüsteemi. See on reaalne juhtumianalüüs teie komplekside eemaldamiseks, kui teil pole kunagi olnud võimalust seda ise teha.

Kui ma esimest korda Visage'iks CTO-na jõudsin, olin ma ainus insener. Tehnikakogust ei teadnud ma midagi, kuid liitusin sellega, et mulle meeldis väga idee, et saaksin värvata ilma ettevõttesiseste värbajate või personaliteenistuseta. See oli Visage'i peamine idee: rahvahulkade kaasamine, mida juhivad paljud nähtamatud värbajad, kes töötavad teie rollide nimel koos tehisintellekti abil ja otsivad mõne päeva jooksul teile kõige sobivamat talenti. Siis suhtlete nendega otse, mitte ükski keskealine mees.

Inimtööjõu pakkumise rahvahulk käivitas hetkega minu inseneriteadused: inimesi, kes töötavad samaaegselt, on palju, kes ootavad häid tulemusi kõikjal maailmas. Mulle meeldis väljakutse.

Kuid süsteemis tark, asjad olid halvad, tõeliselt halvad. Seda leidsin kohale jõudes:

  • Ohustatud Wordpressi eksemplar, mis töötab sadu vananenud vigaseid pistikprogramme ja töötab jagatud serveri VM-is
  • Kompromiteeritud postkastid
  • Hämara hulga Google Docs ja Spreadsheets.

Ja see on täiesti normaalne. Jällegi polnud meeskonnas ühtegi tehnilist liiget ja ma olin midagi sellist oodanud. Sellegipoolest oli meeskond keskendunud ärivõimalusele ja pani toote paistma, nagu see toimiks võluväel, tehes kõike käsitsi! (Võltsige, kuni valmistate). Ja see oli tõesti hämmastav.

Meie esimene süsteem (jah, see imbus, kuid see tegi oma töö)!

Pole üllatav, et minu esimene ülesanne oli uuesti luua VM, installida ajakohastatud Wordpressi versioon, veenduda, et kõik muudavad oma paroole, kehtestavad paroolipoliitika ja eemaldavad ettevõtte arvutitest kümneid õelvara ... kuid jätkame süsteemide kaalutlustega.

Wordpressist veebirakenduseni

Teie esimene keskendumine toote loomise alustamisel peavad olema andmed. Teie ettevõtte väärtust suurendavad andmed. See on see, mida kasutate igapäevaselt otsuste tegemisel, ja see, mida näitate oma investoritele edusammude demonstreerimiseks.

Peate oma andmeid mõistma ja erinevatest allikatest erinevate vormingute andmete varundamine on tohutu ajaraiskamine. Wordpress võib paljudel juhtudel olla väga hea valik, hoides kokku üsna palju inseneritegevust, kuid nende vajadusteks pidi Visage'i meeskond installima väljamõeldud pluginad, mida enam ei hooldatud. Selle tulemusel ei olnud meil genereeritud andmemudeli üle kontrolli ja andmed, mis mudelile ei sobinud, olid hajutatud kümnetele dokumentidele ja arvutustabelitele.

Nii et kui seal pole ühtegi toodet, mis juba vastab 90% teie vajadustest, mõelge ideaalsele andmemudelile ja kavandage ning rakendage minimaalne elujõuline toode (MVP), mis suudab hoida kõiki teie andmeid.

Siis mõelge API-le. Teie rakendusel peab olema API, see on kriitiline, kui lõpuks selle müüte. Ärge kohe suurendage, vaid koodige mastaapsust silmas pidades. Muutke oma API kodakondsuseta ja nii RESTLIKAKS kui võimalik, sest kõik eeldavad, et suudavad seda päringuid teha tavaliste HTTP-meetodite abil.

Valisime meie puhul NodeJS, kuna suurem osa meie koodist töötleks lihtsalt sisendeid ja väljundeid. NodeJS ei blokeeri ja selle juurde kuulub teek, mida on mugav API-de kujundamiseks: ExpressJS.

Kui vajate kliendi jaoks mõeldud veebisaiti, on teil mitu võimalust. Esmalt saate oma rakenduste serverisse luua kihi, mis genereerib teie lehti, või võite luua ühe lehe Javascripti rakenduse, mida hakkab teenindama staatiline veebimajutusserver.

Visage'is otsustasime teise variandi ja otsustasime luua ühe rakenduse kasutajatele ja ühe administraatoritele. See oli lihtsalt sellepärast, et meil oleks kasutajate suhtes palju suuremad ootused, kui me administraatoritega vajasime, ja tahtsime hoida mõlemad koodialused lihtsaks (ka CORSi kaalutluste jaoks hiljem). Meie süsteem nägi välja selline:

Kõik andmed ühes kohas

Delegeerige tundlike andmete säilitamine varakult

Kui see pole teie ettevõtte jaoks kriitiline, pole mõistlik põhjus oma süsteemides tundlike isikuandmete salvestamiseks. Turvalisus on keeruline küsimus ja kui muudate oma koodi iga päev, kuni leiate oma tooteturule sobivuse, siis see puruneb. Oletame, et keegi, kes on halvasti kavatsenud, võib teie taotlust rikkuda, kui nad seda tõesti tahaksid.

Siinkohal on oluline mitte hoida andmeid, mis häkkerile kiireks võidaks. Keegi ei röövi panka, millel pole raha. Kui kavandate SaaS-i toodet, vajate tõenäoliselt autentimist ja veebimakset. On palju kolmandaid osapooli, kellega saate integreeruda ja kes tegelevad sellega palju paremal viisil, kui võiksite.

Näiteks Auth0 on kõige tuntum autentimisega tegelev kolmas osapool. Triip on hea võimalus ka veebimaksete tegemiseks. Nad pühendavad kõik oma ressursid ja planeedi parimatele turbetehnoloogia meeskondadele, et hoida teie andmeid turvaliselt - või kui neil pole ettevõtet.

Tegelik märk autol San Franciscos

Pilveteenused on teie parimad sõbrad

Nii et sel hetkel oli meil võimalus salvestada kõik meie andmed, autentimine, veebimakse ja veebirakendus, mida kliendid said kasutada, koos API-ga, mida saaksime partneritele müüa erinevatel kasutusjuhtudel. Meie kasutajaskond kasvas ja ilmnes, et nad tahavad rakendusele juurde pääseda igal ajal. Seega oli aeg mõelda mastaapsusele ja saadavusele.

Me lootsime ühele serverile, kuid see sai hakkama ainult nii paljude taotlustega ning serverite muutmine või uue versiooni väljaandmine tähendaks rakenduse vabastamist väljalaske ajal. Järgmised meie prioriteedid olid: koormuse tasakaalustamine, automaatne skaleerimine, logimine, kopeerimine ja automatiseeritud varundamine. Muidugi, kui olete oma ettevõttes ainus insener, oleks kõigi nende probleemidega iseseisvalt tegelemine täielik hullumeelsus.

Õnneks elame ajal, kus vaid üks hästi ümar insener saab sellise süsteemi hõlpsasti paari päevaga üles ehitada, kasutades selliseid pilveteenuseid nagu Amazon Web Services, Google Cloud Services või Azure. Otsustasime viia oma süsteemid üle AWS-i, kuna sel ajal oli see kõige täielikum lahendus ja meil oli 2 aastat tasuta krediiti.

Seetõttu räägin selles postituses enamasti AWS-lahendustest, kuid teistes platvormides on samaväärseid teenuseid. See on ka aeg, kui otsustasime hakata oma mooduleid Dockeri konteinerites käima paljudel muudel põhjustel, mida selles postituses ei käsitleta (lisateabe saamiseks võite vaadata seda artiklit: https://medium.freecodecamp.org / amazon-fargate-hüvasti-infrastruktuur-3b66c7e3e413).

See, kuidas otsustate oma rakendusi käitada, sõltub tõesti teie kasutusest, näiteks vajaminevast paindlikkusest võrreldes võimalusega, mille saate kulutada oma infrastruktuuri haldamiseks.

Ei ole head ega halba vastust.

Saate valida, kas koondada kõik oma moodulid ja kasutada konteinerihaldussüsteemi nagu ECS / EKS AWS-is või Kubernetes mootor GCP-s. Kui ei ja te ei soovi ise tegeleda näiteks automaatse mõõtmise ja koormuse tasakaalustamisega, võite kasutada Elastic Beanstalki või App Engine'i.

Kui soovite minna täielikult serverita, saate kombineerida ka Lambda funktsioonide ja API-lüüsi kasutamist. Otsustasime minna ECSi. Juurutasime 3 esinemistsooni 3 eksemplari, koormuse tasakaalustaja, sõltuvalt protsessori kasutamisest seadistanud automaatse skaleerimise, integreerinud kõik konteinerite logid Cloudwatchi ja seadistusmõõdikutega vigade, väliskõnede ja API reageerimise aja jälgimiseks.

Kõrge kättesaadavus: kas teadsite, et kaelkirjakud peaaegu kunagi ei maga? 99% tööaeg

Andmebaasi jaoks kasutasime MongoDB-d, kuna meie mudel sobib hästi NoSQL-i andmebaasi jaoks ja selle suure järjepidevuse jaoks. Otsustasime MongoDB Atlase eelise ära kasutada ja juurutasime 3 koopiat kõrge kättesaadavuse tagamiseks. Teiste teenuste hulgas pakub Atlas automaatskaalamist, automatiseeritud varundamist ja võimaldab katastroofide korral sujuvalt ajas tagasi minna.

Samuti otsustasime majutada kõik oma staatilised veebifailid S3-s ja kasutasime Cloudfrontit CDN-na, nii et meie JS-i rakendused saavad väga kiiresti kõikjal maailmas laadida ja neid nii palju kordi kui vaja. Pilvvalgus on ka hea võimalus ja pakub DDOS-i kaitset karbist välja.

Lihtsuse huvides otsustasime kasutada Route 53 oma DNS-na, kasutades nende nimeservereid kõigi meie domeenide jaoks. See on üks minu lemmikteenuseid AWS-is. See teeb teie elu palju lihtsamaks. Iga kord, kui soovite midagi domeeninime kaudu teenindada, olgu see siis EC2 eksemplar, elastne IP, koormuse tasakaalustaja, Cloudfront'i levitamine või midagi muud, privaatselt või avalikult, võtab see teie jaoks minuteid, kuna see on nii hästi integreeritud kõigi muud teenused.

Kombineerige see sertifikaatide halduriga, mis võimaldab teil mõne minuti jooksul tasuta saada SSL-sertifikaate (ka metamärke) ja neid kõigis serverites kasutusele võtta, märkides ruudu, ning teil on kiireim ja usaldusväärsem viis HTTPS-i lubamiseks kõigis oma moodulites. Head aega “Let’s Encrypt” SSL-sertifikaate, mida pidin uuendama ja oma serveritesse installima umbes iga 3 kuu tagant .

Hakkab juba korralik välja nägema

Otsustage vahemällu salvestamise strateegia

Kõik vihkavad vahemäluhaldust, vahemällu salvestamine võib toimuda paljudes erinevates kihtides ning vahemäluga seotud probleeme on raske taasesitada ja see on õudusunenägu.

Kahjuks tugineb hajutatud süsteemide jõudlus suuresti heale vahemälustrateegiale. Heade vahemälustrateegiate kohta on palju häid artikleid, nii et ma ei lasku palju üksikasjalikumalt. Lihtsalt teadke, et kui teie staatilised veebiressursid on rasked, peate tõenäoliselt kasutama oma brauseri vahemälu, kasutades nutikalt vahemälu juhtimise päist.

Kui teie kasutaja silmitsi olevad lehed genereeritakse rakendusserverites ikka ja jälle, kasutage vahemällu puhverserverit, näiteks Squid. Kuid mis kõige tähtsam - on suur võimalus, et esitate oma andmebaasile ikka ja jälle samu taotlusi. Andmebaasi koormuse vähendamiseks ja andmeedastuse aja kokkuhoiuks kasutage mäluobjektide vahemällusüsteemi, nagu näiteks mäluga objektide jaoks, mida sageli kasutatakse ja mida värskendatakse harva.

Me hakkasime kaaluma memacache'i kasutamist, kuna taotlesime ikka ja jälle samu kandidaadiprofiile ja tööpakkumisi. Selle installimine mälu jaoks optimeeritud masinasse tõstis meie API jõudlust enam kui 30%, kui arvestame kõigi päringutele vastamise aega päevas. Memcached on samuti levitatud, nii et see võib töötada erinevates serverites, kuid toimib siiski nii, nagu see oleks teie objektide salvestamiseks vaid üks suur mäluruum.

vahemälu, vahemälu kõikjal

Asukoht, asukoht, asukoht

Nüüd on meil hajutatud süsteem, millel pole ühte tõrkepunkti (kui arvestada AWS-i ELB-sid ja hajutatud mäluruumi), ja see saab automaatselt üles ja alla skaleerida. Võrguandmete edastamise minimeerimiseks kasutame ka vahemällu salvestamist. Näeb päris hea välja. Sel hetkel soovite tõenäoliselt oma kolmandaid isikuid kontrollida, et näha, kas nad võtavad koormat sama hästi kui teie.

Kuid siiski, mõned meie kasutajad kaebasid, et rakendus oli nende jaoks pisut aeglasem, eriti kui nad faile üles laadisid. Isegi kui meie staatilised veebifailid olid kogu maailmas vahemällu salvestatud (CDNi nõusolekul), olid kõik meie rakendusserverid ainult USA läänes. Ida-Aasia kasutajad kogesid palju suuremat latentsusaega, eriti suurte andmeedastuste puhul.

Lahendus oli lihtne: juurutage täpselt sama ECS-klaster Aasia uuele piirkonnale koos uue koorma tasakaalustajaga ja kasutage Route 53 geoproximity Routing'i marsruuti, et suunata kasutajad lähimasse koorma tasakaalustajasse. MongoDB Atlas võimaldab teil ka oma koopiaid piirkondade vahel paigutada, nii et täiendavat tööd ei olnud vaja teha.

Ja siin me oleme! Meie hajutatud süsteem on valmis.

Järeldus

Ehkki siin nähtavat hajutatud süsteemi on selle postituse jaoks lihtsustatud, uurisime neid osi, mida näete tõenäoliselt paljudes kaasaegsetes veebirakendustes. Muud teemad, mis on seotud, kuid pole hõlmatud, on mikroteenuste arhitektuur, failide salvestamine ja krüptimine, andmebaaside varjestus, ajastatud toimingud, asünkroonne paralleelne arvutamine ... võib-olla järgmises postituses!

Minu peamine mõte on: ärge proovige toote turule toomise ajal luua ideaalset süsteemi. Enamiku kujundusvalikutest lähtub see, mida teie toode teeb ja kes seda kasutab. Saate ainult teada, et kui jõuate tooteturule, sobib ja kui teil on hea ülevaade oma kasutajaskonnast ning see võib võtta kuid, isegi aastaid.

Keskenduge inimeste vajaduste väljamõtlemisele ja proovige leida lahendus oma probleemile, isegi kui sellel on palju käsitsi tehtavaid samme. Seejärel mõelge välja viisid, kuidas automatiseerida, kulutada aega kodeerimisele ja hävitamisele ning kasutada kolmandaid isikuid seal, kus see on mõistlik.

Ärge skaleerige, vaid mõelge, kodeerige ja plaanige mõõtmeid alati. Ehitage oma süsteem samm-sammult, ärge lahendage süsteemide kujundamisega seotud probleeme, mis põhinevad funktsioonidel, mis pole veel küpsed, ja proovige alati leida parim vahekord kulutatud aja ning jõudluse, raha ja madalama hinnaga saavutatud kasu vahel risk.

Kui teile see artikkel meeldis ja leidis, et see on kasulik, siis klõpsake sellel plaksutusnupul ja järgige mind, et saada rohkem arhitektuuri- ja arendusartikleid!