Kuinka pakataan Pub / Sub-viestit ja enemmän, säästät paljon rahaa

(29. joulukuuta 2020)

Pakkaus on temppu, jota voidaan käyttää ongelmien ratkaisemiseen. Työkalusi pakkaavat sisältöä usein läpinäkyvästi: useimmat modernit selaimet pyytävät pakattua HTTP-hyötykuormaa, ja jotkut tiedostojärjestelmät voidaan määrittää pakkaamaan lohkot ilman käyttäjän koskaan kysyttävää.

Tunnettujen käyttötapausten ulkopuolella on erilaisia ​​mahdollisuuksia parantaa tehokkuutta tai säästää rahaa lisäämällä pakkausta. On hyödyllistä olla tietoinen tavallisista käyttötapauksista, joten voit käyttää näitä mahdollisuuksia, kun ne syntyvät.

Lokien siirtäminen

Tuoreena esimerkkinä tiimini oli siirtämässä lokeja yhdestä Elasticsearch-klusterista. toiselle. Vaikka tämä klusteri ei olekaan aivan iso data ™, sillä oli 10 miljardia lokimerkintää tai noin 60 Tt raakaa JSON-tiedostoa.

Koska sinulla on kokemusta tällaisten pitkäaikaisten ja laajamittaisten siirtojen torjunnasta, haluat rakentaa prosessin, joka avulla voit ”pelata peliä” niin usein kuin mahdollista. Tämä tarkoittaa sitä, että voit rakentaa ja suorittaa vientiprosessin käsittelemällä mahdolliset ongelmat (ne tulevat, lupaan!) Ja siirtyä sitten puhtaasti tuontiprosessiin. Kuten viennin kohdalla, myös tuontimenettelysi menee rikki: joten myös sen pitäisi olla helposti suoritettavissa uudelleen.

Koska sitä käytetään GoCardless-järjestelmien kuormituksessa, Google Pub / Sub sopii luonnollisesti tähän ongelmaan. Googlen markkinointitunniste kuulostaa jopa siltä, ​​että se on kirjoitettu kuvaamaan ihanteellista, erotettua prosessia:

Pub / Sub on asynkroninen viestipalvelu, joka erottaa palvelut, jotka tuottavat tapahtumia tapahtumia käsittelevistä palveluista.

Pub / Sub-julkaisussa julkaiset viestejä aiheisiin . Jokaisella aihealueella voi olla useita tilauksia, joista kuluttajat voivat hakea viestejä . Yksinkertaisimmalla tavalla siirto:

  1. Vie lokit alkuryhmästä (hakemistokohtaiseen) Pub / Sub-aiheeseen
  2. Määritä Pub / Sub-tilaukset ylläpitää tapahtumia (set retain\_acked\_messages, katso: Viestien toistaminen ja puhdistaminen ), jotta voimme toistaa ne uudelleen, jos tuonti menee pieleen
  3. Tuo lokit vetämällä viestejä aiheen tilauksista

Joten mitä tässä on tekemistä pakkaamisen kanssa? Kuten useimmat pilvipalvelut, Pub / Sub veloittaa käyttömaksut, mikä tarkoittaa, että perimme palvelun kautta välitettäviin tietoihin suhteutetut maksut.

Nämä maksut ovat:

  • 40 dollaria kutakin toimitettua TiB: tä kohti, sovellettu julkaisemiseen ja tilaamiseen
  • Google Compute Engine -verkkoprosentit (ohitamme nämä, koska ne monimutkaistuvat)
  • Hakuhakuun liittyvien viestien tallennustila säilytämme viestimme, hintaan 0,27 dollaria / GiB-kuukausi.

Parhaassa tapauksessa, kun tuomme / vietään onnistuneesti ensimmäisellä yrityksellä (näin ei käynyt eikä käynyt), veloitetaan 2 x 40 dollaria x 60TB = 4800 dollaria viestien toimittamisesta , koska sitä sovelletaan sekä julkaisemiseen että tilaamiseen. Jos säilytämme viestejä 2 viikkoa siirron aikana, veloitamme 0,5 x 0,27 dollaria x 60 000 Gt = 8 100 dollaria viestien tallennuksesta .

Tämä jättää alarajan 12 900 dollaria siirron suorittamiseksi .

Nyt GoCardless ei ole huono. Nyrkkisääntönä on, että yleensä haluat optimoida suunnitteluaikaa infrastruktuurikustannusten yli.

Mutta jos pystyt vähentämään kustannuksia pienellä vaivalla, sinun pitäisi.

Julkaiseminen pakatut viestit

Tätä varten teimme pienen muutoksen siirtotyökaluun (elastic-toolbox) tukemaan Pub / Sub-sivustoon julkaisemiemme viestien pakkaamista.

Kun virheenkäsittely on poistettu, tämä on julkaisutapa, jossa kompressointia käytetään sarjoituksen jälkeen:

Pakkauksen lisääminen ehdollisesti viestin hyötykuormaan

Pakkaus itsessään on yksinkertainen ja melkein kokonaan havaittavissa oleva koodi:

Gzip-pakkauksen toteuttaminen havainnoitavissa

