Hur REA Group närmar sig Amazon MSK-klusterkapacitetsplanering

Det här inlägget skrevs av Eunice Aguilar och Francisco Rodera från REA Group.

Företag som behöver dela och komma åt stora mängder data över flera domäner och tjänster måste bygga en molninfrastruktur som skalas efter behov. REA Group, ett digitalt företag som specialiserat sig på fastigheter, löste detta problem med hjälp av Amazon Managed Streaming för Apache Kafka (Amazon MSK) och en dataströmningsplattform som heter Hydro.

REA Groups team på mer än 3,000 XNUMX personer styrs av vårt syfte: att förändra hur världen upplever fastigheter. Vi hjälper människor med alla aspekter av deras fastighetsupplevelse – inte bara att köpa, sälja och hyra – genom det rikaste innehållet, data och insikter, värderingsuppskattningar och hemfinansieringslösningar. Vi levererar oöverträffat värde till våra kunder, Australiens fastighetsmäklare, genom att ge tillgång till den största och mest engagerade publiken av fastighetssökande.

För att uppnå detta behöver de olika tekniska produkterna inom företaget regelbundet flytta data över domäner och tjänster effektivt och tillförlitligt.

Inom Data Platform-teamet har vi byggt en dataströmningsplattform som heter Hydro för att tillhandahålla denna förmåga i hela organisationen. Hydro drivs av Amazon MSK och andra verktyg med vilka team kan flytta, transformera och publicera data med låg latens med hjälp av händelsedrivna arkitekturer. Denna typ av struktur är grundläggande för REA för att bygga mikrotjänster och snabb databehandling för realtids- och batchanvändningsfall som tidskänsliga utgående meddelanden, personalisering och maskininlärning (ML).

I det här inlägget delar vi vårt synsätt på MSK-klusterkapacitetsplanering.

Problemet

Hydro hanterar en storskalig Amazon MSK-infrastruktur genom att tillhandahålla konfigurationsabstraktioner, vilket tillåter användare att fokusera på att leverera värde till REA utan den kognitiva omkostnaden för infrastrukturhantering. När användningen av Hydro växer inom REA är det avgörande att utföra kapacitetsplanering för att möta användarnas krav samtidigt som optimal prestanda och kostnadseffektivitet bibehålls.

Hydro använder försedda MSK-kluster i utvecklings- och produktionsmiljöer. I varje miljö hanterar Hydro ett enda MSK-kluster som är värd för flera hyresgäster med olika arbetsbelastningskrav. Korrekt kapacitetsplanering säkerställer att klustren kan hantera hög trafik och ge alla användare den önskade servicenivån.

Realtidsströmning är en relativt ny teknik hos REA. Många användare är ännu inte bekanta med Apache Kafka, och det kan vara svårt att noggrant bedöma deras arbetsbelastningskrav. Som väktare av Hydro-plattformen är det vårt ansvar att hitta ett sätt att utföra kapacitetsplanering för att proaktivt bedöma effekten av användarens arbetsbelastning på våra kluster.

Mål

Kapacitetsplanering innebär att bestämma lämplig storlek och konfiguration av klustret baserat på aktuella och beräknade arbetsbelastningar, samt beakta faktorer som datareplikering, nätverksbandbredd och lagringskapacitet.

Utan ordentlig kapacitetsplanering kan Hydro-kluster bli överväldigade av hög trafik och misslyckas med att ge användarna den önskade servicenivån. Därför är det mycket viktigt för oss att investera tid och resurser i kapacitetsplanering för att säkerställa att Hydro-kluster kan leverera den prestanda och tillgänglighet som moderna applikationer kräver.

Kapacitetsplaneringen vi följer för Hydro täcker tre huvudområden:

• De modeller som används för beräkning av nuvarande och uppskattade framtida kapacitetsbehov, inklusive de attribut som används som variabler i dem
• Modellerna som används för att bedöma den ungefärliga förväntade kapaciteten som krävs för att en ny Hydro-arbetsbelastning ska anslutas till plattformen
• Verktygen som är tillgängliga för operatörer och förvaltare för att bedöma plattformens historiska och nuvarande kapacitetsförbrukning och, baserat på dem, det tillgängliga utrymmet

