Elosztott rendszerek: Mikor kell felépíteni őket, és hogyan kell méretezni. Lépésről lépésre.

Jeremy McKnight fotója az Unsplash-en

Mindig arra számít, hány junior fejlesztő szenved impostor szindrómában, amikor megkezdték termékük elkészítését.

Tudom, sok olyan gondolkodó példa található a legnépszerűbb cégek számára, amelyek hihetetlenül összetett elosztott rendszerekkel képesek milliárdnyi kérelemre reagálni, alkalmazások százaira kecsesen frissíteni bármilyen állásidő nélkül, másodpercek alatt helyreállni a katasztrófa után, 60 percenként elengedni, és könnyű sebességgel bírni. válaszidő a világ bármely pontjáról.

Ezek a várakozások nagyon meglepőek lehetnek, amikor elkezdi a projektet. De amint közületek már sokan tudják, ezeknek a vállalatoknak a többsége minimálisan életképes rendszerrel és nagyon gyenge technológiai veremmel indult. Ennek egyszerű oka van: nekik nem volt rá szükségük induláskor. Ha több időt töltene a kódolás helyett a rendszer tervezésére, valójában kudarcot okozhat.

Ez a cikk lépésről lépésre mutat útmutatást. Megmutatom neked, hogy a Visage-nál miként kezdtük el a legkisebb rendszerrel és felépítettünk egy alapvető, magas rendelkezésre állású skálázható elosztott rendszert. Ez egy valós esettanulmány, amely eltávolítja a komplexeit, ha még soha nem volt lehetősége arra, hogy ezt megcsinálja.

Amikor először megérkeztem a Visage-be, mint műszaki vezető, én voltam az egyetlen mérnök. Nem tudtam semmit a tech veremről, de csatlakoztam, mert nagyon tetszett az ötlet, hogy házon belüli toborzók vagy HR szolgálat nélkül toborozhatok. Ez volt a Visage alapvető gondolata: a tömeges beszerzés, amelyet sok láthatatlan toborzó hajtott végre, akik a szerepeken dolgoztak együtt, olyan mesterséges intelligencia segítségével, amely napok alatt megkeresi a legmegfelelőbb tehetséget. Akkor közvetlenül kapcsolatba lépsz velük, egyetlen középember sem.

A tömegbányászásban a „tömeg” azonnal kiváltotta a mérnöki agyam: sokan vannak egyidejűleg dolgozó emberek, akik a világ minden tájáról jó teljesítményt várnak. Tetszett a kihívás.

De a rendszer szempontjából bonyolultak voltak a dolgok, valóban rosszul. Ezt találtam megérkezésemkor:

  • Egy veszélyeztetett Wordpress példány, amely elavult hibás pluginek százaival fut, virtuális gépben fut egy megosztott szerveren
  • Kompromittált postafiókok
  • A Google Dokumentumok és a Táblázatok szörnyű mennyisége.

És ez teljesen normális. Ismét egyetlen technikai tag sem volt a csapatban, és erre számítottam. Ennek ellenére a csapat az üzleti lehetőségekre összpontosított, és úgy tette, hogy a termék varázslatosan működik, miközben mindent kézzel készít! (Hamisd addig, amíg el nem készíted). És ez volt az, ami igazán elképesztő volt.

Az első rendszerünk (igen, beszívta, de a munkát elvégezte)!

Nem meglepő, hogy első feladatom a virtuális gép újbóli létrehozása, a Wordpress frissített verziójának újratelepítése volt, mindenki megváltoztatta a jelszavát, beállította a jelszavas házirendet és tucatnyi rosszindulatú programot távolított el a cég számítógépeiről ... de térjünk tovább a rendszer szempontjaira.

A Wordpress-től egy webes alkalmazásig

A termék gyártásának megkezdésekor elsődlegesen adatnak kell lennie. Az adatok vezetik a vállalat értékét. Ez lesz az, amit mindennapi döntések meghozatalához használ, és azt, amit a befektetőknek mutat be az előrehaladás bemutatására.

Meg kell értenie az adatait, és az adatok különböző forrásokból történő visszaszerzése, különböző formátumokban hatalmas időveszteség lesz. A Wordpress sok esetben nagyon jó választás lehet, ha nagyon sok mérnöki időt takarít meg, de igényeiknek megfelelően a Visage csapatnak olyan divatos plugineket kellett telepítenie, amelyeket már nem karbantartottak. Ennek eredményeként nem tudtuk ellenőrizni a létrehozott adatmodellt, és az adatok, amelyek nem feleltek meg a modellnek, több tucat dokumentumban és táblázatban szétszóródtak.

