Amazon administrerte arbeidsflyter for Apache Airflow (Amazon MWAA) er en administrert tjeneste for Apache luftstrøm som effektiviserer oppsettet og driften av infrastrukturen for å orkestrere datarørledninger i skyen. Kunder bruker Amazon MWAA til å administrere skalerbarheten, tilgjengeligheten og sikkerheten til deres Apache Airflow-miljøer. Etter hvert som de designer mer intensive, komplekse og stadig voksende databehandlingspipelines, har kunder bedt oss om ytterligere underliggende ressurser for å gi større samtidighet og kapasitet for deres oppgaver og arbeidsflyter.

For å løse dette kunngjør vi i dag tilgjengeligheten av større miljøklasser i Amazon MWAA. I dette innlegget dykker vi ned i egenskapene til disse nye XL- og 2XL-miljøene, scenariene de er godt egnet for, og hvordan du kan sette opp eller oppgradere ditt eksisterende Amazon MWAA-miljø for å dra nytte av de økte ressursene.

Aktuelle utfordringer

Når du oppretter et Amazon MWAA-miljø, et sett med administrerte Amazon Elastic Container Service (Amazon ECS) med AWS Fargate containere er utstyrt med definerte virtuelle CPUer og RAM.

Når du jobber med større, komplekse, ressurskrevende arbeidsbelastninger, eller kjører tusenvis av Regissert asykliske grafer (DAGs) per dag, kan du begynne å utmatte CPU-tilgjengeligheten på planleggere og arbeidere, eller nå minnegrenser hos arbeidere. Å kjøre Apache Airflow i stor skala gir proporsjonalt større belastning på Airflow-metadatadatabasen, noe som noen ganger fører til CPU- og minneproblemer på den underliggende Amazon Relational Database Service (Amazon RDS) klynge. En ressursutsultet metadatadatabase kan føre til at tilkoblinger fra arbeiderne dine blir avbrutt, og at oppgaver mislykkes for tidlig.

For å forbedre ytelsen og robustheten til oppgavene dine, vurder å følge Beste praksis for Apache Airflow til forfatter DAGs. Som et alternativ kan du opprette flere Amazon MWAA-miljøer for å distribuere arbeidsbelastninger. Dette krever imidlertid ytterligere ingeniør- og ledelsesinnsats.

Nye miljøklasser

Med dagens utgivelse kan du nå lage XL- og 2XL-miljøer i Amazon MWAA i tillegg til de eksisterende miljøklassene. De har henholdsvis to og fire ganger beregningen, og tre og seks ganger minnet, av den nåværende store Amazon MWAA-miljøforekomstklassen. Disse forekomstene legger til databehandling og RAM lineært for direkte å forbedre kapasiteten og ytelsen til alle Apache Airflow-komponenter. Følgende tabell oppsummerer miljøevner.

Med introduksjonen av disse større miljøene vil Amazon Aurora-metadatadatabasen din nå bruke større, minneoptimaliserte forekomster drevet av AWS Graviton2. Med Graviton2-familien av prosessorer får du databehandling, lagring og nettverksforbedringer, og reduksjonen av karbonavtrykket ditt som tilbys av AWS-familien av prosessorer.

Priser

Amazon MWAA-prisdimensjoner forblir uendret, og du betaler kun for det du bruker:

• Miljøklassen
• Ytterligere arbeiderforekomster
• Ytterligere planleggerforekomster
• Lagring av metadatadatabase forbrukt

Du får nå to tilleggsalternativer i de tre første dimensjonene: XL og 2XL for miljøklasse, ekstra arbeidere og planleggere-forekomster. Prisen for lagring av metadatadatabase forblir den samme. Referere til Amazon administrerte arbeidsflyter for Apache Airflow-priser for priser og flere detaljer.

Observer Amazon MWAA-ytelse for å planlegge skalering til større miljøer

Før du begynner å bruke de nye miljøklassene, er det viktig å forstå om du er i et scenario som er relatert til kapasitetsproblemer, for eksempel metadatadatabase tom for minne, eller arbeidere eller planleggere som kjører med høy CPU-bruk. Å forstå ytelsen til miljøressursene dine er nøkkelen til feilsøking av problemer knyttet til kapasitet. Vi anbefaler å følge veiledningen beskrevet i Introduserer beholder-, database- og køutnyttelsesberegninger for Amazon MWAA-miljøet for å bedre forstå tilstanden til Amazon MWAA-miljøer, og få innsikt for å tilpasse forekomstene dine i riktig størrelse.

I den følgende testen simulerer vi et scenario med høy belastning, bruk CloudWatch-observasjonsmålinger å identifisere vanlige problemer, og ta en informert beslutning om å planlegge skalering til større miljøer for å redusere problemene.

Under testene våre kjørte vi en kompleks DAG som dynamisk lager over 500 oppgaver og bruker eksterne sensorer for å vente på en oppgavefullføring i en annen DAG. Etter å ha kjørt på en Amazon MWAA stor miljøklasse med automatisk skalering satt opp til maksimalt 10 arbeidernoder, la vi merke til følgende beregninger og verdier i CloudWatch dashbord.

