Hyvä työpäivä

Palasin viime viikolla muutaman vapaapäivän jälkeen töihin. Lueskelin läpi tällä aikaa käydyt keskustelut ja näin sieltä, että tuotantoympäristön Rediksen kanssa on ollut ongelmia. AWSn Redis-palvelussa on dokumentoimaton yläraja uusille yhteyksille. Pellin alla palvelu pyörii tietysti Linux-pannuilla ja niissä on aina rajallinen määrä portteja käytössä. Jos koodi käyttää paljon Redistä, niin uusien Redis-yhteyksien määrä voi ylittää koko käyttöjärjestelmän vapaiden porttien määrän. Tällöin Redikseen ei yhtäkkiä saakaan yhteyttä ja päädytään ongelmiin. Jos saitilla ei ole käyttäjiä, niin tällaisiin ylärajoihin törmäämisestä voi vain haaveilla. Silloin kun pyöritetään liikennemääriltään Suomen top kympissä olevaa saittikokonaisuutta, joka käyttää paljon Redistä, tilanne onkin erilainen. Ihan normaali käyttäjäliikenne saattaa päätyä niin kovaksi, että Redis-yhteyksien yläraja paukkuu jollain palvelimella. Ja näin meille kävi.

Samaan ylärajaan oli törmätty aiemminkin ja silloin tilanne ratkaistiin shardauksella. Eli siis jakamalla Rediksen data useammalle palvelimelle. Tällä tavalla saadaan myös Redis-liikenne jaettua useamman palvelimen kesken. Shardeja voi myös lisätä lennosta, joten ongelmatilanteessa Redistä pystyy skaalaamaan käyttäjien sitä huomaamatta. Autoskaalaukseen ratkaisu ei kyllä taivu, koska shardien lukumäärää ei pysty pienentämään lennosta. Mikä on AWSmäisen typerää.

AWS: “Tällä tavalla voit antaa meille lisää rahaa helposti.”
Asiakas: “Kiva. Entäs miten pystyisin säästämään rahaa?”
AWS: “Se ei valitettavasti onnistu.”

Koska uusien yhteyksien ylärajaan oli jo aiemmin törmätty ja käyrät näyttivät siltä, että lähellä rajoja mennään tälläkin hetkellä, oli varmuuden vuoksi lisätty pari shardia Redis-klusteriin. Valitettavasti tämä ei aina auta. Shardaus tehdään avaimen perusteella ja jos esimerkiksi ylivoimaisesti käytetyin avain saa shardauslokeron 16384/16384, niin shardien lukumäärästä huolimatta liikenne päätyy aina viimeiselle shardille. Jotain vastaavaa kävi myös meille ja lisätyistä shardeista huolimatta ylärajat paukkuivat. Jokaisessa shardissa on yksi master ja n-kappaletta slaveja. AWS-supportin innokas tyyppi suositteli meille slavejen lisäämistä, joten tätä päätettiin kokeilla. Valitettavasti tätä ei voi tehdä helposti kenenkään huomaamatta ja Redis-dataa hävittämättä.

Uutta järeämpää klusteria uusilla slaveilla viriteltiin tulille ja mietittiin miten se saadaan käyttöön aiheuttamatta liikaa ongelmia käyttäjille. Tässä vaiheessa päätin lähteä minimoimaan Redis-liikennettä. Äänitin hetken aikaa aktiivisimman serverin Redis-liikennettä MONITOR komennolla. Sen jälkeen muutamat Linux-loitsut ja edessä oli pullonkaula-serverin top 50 käytetyintä avainta. Tämän jälkeen lähdin kaivelemaan koodia ja etsimään ne kohdat, jotka lukevat ja kirjoittavat näitä avaimia. Kun koodia on yli miljoona riviä ei homma välttämättä ole ihan triviaali. Lopulta sopivat kohdat löytyivät ja muutin ne sellaisiksi, että ne käyttävätkin docker-kontin muistia Rediksen sijaan. Sitten testasin näiden sokkona tehtyjen muutosten toimivuuden testiympäristössä ja lopuksi vein ne tuotantoon. Tässä on lopputulos.

Saatat huomata käyrässä klo 13 liveksi menneiden muutosten vaikutukset. Lisäksi mitään havaittavaa huonoa puolta ei muutoksilla tuntunut olevan. Voin sanoa, että tällaisesta tulee kyllä hyvä mieli! Säästetään asiakkaan rahoja ja maailman luonnonvaroja. Samalla viilataan saittia hieman nopeammaksi ja ratkotaan tuotantoympäristön kipupisteitä. Lopulta meidän järeämmän Redis-klusterin virittely unohdettiin ja päätettiinkin suurentamisen sijaan pienentää Redis-klusteria.

Sanoisin, että erittäin hyvin käytetyt kolme työtuntia! Lisää tällaisia työpäiviä meille kaikille!