Följande diagram visar samspelet mellan kapacitetsanvändning och den förberäknade maximala användningen.

Även om vi inte har denna förmåga ännu, är målet att ta detta tillvägagångssätt ett steg längre i framtiden och förutsäga den ungefärliga resursutarmningstiden, som visas i följande diagram.

För att säkerställa att vår digitala verksamhet är motståndskraftig och effektiv måste vi upprätthålla en omfattande observerbarhet av vår nuvarande kapacitetsanvändning. Denna detaljerade tillsyn tillåter oss inte bara att förstå prestandagränserna för vår befintliga infrastruktur, utan också att identifiera potentiella flaskhalsar innan de påverkar våra tjänster och användare.

Genom att proaktivt ställa in och övervaka välförstådda trösklar kan vi ta emot varningar i rätt tid och vidta nödvändiga skalningsåtgärder. Det här tillvägagångssättet säkerställer att vår infrastruktur kan möta efterfrågan utan att kompromissa med prestanda, vilket i slutändan stöder en sömlös användarupplevelse och bibehåller integriteten hos vårt system.

Lösningsöversikt

MSK-klustren i Hydro är konfigurerade med en PER_TOPIC_PER_BROKER övervakningsnivå, som ger statistik på mäklar- och ämnesnivå. Dessa mätvärden hjälper oss att bestämma attributen för klusteranvändningen på ett effektivt sätt.

Det skulle dock inte vara klokt att visa ett överdrivet antal mätvärden på våra övervakningsinstrumentpaneler eftersom det kan leda till mindre tydlighet och långsammare insikter om klustret. Det är mer värdefullt att välja de mest relevanta måtten för kapacitetsplanering snarare än att visa många mätvärden.

Klustrets användningsattribut

Baserat på Amazon MSK:s riktlinjer för bästa praxis har vi identifierat flera nyckelattribut för att bedöma MSK-klustrets hälsa. Dessa attribut inkluderar följande:

• In/ut genomströmning
• CPU-användning
• Användning av diskutrymme
• Minnesanvändning
• Producent- och konsumentlatens
• Strypning av producent och konsument

För mer information om rätt storlek på dina kluster, se Bästa metoder för rätt storlek på dina Apache Kafka-kluster för att optimera prestanda och kostnad, Bästa metoder för standardmäklare, Övervaka CPU-användning, Övervaka diskutrymmeoch Övervaka Apache Kafka-minne.

Följande tabell innehåller den detaljerade listan över alla attribut vi använder för MSK-klusterkapacitetsplanering i Hydro.

Genom att övervaka dessa attribut kan vi snabbt utvärdera klustrens prestanda när vi lägger till fler arbetsbelastningar till plattformen. Vi matchar sedan dessa attribut med relevanta tillgängliga MSK-mått.

Klusterkapacitetsbegränsningar

Under den inledande kapacitetsplaneringen fick våra MSK-kluster inte tillräckligt med trafik för att ge oss en tydlig uppfattning om deras kapacitetsgränser. För att ta itu med detta använde vi AWS ramverk för prestandatestning för Apache Kafka att utvärdera de teoretiska prestationsgränserna. Vi genomförde prestanda- och kapacitetstester på test-MSK-klustren som hade samma klusterkonfigurationer som våra utvecklings- och produktionskluster. Vi fick en mer omfattande förståelse av klustrets prestanda genom att genomföra dessa olika testscenarier. Följande figur visar ett exempel på ett testklusters prestandamått.

För att utföra testerna inom en specifik tidsram och budget fokuserade vi på testscenarionerna som effektivt kunde mäta klustrets kapacitet. Till exempel genomförde vi tester som involverade att skicka höghastighetstrafik till klustret och skapa ämnen med många partitioner.

