Sådan komprimerer vi Pub / Sub-meddelelser og mere, at spare en masse penge

(29. dec. 2020)

Kompression er et trick, der kan bruges til at løse en masse problemer. Ofte komprimerer dine værktøjer indhold gennemsigtigt: de fleste moderne browsere beder om gzipped HTTP-nyttelast, og nogle filsystemer kan konfigureres til at komprimere blokke uden at brugeren nogensinde spørger.

Uden for kendte brugssager er der en række muligheder for at forbedre effektiviteten eller spare en masse penge ved at udnytte komprimering. Det er nyttigt at være opmærksom på almindelige brugssager, så du kan udnytte disse muligheder, når de opstår.

Migrering af logfiler

Som et nylig eksempel migrerede mit team logfiler fra en Elasticsearch-klynge. til en anden. Selvom det ikke var helt Big Data ™, havde denne klynge 10 milliarder logposter eller ca. 60 TB rå JSON.

Har du erfaring med at tackle langvarige store migrationer som denne, vil du bygge en proces, der giver dig mulighed for at gemme spil så ofte som muligt. Dette betyder, at du kan opbygge og køre en eksportproces, håndtere de problemer, der opstår (de vil, det lover jeg!) Og derefter gå rent videre til importprocessen. Som med eksport vil din importproces også skrue op: så den skal også let kunne køres igen.

Da den bruges på tværs af en masse GoCardless-systemer, Google Pub / Sub er en naturlig pasform til dette problem. Googles marketing-tagline lyder endda som om den blev skrevet for at beskrive vores ideelle, afkoblede proces:

Pub / Sub er en asynkron messaging-tjeneste, der afkobler tjenester, der producerer begivenheder fra tjenester, der behandler begivenheder.

I Pub / Sub offentliggør du meddelelser til emner . Hvert emne kan have mange abonnementer, som forbrugere kan hente beskeder fra . I de mest enkle termer ville migrationen:

  1. Eksportere logfiler fra oprindelsesklyngen til et (pr. Indeks) Pub / Underemne
  2. Konfigurer Pub / Sub-abonnementerne for at bevare begivenheder (sæt retain\_acked\_messages, se: Afspilning og rensning af meddelelser ), så vi kan afspille dem igen, hvis vores import går galt
  3. Importer logfiler ved at trække beskeder fra emneabonnementerne

Så hvad har dette at gøre med komprimering? Som de fleste cloudtjenester opkræves pub / sub-gebyrer ved brug, hvilket betyder, at vi opkræver gebyrer, der er proportionale med de data, vi sender igennem tjenesten.

Disse gebyrer er:

  • $ 40 pr. leveret TiB, anvendt til at udgive og abonnere
  • Google Compute Engine-netværkshastigheder (vi ignorerer disse, da de bliver komplicerede)
  • Søgerelateret meddelelseslagring for at bevarer vores meddelelser til $ 0,27 pr. GiB-måned

I bedste tilfælde hvor vi importerer / eksporterer med succes ved første forsøg (dette vil ikke og skete ikke), vil vi blive opkrævet 2 x $ 40 x 60TB = $ 4.800 for meddelelseslevering , da det gælder for både udgivelse og abonnement. Hvis vi opbevarer vores meddelelser i 2 uger, mens overførslen pågår, debiteres vi 0,5 x $ 0,27 x 60.000 GB = $ 8.100 for beskedlagring .

Dette efterlader en lavere grænse på $ 12.900 for at udføre migrationen .

Nu er GoCardless ikke dårlig. Og som en tommelfingerregel vil du normalt optimere til tekniske timer over infrastrukturomkostninger.

Men hvis du kan reducere omkostningerne med en minimal indsats, skal du gøre det.

Publishing komprimerede meddelelser

Til dette formål foretog vi en lille ændring i vores migreringsværktøj (elastic-toolbox) for at understøtte komprimering af de meddelelser, vi offentliggjorde til Pub / Sub.

Når fejlhåndtering er fjernet, er dette publiceringsmetoden, hvor vi anvender komprimering efter serialisering:

Betinget anvendelse af komprimering på en meddelelsesnyttelast

Selve komprimeringen er død enkel og næsten udelukkende observerbarhedskode:

Implementering af gzip-komprimering med observerbarhed

Da vores besparelser vil være proportionale med vores kompressionsforhold (komprimerede / originale byte), er vi meget interesserede i, hvordan komprimerbare vores data er.

