Det här är ett inlägg skrivet tillsammans med Rivlin Pereira & Vaibhav Pandey från Tanzu CloudHealth (VMware av Broadcom).

VMware Tanzu CloudHealth är den valbara plattformen för molnkostnadshantering för mer än 20,000 2.0 organisationer världen över, som förlitar sig på den för att optimera och styra sina största och mest komplexa multimolnmiljöer. I det här inlägget diskuterar vi hur VMware Tanzu CloudHealth DevOps-teamet migrerade sina självhanterade Apache Kafka-arbetsbelastningar (som kör version XNUMX) till Amazon Managed Streaming för Apache Kafka (Amazon MSK) med version 2.6.2. Vi diskuterar systemarkitekturer, distributionspipelines, ämnesskapande, observerbarhet, åtkomstkontroll, ämnesmigrering och alla problem vi mötte med den befintliga infrastrukturen, tillsammans med hur och varför vi migrerade till den nya Kafka-inställningen och några lärdomar.

Kafka-klusteröversikt

I det snabbt växande landskapet av distribuerade system förlitar sig VMware Tanzu CloudHealths nästa generations mikrotjänstplattform på Kafka som sin ryggrad för meddelanden. För oss utmärker Kafkas högpresterande distribuerade loggsystem i att hantera massiva dataströmmar, vilket gör det oumbärligt för sömlös kommunikation. Kafka, som fungerar som ett distribuerat loggsystem, fångar och lagrar effektivt olika loggar, från HTTP-serverloggar till granskningsloggar för säkerhetshändelser.

Kafkas mångsidighet lyser när det gäller att stödja nyckelmeddelandemönster, behandla meddelanden som grundläggande loggar eller strukturerade nyckel-värdelager. Dynamisk partitionering och konsekvent ordning säkerställer effektiv meddelandeorganisation. Kafkas orubbliga tillförlitlighet överensstämmer med vårt engagemang för dataintegritet.

Integrationen av Ruby-tjänster med Kafka strömlinjeformas genom Karafka-biblioteket, och fungerar som ett omslag på högre nivå. Våra andra språkstacktjänster använder liknande omslag. Kafkas robusta felsökningsfunktioner och administrativa kommandon spelar en avgörande roll för att säkerställa smidig drift och infrastrukturens hälsa.

Kafka som en arkitektonisk pelare

I VMware Tanzu CloudHealths nästa generations mikrotjänstplattform framstår Kafka som en kritisk arkitektonisk pelare. Dess förmåga att hantera höga datahastigheter, stödja olika meddelandemönster och garantera meddelandeleverans stämmer sömlöst med våra operativa behov. När vi fortsätter att förnya och skala, förblir Kafka en stadig följeslagare, vilket gör det möjligt för oss att bygga en motståndskraftig och effektiv infrastruktur.

Varför vi migrerade till Amazon MSK

För oss kom migreringen till Amazon MSK till tre viktiga beslutspunkter:

• Förenklad teknisk drift – Att driva Kafka på en självstyrd infrastruktur var en operativ overhead för oss. Vi hade inte uppdaterat Kafka version 2.0.0 på ett tag, och Kafka-mäklare gick ner i produktion, vilket orsakade problem med ämnen som gick offline. Vi var också tvungna att köra skript manuellt för att öka replikeringsfaktorerna och balansera ledare, vilket var ytterligare manuell ansträngning.
• Utfasade äldre pipelines och förenklade behörigheter – Vi var ute efter att gå bort från våra befintliga pipelines inskrivna Ansible att skapa Kafka-ämnen i klustret. Vi hade också en krånglig process att ge teammedlemmar tillgång till Kafka-maskiner i iscensättning och produktion, och vi ville förenkla detta.
• Kostnad, lappning och support - Eftersom Apache djurskötare hanteras och korrigeras helt av AWS, att flytta till Amazon MSK skulle spara tid och pengar. Dessutom upptäckte vi att köra Amazon MSK med samma typ av mäklare på Amazon Elastic Compute Cloud (Amazon EC2) var billigare att köra på Amazon MSK. I kombination med det faktum att vi får säkerhetskorrigeringar applicerade på mäklare av AWS, var det ett enkelt beslut att migrera till Amazon MSK. Detta gjorde också att teamet frigjordes för att jobba med andra viktiga saker. Slutligen, att få företagssupport från AWS var också avgörande i vårt slutliga beslut att gå över till en hanterad lösning.