Arbeidsnodene har nådd maksimal CPU-kapasitet, noe som fører til at antall oppgaver i kø fortsetter å øke. CPU-utnyttelsen av metadatadatabasen har nådd en topp på over 65 % kapasitet, og ledig databaseminne er redusert. I denne situasjonen kan vi øke arbeidernodene ytterligere for å skalere, men det vil legge ekstra belastning på metadatadatabasen CPU. Dette kan føre til et fall i antall arbeiderdatabasetilkoblinger og ledig ledig databaseminne.

Med nye miljøklasser kan du skalere vertikalt for å øke tilgjengelige ressurser ved å redigere miljøet og velge en høyere miljøklasse, som vist i følgende skjermbilde.

Fra listen over miljøer velger vi det som er i bruk for denne testen. Velge Rediger å navigere til Konfigurer avanserte innstillinger side, og velg passende xlarge- eller 2xlarge-miljø etter behov.

Etter at du har lagret endringen, vil miljøoppgraderingen ta 20–30 minutter å fullføre. Enhver kjørende DAG som ble avbrutt under oppgraderingen er planlagt for et nytt forsøk, avhengig av måten du konfigurerte forsøkene på nytt for DAG-ene dine. Du kan nå velge å starte dem manuelt eller vente på neste planlagte kjøring.

Etter at vi oppgraderte miljøklassen, testet vi den samme DAG og observerte at beregningene viste forbedrede verdier fordi flere ressurser nå er tilgjengelige. Med dette XL-miljøet kan du kjøre flere oppgaver på færre arbeidernoder, og derfor fortsatte antallet oppgaver i køen å synke. Alternativt, hvis du har oppgaver som krever mer minne og/eller CPU, kan du redusere oppgavene per arbeider, men likevel oppnå et høyt antall oppgaver per arbeider med en større miljøstørrelse. For eksempel, hvis du har et stort miljø der arbeidernoden CPU er maksert med celery.worker_autoscale (luftstrømkonfigurasjonen som definerer antall oppgaver per arbeider) Sett til 20,20, kan du øke til et XL-miljø og angi celery.worker_autoscale til 20,20 på XL, i stedet for standard 40 oppgaver per arbeider i et XL-miljø og CPU-belastningen bør reduseres betydelig.

Sett opp et nytt XL-miljø i Amazon MWAA

Du kan komme i gang med Amazon MWAA i kontoen din og foretrukket AWS-region ved å bruke AWS-administrasjonskonsoll, API eller AWS kommandolinjegrensesnitt (AWS CLI). Hvis du tar i bruk infrastruktur som kode (IaC), kan du automatisere oppsettet ved å bruke AWS skyformasjonden AWS skyutviklingssett (AWS CDK), eller Terraform-skript.

Amazon MWAA XL og 2XL miljøklasser er tilgjengelig i dag i alle regioner der Amazon MWAA er tilgjengelig for øyeblikket.

konklusjonen

I dag kunngjør vi tilgjengeligheten av to nye miljøklasser i Amazon MWAA. Med XL- og 2XL-miljøklasser kan du orkestrere større volumer av komplekse eller ressurskrevende arbeidsflyter. Hvis du kjører DAG-er med et høyt antall avhengigheter, kjører tusenvis av DAG-er på tvers av flere miljøer, eller i et scenario som krever at du bruker arbeidere i stor grad til databehandling, kan du nå overvinne de relaterte kapasitetsproblemene ved å øke miljøressursene dine på noen få enkle skritt.

I dette innlegget diskuterte vi mulighetene til de to nye miljøklassene, inkludert priser og noen vanlige ressursproblemer de løser. Vi ga veiledning og et eksempel på hvordan du kan observere dine eksisterende miljøer for å planlegge skalering til XL eller 2XL, og vi beskrev hvordan du kan oppgradere eksisterende miljøer for å bruke de økte ressursene.

For ytterligere detaljer og kodeeksempler på Amazon MWAA, besøk Amazon MWAA brukerveiledning og Amazon MWAA eksempler GitHub repo.

Apache, Apache Airflow og Airflow er enten registrerte varemerker eller varemerker tilhørende Apache Software Foundation i USA og / eller andre land.

Om forfatterne

Hernan Garcia er Senior Solutions Architect hos AWS med base i Nederland. Han jobber i finansnæringen og støtter bedrifter i deres skyadopsjon. Han er lidenskapelig opptatt av serverløse teknologier, sikkerhet og overholdelse. Han liker å tilbringe tid med familie og venner, og prøve ut nye retter fra forskjellige kjøkken.

Jeetendra Vaidya er en senior løsningsarkitekt hos AWS, og bringer sin ekspertise til AI/ML, serverløse og dataanalysedomener. Han brenner for å bistå kunder med å utforme sikre, skalerbare, pålitelige og kostnadseffektive løsninger.

Sriharsh Adari er Senior Solutions Architect hos AWS, hvor han hjelper kunder med å jobbe bakover fra forretningsresultater for å utvikle innovative løsninger på AWS. Gjennom årene har han hjulpet flere kunder med transformasjoner av dataplattformer på tvers av industrivertikaler. Hans kjernekompetanseområde inkluderer teknologistrategi, dataanalyse og datavitenskap. På fritiden liker han å spille sport, se på TV-programmer og spille Tabla.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• kilde: https://aws.amazon.com/blogs/big-data/introducing-amazon-mwaa-larger-environment-sizes/