JSON-logfiler er sandsynligvis meget komprimerbare, da:

  • Logfiler deler mange af JSON-tasterne, som kan de-dupliceres (kubernetes.pod\_name)
  • Værdier for almindelige logfelter kan forekomme meget ofte (kubernetes.labels.namespace)

Brug af den ændrede elastic-toolbox for at køre en samtidig eksport af tre forskellige indekser, kan vi bruge elastic\_toolbox\_export\_pubsub\_write\_compression\_ratio Prometheus-metricen (se compress -metoden ovenfor) for at oprette et varmekort over kompressionsforhold:

Komprimeret bytes / originale byte, altid 0\%

Denne varmekort viser, at alle meddelelser komprimeret til højst 30\% af den originale størrelse . Når vi måler over hele vores korps af logfiler, har vi et gennemsnit på ~ 12\% kompressionsforhold, hvilket betyder, at 1GiB af logfiler kun bliver 120MiB.

Vores oprindelige regning på $ 12.900 er blevet 12\% x $ 12.900 = $ 1.548.

Dette betyder , vi har sparet ca. $ 11.500.

Udforsk dataene selv ved denne Snapshot af Raintank: komprimering af elastisk værktøjskasse .

Næste trin? Ansøg på fuld tid.

Det mest oplagte næste trin var at anvende dette på vores logningspipeline hele tiden. Da vi sender containerlogfiler lige ind i Pub / Sub og trækker dem ud af et abonnement til Elasticsearch, kan vi nemt skrive et fluentd filter, der anvender den samme komprimeringsstrategi.

Min kollega Ben sammensatte et fantastisk dashboard til at spore, hvor meget vi sparer, hvilket viser sig at være flere tusinde om måneden :

Besparelser ved komprimering af logfiler, når de kommer ind i logningspipeline

Hvor ellers kan komprimering hjælpe?

Hvis du arbejder i et skymiljø, er der så mange muligheder for spar penge ved at komprimere dine data.

Ud over logfiler er et andet GoCardless-eksempel et værktøj kaldet draupnir . Denne service er vært for kopier af vores produktionsdatabaser til belastningstest og retsmedicinsk analyse (forudsigelse af forespørgselsplan osv.). Google SSD-lagerplads koster $ 187 per TiB / måned, hvilket betyder, at hver kopi af vores 5TB Postgres koster $ 1.000 / måned .

Draupnir er muligvis vært for flere kopier ad gangen, afhængigt af brugssagerne. Vi kan spare en masse penge ved at aktivere btrfs-komprimering til transparent komprimering af filsystemblokkene, så vi kan bruge ~ 70\% mindre SSD-kapacitet end vi ellers måtte have.

Og hvis du troede, at komprimering var begrænset til omkostningsbesparelser, ville du tage fejl! Efter at have lidt af lejlighedsvis mikroafbrydelser, når folk kørte store udfyldninger eller byggede nye databaseindekser, løste vi problemet ved at aktivere Postgres WAL-komprimering (se Postgres underudnyttede funktioner: WAL-kompression , eller Postgres Skriv forude logdokumenter ).

Afbrydelserne skyldtes databasefunktioner, der skabte en stor mængde WAL-churn, hvor replikaen stoppede under skrivning af WAL til disk. Ved at komprimere WAL-strømmen reducerede vi IO-pigge betydeligt, så replikaen kunne håndtere strømmen uden problem .

Der er flere eksempler, men jeg synes, det tegner et godt billede.

Hvordan hjælper dette dig?

Kompression er en kompromis, en beslutning, vi træffer bytte CPU mod en anden ressource, der kan være dyrere eller mindre tilgængelig. Den værdi, der er tildelt CPU, hukommelse eller netværksbåndbredde, ændres løbende, og du skal foretage denne beregning fra sag til sag.

Dette indlæg havde til formål at dække et scenarie, hvor omkostningerne ved komprimering, både i beregningsressource og tid til at bygge, blev betydeligt opvejet af de besparelser, det ville medføre. Ikke alle situationer har samme økonomi, men det tager et par minutter servietmatematik at beslutte på begge måder.

Jeg håber, at denne casestudie beder om overvejelse af komprimering uden for standard, kedelige brugssager og hjælper for at finde muligheder, hvor du kan anvende det på dine egne systemer.

Diskuter dette indlæg på Hackernews .

Oprindeligt udgivet på https: // blog .lawrencejones.dev den 29. december 2020.