Hur vi migrerade till Amazon MSK

Med de viktigaste drivkrafterna identifierade gick vi vidare med en föreslagen design för att migrera existerande självstyrda Kafka till Amazon MSK. Vi genomförde följande förmigreringssteg innan den faktiska implementeringen:

• Bedömning:
  • Utförde en noggrann utvärdering av det befintliga EC2 Kafka-klustret, för att förstå dess konfigurationer och beroenden
  • Verifierad Kafka-versionskompatibilitet med Amazon MSK
• Amazon MSK-installation med Terraform
• Nätverkskonfiguration:
  • Säkerställd sömlös nätverksanslutning mellan EC2 Kafka och MSK-klustren, finjustering av säkerhetsgrupper och brandväggsinställningar

Efter förmigreringsstegen implementerade vi följande för den nya designen:

• Automatisk distribution, uppgradering och ämnesskapande pipelines för MSK-kluster:
  • I den nya installationen ville vi ha automatiserade distributioner och uppgraderingar av MSK-klustren på ett repeterbart sätt med hjälp av ett IaC-verktyg. Därför skapade vi anpassade Terraform-moduler för MSK-klusterdistributioner såväl som uppgraderingar. Dessa moduler anropades från en Jenkins pipeline för automatiserade distributioner och uppgraderingar av MSK-klustren. För att skapa Kafka-ämnen använde vi en Ansible-baserad hemmaodlad pipeline, som inte var stabil och ledde till många klagomål från utvecklarteam. Som ett resultat utvärderade vi alternativ för implementeringar till Kubernetes kluster och använde Strimzi ämnesoperatör att skapa ämnen på MSK-kluster. Ämneskapandet automatiserades med Jenkins pipelines, som utvecklarteam kunde självbetjäna.
• Bättre observerbarhet för kluster:
  • De gamla Kafka-klustren hade inte bra observerbarhet. Vi hade bara varningar om Kafka-mäklarens diskstorlek. Med Amazon MSK utnyttjade vi öppen övervakning med hjälp av Prometheus. Vi ställde upp en fristående Prometheus-server som skrapade mätvärden från MSK-kluster och skickade dem till vårt interna observerbarhetsverktyg. Som ett resultat av förbättrad observerbarhet kunde vi ställa in robust varning för Amazon MSK, vilket inte var möjligt med vår gamla installation.
• Förbättrade COGS och bättre beräkningsinfrastruktur:
  • För vår gamla Kafka-infrastruktur var vi tvungna att betala för att hantera Kafka, Zookeeper-instanser, plus eventuella ytterligare kostnader för mäklarlagring och dataöverföringskostnader. Med flytten till Amazon MSK, eftersom Zookeeper helt hanteras av AWS, behöver vi bara betala för Kafka-noder, mäklarlagring och kostnader för dataöverföring. Som ett resultat, i den slutliga Amazon MSK-konfigurationen för produktion, sparade vi inte bara på infrastrukturkostnader utan även driftskostnader.
• Förenklad drift och förbättrad säkerhet:
  • Med flytten till Amazon MSK behövde vi inte hantera några Zookeeper-instanser. Mäklarsäkerhetspatchning sköttes också av AWS åt oss.
  • Klusteruppgraderingar blev enklare med flytten till Amazon MSK; det är en enkel process att initiera från Amazon MSK-konsolen.
  • Med Amazon MSK fick vi mäklare automatisk skalning utanför lådan. Som ett resultat behövde vi inte oroa oss för att mäklare skulle få slut på diskutrymme, vilket ledde till ytterligare stabilitet för MSK-klustret.
  • Vi fick också ytterligare säkerhet för klustret eftersom Amazon MSK stöder kryptering i vila som standard, och olika alternativ för kryptering under överföring är också tillgängliga. För mer information, se Dataskydd i Amazon Managed Streaming för Apache Kafka.