Tehát, hacsak nincs olyan termék, amely már megfelel az Ön igényeinek 90% -ának, gondoljon egy ideális adatmodellre, és hozzon létre egy minimális életképes terméket (MVP), amely képes az összes adatot tárolni.

Akkor gondolj az API-ra. Az alkalmazásának API-val kell rendelkeznie, ez kritikus lesz, ha végül eladja. Ne azonnal növelje, hanem a méretezhetőséget szem előtt tartva kódolja. Változtassa meg API-t és a lehető legteljesebb mértékben, mivel mindenki arra számíthat, hogy képes lesz rá kérdezni szokásos HTTP módszerekkel.

Esetünkben a NodeJS-t választottuk, mert a legtöbb kódunk csak bemeneteket és kimeneteket dolgoz fel. A NodeJS nem blokkolja, és az API-k tervezésére kényelmes könyvtárhoz tartozik: ExpressJS.

Ha szüksége van egy ügyféloldalas weboldalra, akkor több lehetősége van. Először létrehozhat egy réteget az alkalmazáskiszolgálón, amely elkészíti az oldalakat, vagy létrehozhat egyoldalú Javascript alkalmazást, amelyet egy statikus webtárhely-kiszolgáló fog kiszolgálni.

A Visage-nál a második lehetőséget választottuk, és úgy döntöttünk, hogy létrehozunk egy alkalmazást a felhasználók számára és egy az adminisztrátorok számára. Ennek oka egyszerűen az volt, hogy sokkal nagyobb elvárások merülnének fel a felhasználókkal szemben, mint amire az adminisztrátoroknál szükségünk volt, és mindkét kódtárat egyszerűen akartuk tartani (a CORS későbbi megfontolásainak is). Így nézett ki a rendszerünk:

Minden adat egy helyen

Az érzékeny adatok tárolását korábban delegálhatja

Hacsak ez nem kritikus az Ön vállalkozása számára, nincs indok a bizalmas személyes adatok tárolására a rendszerében. A biztonság összetett kérdés, és ha minden nap módosítja a kódját, amíg nem találja megfelelőnek a termékpiacot, akkor az eltörik. Tegyük fel, hogy bárki rosszul szándékozott, megsértheti az Ön kérelmét, ha igazán akarják.

A legfontosabb itt az, hogy ne tároljunk olyan adatokat, amelyek hackerek gyors nyerését jelentenék. Senki sem rabol ki olyan bankot, amelyben nincs pénz. Ha SaaS terméket tervez, valószínűleg hitelesítésre és online fizetésre van szüksége. Sok olyan harmadik fél létezik, amelybe integrálódhat, és amely sokkal jobb módon fog foglalkozni ezzel, mint amennyit esetleg tudna.

Az Auth0 például a legismertebb harmadik fél, aki kezeli a hitelesítést. A Stripe jó lehetőség az online fizetésekhez is. Minden erőforrást és a világ legjobb biztonsági mérnöki csapatait elkötelezik az adatok biztonságának megőrzése érdekében - vagy nincs üzletük.

Valódi jel egy autó, San Francisco

A felhőalapú szolgáltatások a legjobb barátok

Tehát ezen a ponton volt módunk tárolni minden adatunkat, hitelesítésünket, online fizetéseinket és egy webalkalmazást, amelyet az ügyfelek használhattak, valamint egy olyan API-t, amelyet különféle felhasználási esetekben eladhatunk a partnereknek. Növekedett felhasználói bázisunk, és nyilvánvalóvá vált, hogy bármikor hozzáférni akarnak az alkalmazáshoz. Tehát ideje volt gondolkodni a méretezhetőségről és a rendelkezésre állásról.

Egy szerverre támaszkodtunk, de csak annyi kérést tudott kezelni, és a kiszolgálók megváltoztatása vagy egy új verzió kiadása azt jelentené, hogy az alkalmazást levonjuk a kiadás alatt. Következő prioritásaink a következők voltak: terheléselosztás, automatikus méretezés, naplózás, replikáció és automatikus biztonsági mentések. Természetesen, ha Ön a cég egyetlen mérnöke, akkor ezeknek a problémáknak a megoldása egyedül lenne őrület.

Szerencsére egy olyan időben élünk, amelyet csak egy jól lekerekített mérnök könnyedén felépíthet egy ilyen rendszerbe néhány nap alatt, felhőalapú szolgáltatások, például az Amazon Web Services, a Google Cloud Services vagy az Azure használatával. Úgy döntöttünk, hogy rendszerünket az AWS-hez költöztetjük, mert akkoriban ez volt a legteljesebb megoldás, és 2 év ingyenes kredit volt.

