http://www.lambda.ee/w/index.php?action=history&feed=atom&title=Hajuss%C3%BCsteemid%3A_skaleerimise_m%C3%A4rkmed 2026-11-03T07:18:26Z Selle lehekülje redigeerimiste ajalugu MediaWiki 1.43.11 http://www.lambda.ee/w/index.php?title=Hajuss%C3%BCsteemid:_skaleerimise_m%C3%A4rkmed&diff=19702&oldid=prev 2022-03-22T17:36:56Z

<p>Uus lehekülg: &#039;&lt;pre&gt; Meditsiinisüsteemi näide ------------------------- 1) koormus liiga suur hommikul ja õhtul: peakid 2) rakendusserver aeglane, panime kaks rakendusserveri kasti, dns-l...&#039;</p> <p><b>Uus lehekülg</b></p><div>&lt;pre&gt;<br /> Meditsiinisüsteemi näide<br /> -------------------------<br /> <br /> 1) koormus liiga suur hommikul ja õhtul: peakid<br /> <br /> 2) rakendusserver aeglane, panime kaks rakendusserveri kasti, dns-l on kaks ip-d taga,<br /> praktikas võeti randomiga üks või teine ip<br /> <br /> NB! <br /> * Liiga palju parallelismi ühes masinas ei ole hea<br /> * <br /> <br /> <br /> 3) andmebaas hiljem aeglaseks:<br /> <br /> a) leidsite aeglased queryd ja optimeerisite andmebaasi (indekseid ja queryde parandamine)<br /> <br /> b) kettakoormus ab-l läks ikkagi suureks, panite raid-10 kettad raid-5 asemel<br /> <br /> c) lisandus palju analüütilisi querisid, tegite ab replikatsiooni teise serverisse<br /> ja jooksutasite analüütilisi querisid teises serveris<br /> <br /> <br /> <br /> <br /> Kalastuspileti näide pilet.ee <br /> ------------------------------<br /> <br /> - oracle <br /> <br /> - connection pool sai täis (rakendusserveri ühendus andmebaasiga), esialgu suurendasid<br /> tulemus läks veel halvemaks<br /> <br /> - lahendus 1:<br /> <br /> - piirasin connection pooli, andsin varem jalaga, värk läks paremaks<br /> <br /> - aeglased queryd: optimeerisime (lisad lisapiiranguid a la aegadele (indekseeritud)), katsetad<br /> <br /> <br /> Id kaardi uuendamise näide<br /> --------------------------<br /> <br /> id-kaardi teema connection pooliga kaartide uuendamisel:<br /> <br /> - kogu aeg aeglane; algul oli piiratud hulk kasutajaid, siis kasutajate arv plahvatas<br /> <br /> - teemaks rakendusserver, mis suhtles mitme asjaga omakorda, tegi mujale api calle<br /> <br /> - ühe ülesande teenindamise protsess oli pikk / nõudis palju calle väljapoole<br /> <br /> - konkreetne suur probleem oli logianalüsaatorile saatmise call: teine pool ei võtnud vastu<br /> <br /> - riik pani tulemüüril piirangud peale: piiras connectionite arvu minutis<br /> <br /> kaartide tühistamist aeglustati<br /> <br /> kasutus ka hajutus<br /> <br /> <br /> <br /> Vaktsineerimise regamise näide<br /> -------------------------------<br /> <br /> vaktsineerimise regamise aegluse case:<br /> <br /> - pandi peale ootejärjekord (uus süsteem: regati sind ootejärjekorda? tehik?)<br /> <br /> <br /> <br /> Tähelepanekuid ja soovitusi <br /> ----------------------------<br /> <br /> * Terminoloogia NB! Mis tähendab &quot;skaleerimine&quot; ja &quot;skaleeritavus&quot;: <br /> <br /> * Praktikas tähendab ta &quot;optimeerimist&quot;<br /> <br /> * Rangemas tähendus on &quot;skaleeritavus&quot;: &quot;võime lisada kergesti ressursse, mis tõstavad võimekust&quot;<br /> <br /> * Hea point:<br /> <br /> ** Vertical scaling &quot;skaleerimine&quot;: paneme parema / kiirema masina / rohkem mälu<br /> <br /> ** Horizontal scaling: hajutame mitme masina peale<br /> <br /> <br /> * Ära optimeeri, kui pole vaja: enamasti ei teki süsteemile eriti suurt koormust<br /> <br /> * Ole valmis, et võivad tekkida ootamatud peakid või takistused<br /> <br /> * Rakendusserver ei pruugi olla süüdi: vbl ta ootab andmebaasi või väliste päringute taga<br /> <br /> * Rakendusserveri reaalse probleemi korral tuleb püüda tuvastada, mis osad tal aeglaselt käivad<br /> <br /> * Sisuliselt on pea alati probleem kas andmebaasis või välistes päringutes, mis on aeglased:<br /> st tüüpiliselt saab rakendusserveri koodi enda kiireks optimeerida<br /> <br /> * Väga suurte koormuste ja keerulise süsteemi puhul on mõtet kaaluda hoopis queuedega <br /> a la Kafka või Rabbit MQ arhitektuuri kasutamist: selles siin hiljem<br /> <br /> * Andmebaasi teema:<br /> <br /> * Leia aeglused ja mõõda<br /> <br /> * Hea on, kui saad katsetada live süsteemi kõrval arendussüsteemis (aga seal<br /> ei pruugi olla sama data / samad välised päringud / samad kõrval-tegevused)<br /> <br /> * Optimeeri kriitilisi päringuid (mis on aeglased)<br /> <br /> * Pane päringule lisapiiranguid (et suudaks kiiresti leida olulise dataseti)<br /> <br /> * Arhiveeri osa datat välja suurt tabelitest, mis paistavad olema kriitilised päringus<br /> <br /> * Ab serveri eraldada analüütilistest päringutest (kaks serverit, üks analüütika jaoks, teine olap-ks kiirpäringud)<br /> <br /> * Ab shardimine : tabelite jagamine tükkidena eraldi serveritesse<br /> <br /> * Ab replikeerimist: ab üldse paljudesse serveritesse<br /> <br /> * Kõik ab hajutamise asjad küsivad konsistentsuse järel: et igal pool oleks sama data (analüütika jaoks võib olla viivitusega!)<br /> <br /> <br /> * Ketta failisüsteem võib ka väga fragmenteeruda (isegi ssd puhul on see probleem)<br /> <br /> * 10.000 päringut sekundis on see, mida sa optimistlikult võid oletada (http teeb, ab samuti)<br /> <br /> <br /> <br /> Kafka ja teenuse-põhine arhitektuur (ei pea olema mikroteenused)<br /> ------------------------------------- <br /> <br /> Message queued a la rabbit mq: saadad sõnumeid ja teiselt poolt tarbid.<br /> <br /> Erinevad teenused kirjutavad sõnumeid (ülesandeid) ja teine pool tarbib neid:<br /> <br /> * Kui &quot;tava-api&quot; pärib ja saab kohe vastuse, siis<br /> <br /> * &quot;queue&quot; süsteem saadab päringu, see salvestatakse sõnumite/ülesannete baasi (a la queue) eraldi<br /> <br /> datastruktuuris (mis võib olla andmebaasis a ei pea olema)<br /> <br /> * Sõnumi &quot;vastuvõtja ja töötleja&quot;, kes peaks vastama, võtab sõnumeid sealt sõnumite/ülesannete baasist<br /> <br /> NB! <br /> <br /> * Tekib väike delay. <br /> <br /> * Saad pidevalt jälgida, kui palju sõnumeid ootel on<br /> <br /> * Saad panna piiranguid sõnumite hoidmise mahtudele<br /> <br /> * Saad panna juurde lisa-teenindajaid, kui ei jaksa teenindada<br /> <br /> * Kubernetes maailmas on näiteks auto-scaler, mis suudab ajutiselt automaatselt teenuseid lisada<br /> <br /> * Webhooks? Kasutaja saaks notificationi, kui toimub sündmus? A la githubi callbackid.<br /> <br /> * Panna soovi korral mitu tarbijat sõnumile<br /> <br /> * Võib tekkida oht (rabbitiga olnud) et rabbiti sõnumimasin ise ei jaksa (kafka paistab efektiivsem)<br /> <br /> <br /> <br /> Kõik tegevused toimuvad läbi queuede.<br /> <br /> Näited:<br /> <br /> * push notification: kasutaja teeb aplikatsioonis tegevuse, me paneme sõnumi queuesse (mälus a la stackis)<br /> <br /> * kui teenus saab sõnumi, teeb requesti väljapoole maailma<br /> <br /> * kui sõnumeid tuleb rohkem, kui tarbitakse, tuleb suurendada teenuste kogust, mis neid tarbivad<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> &lt;/pre&gt;</div>

Tammet