Under våra förmigreringssteg validerade vi inställningarna för iscensättningsmiljön innan vi gick vidare med produktionen.

Kafka ämnesmigreringsstrategi

När MSK-klusterinstallationen var klar, utförde vi en datamigrering av Kafka-ämnen från det gamla klustret som kördes på Amazon EC2 till det nya MSK-klustret. För att uppnå detta utförde vi följande steg:

• Konfigurera MirrorMaker med Terraform – Vi använde Terraform för att orkestrera utplaceringen av en MirrorMaker kluster bestående av 15 noder. Detta demonstrerade skalbarheten och flexibiliteten genom att justera antalet noder baserat på migreringens samtidiga replikeringsbehov.
• Implementera en strategi för samtidig replikering – Vi implementerade en strategi för samtidig replikering med 15 MirrorMaker-noder för att påskynda migreringsprocessen. Vårt Terraform-drivna tillvägagångssätt bidrog till kostnadsoptimering genom att effektivt hantera resurser under migreringen och säkerställde tillförlitligheten och konsekvensen hos MSK- och MirrorMaker-klustren. Den visade också hur den valda installationen påskyndar dataöverföringen, vilket optimerar både tid och resurser.
• Migrera data – Vi har framgångsrikt migrerat 2 TB data inom en anmärkningsvärt kort tidsram, vilket minimerar stilleståndstiden och visar effektiviteten i strategin för samtidig replikering.
• Ställ in övervakning efter migration – Vi implementerade robust övervakning och varning under migreringen, vilket bidrog till en smidig process genom att identifiera och åtgärda problem omgående.

Följande diagram illustrerar arkitekturen efter att ämnesmigreringen var klar.

Utmaningar och lärdomar

Att ge sig ut på en migrationsresa, särskilt med stora datamängder, åtföljs ofta av oförutsedda utmaningar. I det här avsnittet fördjupar vi oss i utmaningarna under migreringen av ämnen från EC2 Kafka till Amazon MSK med hjälp av MirrorMaker, och delar värdefulla insikter och lösningar som formade framgången för vår migrering.

Utmaning 1: Offset avvikelser

En av utmaningarna vi stötte på var oöverensstämmelsen i ämnesförskjutningar mellan käll- och destinationsklustren, även med offsetsynkronisering aktiverad i MirrorMaker. Lärdomen här var att offsetvärden inte nödvändigtvis behöver vara identiska, så länge offsetsynkronisering är aktiverad, vilket säkerställer att ämnena har rätt position att läsa data från.

Vi åtgärdade detta problem genom att använda ett anpassat verktyg för att köra tester på konsumentgrupper, vilket bekräftade att de översatta offseten antingen var mindre eller fångas upp, vilket indikerar synkronisering enligt MirrorMaker.

Utmaning 2: Långsam datamigrering

Migreringsprocessen stod inför en flaskhals – dataöverföringen gick långsammare än förväntat, särskilt med en betydande datauppsättning på 2 TB. Trots ett MirrorMaker-kluster med 20 noder var hastigheten otillräcklig.

För att övervinna detta grupperade teamet MirrorMaker-noder strategiskt baserat på unika portnummer. Kluster med fem MirrorMaker-noder, var och en med en distinkt port, ökade genomströmningen avsevärt, vilket gjorde att vi kunde migrera data inom timmar istället för dagar.

Utmaning 3: Brist på detaljerad processdokumentation

Att navigera på det okända territoriet för att migrera stora datamängder med hjälp av MirrorMaker visade på frånvaron av detaljerad dokumentation för sådana scenarier.

