Cum comprimăm mesajele Pub / Sub și mai mult, economisirea unui volum de bani

(29 dec. 2020)

Compresia este un truc care poate fi folosit pentru a rezolva o mulțime de probleme. Adesea, instrumentele dvs. vor comprima conținutul în mod transparent: majoritatea browserelor moderne solicită încărcarea HTTP gzipată, iar unele sisteme de fișiere pot fi configurate pentru a comprima blocuri fără ca utilizatorul să întrebe vreodată.

În afara cazurilor de utilizare bine cunoscute, există o varietate de oportunități de îmbunătățire a eficienței sau de economisire a unei sume de bani prin folosirea compresiei Este util să fiți conștienți de cazurile de utilizare obișnuite, astfel încât să puteți profita de aceste oportunități atunci când apar.

Migrarea jurnalelor

Ca exemplu recent, echipa mea migra jurnalele dintr-un cluster Elasticsearch altcuiva. Deși nu este chiar Big Data ™, acest cluster avea 10 miliarde de intrări de jurnal sau aproximativ 60 TB de JSON brut.

Având experiență în abordarea migrațiilor pe scară largă, de lungă durată, ca acesta, doriți să construiți un proces care să vă permite să „salvați jocul” cât mai des posibil. Aceasta înseamnă că puteți construi și rula un proces de export, gestionând orice probleme care vor apărea (vor promite!), Apoi treceți în mod curat la procesul de import. La fel ca în cazul exporturilor, procesul dvs. de import se va descurca, de asemenea, și el ar trebui să poată fi rulat cu ușurință.

Întrucât este utilizat pe o mulțime de sisteme GoCardless, Google Pub / Sub este o soluție naturală pentru această problemă. Sloganul de marketing Google pare chiar că a fost scris pentru a descrie procesul nostru ideal, decuplat:

Pub / Sub este un serviciu de mesagerie asincronă care decuplează serviciile care produc evenimente de servicii care procesează evenimente.

În Pub / Sub, publicați mesaje pe subiecte . Fiecare subiect poate avea multe abonamente, din care consumatorii pot extrage mesaje . În termenii cei mai simpli, migrarea ar:

  1. Exporta jurnalele din clusterul de origine într-un subiect (pe index) Pub / Sub
  2. Configurează abonamentele Pub / Sub pentru a păstra evenimentele (setați retain\_acked\_messages, consultați: Redarea și eliminarea mesajelor ), astfel încât să le putem reda, dacă importul nu merge bine
  3. Importați jurnalele extragând mesaje din abonamentele la subiect

Deci, ce legătură are asta cu compresia? La fel ca majoritatea serviciilor Cloud, taxele Pub / Sub pentru utilizare, ceea ce înseamnă că vom suporta taxe proporționale cu datele pe care le vom trece prin serviciu.

Aceste taxe sunt: ​​

  • 40 USD pe TiB livrat, aplicat pentru publicare și abonare
  • Tarifele rețelei Google Compute Engine (le vom ignora, deoarece se complică)
  • Căutați stocarea mesajelor, pentru a păstrați mesajele noastre, la 0,27 USD pe lună GiB

În cel mai bun caz în care importăm / exportăm cu succes la prima încercare (acest lucru nu se va întâmpla și nu s-a întâmplat), vom să fie taxat 2 x 40 $ x 60 TB = 4.800 USD pentru livrarea mesajului , deoarece se va aplica atât publicării, cât și abonării. Dacă ne păstrăm mesajele timp de 2 săptămâni în timp ce migrarea este în curs, vom fi taxați cu 0,5 x 0,27 USD x 60 000 GB = 8.100 USD pentru stocarea mesajelor .

Acest lucru lasă o limită inferioară de 12.900 USD pentru a efectua migrarea .

Acum, GoCardless nu este slab. Și, de regulă, doriți să optimizați pentru ore de inginerie peste costul infrastructurii.

Dar dacă puteți reduce costurile cu o cantitate minimă de efort, ar trebui.

Publicarea mesaje comprimate

În acest scop, am făcut o mică modificare a instrumentului nostru de migrare (elastic-toolbox) pentru a sprijini compresia mesajelor pe care le-am publicat în Pub / Sub.

Cu eliminarea gestionării erorilor, aceasta este metoda de publicare, unde aplicăm compresia după serializare:

Aplicarea condiționată a compresiei unei sarcini utile a mesajelor

Compresia în sine este complet simplă și cod de observabilitate aproape în întregime:

Implementarea compresiei gzip, cu observabilitate

Deoarece economiile noastre vor fi proporționale cu raportul nostru de compresie (octetii comprimați / originali), ne pasă foarte mult de modul în care compresibil datele noastre sunt.

