Kafka-kvoter er en integreret del af Kafka-klynger med flere lejere. De forhindrer Kafka-klyngens ydeevne i at blive negativt påvirket af dårligt opførte applikationer, der overforbruger klyngressourcer. Desuden gør de det muligt at drive den centrale streamingdataplatform som en multi-tenant platform og bruges af downstream og upstream applikationer på tværs af flere forretningsområder. Kafka understøtter to typer kvoter: kvoter for netværksbåndbredde , anmode om satskvoter. Netværksbåndbreddekvoter definerer bytehastighedstærskler, såsom hvor meget data klientapplikationer kan producere til og forbruge fra hver enkelt mægler i en Kafka-klynge målt i bytes pr. sekund. Anmodningssatskvoter begrænser den procentdel af tid, hver enkelt mægler bruger på at behandle anmodninger om klientansøgninger. Afhængigt af din konfiguration kan Kafka-kvoter indstilles for specifikke brugere, specifikke klient-id'er eller begge dele.
In del 1 i denne todelte serie diskuterede vi koncepterne for, hvordan man håndhæver Kafka-kvoter Amazon administrerede streaming til Apache Kafka (Amazon MSK) klynger under brug AWS identitets- og adgangsstyring (IAM) adgangskontrol.
I dette indlæg leder vi dig gennem den trinvise implementering af opsætning af Kafka-kvoter i en MSK-klynge, mens du bruger IAM-adgangskontrol og tester dem gennem eksempelklientapplikationer.
Løsningsoversigt
Følgende figur, som vi først introducerede i del 1, illustrerer, hvordan Kafka-klientapplikationer (ProducerApp-1
, ConsumerApp-1
og ConsumerApp-2
) adgang Topic-B
i MSK-klyngen ved at påtage sig skrive- og læse-IAM-roller. Hver producent- og forbrugerkundeapplikation har en kvote, der bestemmer, hvor meget data de kan producere eller forbruge i bytes/sekund. Det ProducerApp-1
kvote giver den mulighed for at producere op til 1024 bytes/sekund pr. mægler. Tilsvarende ConsumerApp-1
, ConsumerApp-2
kvoter giver dem mulighed for at forbruge henholdsvis 5120 og 1024 bytes/sekund pr. mægler. Det følgende er en kort forklaring af flowet vist i arkitekturdiagrammet:
- P1 -
ProducerApp-1
(via sinProducerApp-1-Role
IAM rolle) påtager sigTopic-B-Write-Role
IAM-rolle at sende beskeder tilTopic-B
- P2 - Med
Topic-B-Write-Role
IAM's rolle påtog sig,ProducerApp-1
begynder at sende beskeder tilTopic-B
- C1 -
ConsumerApp-1
(via sinConsumerApp-1-Role
IAM rolle) ogConsumerApp-2
(via sinConsumerApp-2-Role
IAM rolle) påtage sigTopic-B-Read-Role
IAM-rolle at læse beskeder fraTopic-B
- C2 - Med
Topic-B-Read-Role
IAM's rolle påtog sig,ConsumerApp-1
,ConsumerApp-2
begynde at forbruge beskeder fraTopic-B
Bemærk, at dette indlæg bruger AWS kommandolinjegrænseflade (AWS CLI), AWS CloudFormation skabeloner og AWS Management Console til klargøring og ændring af AWS-ressourcer, og de tilvejebragte ressourcer vil blive faktureret til din AWS-konto.
Trinene på højt niveau er som følger:
- Forsyn en MSK-klynge med IAM-adgangskontrol og Amazon Elastic Compute Cloud (Amazon EC2) instanser til klientapplikationer.
- Opret
Topic-B
på MSK-klyngen. - Opret IAM-roller, som klientapplikationerne kan få adgang til
Topic-B
. - Kør producent- og forbrugerapplikationerne uden at sætte kvoter.
- Konfigurer produktions- og forbrugskvoterne for klientapplikationerne.
- Kør applikationerne igen efter indstilling af kvoterne.
Forudsætninger
Det anbefales at læse del 1 af denne serie, før du fortsætter. For at komme i gang skal du bruge følgende:
- En AWS-konto, der vil blive omtalt som demokontoen i dette indlæg, forudsat at dens konto-id er
1111 1111 1111
- Tilladelser til at oprette, slette og ændre AWS-ressourcer på demokontoen
Forsyn en MSK-klynge med IAM-adgangskontrol og EC2-instanser
Dette trin involverer klargøring af en MSK-klynge med IAM-adgangskontrol i en VPC på demokontoen. Derudover opretter vi fire EC2-instanser for at foretage konfigurationsændringer til MSK-klyngen og værtsproducent- og forbrugerklientapplikationer.
Implementer CloudFormation-stak
- Klon GitHub repository for at downloade CloudFormations skabelonfiler og eksempelklientapplikationer:
- På AWS CloudFormation-konsollen skal du vælge Stakke i navigationsruden.
- Vælg Opret stak.
- Til Forbered skabelon, Vælg Skabelonen er klar.
- Til Skabelonkilde, Vælg Upload en skabelonfil.
- Upload
cfn-msk-stack-1.yaml
fil fraamazon-msk-kafka-quotas/cfn-templates
mappe, og vælg derefter Næste. - Til Staknavn, gå ind
MSKStack
. - Lad parametrene være standard og vælg Næste.
- Rul til bunden af Konfigurer stakindstillinger side og vælg Næste at fortsætte.
- Rul til bunden af anmeldelse side, skal du markere afkrydsningsfeltet Jeg anerkender, at CloudFormation kan oprette IAM-ressourcer, og vælg Indsend.
Det vil tage cirka 30 minutter, før stakken er færdig. Efter at stakken er blevet oprettet, oprettes følgende ressourcer:
- En VPC med tre private undernet og et offentligt undernet
- En MSK-klynge med tre mæglere med IAM-adgangskontrol aktiveret
- En EC2-instans kaldet
MSKAdminInstance
til ændring af MSK-klyngeindstillinger samt oprettelse og ændring af AWS-ressourcer - EC2 forekomster for
ProducerApp-1
,ConsumerApp-1
ogConsumerApp-2
, en for hver klientapplikation - En separat IAM-rolle for hver EC2-instans, der er vært for klientapplikationen, som vist i arkitekturdiagrammet
- Fra stakkens Udgange fanen, bemærk
MSKClusterArn
værdi.
Opret et emne på MSK-klyngen
At skabe Topic-B
på MSK-klyngen skal du udføre følgende trin:
- På Amazon EC2-konsollen skal du navigere til din liste over kørende EC2-instanser.
- Vælg
MSKAdminInstance
EC2 instans og vælg Tilslut. - På Session Manager fanebladet, vælg Tilslut.
- Kør følgende kommandoer på den nye fane, der åbnes i din browser:
- Indstil miljøvariablen til at pege på MSK Cluster brokers IAM-slutpunktet:
- Vær opmærksom på værdien af
BOOTSTRAP_BROKERS_IAM
. - Kør følgende Kafka CLI-kommando for at oprette
Topic-B
på MSK-klyngen:
Fordi MSK-klyngen er forsynet med IAM-adgangskontrol, er muligheden --command-config
peger på config_iam.properties
, som indeholder de egenskaber, der kræves til IAM-adgangskontrol, oprettet af MSKStack
CloudFormation stak.
Følgende advarsler vises muligvis, når du kører Kafka CLI-kommandoer, men du kan ignorere dem:
- For at bekræfte det
Topic-B
er blevet oprettet, skal du liste alle emnerne:
Opret IAM-roller til klientapplikationer for at få adgang til Topic-B
Dette trin involverer at skabe Topic-B-Write-Role
, Topic-B-Read-Role
som vist i arkitekturdiagrammet. Topic-B-Write-Role
aktiverer skriveoperationer på Topic-B
, og kan antages af ProducerApp-1
. På lignende måde er ConsumerApp-1
, ConsumerApp-2
kan antage Topic-B-Read-Role
at udføre læsehandlinger på Topic-B
. For at udføre læsehandlinger på Topic-B
, ConsumerApp-1
, ConsumerApp-2
skal også tilhøre de forbrugergrupper, der er angivet under MSKStack
stak opdatering i det efterfølgende trin.
Opret rollerne med følgende trin:
- På AWS CloudFormation-konsollen skal du vælge Stakke i navigationsruden.
- Type
MSKStack
Og vælg Opdatering. - Til Forbered skabelon, vælg Erstat aktuel skabelon.
- Til Skabelonkilde, Vælg Upload en skabelonfil.
- Upload
cfn-msk-stack-2.yaml
fil fraamazon-msk-kafka-quotas/cfn-templates
mappe, og vælg derefter Næste. - Angiv følgende ekstra stakparametre:
-
- Til Emne B ARN, gå ind i
Topic-B
RNA.
- Til Emne B ARN, gå ind i
ARN skal formateres som arn:aws:kafka:region:account-id:topic/msk-cluster-name/msk-cluster-uuid/Topic-B
. Brug klyngenavnet og klynge-UUID fra den MSK-klynge ARN, du noterede tidligere, og angiv din AWS-region. For mere information, se IAM adgangskontrol til Amazon MSK.
-
- Til ConsumerApp-1 Forbrugergruppenavn, gå ind
ConsumerApp-1
forbrugergruppen ARN.
- Til ConsumerApp-1 Forbrugergruppenavn, gå ind
Det skal formateres som arn:aws:kafka:region:account-id:group/msk-cluster-name/msk-cluster-uuid/consumer-group-name
-
- Til ConsumerApp-2 Forbrugergruppenavn, gå ind
ConsumerApp-2
forbrugergruppen ARN.
- Til ConsumerApp-2 Forbrugergruppenavn, gå ind
Brug et lignende format som det tidligere ARN.
- Vælg Næste at fortsætte.
- Rul til bunden af Konfigurer stakken indstillingssiden og vælg Næste at fortsætte.
- Rul til bunden af anmeldelse side, skal du markere afkrydsningsfeltet Jeg anerkender, at CloudFormation kan oprette IAM-ressourcer, og vælg Opdater stak.
Det vil tage cirka 3 minutter for stakken at opdatere. Efter at stakken er blevet opdateret, oprettes følgende ressourcer:
- Emne-B-Skrive-Rolle – En IAM-rolle med tilladelse til at udføre skrivehandlinger på
Topic-B
. Dens tillidspolitik tilladerProducerApp-1-Role
IAM rolle at påtage sig det. - Emne-B-Læs-Rolle – En IAM-rolle med tilladelse til at udføre læsehandlinger på
Topic-B
. Dens tillidspolitik tilladerConsumerApp-1-Role
,ConsumerApp-2-Role
IAM-roller til at påtage sig det. Desuden,ConsumerApp-1
,ConsumerApp-2
skal også tilhøre de forbrugergrupper, du angav ved opdatering af stakken for at udføre læsehandlinger påTopic-B
.
- Fra stakkens Udgange fanen, bemærk
TopicBReadRoleARN
,TopicBWriteRoleARN
værdier.
Kør producent- og forbrugerapplikationerne uden at sætte kvoter
Her løber vi ProducerApp-1
, ConsumerApp-1
og ConsumerApp-2
uden at sætte deres kvoter. Fra de foregående trin skal du bruge BOOTSTRAP_BROKERS_IAM
værdi, Topic-B-Write-Role
ARN, og Topic-B-Read-Role
ARN. Kildekoden for klientapplikationer og deres pakkede versioner er tilgængelige i GitHub repository.
Kør ConsumerApp-1-applikationen
At køre ConsumerApp-1
ansøgning, udfør følgende trin:
- På Amazon EC2-konsollen skal du vælge
ConsumerApp-1
EC2 instans og vælg Tilslut. - På Session Manager fanebladet, vælg Tilslut.
- Kør følgende kommandoer på den nye fane, der åbnes i din browser:
- Kør
ConsumerApp-1
applikation til at begynde at forbruge beskeder fraTopic-B
:
Du kan finde kildekode på GitHub til din reference. Kommandolinjeparameterdetaljerne er som følger:
- -bootstrap-servere – MSK cluster bootstrap brokers IAM-slutpunkt.
- –påtage-rolle-arn -
Topic-B-Read-Role
IAM rolle ARN. Påtager man sig denne rolle,ConsumerApp-1
vil læse beskeder fra emnet. - -område – Region du bruger.
- –emnenavn – Emnenavn hvorfra
ConsumerApp-1
vil læse beskeder. Standard erTopic-B
. - –forbrugergruppe – Forbrugergruppenavn for
ConsumerApp-1
, som angivet under stakopdateringen. - –rollesession-navn -
ConsumerApp-1
antagerTopic-B-Read-Role
ved hjælp af AWS Security Token Service (AWS STS) SDK.ConsumerApp-1
vil bruge dette rollesessions navn, når du kalderassumeRole
funktion. - –klient-id – Klient-id for
ConsumerApp-1
. - –print-forbruger-kvote-metrics – Flag, der angiver, om klientmetrics skal udskrives på terminalen ved
ConsumerApp-1
. - –cw-dimension-navn - amazoncloudwatch dimensionsnavn, der vil blive brugt til at publicere klient-throttling-metrics fra
ConsumerApp-1
. - –cw-dimension-værdi – CloudWatch-dimensionsværdi, der vil blive brugt til at publicere klient-throttling-metrics fra
ConsumerApp-1
. - –cw-navneområde – Navneområde hvor
ConsumerApp-1
vil offentliggøre CloudWatch-målinger for at overvåge drosling.
- Hvis du er tilfreds med resten af parametrene, skal du bruge følgende kommando og ændre
--assume-role-arn
,--region
i henhold til dit miljø:
fetch-throttle-time-avg
, fetch-throttle-time-max
klientmetrics skal vise 0.0, hvilket indikerer, at der ikke forekommer drosling for ConsumerApp-1
. Husk, at vi ikke har sat forbrugskvoten for ConsumerApp-1
endnu. Lad det køre et stykke tid.
Kør ConsumerApp-2-applikationen
At køre ConsumerApp-2
ansøgning, udfør følgende trin:
- På Amazon EC2-konsollen skal du vælge
ConsumerApp-2
EC2 instans og vælg Tilslut. - På Session Manager fanebladet, vælg Tilslut.
- Kør følgende kommandoer på den nye fane, der åbnes i din browser:
- Kør
ConsumerApp-2
applikation til at begynde at forbruge beskeder fraTopic-B
:
Koden har lignende kommandolinjeparametre detaljer som ConsumerApp-1
diskuteret tidligere, bortset fra følgende:
- –forbrugergruppe – Forbrugergruppenavn for
ConsumerApp-2
, som angivet under stakopdateringen. - –rollesession-navn -
ConsumerApp-2
antagerTopic-B-Read-Role
ved at bruge AWS STS SDK.ConsumerApp-2
vil bruge dette rollesessions navn, når du kalderassumeRole
funktion. - –klient-id – Klient-id for
ConsumerApp-2
.
- Hvis du er tilfreds med resten af parametrene, skal du bruge følgende kommando og ændre
--assume-role-arn
,--region
i henhold til dit miljø:
fetch-throttle-time-avg
, fetch-throttle-time-max
klientmetrics skal vise 0.0, hvilket indikerer, at der ikke forekommer drosling for ConsumerApp-2
. Husk, at vi ikke har sat forbrugskvoten for ConsumerApp-2
endnu. Lad det køre et stykke tid.
Kør programmet ProducerApp-1
At køre ProducerApp-1
ansøgning, udfør følgende trin:
- På Amazon EC2-konsollen skal du vælge
ProducerApp-1
EC2 instans og vælg Tilslut. - På Session Manager fanebladet, vælg Tilslut.
- Kør følgende kommandoer på den nye fane, der åbnes i din browser:
- Kør
ProducerApp-1
applikation til at begynde at sende beskeder tilTopic-B
:
Du kan finde kildekode på GitHub til din reference. Kommandolinjeparameterdetaljerne er som følger:
- -bootstrap-servere – MSK cluster bootstrap brokers IAM-slutpunkt.
- –påtage-rolle-arn -
Topic-B-Write-Role
IAM rolle ARN. Påtager man sig denne rolle,ProducerApp-1
vil skrive beskeder til emnet. - –emnenavn -
ProducerApp-1
vil sende beskeder til dette emne. Standard erTopic-B
. - -område – AWS-region, du bruger.
- –antal-beskeder – Antal meddelelser
ProducerApp-1
ansøgning sendes til emnet. - –rollesession-navn -
ProducerApp-1
antagerTopic-B-Write-Role
ved at bruge AWS STS SDK.ProducerApp-1
vil bruge dette rollesessions navn, når du kalderassumeRole
funktion. - –klient-id – Klient-id på
ProducerApp-1
. - – producent-type -
ProducerApp-1
kan køres enten synkront or asynkront. Valgmuligheder er synkronisere or async. - –tryk-producent-kvote-metrics – Flag, der angiver, om klientmålingerne skal udskrives på terminalen ved ProducerApp-1.
- –cw-dimension-navn – CloudWatch-dimensionsnavn, der vil blive brugt til at offentliggøre klient-throttling-metrics fra ProducerApp-1.
- –cw-dimension-værdi – CloudWatch-dimensionsværdi, der vil blive brugt til at publicere klient-throttling-metrics fra ProducerApp-1.
- –cw-navneområde – Navnerummet hvor ProducerApp-1 vil offentliggøre CloudWatch-målinger for at overvåge drosling.
- Hvis du er tilfreds med resten af parametrene, skal du bruge følgende kommando og ændre
--assume-role-arn
,--region
efter dit miljø. For at køre en synkron Kafka-producent bruger den muligheden--producer-type sync
:
Alternativt, brug --producer-type async
at drive en asynkron producer. For flere detaljer, se Asynkron afsendelse.
produce-throttle-time-avg
, produce-throttle-time-max
klientmetrics skal vise 0.0, hvilket indikerer, at der ikke forekommer drosling for ProducerApp-1
. Husk, at vi ikke har fastsat produktionskvoten for ProducerApp-1
endnu. Tjek det ConsumerApp-1
, ConsumerApp-2
kan forbruge beskeder og bemærke, at de ikke er droslet. Stop forbruger- og producentklientapplikationerne ved at trykke på Ctrl + C i deres respektive browserfaner.
Indstil produktions- og forbrugskvoter for klientapplikationer
Nu hvor vi har kørt producent- og forbrugerapplikationerne uden kvoter, sætter vi deres kvoter og kører dem igen.
Åbne Sessionsleder terminal til MSKAdminInstance
EC2-instans som beskrevet tidligere, og kør følgende kommandoer for at finde standardkonfigurationen for en af mæglerne i MSK-klyngen. MSK-klynger leveres med standard Kafka-kvotekonfigurationen.
Følgende skærmbillede viser Broker-1
standardværdier for quota.consumer.default
, quota.producer.default
.
ProducerApp-1 kvotekonfiguration
Erstat pladsholdere i alle kommandoerne i dette afsnit med værdier, der svarer til din konto.
Indstil i henhold til arkitekturdiagrammet, der blev diskuteret tidligere ProducerApp-1
producere kvote til 1024 bytes/sekund. Til <ProducerApp-1 Client Id>
, <ProducerApp-1 Role Session>
, skal du sørge for at bruge de samme værdier, som du brugte, mens du løb ProducerApp-1
tidligere (producerapp-1-client-id
, producerapp-1-role-session
, henholdsvis):
Bekræft ProducerApp-1
producere kvote ved hjælp af følgende kommando:
Du kan fjerne ProducerApp-1
producere kvote ved at bruge følgende kommando, men kør ikke kommandoen da vi herefter tester kvoterne.
ConsumerApp-1 kvotekonfiguration
Erstat pladsholdere i alle kommandoerne i dette afsnit med værdier, der svarer til din konto.
Lad os sætte en forbrugskvote på 5120 bytes/sekund for ConsumerApp-1
. Forum <ConsumerApp-1 Client Id>
, <ConsumerApp-1 Role Session>
, skal du sørge for at bruge de samme værdier, som du brugte, mens du løb ConsumerApp-1
tidligere (consumerapp-1-client-id
, consumerapp-1-role-session
, henholdsvis):
kafka-configs.sh --bootstrap-server $BOOTSTRAP_BROKERS_IAM --command-config config_iam.properties --alter --add-config 'consumer_byte_rate=5120' --entity-type clients --entity-name <ConsumerApp-1 Client Id> --entity-type users --entity-name arn:aws:sts::<AWS Account Id>:assumed-role/MSKStack-TopicBReadRole-xxxxxxxxxxx/<ConsumerApp-1 Role Session>
Bekræft ConsumerApp-1
forbruge kvote ved hjælp af følgende kommando:
Du kan fjerne ConsumerApp-1
forbruge kvote ved at bruge følgende kommando, men kør ikke kommandoen da vi herefter tester kvoterne.
ConsumerApp-2 kvotekonfiguration
Erstat pladsholdere i alle kommandoerne i dette afsnit med værdier, der svarer til din konto.
Lad os sætte en forbrugskvote på 1024 bytes/sekund for ConsumerApp-2
. Forum <ConsumerApp-2 Client Id>
, <ConsumerApp-2 Role Session>
, skal du sørge for at bruge de samme værdier, som du brugte, mens du løb ConsumerApp-2
tidligere (consumerapp-2-client-id
, consumerapp-2-role-session
, henholdsvis):
Bekræft ConsumerApp-2
forbruge kvote ved hjælp af følgende kommando:
Som med ConsumerApp-1
, kan du fjerne ConsumerApp-2
forbruge kvote ved at bruge den samme kommando med ConsumerApp-2
klient- og brugeroplysninger.
Kør producent- og forbrugerapplikationerne igen efter at have sat kvoter
Lad os køre applikationerne igen for at kontrollere effekten af kvoterne.
Kør ProducerApp-1 igen
Rerun ProducerApp-1
in synkron tilstand med den samme kommando, som du brugte tidligere. Følgende skærmbillede illustrerer, hvornår ProducerApp-1
når sin kvote på nogen af mæglerne, den produce-throttle-time-avg
, produce-throttle-time-max client
metric-værdien vil være over 0.0. En værdi over 0.0 indikerer det ProducerApp-1
er droslet. Give lov til ProducerApp-1
at køre i et par sekunder og derefter stoppe den ved at bruge Ctrl + C.
Du kan også teste effekten af produktkvoten ved at køre igen ProducerApp-1
igen ind asynkron tilstand (--producer-type async
). I lighed med en synkron kørsel illustrerer følgende skærmbillede, at hvornår ProducerApp-1
når sin kvote på nogen af mæglerne, den produce-throttle-time-avg
, produce-throttle-time-max
værdi for klientmålinger vil være over 0.0. En værdi over 0.0 indikerer det ProducerApp-1
er droslet. Tillad asynkron ProducerApp-1
at løbe et stykke tid.
Du vil til sidst se en TimeoutException
angivelse org.apache.kafka.common.errors.TimeoutException: Expiring xxxxx record(s) for Topic-B-2:xxxxxxx ms has passed since batch creation
Når du bruger en asynkron producent og sender meddelelser med en højere hastighed end mægleren kan acceptere på grund af kvoten, vil meddelelserne først blive lagt i kø i klientapplikationens hukommelse. Klienten vil til sidst løbe tør for bufferplads, hvis hastigheden for afsendelse af meddelelser fortsætter med at overstige hastigheden for at acceptere meddelelser, hvilket forårsager den næste Producer.send()
opkald skal blokeres. Producer.send()
vil til sidst kaste en TimeoutException
hvis timeout-forsinkelsen ikke er tilstrækkelig til at give mægleren mulighed for at indhente producentansøgningen. Hold op ProducerApp-1
ved hjælp af Ctrl + C.
Kør ConsumerApp-1 igen
Rerun ConsumerApp-1
med den samme kommando, som du brugte tidligere. Følgende skærmbillede illustrerer, at hvornår ConsumerApp-1
når sin kvote, den fetch-throttle-time-avg
, fetch-throttle-time-max client
metric-værdien vil være over 0.0. En værdi over 0.0 indikerer det ConsumerApp-1
er droslet.
Tillad ConsumerApp-1
at køre i et par sekunder og derefter stoppe den ved at bruge Ctrl + C.
Kør ConsumerApp-2 igen
Rerun ConsumerApp-2
med den samme kommando, som du brugte tidligere. Tilsvarende hvornår ConsumerApp-2
når sin kvote, den fetch-throttle-time-avg
, fetch-throttle-time-max client
metric-værdien vil være over 0.0. En værdi over 0.0 angiver det ConsumerApp-2
er droslet. Give lov til ConsumerApp-2
at køre i et par sekunder og derefter stoppe den ved at trykke på Ctrl + C.
Kundekvotemålinger i Amazon CloudWatch
In del 1, forklarede vi, at klientmålinger er målinger, der eksponeres af klienter, der forbinder til Kafka-klynger. Lad os undersøge klientmålingerne i CloudWatch.
- På CloudWatch-konsollen skal du vælge Alle målinger.
- Under Brugerdefinerede navnerum, skal du vælge det navneområde, du angav, mens du kørte klientprogrammerne.
- Vælg dimensionsnavnet og vælg
produce-throttle-time-max
,produce-throttle-time-avg
,fetch-throttle-time-max
ogfetch-throttle-time-avg metrics
for alle applikationer.
Disse metrics angiver drosseladfærd for ProducerApp-1
, ConsumerApp-1
og ConsumerApp-2
applikationer testet med kvotekonfigurationerne i det foregående afsnit. Følgende skærmbilleder viser droslingen af ProducerApp-1
, ConsumerApp-1
og ConsumerApp-2
baseret på netværksbåndbreddekvoter. ProducerApp-1
, ConsumerApp-1
og ConsumerApp-2
applikationer leverer deres respektive klient-metrics til CloudWatch. Du kan finde kildekode på GitHub til din reference.
Sikkert klient-id og rollesessionsnavn
Vi diskuterede, hvordan man konfigurerer Kafka-kvoter ved hjælp af en applikations klient-id og autentificeret bruger rektor. Når en klientapplikation påtager sig en IAM-rolle for at få adgang til Kafka-emner på en MSK-klynge med IAM-godkendelse aktiveret, er dens autentificerede bruger principal er repræsenteret i følgende format (for mere information, se IAM identifikatorer):
arn:aws:sts::111111111111:assumed-role/Topic-B-Write-Role/producerapp-1-role-session
Den indeholder rollesessions navn (I dette tilfælde, producerapp-1-role-session
) brugt i klientapplikationen, mens du påtager dig en IAM-rolle gennem AWS STS SDK. Klientapplikationen kildekode er tilgængelig for din reference. Det klient-id er en logisk navnestreng (f.eks. producerapp-1-client-id
), der er konfigureret i applikationskoden af applikationsteamet. Derfor kan en applikation efterligne en anden applikation, hvis den opnår klient-id , rollesessions navn af den anden applikation, og hvis den har tilladelse til at påtage sig den samme IAM-rolle.
Som vist i arkitekturdiagrammet, ConsumerApp-1
, ConsumerApp-2
er to separate klientapplikationer med deres respektive kvotetildelinger. Fordi begge har tilladelse til at påtage sig den samme IAM-rolle (Topic-B-Read-Role
) på demokontoen har de lov til at forbruge beskeder fra Topic-B
. MSK klyngemæglere skelner dem således ud fra deres klient-id'er , brugere (som indeholder deres respektive rollesessions navn værdier). Hvis ConsumerApp-2
på en eller anden måde opnår ConsumerApp-1
rollesessions navn , klient-id, kan det efterligne ConsumerApp-1
ved at specificere ConsumerApp-1
rollesessions navn , klient-id i applikationskoden.
Lad os antage ConsumerApp-1
bruger consumerapp-1-client-id
, consumerapp-1-role-session
som dets klient-id , rollesessions navn, henholdsvis. Derfor, ConsumerApp-1's
autentificeret bruger hovedstol vil fremstå som følger, når den antager Topic-B-Read-Role
IAM rolle:
arn:aws:sts::<AWS Account Id>:assumed-role/Topic-B-Read-Role/consumerapp-1-role-session
Tilsvarende ConsumerApp-2
bruger consumerapp-2-client-id
, consumerapp-2-role-session
som dets klient-id , rollesessions navn, henholdsvis. Derfor, ConsumerApp-2's
autentificeret bruger hovedstol vil fremstå som følger, når den antager Topic-B-Read-Role
IAM rolle:
arn:aws:sts::<AWS Account Id>:assumed-role/Topic-B-Read-Role/consumerapp-2-role-session
If ConsumerApp-2
opnår ConsumerApp-1's
klient-id , rollesessions navn og angiver dem i sin applikationskode, vil MSK-klyngemæglere behandle det som ConsumerApp-1
og se den klient-id as consumerapp-1-client-id
, og den godkendte bruger hovedstol som følger:
arn:aws:sts::<AWS Account Id>:assumed-role/Topic-B-Read-Role/consumerapp-1-role-session
Dette tillader ConsumerApp-2
at forbruge data fra MSK-klyngen med en maksimal hastighed på 5120 bytes pr. sekund i stedet for 1024 bytes pr. sekund i henhold til dens oprindelige kvotetildeling. Følgelig, ConsumerApp-1's
gennemløb vil blive negativt påvirket, hvis ConsumerApp-2
kører sideløbende.
Forbedret arkitektur
Du kan introducere AWS Secrets Manager , AWS Key Management Service (AWS KMS) i arkitekturen for at sikre applikationer' klient-id'er , rolle session navne. For at give stærkere styring skal applikationernes klient-id og rollesessionsnavn gemmes som krypterede hemmeligheder i Secrets Manager. IAM-ressourcepolitikkerne forbundet med krypterede hemmeligheder og en KMS-kundeadministreret nøgle (CMK) vil tillade applikationer kun at få adgang til og dekryptere deres respektive klient-id og rollesessionsnavn. På denne måde vil applikationer ikke være i stand til at få adgang til hinandens klient-id og rollesessionsnavn og efterligne hinanden. Følgende billede viser den forbedrede arkitektur.
Det opdaterede flow har følgende trin:
- P1 -
ProducerApp-1
henter sinclient-id
,role-session-name
hemmeligheder fra Secrets Manager - P2 -
ProducerApp-1
konfigurerer hemmelighedenclient-id
asCLIENT_ID_CONFIG
i applikationskoden og antagerTopic-B-Write-Role
(via sinProducerApp-1-Role
IAM-rolle) ved at videregive hemmelighedenrole-session-name
til AWS STS SDKassumeRole
funktionskald - P3 - Med
Topic-B-Write-Role
IAM's rolle påtog sig,ProducerApp-1
begynder at sende beskeder tilTopic-B
- C1 -
ConsumerApp-1
,ConsumerApp-2
hente deres respektiveclient-id
,role-session-name
hemmeligheder fra Secrets Manager - C2 -
ConsumerApp-1
,ConsumerApp-2
konfigurere deres respektive hemmelighedclient-id
asCLIENT_ID_CONFIG
i deres ansøgningskode, og antagerTopic-B-Write-Role
(ViaConsumerApp-1-Role
,ConsumerApp-2-Role
IAM-roller) ved at videregive deres hemmelighedrole-session-name
i AWS STS SDKassumeRole
funktionskald - C3 - Med
Topic-B-Read-Role
IAM's rolle påtog sig,ConsumerApp-1
,ConsumerApp-2
begynde at forbruge beskeder fraTopic-B
Se dokumentationen for AWS Secrets Manager , AWS KMS for at få en bedre forståelse af, hvordan de passer ind i arkitekturen.
Ryd op i ressourcer
Naviger til CloudFormation-konsollen og slet MSKStack
stak. Alle ressourcer oprettet i løbet af dette indlæg vil blive slettet.
Konklusion
I dette indlæg dækkede vi detaljerede trin til at konfigurere Amazon MSK-kvoter og demonstrerede deres effekt gennem prøveklientapplikationer. Derudover diskuterede vi, hvordan du kan bruge klientmålinger til at afgøre, om en klientapplikation er droslet. Vi fremhævede også et potentielt problem med klient-id'er i klartekst og rollesessionsnavne. Vi anbefaler at implementere Kafka-kvoter med Amazon MSK ved hjælp af Secrets Manager og AWS KMS i henhold til det reviderede arkitekturdiagram for at sikre en nul-tillidsarkitektur.
Hvis du har feedback eller spørgsmål til dette indlæg, inklusive den reviderede arkitektur, hører vi gerne fra dig. Vi håber, du nød at læse dette indlæg.
Om forfatteren
Vikas Bajaj er Senior Manager, Solutions Architects, Financial Services hos Amazon Web Services. Med over to årtiers erfaring med finansielle tjenester og arbejde med digitalt indfødte virksomheder rådgiver han kunder om produktdesign, teknologiske køreplaner og applikationsarkitekturer.
- SEO Powered Content & PR Distribution. Bliv forstærket i dag.
- EVM Finans. Unified Interface for Decentralized Finance. Adgang her.
- Quantum Media Group. IR/PR forstærket. Adgang her.
- PlatoAiStream. Web3 Data Intelligence. Viden forstærket. Adgang her.
- Kilde: https://aws.amazon.com/blogs/big-data/multi-tenancy-apache-kafka-clusters-in-amazon-msk-with-iam-access-control-and-kafka-quotas-part-2/
- :har
- :er
- :ikke
- :hvor
- $OP
- 1
- 10
- 11
- 30
- 7
- 70
- 8
- 9
- a
- I stand
- Om
- over
- Acceptere
- acceptere
- adgang
- Konto
- anerkende
- tværs
- tilføje
- Desuden
- Yderligere
- Derudover
- Efter
- igen
- Alle
- allokering
- tildelinger
- tillade
- tillader
- også
- Amazon
- Amazon EC2
- Amazon Web Services
- an
- ,
- En anden
- enhver
- Apache
- Apache Kafka
- vises
- Anvendelse
- applikationer
- cirka
- arkitektur
- ER
- AS
- forbundet
- antaget
- At
- autentificeret
- Godkendelse
- til rådighed
- AWS
- AWS CloudFormation
- båndbredde
- baseret
- BE
- fordi
- været
- før
- være
- Bedre
- blokeret
- Bootstrap
- både
- Bund
- Boks
- mægler
- mæglere
- browser
- buffer
- virksomhed
- virksomheder
- men
- by
- ringe
- kaldet
- ringer
- CAN
- tilfælde
- KAT
- brydning
- forårsager
- CD
- central
- lave om
- Ændringer
- kontrollere
- Vælg
- klasse
- kunde
- kunder
- Cluster
- kode
- Fælles
- fuldføre
- Compute
- begreber
- Konfiguration
- konfigureret
- Tilslutning
- følgelig
- Konsol
- forbruge
- forbruger
- indeholder
- fortsæt
- fortsætter
- fortsættende
- kontrol
- dækket
- skabe
- oprettet
- Oprettelse af
- Nuværende
- kunde
- Kunder
- data
- Dataplatform
- årtier
- Dekryptér
- Standard
- forsinkelse
- Demo
- demonstreret
- Afhængigt
- beskrive
- beskrevet
- Design
- detaljeret
- detaljer
- Bestem
- bestemmer
- Dimension
- drøftet
- Skærm
- skelne
- dokumentation
- downloade
- grund
- i løbet af
- hver
- tidligere
- ekko
- effekt
- enten
- muliggøre
- aktiveret
- muliggør
- krypteret
- Endpoint
- håndhæve
- forbedret
- sikre
- Indtast
- Miljø
- fejl
- Ether (ETH)
- til sidst
- undersøge
- eksempel
- overstige
- Undtagen
- erfaring
- forklarede
- forklaring
- eksport
- udsat
- tilbagemeldinger
- få
- Figur
- File (Felt)
- Filer
- finansielle
- finansielle tjenesteydelser
- Finde
- Fornavn
- passer
- flow
- efter
- følger
- Til
- format
- fire
- fra
- funktion
- Endvidere
- få
- Git
- GitHub
- regeringsførelse
- større
- gruppe
- Gruppens
- Gem
- Have
- he
- høre
- højt niveau
- Fremhævet
- håber
- host
- værter
- Hvordan
- How To
- HTML
- http
- HTTPS
- IAM
- ID
- Identity
- id'er
- if
- illustrerer
- billede
- påvirket
- implementering
- gennemføre
- in
- Herunder
- angiver
- angiver
- angiver
- individuel
- oplysninger
- instans
- integral
- ind
- indføre
- introduceret
- isn
- spørgsmål
- IT
- ITS
- Java
- jpg
- Kafka
- Nøgle
- kendt
- GRÆNSE
- Line (linje)
- linjer
- Liste
- logisk
- lave
- lykkedes
- ledelse
- leder
- maksimal
- Kan..
- målt
- Hukommelse
- beskeder
- Metrics
- minutter
- tilstand
- ændre
- Overvåg
- mere
- MS
- meget
- flere
- skal
- navn
- navne
- Naviger
- Navigation
- Behov
- negativt
- netværk
- Ny
- næste
- ingen
- bemærkede
- Varsel..
- nummer
- opnår
- forekommende
- of
- on
- ONE
- kun
- åbner
- betjenes
- Produktion
- Option
- Indstillinger
- or
- ordrer
- original
- Andet
- ud
- i løbet af
- emballeret
- side
- brød
- parameter
- parametre
- del
- Bestået
- Passing
- sti
- procentdel
- udføre
- ydeevne
- tilladelse
- Simpel tekst
- perron
- plato
- Platon Data Intelligence
- PlatoData
- Punkt
- punkter
- politikker
- politik
- Indlæg
- potentiale
- trykke
- forhindre
- tidligere
- tidligere
- Main
- private
- forarbejdning
- producere
- producent
- Produkt
- Produktdesign
- egenskaber
- give
- forudsat
- offentlige
- offentliggøre
- Spørgsmål
- Sats
- hellere
- når
- Læs
- Læsning
- anbefaler
- anbefales
- benævnt
- region
- huske
- Fjern
- erstatte
- Repository
- repræsenteret
- anmode
- anmodninger
- påkrævet
- ressource
- Ressourcer
- dem
- henholdsvis
- REST
- køreplaner
- roller
- roller
- Kør
- kører
- s
- samme
- tilfreds
- Tilfreds med
- screenshots
- SDK
- Anden
- sekunder
- Secret
- Sektion
- sikker
- sikkerhed
- sikkerhedsbogstav
- se
- send
- afsendelse
- senior
- adskille
- Series
- Tjenester
- Session
- sæt
- indstilling
- indstillinger
- bør
- vist
- Shows
- lignende
- Tilsvarende
- siden
- Løsninger
- Kilde
- kildekode
- Space
- specifikke
- specificeret
- stable
- etaper
- starte
- påbegyndt
- Trin
- Steps
- Stands
- opbevaret
- streaming
- String
- stærkere
- undernet
- efterfølgende
- Succesfuld
- sådan
- tilstrækkeligt
- tilført
- Understøtter
- Tag
- hold
- Teknologier
- skabelon
- skabeloner
- terminal
- prøve
- afprøvet
- Test
- end
- at
- The Source
- deres
- Them
- derefter
- derfor
- de
- denne
- tre
- Gennem
- kapacitet
- tid
- til
- token
- emne
- Emner
- behandle
- Stol
- to
- typen
- typer
- forståelse
- Opdatering
- opdateret
- opdatering
- brug
- anvendte
- Bruger
- brugere
- bruger
- ved brug af
- værdi
- Værdier
- verificere
- via
- Specifikation
- var
- Vej..
- we
- web
- webservices
- GODT
- hvornår
- hvorvidt
- som
- mens
- vilje
- med
- uden
- arbejder
- skriver
- endnu
- dig
- Din
- zephyrnet