Genom försök och misstag skapade teamet en IaC-modul med Terraform. Denna modul effektiviserade hela processen för att skapa kluster med optimerade inställningar, vilket möjliggjorde en sömlös start på migreringen inom några minuter.

Slutlig installation och nästa steg

Som ett resultat av flytten till Amazon MSK såg vår slutliga installation efter ämnesmigrering ut som följande diagram.

Vi överväger följande framtida förbättringar:

Slutsats.

I det här inlägget diskuterade vi hur VMware Tanzu CloudHealth migrerade sin befintliga Amazon EC2-baserade Kafka-infrastruktur till Amazon MSK. Vi ledde dig genom den nya arkitekturen, distributionen och ämnesskapande pipelines, förbättringar av observerbarhet och åtkomstkontroll, ämnesmigreringsutmaningar och de problem vi stod inför med den befintliga infrastrukturen, tillsammans med hur och varför vi migrerade till den nya Amazon MSK-konfigurationen. Vi pratade också om alla fördelar som Amazon MSK gav oss, den slutliga arkitekturen vi uppnådde med denna migrering och lärdomar.

För oss visade sig samspelet mellan offsetsynkronisering, strategisk nodgruppering och IaC avgörande för att övervinna hinder och säkerställa en framgångsrik migrering från Amazon EC2 Kafka till Amazon MSK. Det här inlägget fungerar som ett bevis på kraften i anpassningsförmåga och innovation i migrationsutmaningar, och ger insikter för andra som navigerar på en liknande väg.

Om du kör självstyrd Kafka på AWS uppmuntrar vi dig att prova det hanterade Kafka-erbjudandet, Amazon MSK.

Om författarna

Rivlin Pereira är Staff DevOps Engineer på VMware Tanzu Division. Han brinner mycket för Kubernetes och arbetar med CloudHealth Platform som bygger och driver molnlösningar som är skalbara, pålitliga och kostnadseffektiva.

Vaibhav Pandey, en Staff Software Engineer på Broadcom, är en viktig bidragsgivare till utvecklingen av cloud computing-lösningar. Han är specialiserad på arkitektur och konstruktion av datalagringsskikt och brinner för att bygga och skala SaaS-applikationer för optimal prestanda.

Raj Ramasubbu är en Senior Analytics Specialist Solutions Architect fokuserad på big data och analys och AI/ML med Amazon Web Services. Han hjälper kunder att utforma och bygga mycket skalbara, prestanda och säkra molnbaserade lösningar på AWS. Raj tillhandahöll teknisk expertis och ledarskap inom att bygga datateknik, big data-analys, business intelligence och datavetenskapliga lösningar i över 18 år innan han började med AWS. Han hjälpte kunder inom olika branschvertikaler som hälsovård, medicintekniska produkter, life science, detaljhandel, kapitalförvaltning, bilförsäkring, bostadsrättsförsäkring, jordbruk, titelförsäkring, leveranskedja, dokumenthantering och fastigheter.

Todd McGrath är en dataströmningsspecialist på Amazon Web Services där han ger råd till kunder om deras streamingstrategier, integration, arkitektur och lösningar. På den personliga sidan tycker han om att titta på och stödja sina tre tonåringar i deras föredragna aktiviteter samt att följa sina egna sysselsättningar som fiske, pickleball, ishockey och happy hour med vänner och familj på pontonbåtar. Ta kontakt med honom på LinkedIn.

Satya Pattanaik är Sr. Solutions Architect på AWS. Han har hjälpt ISV:er att bygga skalbara och motståndskraftiga applikationer på AWS Cloud. Innan han kom till AWS spelade han en betydande roll i Enterprise-segmenten med deras tillväxt och framgång. Utanför jobbet ägnar han tid åt att lära sig "hur man lagar en smakrik BBQ" och testar nya recept.

• 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-vmware-tanzu-cloudhealth-migrated-from-self-managed-kafka-to-amazon-msk/