Efter varje test samlade vi in ​​mätvärdena för testklustret och extraherade de maximala värdena för nyckelklustrets användningsattribut. Vi konsoliderade sedan resultaten och bestämde de lämpligaste gränserna för varje attribut. Följande skärmdump visar ett exempel på det exporterade testklustrets prestandamått.

Instrumentpaneler för kapacitetsövervakning

Som en del av vår plattformshanteringsprocess genomför vi månatliga verksamhetsgenomgångar för att upprätthålla optimal prestanda. Detta innebär att analysera en automatiserad verksamhetsrapport som täcker alla system på plattformen. Under granskningen utvärderar vi servicenivåmålen (SLOs) baserat på utvalda servicenivåindikatorer (SLIs) och bedömer de övervakningsvarningar som utlösts från föregående månad. Genom att göra det kan vi identifiera eventuella problem och vidta korrigerande åtgärder.

För att hjälpa oss att genomföra de operativa granskningarna och för att ge oss en översikt över klustrets användning utvecklade vi en instrumentpanel för kapacitetsövervakning, som visas i följande skärmdump, för varje miljö. Vi byggde instrumentpanelen som infrastruktur som kod (IaC) med hjälp av AWS Cloud Development Kit (AWS CDK). Instrumentpanelen genereras och hanteras automatiskt som en komponent i plattformens infrastruktur, tillsammans med MSK-klustret.

Genom att definiera de maximala kapacitetsgränserna för MSK-klustret i en konfigurationsfil, läses gränserna automatiskt in i kapacitetspanelen som kommentarer i amazoncloudwatch graf widgets. Anteckningarna för kapacitetsbegränsningarna är tydligt synliga och ger oss en bild av klustrets kapacitetsutrymme baserat på användning.

Vi bestämde kapacitetsgränserna för genomströmning, latens och strypning genom prestandatestningen. Kapacitetsbegränsningar för andra mätvärden, såsom CPU, diskutrymme och minne, är baserade på Amazon MSK:s riktlinjer för bästa praxis.

Under de operativa granskningarna utvärderar vi proaktivt instrumentpanelerna för kapacitetsövervakning för att avgöra om mer kapacitet behöver läggas till i klustret. Detta tillvägagångssätt gör att vi kan identifiera och ta itu med potentiella prestandaproblem innan de har en betydande inverkan på användarnas arbetsbelastning. Det är en förebyggande åtgärd snarare än ett reaktivt svar på en prestationsförsämring.

Förebyggande CloudWatch-larm

Vi har implementerat förebyggande CloudWatch-larm utöver instrumentpanelerna för kapacitetsövervakning. Dessa larm är konfigurerade för att varna oss innan ett specifikt kapacitetsmått når sitt tröskelvärde och meddelar oss när det ihållande värdet når 80 % av kapacitetsgränsen. Denna övervakningsmetod gör det möjligt för oss att vidta omedelbara åtgärder istället för att vänta på vår månatliga granskningsfrekvens.

Mervärde genom vår kapacitetsplanering

Som operatörer av Hydro-plattformen har vår strategi för kapacitetsplanering gett ett konsekvent sätt att bedöma hur långt vi är från de teoretiska kapacitetsgränserna för alla våra kluster, oavsett deras konfiguration. Våra instrumentpaneler för kapacitetsövervakning är ett viktigt observerbarhetsinstrument som vi granskar regelbundet; de är också användbara vid felsökning av prestandaproblem. De hjälper oss att snabbt avgöra om kapacitetsbegränsningar kan vara en potentiell grundorsak till pågående problem. Detta innebär att vi kan använda vår nuvarande kapacitetsplaneringsmetod och verktyg både proaktivt eller reaktivt, beroende på situation och behov.