Ez az oka annak, hogy ebben a bejegyzésben többnyire az AWS megoldásokról fogok beszélni, de vannak hasonló szolgáltatások más platformon is. Ez az az idő, amikor úgy döntöttünk, hogy a moduljainkat a Docker tárolókban való futtatása céljából számos más okból, amelyekre ez a bejegyzés nem vonatkozik (további információt a cikkben talál: https://medium.freecodecamp.org / amazon-fargate-goodbye-infrastruktúra-3b66c7e3e413).

Az, hogy miként dönt az alkalmazások futtatása, valójában az adott felhasználási esettől függ, például a szükséges rugalmasságtól, az infrastruktúra kezelésével töltött idővel szemben.

Nincs jó vagy rossz válasz.

Kiválaszthatja az összes modul tárolását, és olyan konténerkezelő rendszert is használhat, mint az ECS / EKS az AWS-ben vagy a Kubernetes motor a GCP-ben. Ha nem, és nem akarja olyan dolgokkal foglalkozni, mint például az automatikus méretezés és a terheléselosztás, akkor használhatja az Elastic Beanstalk vagy az App Engine szoftvert.

Ha teljes kiszolgáló nélküli állapotba akar lépni, akkor kombinálhatja a Lambda funkciók és az API átjáró használatát is. Úgy döntöttünk, hogy az ECS-re megyünk. 3 példányt telepítettünk 3 rendelkezésre állás zónában, egy terheléselosztót, beállított automatikus méretezést a CPU használatától függően, integráltuk az összes konténer naplóját a Cloudwatchbe és a beállítási metrikába a hibák, a külső hívások és az API válaszideje figyelésére.

Magas rendelkezésre állás: Tudta, hogy a zsiráfok szinte soha nem alszanak? 99% üzemidő

Adatbázisunkhoz a MongoDB-t használtuk, mert a modellünk jól illeszkedik egy NoSQL adatbázishoz és a nagy konzisztencia szempontjából. Úgy döntöttünk, hogy kihasználjuk a MongoDB Atlaszt, és 3 replikát telepítettünk a magas rendelkezésre állás érdekében. Az Atlas többek között az automatikus méretezést, az automatikus mentéseket nyújtja, és lehetővé teszi, hogy katasztrófa esetén zökkenőmentesen visszatérjen az időbe.

Ezenkívül úgy döntöttünk, hogy az összes statikus webfájlt az S3-ban tároljuk, és a Cloudfrontot CDN-ként használtuk, így a JS-alkalmazások nagyon gyorsan betöltődhetnek a világ bármely pontjára, és a kért számú alkalommal kiszolgálhatók. A Cloudflare szintén jó lehetőség, és DDOS védelmet kínál a dobozból.

Az egyszerűség kedvéért úgy döntöttünk, hogy az 53. útvonalat használjuk DNS-ként azáltal, hogy névtartalmukkal minden domainhez használjuk. Ez az egyik kedvenc szolgáltatásom az AWS-en. Sokkal könnyebbé teszi az életed. Minden alkalommal, amikor valamit domain név segítségével kíván kiszolgálni, legyen az EC2 példány, rugalmas IP, terheléselosztó, felhőalapú disztribúció vagy bármi más, akár magántulajdonban, akár nyilvános, percig tart, mert annyira jól integrálva van az összes egyéb szolgáltatások.

Kombinálja ezt a Tanúsítványkezelővel, amely lehetővé teszi SSL-tanúsítványok (beleértve a helyettesítő karaktereket) ingyen beszerzését perc alatt, és a kiszolgálókon történő telepítéshez jelölőnégyzet bejelölésével, és a leggyorsabb és legmegbízhatóbb módja a HTTPS engedélyezése az összes modulján. Viszlát „Nézzük titkosításra” SSL tanúsítványokat, amelyeket kb. Háromhavonta meg kellett újítanom és telepítenem a szervereimre .

Kezd tisztességesnek tűnni

Döntse el a gyorsítótárazási stratégiát

Mindenki utálja a gyorsítótár-kezelést, a gyorsítótárazás sokféle rétegben megtörténhet, a gyorsítótárral kapcsolatos problémákat nehéz reprodukálni, és rémálom hibaelhárításra.

Sajnos az elosztott rendszerek teljesítménye nagymértékben függ egy jó gyorsítótárazási stratégiától. Sok jó cikk található a jó gyorsítótárazási stratégiákról, tehát nem fogok mélyebben bemélyedni. Csak tudd, hogy ha a statikus webes erőforrások nehézek, akkor valószínűleg ki akarja használni a felhasználó böngésző gyorsítótárának előnyeit, ha ügyesen használja a gyorsítótár-vezérlő fejlécet.

Ha a felhasználó oldalát újra és újra létrehozza az alkalmazáskiszolgáló, használjon olyan gyorsítótárazó proxy-ot, mint a Squid. De ami a legfontosabb: nagy esély van arra, hogy újra és újra ugyanazokat a kéréseket fogja tenni az adatbázisához. Az adatbázis-terhelés csökkentéséhez és az adatátviteli idő megtakarításához használjon olyan memóriaobjektum-gyorsítótárazási rendszert, mint például a gyakran használt és ritkán frissített objektumok memcachedje.

Elkezdtük fontolóra venni a memacached használatát, mert gyakran és újra kérjük ugyanazokat a jelölt profilokat és állásajánlatokat. A memóriaoptimalizált gépen történő végrehajtása több mint 30% -kal növeli API-teljesítményünket, amikor egy nap összes kérésének válaszidejét átlagoljuk. A Memcached elosztva van, tehát különféle szerverekön futhat, de úgy viselkedik, mintha csak egy nagy memóriahely lenne az objektumok tárolására.

gyorsítótár, gyorsítótár mindenhol

Hely, hely, hely

Most van egy elosztott rendszerünk, amelynek nincs egyetlen meghibásodási pontja (ha figyelembe vesszük az AWS ELB-ket és egy elosztott memóriakártyát), és képes automatikusan skálázni fel és le. A gyorsítótárazást is használjuk a hálózati adatátvitel minimalizálása érdekében. Nagyon jól néz ki. Ezen a ponton valószínűleg ellenőrizni szeretné a harmadik feleket, hogy megtudja, vajon azok ugyanúgy elnyelik-e a rakományt, mint te.

De mégis, néhány felhasználónk panaszkodott, hogy számukra az alkalmazás kissé lassabb, főleg amikor fájlokat töltöttek fel. Sőt, még ha a statikus webfájlokat is a világ minden tájáról tároltuk (a CDN jóvoltából), minden alkalmazáskiszolgálót csak az USA nyugati részén telepítettük. A kelet-ázsiai felhasználók sokkal több késést tapasztaltak, különösen a nagy adatátvitel esetén.

A megoldás könnyű volt: pontosan ugyanazt az ECS-klasztert telepíti egy új ázsiai régióban, egy új terheléselosztóval együtt, és támaszkodhat az 53. útvonal geoproximity Routing útján, hogy a felhasználókat a legközelebbi terheléselosztóhoz irányítsa. A MongoDB Atlas lehetővé teszi a replikák régiók közötti telepítését is, így nincs szükség további munkára.

És itt vagyunk! Elosztott rendszerünk kész.

Következtetés

Noha az itt látható elosztott rendszert egyszerűsítették e bejegyzésnél, megvizsgáltuk azokat a részeket, amelyeket sok modern webes alkalmazásban valószínűleg lát. További, de nem tárgyalt témák a mikroszolgáltatások architektúrája, a fájlok tárolása és a titkosítás, az adatbázis shardingja, az ütemezett feladatok, az aszinkron párhuzamos számítástechnika… talán a következő üzenetben!

A lényeg az, hogy ne próbálja meg a tökéletes rendszert felépíteni, amikor elkezdi a terméket. A tervezési döntések nagy részét az fogja meghatározni, amit a termék csinál, és ki használja. Csak azt fogja tudni, hogy amikor eléri a megfelelő termékpiacot, és jó áttekintést kap a felhasználói bázissal, és ez akár hónapok, akár évek is eltarthat.

Fókuszáljon arra, hogy kitalálja, mire van szüksége az embereknek, és próbáljon megoldást találni problémájára, még akkor is, ha sok kézi lépéssel rendelkezik. Ezután gondoljon az automatizálásra, az idő eltöltésére a kódolásra és a pusztításra, és vegyen igénybe harmadik feleket, ahol van értelme.

Ne méretezze, hanem mindig gondolja át, kódolja és tervezze meg a méretezést. Készítse el a rendszert lépésről lépésre, ne foglalkozzon a rendszer tervezésével kapcsolatos problémákkal, amelyek még nem érett funkciók, és végül mindig próbálja meg megtalálni a legjobb kompromisszumot a eltöltött idő és a teljesítmény, a pénz és az alacsonyabb teljesítmény megszerzése között. kockázat.

Ha tetszett ez a cikk, és hasznosnak találta azt, nyomja meg a taps gombot, és kövessen engem további építészeti és fejlesztési cikkekhez!