Hälytykset, jotka laukeavat kerran, eivät kerran palvelinta kohden

Yksi operatiivisista hälytyksistämme, ”vähäiset krediitit” rakentajan julkaistulle sovellukselle, on tarkoitettu tavoittamaan meidät enintään kerran päivässä. Eräänä iltapäivänä se tuli viisi kertaa. Syy: jokainen API-kopiomme muisti omaan muistiinsa, mitkä hälytykset se oli jo lähettänyt, joten kaksi palvelinta lähetti sen kahdesti, ja jokainen deploy pyyhki muistin ja antoi niiden lähettää sen uudelleen. Sama kuvio sai myös taustatyön tekemään työnsä kahdesti. Molemmat koordinoivat nyt jaetun tallennuksen kautta, ja molemmat epäonnistuvat turvallisella puolella, jos se ei ole käytettävissä.

Oire

Mythex lähettää tiimille hälytyksiä, kun jokin vaatii huomiota: palvelu on alhaalla, työ jumittuu tai rakentajan krediittisaldo on vähissä, kun hänen sovelluksensa on julkaistuna. Jokaisella hälytyksellä on deduplikointi-ikkuna, eli aika, jonka aikana saman hälytyksen lähetetään vain kerran. Vähäisten krediittien hälytyksellä se on 24 tuntia.

Viisi saman hälytyksen kopiota yhden iltapäivän aikana tarkoitti, että ikkuna ei pitänyt. Pahempaa oli, että ne tulivat pareittain, noin 11 minuutin välein.

Miksi näin tapahtui

Hälytyspakettimme piti deduplikoinnin muistissa: taulukko ”hälytysavain → milloin se lähetettiin viimeksi” käynnissä olevan prosessin sisällä. Se toimii, kun on yksi prosessi, joka ei koskaan käynnisty uudelleen. Tuotannossa ei ole kumpaakaan:

• Kaksi API-replikaa. Tuotannossa on kaksi API-kopiota. Kummallakin oli oma taulukkonsa, joten kumpikin lähetti hälytyksen kerran. Ne ovat ne parit.
• Deployt. Jokainen deploy korvaa molemmat replikat uusilla prosesseilla ja tyhjillä taulukoilla. Deployn jälkeen hälytys lähti uudelleen, ikään kuin sitä ei olisi koskaan lähetetty.

Noin 11 minuutin väli parin kahden hälytyksen välillä tuli työstä, joka nostaa tämän hälytyksen. Se ajaa molemmilla replikoilla ja ottaa lukon, joten replikat vuorottelevat, ja kumpikin nosti hälytyksen vuoronsa tullessa.

Samassa koodissa oli toinen, hiljaisempi virhe. Jotta taulukko ei kasvaisi loputtomiin, se siivosi itsensä, kun siinä oli 500 avainta, poistamalla kaikki yli 15 minuuttia vanhat merkinnät riippumatta niiden ikkunasta. Kuormituksen alla 24 tunnin deduplikointi saattoi kestää vain varttitunnin.

Korjaus

Yksi jaettu tietue per hälytys

Ennen kuin API lähettää hälytyksen, se varaa hälytyksen deduplikointiavaimen Redisissä. Redis on jaettu muistitallennus, johon molemmat replikat puhuvat ja joka ei käynnisty uudelleen, kun API käynnistyy. Varaus on yksi operaatio: ”aseta tämä avain vain, jos sitä ei ole, ja vanhenna se ikkunan jälkeen”. Replika, joka varaa avaimen ensin, lähettää hälytyksen. Toinen löytää avaimen varatuksi ja pysyy hiljaa. Deployn jälkeen uusi prosessi löytää avaimen yhä paikallaan.

Avain ja ikkuna tulevat samasta säännöstä, jota hälytyspaketti käyttää, ja sääntö on nyt jaettu molempien tasojen kesken. Ne eivät voi olla eri mieltä siitä, mikä lasketaan ”samaksi hälytykseksi”.

Epäonnistu avoimena, ei suljettuna

