Amazon MSK Serverloos is een clustertype van Amazon Managed Streaming voor Apache Kafka (Amazon MSK) waarmee u Apache Kafka eenvoudig kunt uitvoeren zonder de clustercapaciteit te hoeven beheren en schalen. MSK Serverless voorziet en schaalt automatisch computer- en opslagbronnen. Met MSK Serverless kunt u Apache Kafka op aanvraag gebruiken en betalen voor de gegevens die u streamt en bewaart op basis van gebruik.
Het implementeren van infrastructuur over meerdere VPC's en meerdere accounts wordt als best practice beschouwd, waardoor de schaalbaarheid wordt vergemakkelijkt en de isolatiegrenzen behouden blijven. In een omgeving met meerdere accounts kunnen Kafka-producenten en -consumenten binnen dezelfde VPC bestaan, maar ze bevinden zich vaak in verschillende VPC's, soms binnen hetzelfde account, in een ander account of zelfs in meerdere verschillende accounts. Er is behoefte aan een oplossing die de toegang tot MSK Serverless-clusters kan uitbreiden naar producenten en consumenten vanaf meerdere VPC's binnen hetzelfde AWS-account en over meerdere AWS-accounts. De oplossing moet schaalbaar en eenvoudig te onderhouden zijn.
In dit bericht leiden we u door meerdere oplossingsbenaderingen die zich richten op de MSK Serverless cross-VPC en cross-account toegangsconnectiviteitsopties, en bespreken we de voordelen en beperkingen van elke aanpak.
MSK Serverloze connectiviteit en authenticatie
Wanneer een MSK serverloos cluster wordt gemaakt, beheert AWS namens u de clusterinfrastructuur en breidt de privéconnectiviteit terug naar uw VPC's via VPC-eindpunten mogelijk gemaakt door AWS PrivéLink. U bootstrapt uw verbinding met het cluster op via een bootstrapserver die een overzicht van al uw onderliggende makelaars bijhoudt.
Bij het maken wordt een volledig gekwalificeerde domeinnaam (FQDN) toegewezen aan uw clusterbootstrapserver. De bootstrapserver FQDN heeft het algemene formaat van boot-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com, en uw clusterbrokers volgen de indeling van bxxxx-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com, WAAR ClusterUniqueID.xx is uniek voor uw cluster en bxxxx is een dynamisch makelaarsbereik (b0001, b0037 en b0523 kunnen op een bepaald moment enkele van uw toegewezen makelaars zijn). Het is vermeldenswaard dat de makelaars die aan uw cluster zijn toegewezen dynamisch zijn en in de loop van de tijd veranderen, maar dat uw bootstrap-adres hetzelfde blijft voor het cluster. Al uw communicatie met het cluster begint met de bootstrap-server die indien nodig kan reageren met de lijst met actieve makelaars. Voor een goede Kafka-communicatie moet uw MSK-client de domeinnamen van uw bootstrap-server en al uw makelaars kunnen omzetten.
Bij het aanmaken van het cluster geeft u de VPC's op waarmee u wilt dat het cluster communiceert (maximaal vijf VPC's in hetzelfde account als uw cluster). Voor elke VPC die wordt opgegeven tijdens het maken van het cluster, worden cluster VPC-eindpunten gemaakt samen met een privé gehoste zone met een lijst van uw bootstrap-server en alle dynamische makelaars die up-to-date worden gehouden. De privé gehoste zones vergemakkelijken het omzetten van de FQDN's van uw bootstrapserver en makelaars, vanuit de bijbehorende VPC's die zijn gedefinieerd tijdens het maken van het cluster, naar de respectieve VPC-eindpunten voor elk.
Toegang voor meerdere accounts
Om de privéconnectiviteit van uw Kafka-producenten en -consumenten uit te breiden naar uw MSK Serverless-cluster, moet u rekening houden met drie hoofdaspecten: privéconnectiviteit, authenticatie en autorisatie, en DNS-resolutie.
Het volgende diagram benadrukt de mogelijke connectiviteitsopties. Hoewel het diagram ze hier allemaal voor demonstratiedoeleinden toont, zou u in de meeste gevallen een of meer van deze opties gebruiken, afhankelijk van uw architectuur, en niet noodzakelijk allemaal in dezelfde opstelling.
In deze sectie bespreken we de verschillende connectiviteitsopties, samen met hun voor- en nadelen. We behandelen ook de authenticatie- en DNS-resolutieaspecten die verband houden met de relevante connectiviteitsopties.
Privé-connectiviteitslaag
Dit is de onderliggende particuliere netwerkconnectiviteit. U kunt deze connectiviteit bereiken met behulp van VPC-peering, AWS-transitgateway, of PrivateLink, zoals aangegeven in het voorgaande diagram. VPC-peering vereenvoudigt de installatie, maar mist de ondersteuning voor transitieve routering. In de meeste gevallen wordt peering gebruikt als u een beperkt aantal VPC's heeft of als uw VPC's over het algemeen communiceren met een beperkt aantal kernservices-VPC's zonder de noodzaak van laterale connectiviteit of transitieve routering. Aan de andere kant vergemakkelijkt AWS Transit Gateway transitieve routering en kan het de architectuur vereenvoudigen wanneer u over een groot aantal VPC's beschikt, en vooral wanneer laterale connectiviteit vereist is. PrivateLink is meer geschikt om de connectiviteit naar een specifieke bron unidirectioneel uit te breiden over VPC's of accounts zonder de volledige VPC-naar-VPC-connectiviteit bloot te leggen, waardoor een isolatielaag wordt toegevoegd. PrivateLink is handig als u overlappende CIDR's heeft, wat niet wordt ondersteund door Transit Gateway of VPC-peering. PrivateLink is ook handig wanneer uw aangesloten partijen afzonderlijk worden beheerd en wanneer eenrichtingsconnectiviteit en -isolatie vereist is.
Als u PrivateLink als connectiviteitsoptie kiest, moet u een Netwerk Load Balancer (NLB) met een doelgroep van het IP-type waarvan de geregistreerde doelen zijn ingesteld als de IP-adressen van de zonale eindpunten van uw MSK serverloze cluster.
Clusterverificatie en -autorisatie
Naast het hebben van privéconnectiviteit en het kunnen omzetten van de bootstrapserver en makelaarsdomeinnamen, moet u, zodat uw producenten en consumenten toegang hebben tot uw cluster, uw clients configureren met de juiste inloggegevens. MSK Serverloze ondersteuning AWS Identiteits- en toegangsbeheer (IAM) authenticatie en autorisatie. Voor toegang tussen accounts moet uw MSK-client een rol aannemen die over de juiste referenties beschikt voor toegang tot het cluster. Dit bericht richt zich voornamelijk op de cross-account connectiviteit en aspecten van naamresolutie. Raadpleeg het volgende voor meer informatie over authenticatie en autorisatie tussen accounts GitHub repo.
DNS-resolutie
Om ervoor te zorgen dat Kafka-producenten en -consumenten die zich in accounts in de hele organisatie bevinden, kunnen produceren en consumeren van en naar het gecentraliseerde MSK Serverless-cluster, moeten ze in staat zijn om de FQDN's van de clusterbootstrapserver en elk van de clustermakelaars om te zetten. Als we de dynamische aard van de toewijzing van makelaars begrijpen, zal de oplossing aan een dergelijke vereiste moeten voldoen. In de volgende paragraaf gaan we in op de manier waarop we aan dit deel van de eisen kunnen voldoen.
Cluster DNS-omzetting voor meerdere accounts
Nu we hebben besproken hoe MSK Serverless werkt, hoe privéconnectiviteit wordt uitgebreid en de authenticatie- en autorisatievereisten, gaan we bespreken hoe DNS-resolutie werkt voor uw cluster.
Voor elke VPC die tijdens het maken van het cluster aan uw cluster is gekoppeld, wordt een VPC-eindpunt gemaakt samen met een privé gehoste zone. Privé gehoste zones maken naamherkenning mogelijk van de FQDN's van de clusterbootstrapserver en de dynamisch toegewezen makelaars, vanuit elke respectieve VPC. Dit werkt goed wanneer verzoeken afkomstig zijn van een van de VPC's die zijn toegevoegd tijdens het maken van het cluster, omdat deze al over de vereiste VPC-eindpunten en relevante privé-gehoste zones beschikken.
Laten we bespreken hoe u de naamomzetting kunt uitbreiden naar andere VPC's binnen hetzelfde account die niet zijn opgenomen tijdens het maken van het cluster, en naar andere die zich mogelijk in andere accounts bevinden.
U heeft al uw keuze gemaakt voor de optie voor privéconnectiviteit die het beste bij uw architectuurvereisten past, of het nu VPC-peering, PrivateLink of Transit Gateway is. Ervan uitgaande dat u uw MSK-clients ook hebt geconfigureerd om rollen aan te nemen die over de juiste IAM-referenties beschikken om clustertoegang te vergemakkelijken, moet u nu het naamomzettingsaspect van connectiviteit aanpakken. Het is vermeldenswaard dat, hoewel we verschillende connectiviteitsopties vermelden met behulp van VPC-peering, Transit Gateway en PrivateLink, in de meeste gevallen slechts een of twee van deze connectiviteitsopties aanwezig zijn. Je hoeft ze niet per se allemaal te hebben; ze worden hier vermeld om uw opties te demonstreren, en u bent vrij om degene te kiezen die het beste bij uw architectuur en vereisten passen.
In de volgende secties beschrijven we twee verschillende methoden om DNS-resolutie aan te pakken. Voor elke methode zijn er voordelen en beperkingen.
Privé gehoste zones
In het volgende diagram worden de oplossingsarchitectuur en de componenten ervan belicht. Merk op dat we, om het diagram te vereenvoudigen en om ruimte te maken voor meer relevante details die in deze sectie nodig zijn, een aantal connectiviteitsopties hebben geëlimineerd.
De oplossing begint met het creëren van een privé gehoste zone, gevolgd door het creëren van een VPC-associatie.
Maak een privé gehoste zone
We beginnen met het maken van een privé-gehoste zone voor naamomzetting. Om de oplossing schaalbaar en eenvoudig te onderhouden te maken, kunt u ervoor kiezen om deze privé gehoste zone in hetzelfde MSK Serverless clusteraccount te creëren; in sommige gevallen verdient het de voorkeur om de privé gehoste zone in een gecentraliseerd netwerkaccount te creëren. Door de privé-gehoste zone in het MSK Serverless-clusteraccount te maken, wordt gecentraliseerd beheer van de privé-gehoste zone naast het MSK-cluster mogelijk gemaakt. Vervolgens kunnen we de gecentraliseerde privé-gehoste zone koppelen aan VPC's binnen hetzelfde account of in verschillende andere accounts. Ervoor kiezen om uw privé gehoste zones te centraliseren in een netwerkaccount kan ook een haalbare oplossing zijn om te overwegen.
Het doel van de privé gehoste zone is om de FQDN's van de bootstrap-server te kunnen omzetten, evenals alle dynamisch toegewezen cluster-geassocieerde brokers. Zoals eerder besproken is het FQDN-formaat van de bootstrapserver boot-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com, en de clusterbrokers gebruiken het formaat bxxxx-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.commet bxxxx zijnde de makelaar-ID. U moet de nieuwe gehoste privézone maken met het primaire domein ingesteld als kafka-serverless.Region.amazonaws.com, met een A-Alias-record genoemd *.kafka-serverless.Region.amazonaws.com verwijzend naar het regionale VPC-eindpunt van het MSK serverloze cluster in het MSK-cluster VPC. Dit zou voldoende moeten zijn om al het verkeer dat op uw cluster is gericht, naar de primaire cluster-VPC-eindpunten te leiden die u in uw privé-gehoste zone hebt opgegeven.
Nu u de privé-gehoste zone hebt gemaakt, moet u, om de naamomzetting te laten werken, de privé-gehoste zone koppelen aan elke VPC waarop u clients heeft voor het MSK-cluster (producent of consument).
Koppel een privé gehoste zone aan VPC's in hetzelfde account
Voor VPC's die zich in hetzelfde account bevinden als het MSK-cluster en niet zijn opgenomen in de configuratie tijdens het maken van het cluster, kunt u ze koppelen aan de privé gehoste zone die is gemaakt met behulp van de AWS-beheerconsole door de privé-gehoste zone-instellingen te bewerken en de respectieve VPC's toe te voegen. Voor meer informatie, zie Meer VPC's koppelen aan een privé gehoste zone.
Koppel een privé gehoste zone aan VPC's voor meerdere accounts
Voor VPC's die zich in een ander account bevinden dan het MSK-clusteraccount, raadpleegt u Koppel een Amazon VPC en een privé gehoste zone die u hebt gemaakt met verschillende AWS-accounts. De belangrijkste stappen zijn als volgt:
- Maak een VPC-koppelingsautorisatie aan in het account waar de privé gehoste zone is aangemaakt (in dit geval is dit hetzelfde account als het MSK Serverless clusteraccount) om de externe VPC's te autoriseren om aan de gehoste zone te worden gekoppeld:
- Koppel de VPC aan de privé gehoste zone in het account waar u de VPC's heeft bij de MSK-clients (account op afstand), verwijzend naar de associatieautorisatie die u eerder hebt aangemaakt:
- Verwijder de VPC-autorisatie om de VPC te koppelen aan de gehoste zone:
Het verwijderen van de autorisatie heeft geen invloed op de koppeling, maar voorkomt alleen dat u de VPC in de toekomst opnieuw kunt koppelen aan de gehoste zone. Als u de VPC opnieuw wilt koppelen aan de gehoste zone, moet u stap 1 en 2 van deze procedure herhalen.
Houd er rekening mee dat uw VPC de enableDnsSupport en enableDnsHostnames DNS-kenmerken zijn ingeschakeld om dit te laten werken. Deze twee instellingen kunnen worden geconfigureerd onder de VPC DNS-instellingen. Voor meer informatie, zie DNS-kenmerken in uw VPC.
Deze procedures werken goed voor alle externe accounts wanneer de connectiviteit wordt uitgebreid met behulp van VPC-peering of Transit Gateway. Als uw connectiviteitsoptie PrivateLink gebruikt, moet de privé gehoste zone in plaats daarvan worden aangemaakt in het externe account (het account waar de PrivateLink VPC-eindpunten zich bevinden). Bovendien moet er een A-aliasrecord worden gemaakt dat wordt omgezet naar het PrivateLink-eindpunt in plaats van het MSK-clustereindpunt, zoals aangegeven in het eerdere diagram. Dit vergemakkelijkt de naamomzetting naar het PrivateLink-eindpunt. Als andere VPC's via diezelfde PrivateLink-installatie toegang tot het cluster nodig hebben, moet u dezelfde procedure voor het koppelen van gehoste privézones volgen als eerder beschreven en uw andere VPC's koppelen aan de gehoste privézone die voor uw PrivateLink VPC is gemaakt.
Beperkingen
De oplossing voor privé gehoste zones heeft enkele belangrijke beperkingen.
Ten eerste omdat u kafka-serverless.Region.amazonaws.com gebruikt als het primaire domein voor onze privé gehoste zone, en uw A-Alias-record gebruikt *.kafka-serverless.Region.amazonaws.com, wordt al het verkeer naar de MSK Serverless-service afkomstig van een VPC die aan deze privé gehoste zone is gekoppeld, doorgestuurd naar het ene specifieke regionale VPC-eindpunt van het cluster dat u hebt opgegeven in het A-Alias-record van de gehoste zone.
Deze oplossing is geldig als u één MSK serverloos cluster in uw gecentraliseerde service-VPC heeft. Als u toegang moet bieden tot meerdere MSK serverloze clusters, kunt u dezelfde oplossing gebruiken, maar een gedistribueerde, privé gehoste zonebenadering aanpassen in plaats van een gecentraliseerde aanpak. Bij een gedistribueerde privé-gehoste zonebenadering kan elke privé-gehoste zone naar een specifiek cluster verwijzen. De VPC's die aan die specifieke privé-gehoste zone zijn gekoppeld, communiceren alleen met het respectieve cluster dat wordt vermeld onder de specifieke privé-gehoste zone.
Nadat u bovendien een VPC-koppeling tot stand hebt gebracht met een privé-gehoste zone die *.kafka-serverless.Region.amazonaws.com oplost, kan de betreffende VPC alleen communiceren met het cluster dat is gedefinieerd in die specifieke privé-gehoste zone en met geen ander cluster. . Een uitzondering op deze regel is als er binnen dezelfde client-VPC een lokaal cluster wordt aangemaakt. In dat geval kunnen de clients binnen de VPC alleen met het lokale cluster communiceren.
U kunt PrivateLink ook gebruiken om meerdere clusters te huisvesten door per cluster een PrivateLink plus gehoste privézone te maken, waarbij u de eerder beschreven configuratiestappen repliceert.
Beide oplossingen, die gebruik maken van gedistribueerde privé gehoste zones of PrivateLink, zijn nog steeds onderworpen aan de beperking dat u voor elke client-VPC alleen kunt communiceren met het ene MSK Serverless cluster waarvoor uw bijbehorende privé gehoste zone is geconfigureerd.
In de volgende sectie bespreken we een andere mogelijke oplossing.
Resolverregels en AWS Resource Access Manager
Het volgende diagram toont een overzicht op hoog niveau van de oplossing die gebruikt Amazon Route 53 regels van de oplosser en AWS Resource Access Manager.
De oplossing begint met creëren Route 53 inkomende en uitgaande oplossingseindpunten, die zijn gekoppeld aan het MSK-cluster VPC. Vervolgens maakt u in het MSK-account een doorstuurregel voor de oplossing die niet aan een VPC is gekoppeld. Vervolgens deelt u de oplosserregel tussen accounts met behulp van Resource Access Manager. Op het externe account waarnaar u de naamomzetting moet uitbreiden, moet u de bronshare accepteren en de oplosserregels koppelen aan uw doel-VPC's die zich in het externe account bevinden (het account waar de MSK-clients zich bevinden).
Voor meer informatie over deze aanpak raadpleegt u de derde use case in Vereenvoudig DNS-beheer in een omgeving met meerdere accounts met Route 53 Resolver.
Deze oplossing biedt plaats aan meerdere gecentraliseerde MSK-serverloze clusters in een meer schaalbare en flexibele aanpak. Daarom rekent de oplossing op het doorsturen van DNS-verzoeken die moeten worden opgelost door de VPC waar de MSK-clusters zich bevinden. Er kunnen meerdere MSK Serverless-clusters naast elkaar bestaan, waarbij clients in een bepaalde VPC tegelijkertijd met een of meer van hen kunnen communiceren. Deze optie wordt niet ondersteund met de benadering van de privé gehoste zoneoplossing.
Beperkingen
Hoewel deze oplossing zijn voordelen heeft, kent deze ook enkele beperkingen.
Ten eerste moeten al uw MSK Serverless-clusters voor een bepaald doelconsumenten- of producentenaccount zich in dezelfde kernservice-VPC in het MSK-account bevinden. Dit komt door het feit dat de oplosserregel op accountniveau is ingesteld en.kafka-serverless.Region.amazonaws.com als het primaire domein gebruikt, waarbij de resolutie wordt gericht op één specifiek inkomend/uitgaand VPC-resolver-eindpuntpaar binnen die service-VPC . Als u afzonderlijke clusters in verschillende VPC's nodig heeft, kunt u overwegen afzonderlijke accounts aan te maken.
De tweede beperking is dat al uw client-VPC's zich in dezelfde regio moeten bevinden als uw kern MSK Serverloze VPC. De reden achter deze beperking is dat oplosserregels die naar een paar van de oplossereindpunten verwijzen (in werkelijkheid verwijzen ze naar het uitgaande eindpunt dat in een lus naar de inkomende eindpunten loopt) zich in dezelfde regio moeten bevinden als de oplosserregels, en dat Resource Access Manager zich zal uitbreiden het aandeel alleen binnen dezelfde regio. Deze oplossing is echter goed als u meerdere MSK-clusters in dezelfde kern-VPC heeft, en hoewel uw externe clients zich in verschillende VPC's en accounts bevinden, bevinden ze zich nog steeds in dezelfde regio. Een oplossing voor deze beperking is het dupliceren van het maken van oplosserregels en het uitgaande oplossereindpunt in een tweede regio, waar het uitgaande eindpunt terugloopt via het oorspronkelijke inkomende oplossereindpunt van de eerste regio dat is gekoppeld aan de MSK Serverloze cluster VPC (ervan uitgaande dat IP-connectiviteit wordt gefaciliteerd) . Deze tweede regio-resolverregel kan vervolgens worden gedeeld met behulp van Resource Access Manager binnen de tweede regio.
Conclusie
U kunt MSK serverloze cross-VPC- en cross-account-toegang configureren in omgevingen met meerdere accounts met behulp van privé gehoste zones of Route 53-resolverregels. Met de oplossing die in dit bericht wordt besproken, kunt u uw configuratie centraliseren en tegelijkertijd de toegang tot meerdere accounts uitbreiden, waardoor het een schaalbare en eenvoudig te onderhouden oplossing wordt. Jij kan maak uw MSK serverloze clusters Met cross-account toegang voor producenten en consumenten kunt u zich blijven concentreren op uw bedrijfsresultaten en inzichten verkrijgen uit gegevensbronnen in uw hele organisatie, zonder dat u een Kafka-infrastructuur op de juiste maat hoeft te maken en te beheren.
Over de auteur
Tamer Soliman is een Senior Solutions Architect bij AWS. Hij helpt Independent Software Vendor (ISV)-klanten bij het innoveren, bouwen en schalen van AWS. Hij heeft meer dan twintig jaar ervaring in de sector en is een uitvinder met drie toegekende patenten. Zijn ervaring omvat meerdere technologiedomeinen, waaronder telecom, netwerken, applicatie-integratie, data-analyse, AI/ML en cloudimplementaties. Hij is gespecialiseerd in AWS-netwerken en heeft een diepgaande passie voor machine leaning, AI en generatieve AI.
- 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/secure-connectivity-patterns-for-amazon-msk-serverless-cross-account-access/
