{"id":52389,"date":"2019-11-07T00:00:00","date_gmt":"2019-11-06T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions"},"modified":"2020-02-18T14:00:05","modified_gmt":"2020-02-18T11:00:05","slug":"kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","title":{"rendered":"Kuidas rakendatakse talitlush\u00e4irekindlat veebiarhitektuuri Mail.ru Cloud Solutions platvormil","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kuidas
\n
\nTere, Habr! Mina olen Artyom Karamyshev, s\u00fcsteemi haldamise meeskonna juht. Mail.Ru Cloud Solutions (MCS)<\/a><\/noindex>. Viimase aasta jooksul on meil olnud palju uusi tooteid. Soovisime tagada, et API teenused oleksid kergesti skaleeritavad, talitlusp\u00fcsivad ja valmis kiiresti kasvavale kasutajakoormusele. Meie platvorm p\u00f5hineb OpenStackil ja soovin r\u00e4\u00e4kida nendest talitlusp\u00fcsivuse probleemidest, millega oleme silmitsi seisnud, et luua talitlusp\u00fcsiv s\u00fcsteem. Arvan, et see v\u00f5iks huvi pakkuda ka neile, kes arendavad tooteid OpenStackil.<\/p>\n

Platvormi \u00fcldine talitlusp\u00fcsivus tuleneb selle komponentide talitlusp\u00fcsivusest. Niisiis, liigume j\u00e4rk-j\u00e4rgult l\u00e4bi k\u00f5ikidest tasemetest, kus oleme avastanud riske ja need k\u00f5rvaldada.<\/p>\n

Selle loo videoversioon, mille algallikaks on ettekande Uptime day 4 konverentsil, mille korraldas ITSumma<\/a><\/noindex>, on saadaval Uptime Community YouTube kanalil.<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

F\u00fc\u00fcsilise arhitektuuri talitlusp\u00fcsivus<\/h2>\n

\nMCSi avalik osa asub praegu kahel Tier III andmekeskusel, nende vahel on pimedat kiudkaablit, mis on f\u00fc\u00fcsilisel tasemel reserveeritud erinevate marsruutide jaoks, mille l\u00e4bilaskev\u00f5ime on 200 Gbit\/s. Tier III tase tagab vajaliku f\u00fc\u00fcsilise infrastruktuuri talitlusp\u00fcsivuse taseme. <\/p>\n

Pime kiud on reserveeritud nii f\u00fc\u00fcsilisel kui ka loogilisel tasemel. Kanali reserveerimise protsess oli iteratiivne, tekkisid probleemid ja pidevalt t\u00e4iustame side\u00fchendust andmekeskuste vahel. <\/p>\n

N\u00e4iteks hiljuti, kui t\u00f6\u00f6tati \u00fche andmekeskuse l\u00e4hedal kaevanduses, l\u00f5hkus ekskavaator toru, milles olid nii p\u00f5hikaabel kui ka reserveeritud optiline kaabel. Meie talitlusp\u00fcsiv sidekanal andmekeskusega osutus \u00fches punktis, kaevanduses, haavatavaks. Vastavalt kaotasime osa infrastruktuurist. T\u00f5ime v\u00e4lja j\u00e4reldused, tegime mitmeid samme, sealhulgas paigaldasime k\u00f5rvalasuvasse kaevandusse t\u00e4iendava optika.<\/p><\/blockquote>\n

\nAndmekeskustes on sidepakkujate kohalolekupunktid, kellele edastame oma eeliseid BGP kaudu. Iga v\u00f5rgu suuna jaoks valitakse parim m\u00f5\u00f5dik, mis v\u00f5imaldab pakkuda erinevatele klientidele parima kvaliteediga \u00fchendust. Kui \u00fche pakkuja kaudu \u00fchendus katkeb, kohandame oma marsruutimist saadaval olevate pakkujate kaudu.<\/p>\n

Pakkuja t\u00f6\u00f6 t\u00f5rke korral l\u00fclitame automaatselt j\u00e4rgmisele. Kui \u00fcks andmekeskus eba\u00f5nnestub, on meil teises andmekeskuses peegelkohalik koopia meie teenustest, mis v\u00f5tavad kogu koormuse enda peale.<\/p>\n

\"Kuidas
\nF\u00fc\u00fcsilise infrastruktuuri t\u00f5rketaluvus<\/i><\/p>\n

Mida me kasutame t\u00f5rketaluvuse tagamiseks rakendustasandil<\/h2>\n

\nMeie teenus on \u00fcles ehitatud mitmete avatud l\u00e4htekoodiga komponentide baasil. <\/p>\n

ExaBGP<\/b> \u2014 teenus, mis realiseerib mitmeid funktsioone d\u00fcnaamilise marsruutimise protokolli kaudu BGP baasil. Me kasutame seda aktiivselt, et kuulutada v\u00e4lja meie valged IP-aadressid, mille kaudu kasutajad p\u00e4\u00e4sevad API-le.<\/p>\n

Edasi l\u00e4ks kliendi p\u00e4ring HAProxy-sse, mis lahendas j\u00e4rgmised \u00fclesanded:<\/b> \u2014 k\u00f5rgkoormusega tasakaalustaja, mis lubab seadistada v\u00e4ga paindlikke liikluse tasakaalustamise reegleid erinevatel OSI mudeli tasanditel. Me kasutame seda tasakaalustamiseks k\u00f5igi teenuste ees: andmebaasid, s\u00f5numibrokereid, API-teenuseid, veebiteenuseid, meie sisemisi projekte \u2014 k\u00f5ik on HAProxy taga.<\/p>\n

API rakendus<\/b> \u2014 veebirakendus, kirjutatud pythonis, mille abil kasutaja haldab oma infrastruktuuri, oma teenust.<\/p>\n

T\u00f6\u00f6taja rakendus <\/b>(edaspidi lihtsalt t\u00f6\u00f6taja) \u2014 OpenStack teenustes on see infrastruktuuri demon, mis v\u00f5imaldab edastada API-k\u00e4sku infrastruktuurile. N\u00e4iteks toimub ketta loomine just t\u00f6\u00f6tajas, samas kui loomise p\u00e4ring l\u00e4heb API rakendusse. <\/p>\n

Standardne OpenStack rakenduste arhitektuur<\/h2>\n

\nEnamik OpenStacki alla arendatavaid teenuseid p\u00fc\u00fcab j\u00e4rgida \u00fchtset paradigmat. Teenus koosneb tavaliselt kahest osast: API-st ja t\u00f6\u00f6tajatest (taustarakenditest). Reeglina on API WSGI rakendus Pythonis, mis t\u00f6\u00f6tab kas iseseisva protsessina (daemon) v\u00f5i olemasoleva veebiserveri Nginx, Apache kaudu. API t\u00f6\u00f6tleb kasutaja p\u00e4ringut ja edastab edasised juhised t\u00f6\u00f6taja rakendusele. Edastamine toimub s\u00f5numivahendi kaudu, tavaliselt RabbitMQ, kuid teisi toetatakse halvasti. Kui s\u00f5numid j\u00f5uavad vahendisse, t\u00f6\u00f6tavad need t\u00f6\u00f6tajad ja vajadusel tagastavad vastuse. <\/p>\n

See paradigma eeldab isoleeritud \u00fcldisi rikkepunkte: RabbitMQ ja andmebaasi. RabbitMQ on aga isoleeritud \u00fches teenuses ja v\u00f5ib idee kohaselt olla iga teenuse jaoks individuaalne. Seega, meie MCS-is jagame maksimaalselt neid teenuseid; iga projekti jaoks loome eraldi andmebaasi ja eraldi RabbitMQ. See l\u00e4henemine on hea, kuna rikke korral m\u00f5nes haavatavas kohas ei l\u00f5hku kogu teenust, vaid ainult selle osa.<\/p>\n

T\u00f6\u00f6tajate rakenduste arv ei ole millegagi piiratud, mist\u00f5ttu API saab h\u00f5lpsasti horisontaalselt skaleerida koormustasakaalustajate abil j\u00f5udluse ja t\u00f5rkeotsingu suurendamiseks.<\/p>\n

M\u00f5nes teenuses on teenuse sees vajalik koordineerimine - kui toimub keerulisi j\u00e4rjestikuseid toiminguid API ja t\u00f6\u00f6tlejate vahel. Sellisel juhul kasutatakse \u00fchtset koordineerimiskeskust, klustserite s\u00fcsteemi nagu Redis, Memcache, etcd, mis v\u00f5imaldab \u00fchel t\u00f6\u00f6tlejal \u00f6elda teisele, et see \u00fclesanne on tema p\u00e4ralt (\u201epalun, \u00e4ra v\u00f5ta seda\u201c). Me kasutame etcd-d. Reeglina suhtlevad t\u00f6\u00f6tlejad aktiivselt andmebaasiga, kirjutavad ja loevad sealt teavet. Andmebaasina kasutame MariaDB-d, mis asub meil multimeister-klusteris.\n<\/p><\/blockquote>\n

\nKlassikaline \u00fchekordne teenus on korraldatud OpenStackile omase viisi kohaselt. Seda v\u00f5ib pidada isoleeritud s\u00fcsteemiks, mille jaoks on skaleerimise ja t\u00f5rkeotsingu viisid piisavalt selged. N\u00e4iteks, et tagada API t\u00f5rkeotsing, piisab, kui paigaldada nende ette koormustasakaalustaja. T\u00f6\u00f6tajate skaleerimine saavutatakse nende arvu suurendamisega. <\/p>\n

Kogu s\u00fcsteemi n\u00f5rk koht on RabbitMQ ja MariaDB. Nende arhitektuur v\u00e4\u00e4rib eraldi artiklit. Selles artiklis soovin keskenduda API talitlush\u00e4irete v\u00e4ltimisele.<\/p>\n

\"Kuidas
\nOpenstacki rakenduse arhitektuur. Pilveplatvormi koormuse ja talitlush\u00e4irete v\u00e4ltimine.<\/i><\/p>\n

Teeme HAProxy koormuse tasandaja talitlush\u00e4irete v\u00e4ltimiseks ExaBGP abil.<\/h2>\n

\nKuna meie API-d peavad olema skaleeritavad, kiired ja talitlush\u00e4irete v\u00e4ltimisega, panime nende ette koormuse tasandaja. Valisime HAProxy. Minu arvates omab see k\u00f5iki vajalikke omadusi meie \u00fclesande jaoks: tasandamine mitmel OSI tasemel, haldust\u00fc\u00fcp, paindlikkus ja skaleeritavus, suur hulk tasandamismeetodeid, toeks sessioonitabelid.<\/p>\n

Esimene probleem, mille lahendamine on vajalik, on koormuse tasandaja talitlush\u00e4irete v\u00e4ltimine. Lihtsalt koormuse tasandaja paigaldamine loob samuti rikke punkti: koormuse tasandaja eba\u00f5nnestub - teenus kukub v\u00e4lja. Selle v\u00e4ltimiseks kasutasime HAProxy koos ExaBGP-ga.<\/p>\n

ExaBGP v\u00f5imaldab rakendada teenuse seisundi kontrollimise mehhanismi. Me kasutasime seda mehhanismi HAProxy t\u00f6\u00f6kindluse kontrollimiseks ning probleemide ilmnemisel l\u00fclitasime HAProxy teenuse BGP-st v\u00e4lja. <\/p>\n

ExaBGP+HAProxy skeem.<\/b><\/p>\n

    \n
  1. Installime kolmele serverile vajaliku tarkvara, ExaBGP ja HAProxy. <\/li>\n
  2. Loome igas serveris loopback-liidese.<\/li>\n
  3. Kasutame k\u00f5igil kolmel serveril selle liidese jaoks sama avalikku IP-aadressi.<\/li>\n
  4. Avalik IP-aadress kuulutab v\u00e4lja ExaBGP kaudu internetis. <\/li>\n<\/ol>\n

    \nTalitlush\u00e4irete v\u00e4ltimine saavutatakse sama IP-aadressi kuulutamisega k\u00f5igilt kolmest serverist. V\u00f5rgu vaates on tegemist sama aadressiga, mis on saadaval kolme erineva j\u00e4rgmise h\u00fcppena. Ruuter n\u00e4eb kolme identset marsruuti, valib oma meetri alusel k\u00f5ige prioriteetsemalt (tavaliselt on see sama valik) ning liiklus suunatakse ainult \u00fchele serverile. <\/p>\n

    Kui HAProxy t\u00f6\u00f6ga tekivad probleemid v\u00f5i server eba\u00f5nnestub, l\u00f5petab ExaBGP marsruudi kuulutamise ning liiklus sujuvalt l\u00fclitub teisele serverile. <\/p>\n

    Nii saavutasime koormuse tasandaja talitlush\u00e4irete v\u00e4ltimise.<\/p>\n

    \"Kuidas
    \nHAProxy koormuse tasandajate talitlush\u00e4irete v\u00e4ltimine.<\/i><\/p>\n

    Skeem on osutunud mitteideaalseks: me \u00f5ppisime HAProxy varukoopiaid tegema, kuid ei \u00f5ppinud koormust teenuste sees jagama. Seet\u00f5ttu laiendasime skeemi veidi: l\u00e4ksime \u00fcle koormuse tasandamisele mitme avaliku IP-aadressi vahel.<\/p>\n

    DNS ja BGP-p\u00f5hine koormuse tasakaalustamine<\/h2>\n

    \nKoormuse tasakaalustamine meie HAProxy ees on endiselt lahendamata k\u00fcsimus. Siiski, seda on v\u00f5imalik lahendada \u00fcsna lihtsalt, nagu me ka ise tegime.<\/p>\n

    Kolme serveri tasakaalustamiseks on vajalik 3 avalikku IP-aadressi ja vana hea DNS. Iga\u00fcks neist aadressidest m\u00e4\u00e4ratakse iga HAProxy loopback-liidesele ja kuulutatakse internetis. <\/p>\n

    OpenStackis kasutatakse ressursside haldamiseks teenuste katalooge, kus m\u00e4\u00e4ratakse mingisuguse teenuse API l\u00f5pp-punkt. Selles kataloogis kirjutame domeeninime \u2014 public.infra.mail.ru, mis lahendatakse DNS kaudu kolme erineva IP-aadressiga. Tulemuseks on koormuse jaotamine kolme aadressi vahel DNS-i kaudu. <\/p>\n

    Kuna me ei halda avalike IP-aadresside kuulutamisel serveri valimise prioriteete, ei ole see veel tasakaalustamine. \u00dcldiselt valitakse ainult \u00fcks server IP-aadresside vanuse alusel, samas kui kaks teist j\u00e4\u00e4vad k\u00e4est, kuna BGP-s ei ole mingeid meetrikaid m\u00e4\u00e4ratud.<\/p>\n

    Oleme hakanud kuulutama marsruute ExaBGP kaudu erineva meetriku j\u00e4rgi. Iga koormuse tasakaalustaja kuulutab k\u00f5ik kolm avalikku IP-aadressi, kuid \u00fcks neist, antud koormuse tasakaalustaja jaoks peamine, kuulutatakse minimaalse meetrikaga. Seet\u00f5ttu, kuni k\u00f5ik kolm tasakaalustajat on t\u00f6\u00f6s, saavad esimest IP-aadressi ringlusse esimesest tasakaalustajast, teise aadressi teiselt ja kolmanda aadressi kolmandalt.<\/p>\n

    Mis juhtub, kui \u00fcks koormuse tasakaalustajatest t\u00f5rjub? Kui m\u00f5ni koormuse tasakaalustaja eba\u00f5nnestub, kuulutatakse tema p\u00f5hjaadress ikka veel kahe teise kaudu, liiklus nende vahel jaotatakse \u00fcmber. Seel\u00e4bi saame kasutajale DNS kaudu kohe mitu IP-aadressi. DNS-i ja erineva meetrikaga tasakaalustamisega saavutame koormuse \u00fchtlase jaotuse k\u00f5igi kolme tasakaalustaja vahel. Ja samal ajal ei kaota me rikke taluvust.<\/p>\n

    \"Kuidas
    \nHAProxy tasakaalustamine DNS + BGP-p\u00f5hiselt<\/i><\/p>\n

    ExaBGP ja HAProxy vaheline suhtlus<\/h2>\n

    \nSeega oleme rakendanud rikke taluvuse serveri v\u00e4ljalangemise korral, tuginedes marsruutide kuulutamise l\u00f5petamisele. Kuid HAProxy v\u00f5ib sulguda ka muudel p\u00f5hjustel, kui serveri rike: haldusvead, teenuse sisevead. Soovime sellistel juhtudel kahjustatud koormuse tasakaalustaja koormuse alt eemaldada ja seet\u00f5ttu on vajalik teine mehhanism. <\/p>\n

    Seet\u00f5ttu, laiendades eelmist skeemi, rakendasime heartbeat'i ExaBGP ja HAProxy vahel. See on tarkvara rakendus ExaBGP ja HAProxy vahelise suhtluse jaoks, kus ExaBGP kasutab rakenduste staatuse kontrollimiseks kohandatud skripte.<\/p>\n

    Selleks tuleb ExaBGP konfiguratsioonis seadistada tervise kontrollimise t\u00f6\u00f6riist, mis suudab HAProxy staatust j\u00e4lgida. Meie puhul seadistasime HAProxy-s tervise taustteenuse ja ExaBGP kontrollime seda lihtsa GET p\u00e4ringuga. Kui kuulutus l\u00f5petab toimumise, ei tohiks HAProxy t\u00f5en\u00e4oliselt t\u00f6\u00f6tada ja kuulutamine ei ole vajalik. <\/p>\n

    \"Kuidas
    \nHAProxy Tervise Kontroll<\/i><\/p>\n

    HAProxy Peers: sessioonide s\u00fcnkroniseerimine <\/h2>\n

    \nJ\u00e4rgmine, mida tuli teha, oli sessioonide s\u00fcnkroniseerimine. Jaotatud tasakaalustajate kaudu t\u00f6\u00f6tades on keeruline korraldada kliendi sessioonide teabe s\u00e4ilitamist. Kuid HAProxy on \u00fcks v\u00e4heseid tasakaalustajaid, mis suudab seda teha Peers funktsionaalsuse kaudu, mis v\u00f5imaldab edastada HAProxy erinevate protsesside vahel sessioonide tabelid. <\/p>\n

    On olemas erinevaid tasakaalustamise meetodeid: lihtsad, nagu round-robin<\/a><\/noindex>, ja t\u00e4iustatud, kui kliendi sessioon salvestatakse ja ta j\u00f5uab igal korral samale serverile, nagu varem. Soovisime rakendada teist varianti.<\/p>\n

    HAProxy-s kasutatakse kliendi sessioonide s\u00e4ilitamiseks selle mehhanismi stick-tables. Need salvestavad kliendi algse IP-aadressi, valitud sihtaadressi (taustteenus) ja teatud teenuseteavet. \u00dcldiselt kasutatakse stick-tabeleid source-IP ja destination-IP paari s\u00e4ilitamiseks, mis on eriti kasulik rakendustes, mis ei suuda edastada kasutaja sessiooni konteksti teisele tasakaalustajale, n\u00e4iteks RoundRobin tasakaalustamise re\u017eiimis.<\/p>\n

    Kui stick-tabelit \u00f5petada liikuma erinevate HAProxy protsesside vahel (kui toimub tasakaalustamine), saavad meie tasakaalustajad t\u00f6\u00f6tada \u00fche stick-tabelite kogumiga. See v\u00f5imaldab sujuvat kliendi v\u00f5rgu \u00fcleminekut, kui \u00fcks tasakaalustaja kokku kukub, ja kliendi sessioonidega t\u00f6\u00f6tamine j\u00e4tkub valitud taustteenustes, mis olid valitud varem.<\/p>\n

    \u00d5ige toimimise tagamiseks peab olema lahendatud tasakaalustaja source IP-aadressi probleem, millelt sessioon on loodud. Meie puhul on see d\u00fcnaamiline aadress loopback-interf\u00e4\u00e4sil. <\/p>\n

    Peers'i \u00f5ige t\u00f6\u00f6 saavutatakse ainult teatud tingimustes. See t\u00e4hendab, et TCP aegumised peavad olema piisavalt suured v\u00f5i \u00fcleminek peab olema piisavalt kiire, et TCP seanss ei katkeks. Sellegipoolest v\u00f5imaldab see sujuvat \u00fcleminekut. <\/p>\n

    Meie IaaS-is on teenus, mis on ehitatud sama tehnoloogia alusel. See on Load Balancer teenus OpenStacki jaoks<\/a><\/noindex>, mille nimi on Octavia. See p\u00f5hineb kahe HAProxy protsessi baasil ning selles on algselt olemas peer'ide tugi. Selles teenuses on nad end h\u00e4sti t\u00f5estanud.<\/p>\n

    Pildil on diagrammil kujutatud peers-tabelite liikumist kolme HAProxy instantsi vahel, on pakutud konfiguratsioon, kuidas seda seadistada:<\/p>\n

    \"Kuidas
    \nHAProxy Peers (seansside s\u00fcnkroonimine)<\/i><\/p>\n

    Kui te rakendate sarnast skeemi, tuleb selle t\u00f6\u00f6d hoolikalt testida. Pole kindel, et see t\u00f6\u00f6tab samamoodi 100% juhtudel. Kuid v\u00e4hemalt ei kaota te stick-tabeleid, kui on vaja meeles pidada kliendi source IP-d.<\/p>\n

    Piirang samaaegsete p\u00e4ringute arvu peale \u00fchelt ja samalt kliendilt<\/h2>\n

    \nK\u00f5ik avalikud teenused, sealhulgas meie API-d, v\u00f5ivad olla kalduvad p\u00e4ringute laviinidele. Nende p\u00f5hjused v\u00f5ivad olla t\u00e4iesti erinevad, alates kasutajate vigadest kuni sihitud r\u00fcnnakuteni. Meid r\u00fcnnatakse aeg-ajalt DDoS-iga IP-aadresside kaudu. Kliendid teevad sageli vigu oma skriptides, tehes meile mini-DDoS-e.<\/p>\n

    Nii v\u00f5i teisiti tuleb ette n\u00e4ha lisakaitse. Ilmselge lahendus on piirata p\u00e4ringute arvu API-le ja mitte raisata protsessoriaega pahatahtlike p\u00e4ringute t\u00f6\u00f6tlemiseks.<\/p>\n

    Selliste piirangute rakendamiseks kasutame rate limits, mis on organiseeritud HAProxy baasil, samade stick-tabelite abil. Piirangute seadistamine on piisavalt lihtne ja v\u00f5imaldab piirata kasutajat API p\u00e4ringute arvu osas. Algoritm salvestab source IP, kust p\u00e4ringud tehakse, ja piirab sama kasutaja samaaegsete p\u00e4ringute arvu. Loomulikult oleme arvutanud igas teenuses API koormuse keskmise profiili ja seadnud piiri, mis on umbes 10 korda suurem kui see v\u00e4\u00e4rtus. J\u00e4tkame siiani t\u00e4helepanelikku olukorra j\u00e4lgimist, hoides k\u00e4e pulsil.<\/p>\n

    Kuidas see praktikas v\u00e4lja n\u00e4eb? Meil on kliente, kes kasutavad pidevalt meie API-sid automaatselt skaleerimiseks. Nad loovad umbes kakssada-kolmsada virtuaalmasinat varahommikul ja kustutavad need \u00f5htul. OpenStackis virtuaalmasina loomine, koos PaaS-teenustega, t\u00e4hendab v\u00e4hemalt 1000 API-p\u00e4ringut, kuna teenuste vaheline suhtlus toimub samuti l\u00e4bi API. <\/p>\n

    Sellised \u00fclesannete \u00fclekanded tekitavad \u00fcsna suurt koormust. Me hindasime seda koormust, kogusime p\u00e4evased tipud, suurendasime neid k\u00fcmme korda ja see sai meie rate-limiidiks. Hoidke k\u00e4t pulsil. N\u00e4eme tihti roboteid, skaneerijaid, kes proovivad meie peale vaadata, kas meil on mingeid CGA-skripte, mida k\u00e4ivitada, ja me l\u00f5ikame neid aktiivselt.<\/p>\n

    Kuidas v\u00e4rskendada koodibaasi kasutajatele m\u00e4rkamatult<\/h2>\n

    \nKasutame ka koodi juurutamise protsesside tasemel t\u00f5rketaluvust. Juurutamise ajal v\u00f5ivad esineda t\u00f5rked, kuid nende m\u00f5ju teenuste k\u00e4ttesaadavusele saab minimeerida.<\/p>\n

    Uuendame pidevalt oma teenuseid ja peame tagama koodibaasi uuendamise protsessi ilma kasutajatele m\u00f5ju avaldamata. Selle \u00fclesande lahendamine \u00f5nnestus meil, kasutades HAProxy haldusv\u00f5imalusi ja meie teenustes Graceful Shutdowni rakendamist.<\/p>\n

    Selle \u00fclesande lahendamiseks oli vajalik tagada koormuse ja \u201e\u00f5ige\u201d teenuste v\u00e4ljal\u00fclitamine:<\/p>\n