Jurnalele JSON sunt probabil foarte comprimabile, deoarece:

  • Jurnalele partajează multe dintre cheile JSON, care pot fi de-duplicate (kubernetes.pod\_name)>
  • Valorile câmpurilor de jurnal comune pot apărea foarte des (kubernetes.labels.namespace)

Utilizând elastic-toolbox pentru a rula un export simultan de trei indici diferiți, putem utiliza elastic\_toolbox\_export\_pubsub\_write\_compression\_ratio metrica Prometheus (consultați compress metoda de mai sus) pentru a construi o hartă de căldură a raporturilor de compresie:

Comprimat octeți / octeți originali, întotdeauna 0\%

Această hartă arată că toate mesajele comprimate la cel mult 30\% dimensiunea originală . Atunci când sunt măsurate pe întreg corpul nostru de jurnale, avem o medie la un ~ 12\% raport de compresie, ceea ce înseamnă că 1 GiB de jurnale devine doar 120 MiB. >

Factura noastră inițială de 12.900 USD a devenit 12\% x 12.900 USD = 1.548 USD.

Aceasta înseamnă am economisit aproximativ 11.500 USD.

Explorează datele pentru tine la acest Instantaneu Raintank: compresie elastică a cutiei de instrumente .

Pasul următor? Aplicați cu normă întreagă.

Cel mai evident pas următor a fost să aplicăm acest lucru la conducta noastră de înregistrare tot timpul. Având în vedere că livrăm jurnalele de containere direct în Pub / Sub, scoțându-le dintr-un abonament în Elasticsearch, putem scrie cu ușurință un filtru fluentd care aplică aceeași strategie de compresie.

Colegul meu Ben a pus la punct un tablou de bord minunat pentru a urmări cât economisim, ceea ce se dovedește a fi câteva mii pe lună :

Economii de la comprimarea jurnalelor când intră în conducta de înregistrare

Unde mai poate ajuta compresia?

Dacă lucrați într-un mediu cloud, există atât de multe oportunități de a economisiți bani prin comprimarea datelor dvs.

Dincolo de jurnale, un alt exemplu GoCardless este un instrument numit draupnir . Acest serviciu găzduiește copii ale bazelor noastre de date de producție pentru testarea încărcării și analiza criminalistică (predicția planului de interogare etc.). Spațiul de stocare Google SSD costă 187 USD per TiB / lună, ceea ce înseamnă că fiecare copie a 5TB Postgres costă 1.000 USD / lună .

Draupnir ar putea găzdui mai multe copii la un moment dat, în funcție de cazurile de utilizare. Putem economisi o mulțime de bani activând compresia btrfs pentru a comprima în mod transparent blocurile sistemului de fișiere, permițându-ne să folosim ~ 70\% mai puțină capacitate SSD decât am putea altfel.

Și dacă ați crezut că compresia este limitată la reducerea costurilor, v-ați înșela! După ce am suferit de întreruperi ocazionale când oamenii au efectuat completări mari sau au construit noi indexuri de baze de date, am rezolvat problema activând compresia Postgres WAL (vezi Caracteristici Postgres subutilizate: compresie WAL , sau Postgres Write Ahead Log docs ).

Intreruperile au fost cauzate de operațiile bazei de date care creează o cantitate mare de churn WAL, unde replica se va bloca în timp ce scrie WAL pe disc. Prin comprimarea fluxului WAL, am redus semnificativ vârfurile IO, permițând replicii să gestioneze fluxul fără probleme .

Există mai multe exemple, dar cred că acest lucru dă o imagine bună.

Cum vă ajută acest lucru?

Compresia este un compromis, o decizie pe care o luăm tranzacționați CPU cu o altă resursă care ar putea fi mai scumpă sau mai puțin disponibilă. Valoarea alocată procesorului, memoriei sau lățimii de bandă a rețelei se modifică continuu și va trebui să faceți acest calcul de la caz la caz.

Această postare urmărea să acopere un scenariu în care costul compresia, atât în ​​resursele de calcul, cât și în timpul de construire, a fost semnificativ depășită de economiile pe care le-ar face. Nu toate situațiile vor avea aceeași economie, dar este nevoie de câteva minute de matematică a șervețelului pentru a decide în ambele sensuri.

Sper că acest studiu de caz solicită luarea în considerare a compresiei în afara cazurilor de utilizare plictisitoare standard și ajută pentru a găsi oportunități în care o puteți aplica propriilor sisteme.

Discutați despre această postare pe Hackernews .

Publicat inițial la https: // blog .lawrencejones.dev pe 29 decembrie 2020.