Tärkein päätös koski sitä, mitä tehdään, kun Redisiin ei saada yhteyttä. Päätimme lähettää hälytyksen silti. Jos Redis on alhaalla tai ei vastaa 1,5 sekunnin kuluessa, hälytys lähtee. Päällekkäinen hälytys on kohinaa. Pudotettu hälytys tarkoittaa, että joku ei saa tietää asiasta.

Vakavimpia hälytyksiä, P0-tason hälytyksiä, deduplikointi ei pidätä koskaan.

Jokaisella merkinnällä on oma ikkunansa

Hälytyspaketin oman muistissa olevan deduplikoinnin jokainen merkintä tallentaa nyt, milloin sen ikkuna päättyy, ja siivous poistaa vain merkinnät, joiden ikkuna on ohi. 24 tunnin avain pysyy 24 tuntia, riippumatta siitä, kuinka monta muuta hälytystä saapuu.

Sama virhe muualla

Sama kuvio oli kaksinkertaistanut myös osan taustatyöstä: täsmäytystyön, joka pitää kirjanpidossamme jokaisen työtilan tilan linjassa hiekkalaatikkopalveluntarjoajamme kanssa. Jokainen kierros listaa jokaisen hiekkalaatikon tilillä, tuotannossa tuhansia, noin viisi sekuntia, sekä jokaisen käynnissä olevan tai pysäytetyn projektin. Molemmat replikat ajoivat sen joka kahdes minuutti.

Sen kirjoitukset ovat idempotentteja, eli kahdesti ajaminen antaa saman tuloksen kuin kerran ajaminen, joten mikään ei hajonnut. Se oli vain kaksinkertainen työmäärä. Nyt jokainen kahden minuutin ikkuna varataan Redisissä samalla tavalla kuin käyttömittarimme jo varasivat omansa, ja vain se replika, joka varaa ikkunan, ajaa kierroksen. Jos Redisiin ei saada yhteyttä, kierros ajetaan silti: työn tekeminen kahdesti on vaaratonta, mutta sen tekemättä jättäminen ei ole.

Miten testasimme

Testit mallintavat todellisen asetelman. Ne lataavat hälytysmoduulin kahdesti, kuin kaksi erillistä ”replikaa”, osoittavat molemmat yhteen jaettuun tallennukseen, lähettävät saman hälytyksen kummastakin ja lataavat sitten kolmannen tuoreen kopion, joka edustaa ”deployn jälkeistä tilaa”, ja lähettävät hälytyksen uudelleen. Täsmälleen yksi hälytys lähtee. Muut testit varmistavat, että toisen rakentajan hälytys menee perille, että P0 lähtee molemmista replikoista ja että hälytys lähtee silloinkin, kun tallennus on alhaalla tai ylittää aikarajan. Siivauskorjauksella on oma testinsä: 24 tunnin avain säilyy, kun 600 muuta hälytystä saapuu 20 minuutin kuluttua.

Täsmäytystyölle testasimme kaksi replikaa, jotka käyvät samaan aikaan, ja kolmannen käynnin samassa ikkunassa. Tuloksena on yksi listaus.

Mitä opimme

• Muistissa oleva tila on prosessikohtaista. Kaikki, minkä täytyy pitää paikkansa palvelinten välillä, ”lähetetty kerran” tai ”ajettu kerran”, tarvitsee paikan, jonka ne jakavat.
• Deployt ovat uudelleenkäynnistyksiä. Tila, joka säilyy vain seuraavaan uudelleenkäynnistykseen asti, ei säily tavallisen työpäivän yli.
• Päätä, kumpaan suuntaan epäonnistutaan. Hälytyksissä jaetun tallennuksen alashan tarkoittaa enemmän hälytyksiä, ei vähemmän.
• Etsi kuvio, älä vain esiintymää. Hälytys oli äänekäs tapaus. Kaksinkertaistettu täsmäytystyö oli sama virhe, joka hiljaa maksoi työmäärää.

Tästä ei näe mitään Mythexin sisältä. Lisää siitä, miten pidämme alustan vakaana, löytyy artikkeleista miten saimme deployt nollaan 502-virheeseen ja puuttuva swap-tiedosto. Jos olet uusi ajatukseen useammasta palvelinkopiosta, mikä on palvelin -opas kertoo perusteet.