Dit is een bericht dat is geschreven in samenwerking met Rivlin Pereira & Vaibhav Pandey van Tanzu CloudHealth (VMware by Broadcom).

VMware Tanzu CloudHealth is het cloudkostenbeheerplatform bij uitstek voor meer dan 20,000 organisaties wereldwijd, die erop vertrouwen om hun grootste en meest complexe multi-cloudomgevingen te optimaliseren en te beheren. In dit bericht bespreken we hoe het VMware Tanzu CloudHealth DevOps-team hun zelfbeheerde Apache Kafka-workloads (met versie 2.0) migreerde naar Amazon Managed Streaming voor Apache Kafka (Amazon MSK) met versie 2.6.2. We bespreken de systeemarchitecturen, de implementatiepijplijnen, het maken van onderwerpen, waarneembaarheid, toegangscontrole, onderwerpmigratie en alle problemen waarmee we te maken kregen met de bestaande infrastructuur, samen met hoe en waarom we naar de nieuwe Kafka-opstelling zijn gemigreerd en enkele lessen die we hebben geleerd.

Kafka-clusteroverzicht

In het snel evoluerende landschap van gedistribueerde systemen vertrouwt het microservicesplatform van VMware Tanzu CloudHealth op Kafka als berichtenbackbone. Voor ons blinkt Kafka's krachtige gedistribueerde logsysteem uit in het verwerken van enorme datastromen, waardoor het onmisbaar is voor naadloze communicatie. Kafka fungeert als een gedistribueerd logsysteem en legt op efficiënte wijze diverse logbestanden vast en bewaart deze, van HTTP-servertoegangslogboeken tot auditlogboeken voor beveiligingsgebeurtenissen.

Kafka's veelzijdigheid komt tot uiting in het ondersteunen van belangrijke berichtenpatronen, waarbij berichten worden behandeld als basislogboeken of gestructureerde sleutelwaardeopslagplaatsen. Dynamische indeling en consistente volgorde zorgen voor een efficiënte organisatie van berichten. De onwrikbare betrouwbaarheid van Kafka sluit aan bij onze toewijding aan data-integriteit.

De integratie van Ruby-services met Kafka wordt gestroomlijnd via de Karafka-bibliotheek, die fungeert als een wrapper op een hoger niveau. Onze andere taalstapelservices gebruiken vergelijkbare wrappers. De robuuste foutopsporingsfuncties en administratieve opdrachten van Kafka spelen een cruciale rol bij het garanderen van soepele operaties en de gezondheid van de infrastructuur.

Kafka als architecturale pijler

In het microservicesplatform van de volgende generatie van VMware Tanzu CloudHealth komt Kafka naar voren als een cruciale architectonische pijler. Het vermogen om hoge datasnelheden te verwerken, diverse berichtenpatronen te ondersteunen en de bezorging van berichten te garanderen, sluit naadloos aan bij onze operationele behoeften. Terwijl we blijven innoveren en opschalen, blijft Kafka een standvastige metgezel, die ons in staat stelt een veerkrachtige en efficiënte infrastructuur op te bouwen.

Waarom we zijn gemigreerd naar Amazon MSK

Voor ons kwam de migratie naar Amazon MSK neer op drie belangrijke beslissingspunten:

• Vereenvoudigde technische handelingen – Het runnen van Kafka op een zelfbeheerde infrastructuur was voor ons een operationele overhead. We hadden Kafka versie 2.0.0 al een tijdje niet bijgewerkt en de productie van Kafka-makelaars lag stil, wat problemen veroorzaakte met het offline gaan van onderwerpen. We moesten ook scripts handmatig uitvoeren om de replicatiefactoren te vergroten en leiders opnieuw in evenwicht te brengen, wat extra handmatige inspanning kostte.
• Verouderde pijplijnen en vereenvoudigde machtigingen zijn verouderd – We wilden afstappen van onze bestaande pijpleidingen Ansible om Kafka-onderwerpen op het cluster te maken. We hadden ook een omslachtig proces om teamleden toegang te geven tot Kafka-machines tijdens de fasering en productie, en we wilden dit vereenvoudigen.
• Kosten, patching en ondersteuning - Omdat Apache Dierenverzorger wordt volledig beheerd en gepatcht door AWS, de overstap naar Amazon MSK zou ons tijd en geld besparen. Bovendien ontdekten we dat Amazon MSK met hetzelfde type makelaars wordt uitgevoerd Amazon Elastic Compute-cloud (Amazon EC2) was goedkoper in gebruik op Amazon MSK. Gecombineerd met het feit dat we door AWS beveiligingspatches op makelaars krijgen toegepast, was de migratie naar Amazon MSK een gemakkelijke beslissing. Dit betekende ook dat het team de vrijheid kreeg om aan andere belangrijke zaken te werken. Ten slotte was het verkrijgen van bedrijfsondersteuning van AWS ook van cruciaal belang bij onze uiteindelijke beslissing om over te stappen op een beheerde oplossing.