Koska säästömme ovat verrannollisia pakkaussuhteeseemme (pakatut / alkuperäiset tavut), välitämme paljon siitä, kuinka pakkaamattomat tietomme ovat.

JSON-lokit ovat todennäköisesti hyvin pakattavia:

  • Lokit jakavat monia JSON-avaimia, jotka voidaan kopioida (kubernetes.pod\_name)
  • Yhteisten lokikenttien arvoja voi esiintyä hyvin usein (kubernetes.labels.namespace)

Muokatun elastic-toolbox kolmen eri indeksin samanaikaisen viennin suorittamiseksi voimme käyttää elastic\_toolbox\_export\_pubsub\_write\_compression\_ratio Prometheus-metriikkaa (katso compress menetelmä yllä) rakentaa pakkaussuhteiden lämpökartta:

Pakattu tavua / alkuperäisiä tavuja, aina 0\%

Tämä lämpökartta osoittaa, että kaikki korkeintaan 30\% alkuperäisestä koosta . Mitattuna koko lokikokonaisuuttamme keskiarvo on ~ 12\%: n puristussuhteella, mikä tarkoittaa, että 1GiB lokista tulee vain 120MiB.

Alkuperäisestä 12 900 dollarin laskustamme on tullut 12\% x 12 900 dollaria = 1 548 dollaria.

Tämä tarkoittaa , että olemme säästäneet noin 11 500 dollaria.

Tutki tietoja itse tällä Raintank Snapshot: elastinen-työkalupakki-pakkauksella .

Seuraava vaihe? Käytä kokopäiväisesti.

Ilmeisin seuraava askel oli soveltaa tätä koko ajan puunkorjuuputkellemme. Kun lähetämme konttilokit suoraan Pub / Sub-osioon vetämällä ne pois tilauksesta Elasticsearchiin, voimme helposti kirjoittaa fluentd -suodattimen, joka käyttää samaa pakkausstrategiaa.

Kollegani Ben kootti mahtavan kojelaudan seuraamaan säästämistämme, mikä on useita tuhansia kuukaudessa :

Säästöt lokien pakkaamisesta, kun ne saapuvat kirjausputkelle

Mistä muusta pakkaamisesta voi olla apua?

Jos työskentelet pilviympäristössä, on niin paljon mahdollisuuksia säästä rahaa pakkaamalla tietoja.

Lokien lisäksi toinen GoCardless-esimerkki on työkalu nimeltä draupnir . Tämä palvelu isännöi kopioita tuotantotietokannoistamme kuormitustestausta ja rikosteknistä analyysia varten (kyselysuunnitelman ennustaminen jne.). Google SSD -tallennustila maksaa 187 dollaria / TiB / kk, mikä tarkoittaa, että jokainen kopio 5TB Postgres -maksustamme maksaa 1000 dollaria kuukaudessa .

Draupnir saattaa isännöidä useita kopioita kerrallaan käyttötapauksista riippuen. Voimme säästää paljon rahaa mahdollistamalla btrfs-pakkauksen pakkaamaan tiedostojärjestelmälohkot läpinäkyvästi, jolloin voimme käyttää ~ 70\% vähemmän SSD-kapasiteettia kuin voimme muuten.

Ja jos luulet pakkaamisen rajoittuvan kustannussäästöihin, olisit väärässä! Olemme kärsineet satunnaisista mikrohäiriöistä, kun ihmiset suorittivat suuria täytteitä tai rakensivat uusia tietokantahakemistoja, joten ratkaisimme ongelman ottamalla käyttöön Postgres WAL -pakkauksen (katso Postgres Underused Features: WAL Compression tai Postgres Write Ahead Log -asiakirjat ).

Katkokset johtuivat tietokantatoiminnoista, jotka loivat suuren määrän WAL-vaihtelua, missä kopio pysähtyi kirjoittaessaan WAL-levyä levylle. Pakkaamalla WAL-virran vähensimme merkittävästi IO-piikkejä, jolloin replikan pystyi käsittelemään virtaa ongelmitta .

Esimerkkejä on enemmän, mutta mielestäni tämä antaa hyvän kuvan.

Kuinka tämä auttaa sinua?

Pakkaus on kompromissi, päätöksen, johon teemme käy kauppaa suorittimella toiselle resurssille, joka voi olla kalliimpi tai vähemmän käytettävissä. Suorittimelle, muistille tai verkon kaistanleveydelle määritetty arvo muuttuu jatkuvasti, ja sinun on tehtävä tämä laskelma tapauskohtaisesti.

Tämän viestin tarkoituksena oli kattaa skenaario, jossa pakkaaminen, sekä laskennallisessa resurssissa että rakennusajassa, ylitti merkittävästi sen säästöt. Kaikissa tilanteissa ei ole samaa taloutta, mutta kumpaankin suuntaan kuluminen kestää muutaman minuutin lautasliinamatematiikkaa.

Toivon, että tämä tapaustutkimus kehottaa harkitsemaan pakkaamista tavallisten, tylsien käyttötapojen ulkopuolella ja auttaa löytää mahdollisuuksia, joissa voit soveltaa sitä omiin järjestelmiin.

Keskustele tästä viestistä Hackernews .

Alun perin julkaistu osoitteessa https: // blogi .lawrencejones.dev 29. joulukuuta 2020.