En annan fördel med detta tillvägagångssätt är att vi beräknar de teoretiska maximala användningsvärdena som ett givet kluster med en specifik konfiguration kan motstå från ett separat kluster utan att påverka några faktiska användare av plattformen. Vi spinner upp kortlivade MSK-kluster genom vår AWS CDK-baserade automation och utför kapacitetstester på dem. Vi gör detta ganska ofta för att bedöma vilken inverkan, om någon, som ändringar som görs i klustrets konfigurationer har på de kända kapacitetsgränserna. Enligt vår nuvarande återkopplingsslinga, om dessa nyligen beräknade gränser ändras från de tidigare kända, används de för att automatiskt uppdatera våra kapacitetsinstrumentpaneler och larm i CloudWatch.

Framtida evolution

Hydro är en plattform som ständigt förbättras med introduktionen av nya funktioner. En av dessa funktioner inkluderar möjligheten att enkelt skapa Kafka-klientapplikationer. För att möta den ökande efterfrågan är det viktigt att ligga steget före kapacitetsplaneringen. Även om det tillvägagångssätt som diskuteras här har tjänat oss väl hittills, är det inte på något sätt slutskedet, och det finns förmågor som vi behöver utöka och områden vi behöver förbättra.

Flerklusterarkitektur

För att stödja kritiska arbetsbelastningar överväger vi att använda en multiklusterarkitektur med Amazon MSK, vilket också skulle påverka vår kapacitetsplanering. I framtiden planerar vi att profilera arbetsbelastningar baserat på metadata, korskontrollera dem med kapacitetsmått och placera dem i lämpligt MSK-kluster. Utöver de befintliga tillhandahållna MSK-klustren kommer vi att utvärdera hur Amazon MSK Serverlös klustertyp kan komplettera vår plattformsarkitektur.

Användningstrender

Vi har lagt till CloudWatch detektering av anomalier grafer till våra instrumentpaneler för kapacitetsövervakning för att spåra eventuella ovanliga trender. Men eftersom CloudWatch-algoritmen för avvikelsedetektering bara utvärderar upp till två veckors metrisk data, kommer vi att omvärdera dess användbarhet när vi tar med fler arbetsbelastningar. Förutom att identifiera användningstrender kommer vi att undersöka alternativ för att implementera en algoritm med prediktiva möjligheter för att upptäcka när MSK-klusterresurser försämras och utarmas.

Slutsats

Initial kapacitetsplanering lägger en solid grund för framtida förbättringar och ger en säker onboardingprocess för arbetsbelastningar. För att uppnå optimal prestanda för vår plattform måste vi se till att vår kapacitetsplaneringsstrategi utvecklas i takt med plattformens tillväxt. Som ett resultat av detta upprätthåller vi ett nära samarbete med AWS för att kontinuerligt utveckla ytterligare funktioner som möter våra affärsbehov och är i synk med Amazon MSK-färdplanen. Detta säkerställer att vi ligger före kurvan och kan leverera bästa möjliga upplevelse till våra användare.

Vi rekommenderar alla Amazon MSK-användare att inte missa att maximera sitt kluster potential och att börja planera sin kapacitet. Att implementera strategierna som listas i det här inlägget är ett bra första steg och kommer att leda till smidigare verksamhet och betydande besparingar på lång sikt.

Om författarna

Eunice Aguilar är Staff Data Engineer på REA. Hon har arbetat inom mjukvaruteknik i olika branscher genom åren och nyligen för fastighetsdata. Hon är också en förespråkare för kvinnor som är intresserade av att gå över till teknik, tillsammans med de välbevandrade som hon hämtar inspiration från.

Francisco Rodera är en Staff Systems Engineer på REA. Han har lång erfarenhet av att bygga och driva storskaliga distribuerade system. Hans intressen är automatisering, observerbarhet och att tillämpa SRE-praxis på affärskritiska tjänster och plattformar.

Khizer Naeem är Technical Account Manager på AWS. Han är specialiserad på Efficient Compute och har en djup passion för Linux och teknik med öppen källkod, som han utnyttjar för att hjälpa företagskunder att modernisera och optimera sina molnarbeten.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://aws.amazon.com/blogs/big-data/how-rea-group-approaches-amazon-msk-cluster-capacity-planning/