Hoe we migreerden naar Amazon MSK

Nu de belangrijkste drijfveren waren geïdentificeerd, zijn we verder gegaan met een voorgesteld ontwerp om bestaande, zelfbeheerde Kafka naar Amazon MSK te migreren. Vóór de daadwerkelijke implementatie hebben we de volgende pre-migratiestappen uitgevoerd:

• Beoordeling:
  • Een nauwgezette beoordeling uitgevoerd van het bestaande EC2 Kafka-cluster, waarbij inzicht werd verkregen in de configuraties en afhankelijkheden ervan
  • Geverifieerde compatibiliteit van de Kafka-versie met Amazon MSK
• Amazon MSK-installatie met Terraform
• Netwerk configuratie:
  • Zorgde voor een naadloze netwerkconnectiviteit tussen de EC2 Kafka- en MSK-clusters, waarbij beveiligingsgroepen en firewall-instellingen werden verfijnd

Na de pre-migratiestappen hebben we het volgende geïmplementeerd voor het nieuwe ontwerp:

• Geautomatiseerde pijplijnen voor implementatie, upgrades en onderwerpcreatie voor MSK-clusters:
  • In de nieuwe opzet wilden we automatische implementaties en upgrades van de MSK-clusters op een herhaalbare manier hebben met behulp van een IaC-tool. Daarom hebben we aangepaste Terraform-modules gemaakt voor MSK-clusterimplementaties en upgrades. Deze modules werden aangeroepen vanuit een Jenkins pijplijn voor geautomatiseerde implementaties en upgrades van de MSK-clusters. Voor het maken van Kafka-onderwerpen gebruikten we een op Ansible gebaseerde pijplijn van eigen bodem, die niet stabiel was en tot veel klachten van ontwikkelteams leidde. Als gevolg hiervan hebben we opties voor implementaties geëvalueerd Kubernetes clusters en gebruikte de Strimzi-onderwerpoperator om onderwerpen op MSK-clusters te maken. Het maken van onderwerpen werd geautomatiseerd met behulp van Jenkins-pijplijnen, die ontwikkelteams zelf konden bedienen.
• Betere waarneembaarheid voor clusters:
  • De oude Kafka-clusters waren niet goed waarneembaar. We hadden alleen waarschuwingen over de schijfgrootte van Kafka Broker. Met Amazon MSK hebben we hiervan geprofiteerd open monitoring gebruik Prometheus. We hebben een zelfstandige Prometheus-server opgezet die statistieken uit MSK-clusters verzamelde en deze naar onze interne observatietool stuurde. Als gevolg van de verbeterde waarneembaarheid konden we robuuste waarschuwingen instellen voor Amazon MSK, wat niet mogelijk was met onze oude configuratie.
• Verbeterde COGS en betere computerinfrastructuur:
  • Voor onze oude Kafka-infrastructuur moesten we betalen voor het beheer van Kafka en Zookeeper-instanties, plus eventuele extra opslagkosten en kosten voor gegevensoverdracht. Met de overstap naar Amazon MSK hoeven we, omdat Zookeeper volledig wordt beheerd door AWS, alleen te betalen voor Kafka-nodes, brokeropslag en gegevensoverdrachtskosten. Als gevolg hiervan hebben we bij de uiteindelijke Amazon MSK-opstelling voor productie niet alleen bespaard op infrastructuurkosten, maar ook op operationele kosten.
• Vereenvoudigde handelingen en verbeterde beveiliging:
  • Met de overstap naar Amazon MSK hoefden we geen Zookeeper-instanties meer te beheren. Ook de beveiligingspatches voor makelaars werden door AWS voor ons verzorgd.
  • Clusterupgrades werden eenvoudiger met de overstap naar Amazon MSK; het is een eenvoudig proces om te starten vanaf de Amazon MSK-console.
  • Met Amazon MSK hebben we een makelaar automatisch schalen uit de doos. Als gevolg hiervan hoefden we ons geen zorgen te maken dat makelaars onvoldoende schijfruimte zouden krijgen, wat leidde tot extra stabiliteit van het MSK-cluster.
  • We hebben ook extra beveiliging voor het cluster gekregen omdat Amazon MSK standaard versleuteling in rust ondersteunt, en er zijn ook verschillende opties voor versleuteling tijdens de overdracht beschikbaar. Voor meer informatie, zie Gegevensbescherming in Amazon Managed Streaming voor Apache Kafka.

