Hajussüsteemid: skaleerimise märkmed

Meditsiinisüsteemi näide
-------------------------

1) koormus liiga suur hommikul ja õhtul: peakid

2) rakendusserver aeglane, panime kaks rakendusserveri kasti, dns-l on kaks ip-d taga,
   praktikas võeti randomiga üks või teine ip
   
   NB! 
    * Liiga palju parallelismi ühes masinas ei ole hea
    * 
   

3) andmebaas hiljem aeglaseks:

   a) leidsite aeglased queryd ja optimeerisite andmebaasi (indekseid ja queryde parandamine)
   
   b) kettakoormus ab-l läks ikkagi suureks, panite raid-10 kettad raid-5 asemel
   
   c) lisandus palju analüütilisi querisid, tegite ab replikatsiooni teise serverisse
      ja jooksutasite analüütilisi querisid teises serveris




Kalastuspileti näide pilet.ee 
------------------------------
  
  - oracle 
  
  - connection pool sai täis (rakendusserveri ühendus andmebaasiga), esialgu suurendasid
    tulemus läks veel halvemaks
    
  - lahendus 1:
  
     - piirasin connection pooli, andsin varem jalaga, värk läks paremaks
     
     - aeglased queryd: optimeerisime (lisad lisapiiranguid a la aegadele (indekseeritud)), katsetad
     

Id kaardi uuendamise näide
--------------------------

id-kaardi teema connection pooliga kaartide uuendamisel:

  - kogu aeg aeglane; algul oli piiratud hulk kasutajaid, siis kasutajate arv plahvatas
  
  - teemaks rakendusserver, mis suhtles mitme asjaga omakorda, tegi mujale api calle

     - ühe ülesande teenindamise protsess oli pikk / nõudis palju calle väljapoole
     
     - konkreetne suur probleem oli logianalüsaatorile saatmise call: teine pool ei võtnud vastu
     
  - riik pani tulemüüril piirangud peale: piiras connectionite arvu minutis
  
    kaartide tühistamist aeglustati
    
    kasutus ka hajutus
    


Vaktsineerimise regamise näide
-------------------------------

vaktsineerimise regamise aegluse case:

  - pandi peale ootejärjekord (uus süsteem: regati sind ootejärjekorda? tehik?)
  


Tähelepanekuid ja soovitusi  
----------------------------

* Terminoloogia NB! Mis tähendab "skaleerimine" ja "skaleeritavus": 

  * Praktikas tähendab ta "optimeerimist"
  
  * Rangemas tähendus on "skaleeritavus": "võime lisada kergesti ressursse, mis tõstavad võimekust"
  
  * Hea point:
  
    ** Vertical scaling "skaleerimine": paneme parema / kiirema masina / rohkem mälu
    
    ** Horizontal scaling: hajutame mitme masina peale


* Ära optimeeri, kui pole vaja: enamasti ei teki süsteemile eriti suurt koormust

* Ole valmis, et võivad tekkida ootamatud peakid või takistused

* Rakendusserver ei pruugi olla süüdi: vbl ta ootab andmebaasi või väliste päringute taga

* Rakendusserveri reaalse probleemi korral tuleb püüda tuvastada, mis osad tal aeglaselt käivad

* Sisuliselt on pea alati probleem kas andmebaasis või välistes päringutes, mis on aeglased:
  st tüüpiliselt saab rakendusserveri koodi enda kiireks optimeerida
  
* Väga suurte koormuste ja keerulise süsteemi puhul on mõtet kaaluda hoopis queuedega 
  a la Kafka või Rabbit MQ arhitektuuri kasutamist: selles siin hiljem

* Andmebaasi teema:

  * Leia aeglused ja mõõda
  
  * Hea on, kui saad katsetada live süsteemi kõrval arendussüsteemis (aga seal
    ei pruugi olla sama data / samad välised päringud / samad kõrval-tegevused)
  
  * Optimeeri kriitilisi päringuid (mis on aeglased)
  
  * Pane päringule lisapiiranguid (et suudaks kiiresti leida olulise dataseti)
  
  * Arhiveeri osa datat välja suurt tabelitest, mis paistavad olema kriitilised päringus
  
  * Ab serveri eraldada analüütilistest päringutest (kaks serverit, üks analüütika jaoks, teine olap-ks kiirpäringud)
  
  * Ab shardimine : tabelite jagamine tükkidena eraldi serveritesse
  
  * Ab replikeerimist: ab üldse paljudesse serveritesse
  
  * Kõik ab hajutamise asjad küsivad konsistentsuse järel: et igal pool oleks sama data (analüütika jaoks võib olla viivitusega!)
  
  
* Ketta failisüsteem võib ka väga fragmenteeruda (isegi ssd puhul on see probleem)

* 10.000 päringut sekundis on see, mida sa optimistlikult võid oletada (http teeb, ab samuti)



Kafka ja teenuse-põhine arhitektuur (ei pea olema mikroteenused)
------------------------------------- 

Message queued a la rabbit mq: saadad sõnumeid ja teiselt poolt tarbid.

Erinevad teenused kirjutavad sõnumeid (ülesandeid) ja teine pool tarbib neid:

* Kui "tava-api" pärib ja saab kohe vastuse, siis

* "queue" süsteem saadab päringu, see salvestatakse sõnumite/ülesannete baasi (a la queue) eraldi

  datastruktuuris (mis võib olla andmebaasis a ei pea olema)
  
* Sõnumi "vastuvõtja ja töötleja", kes peaks vastama, võtab sõnumeid sealt sõnumite/ülesannete baasist

NB! 

* Tekib väike delay. 

* Saad pidevalt jälgida, kui palju sõnumeid ootel on

* Saad panna piiranguid sõnumite hoidmise mahtudele

* Saad panna juurde lisa-teenindajaid, kui ei jaksa teenindada

* Kubernetes maailmas on näiteks auto-scaler, mis suudab ajutiselt automaatselt teenuseid lisada

* Webhooks? Kasutaja saaks notificationi, kui toimub sündmus? A la githubi callbackid.

* Panna soovi korral mitu tarbijat sõnumile

* Võib tekkida oht (rabbitiga olnud) et rabbiti sõnumimasin ise ei jaksa (kafka paistab efektiivsem)



Kõik tegevused toimuvad läbi queuede.

Näited:

  * push notification: kasutaja teeb aplikatsioonis tegevuse, me paneme sõnumi queuesse (mälus a la stackis)
  
  * kui teenus saab sõnumi, teeb requesti väljapoole maailma
  
  * kui sõnumeid tuleb rohkem, kui tarbitakse, tuleb suurendada teenuste kogust, mis neid tarbivad