Tijdens onze pre-migratiestappen hebben we de installatie in de testomgeving gevalideerd voordat we verder gingen met de productie.

Migratiestrategie voor Kafka-onderwerpen

Toen de installatie van het MSK-cluster voltooid was, voerden we een datamigratie uit van Kafka-onderwerpen van het oude cluster dat op Amazon EC2 draaide naar het nieuwe MSK-cluster. Om dit te bereiken hebben wij de volgende stappen uitgevoerd:

• Stel MirrorMaker in met Terraform – We hebben Terraform gebruikt om de implementatie van een SpiegelMaker cluster bestaande uit 15 knooppunten. Dit demonstreerde de schaalbaarheid en flexibiliteit door het aantal knooppunten aan te passen op basis van de gelijktijdige replicatiebehoeften van de migratie.
• Implementeer een strategie voor gelijktijdige replicatie – We hebben een strategie voor gelijktijdige replicatie geïmplementeerd met 15 MirrorMaker-knooppunten om het migratieproces te versnellen. Onze op Terraform gebaseerde aanpak heeft bijgedragen aan kostenoptimalisatie door het efficiënt beheren van resources tijdens de migratie en zorgde voor de betrouwbaarheid en consistentie van de MSK- en MirrorMaker-clusters. Het liet ook zien hoe de gekozen opstelling de gegevensoverdracht versnelt, waardoor zowel tijd als middelen worden geoptimaliseerd.
• Gegevens migreren – We hebben met succes 2 TB aan gegevens gemigreerd in een opmerkelijk kort tijdsbestek, waardoor de downtime tot een minimum is beperkt en de efficiëntie van de gelijktijdige replicatiestrategie is aangetoond.
• Stel monitoring na de migratie in – We hebben robuuste monitoring en waarschuwingen geïmplementeerd tijdens de migratie, wat heeft bijgedragen aan een soepel proces door problemen snel te identificeren en aan te pakken.

Het volgende diagram illustreert de architectuur nadat de onderwerpmigratie was voltooid.

Uitdagingen en geleerde lessen

Het starten van een migratietraject, vooral als het om grote datasets gaat, gaat vaak gepaard met onvoorziene uitdagingen. In deze sectie duiken we in de uitdagingen die we tegenkwamen tijdens de migratie van onderwerpen van EC2 Kafka naar Amazon MSK met behulp van MirrorMaker, en delen we waardevolle inzichten en oplossingen die het succes van onze migratie hebben bepaald.

Uitdaging 1: Compensatieverschillen

Een van de uitdagingen die we tegenkwamen was de discrepantie in onderwerp-offsets tussen de bron- en bestemmingsclusters, zelfs als offset-synchronisatie was ingeschakeld in MirrorMaker. De les die we hier leerden was dat offsetwaarden niet noodzakelijkerwijs identiek hoeven te zijn, zolang offsetsynchronisatie maar is ingeschakeld, wat ervoor zorgt dat de onderwerpen de juiste positie hebben om de gegevens van te lezen.

We hebben dit probleem aangepakt door een aangepaste tool te gebruiken om tests uit te voeren op consumentengroepen, waarbij we bevestigden dat de vertaalde offsets kleiner of ingehaald waren, wat duidt op synchronisatie volgens MirrorMaker.

Uitdaging 2: Trage datamigratie

Het migratieproces stuitte op een knelpunt: de gegevensoverdracht verliep langzamer dan verwacht, vooral met een aanzienlijke dataset van 2 TB. Ondanks een MirrorMaker-cluster met 20 knooppunten was de snelheid onvoldoende.

Om dit te ondervangen heeft het team MirrorMaker-knooppunten strategisch gegroepeerd op basis van unieke poortnummers. Clusters van vijf MirrorMaker-knooppunten, elk met een aparte poort, hebben de doorvoer aanzienlijk verhoogd, waardoor we gegevens binnen enkele uren in plaats van dagen konden migreren.

Uitdaging 3: Gebrek aan gedetailleerde procesdocumentatie

Bij het navigeren op het onbekende terrein van het migreren van grote datasets met behulp van MirrorMaker werd de afwezigheid van gedetailleerde documentatie voor dergelijke scenario's benadrukt.

Met vallen en opstaan ​​heeft het team een ​​IaC-module gemaakt met behulp van Terraform. Deze module stroomlijnde het hele clustercreatieproces met geoptimaliseerde instellingen, waardoor een naadloze start van de migratie binnen enkele minuten mogelijk werd.

Definitieve installatie en volgende stappen

Als gevolg van de overstap naar Amazon MSK zag onze definitieve opzet na de onderwerpmigratie eruit als het volgende diagram.

We overwegen de volgende toekomstige verbeteringen:

Conclusie.

In dit bericht hebben we besproken hoe VMware Tanzu CloudHealth hun bestaande op Amazon EC2 gebaseerde Kafka-infrastructuur naar Amazon MSK migreerde. We hebben u door de nieuwe architectuur, de implementatie en het aanmaken van onderwerpen geleid, verbeteringen aan de zichtbaarheid en toegangscontrole, uitdagingen op het gebied van onderwerpmigratie en de problemen waarmee we te maken kregen met de bestaande infrastructuur, samen met hoe en waarom we zijn gemigreerd naar de nieuwe Amazon MSK-installatie. We hebben ook gesproken over alle voordelen die Amazon MSK ons heeft geboden, de uiteindelijke architectuur die we met deze migratie hebben bereikt en de lessen die we hebben geleerd.

Voor ons bleek de wisselwerking tussen offsetsynchronisatie, strategische knooppuntgroepering en IaC cruciaal bij het overwinnen van obstakels en het garanderen van een succesvolle migratie van Amazon EC2 Kafka naar Amazon MSK. Dit bericht dient als bewijs van de kracht van aanpassingsvermogen en innovatie bij migratie-uitdagingen en biedt inzichten voor anderen die een soortgelijk pad bewandelen.

Als u zelfbeheerde Kafka op AWS gebruikt, raden we u aan het beheerde Kafka-aanbod te proberen. Amazon MSK.

Over de auteurs

Rivlin Pereira is Staff DevOps Engineer bij de VMware Tanzu Division. Hij heeft een grote passie voor Kubernetes en werkt aan het CloudHealth Platform om cloudoplossingen te bouwen en te exploiteren die schaalbaar, betrouwbaar en kosteneffectief zijn.

Vaibhav Pandey, een Staff Software Engineer bij Broadcom, levert een belangrijke bijdrage aan de ontwikkeling van cloud computing-oplossingen. Hij is gespecialiseerd in het ontwerpen en ontwikkelen van dataopslaglagen en heeft een passie voor het bouwen en schalen van SaaS-applicaties voor optimale prestaties.

Raj Ramasubbu is een Senior Analytics Specialist Solutions Architect gericht op big data en analyse en AI/ML met Amazon Web Services. Hij helpt klanten bij het ontwerpen en bouwen van zeer schaalbare, performante en veilige cloudgebaseerde oplossingen op AWS. Raj leverde meer dan 18 jaar technische expertise en leiderschap in het bouwen van data-engineering, big data-analyse, business intelligence en data science-oplossingen voordat hij bij AWS kwam. Hij hielp klanten in verschillende branches, zoals gezondheidszorg, medische hulpmiddelen, biowetenschappen, detailhandel, vermogensbeheer, autoverzekeringen, residentiële REIT's, landbouw, titelverzekeringen, toeleveringsketen, documentbeheer en onroerend goed.

Todd McGrath is een datastreamingspecialist bij Amazon Web Services, waar hij klanten adviseert over hun streamingstrategieën, integratie, architectuur en oplossingen. Op persoonlijk vlak vindt hij het leuk om zijn drie tieners te zien en te ondersteunen bij hun favoriete activiteiten, maar ook om zijn eigen bezigheden te volgen, zoals vissen, pickleball, ijshockey en happy hour met vrienden en familie op pontonboten. Connect met hem op LinkedIn.

Satya Pattanaik is een Sr. Solutions Architect bij AWS. Hij heeft ISV's geholpen bij het bouwen van schaalbare en veerkrachtige applicaties op AWS Cloud. Voordat hij bij AWS kwam, speelde hij een belangrijke rol in de Enterprise-segmenten met hun groei en succes. Buiten zijn werk besteedt hij tijd aan het leren “hoe je een smaakvolle barbecue kunt bereiden” en het uitproberen van nieuwe recepten.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://aws.amazon.com/blogs/big-data/how-vmware-tanzu-cloudhealth-migrated-from-self-managed-kafka-to-amazon-msk/