Forbedre skalerbarheten for Amazon Rekognition statsløse APIer ved å bruke flere regioner

I forrige blogginnlegg, beskrev vi en ende-til-ende identitetsverifiseringsløsning i en enkelt AWS-region. Løsningen bruker Amazon-anerkjennelse APIer Oppdag ansikter for ansiktsgjenkjenning og Sammenlign ansikter for ansiktssammenligning. Vi tenker på disse API-ene som statsløse APIer fordi de ikke er avhengige av en Amazon-gjenkjenning ansiktssamling. De er også idempotente, noe som betyr at gjentatte anrop med de samme parameterne vil returnere det samme resultatet. De gir fleksible alternativer for å sende bilder, enten gjennom en Amazon enkel lagringstjeneste (Amazon S3) plassering eller råbyte.

I dette innlegget fokuserer vi på Amazon -anerkjennelsesbilde statsløse APIer, og diskutere to alternativer for å sende bilder og når man skal velge det ene fremfor det andre fra et systemarkitektursynspunkt. Deretter diskuterer vi hvordan man skalerer de statsløse API-ene for å overvinne noen regionale begrensninger. Når vi snakker om skalerbarhet, viser vi ofte til de maksimale transaksjonene per sekund (TPS) løsningen kan håndtere. For eksempel, når du er vert for et stort arrangement som bruker datasyn til å oppdage ansikter eller objektetiketter, kan du støte på en trafikkøkning, og du vil ikke at systemet skal stoppe. Det betyr at du noen ganger må øke TPS og til og med gå utover den regionale tjenestekvoten Amazon Rekognition APIer har. Dette innlegget foreslår en løsning for å øke de statsløse API-enes TPS ved å bruke flere regioner.

Amazon Rekognition statsløse APIer

Av Amazon Rekognition Image API-ene som er tilgjengelige, Sammenlign ansikter, Oppdag ansikter, Oppdage etiketter, DetectModerationLabels, DetectProtectiveEquipment, Oppdag tekstog Gjenkjenne kjendiser er statsløse. De gir både Amazon S3 og råbyte-alternativer for å sende bilder. For eksempel, i forespørselssyntaksen til DetectFaces API, er det to alternativer å overføre til Image felt: Bytes or S3Object.

Når du bruker S3Object alternativ, er en typisk arkitektur som følger.

Denne løsningen har følgende arbeidsflyt:

1. Klientapplikasjonen får tilgang til en nettside som er vert for AWS forsterke.
2. Klientapplikasjonen er autentisert og autorisert med Amazon Cognito.
3. Klientapplikasjonen laster opp et bilde til en S3-bøtte.
4. Amazon S3 utløser en AWS Lambda funksjon for å kalle Amazon Rekognition.
5. Lambda-funksjonen kaller opp Amazon Rekognition APIer med S3Object-alternativet.
6. Lambda-funksjonen vedvarer resultatet til en Amazon DynamoDB tabellen.

Velg S3Object alternativ i følgende scenarier:

• Bildet er enten en PNG- eller JPEG-formatert fil
• Du distribuerer hele stabelen i samme region der Amazon Rekognition er tilgjengelig
• Den regionale tjenestekvoten til Amazon Rekognition API oppfyller systemkravet ditt

Når du ikke oppfyller alle disse kravene, bør du velge Bytes alternativet.

Bruk Amazon Rekognition Stateless API-er i en annen region

Et eksempel på bruk av Bytes alternativet er når du vil distribuere brukstilfellet ditt i en region der Amazon Rekognition ikke er generelt tilgjengelig, for eksempel hvis du har kundetilstedeværelse i Sør-Amerika (sa-east-1) Region. For dataopphold må S3-bøtten som du bruker til å lagre brukernes bilder være i sa-east-1, men du vil bruke Amazon Rekognition for løsningen din selv om den ikke er generelt tilgjengelig i sa-east-1. En løsning er å bruke Bytes mulighet for å ringe Amazon Rekognition i en annen region der Amazon Rekognition er tilgjengelig, for eksempel us-east-1. Følgende diagram illustrerer denne arkitekturen.

Etter at Lambda-funksjonen er utløst (trinn 4), i stedet for å kalle Amazon Rekognition direkte med bildets S3-plassering, må funksjonen hente bildet fra S3-bøtten (trinn 5), og deretter kalle Amazon Rekognition med bildets råbyte (trinn). 6). Følgende er en kodebit av Lambda-funksjonen:

rekognition_region = os.getenv("REKOGNITION_REGION")
s3 = boto3.client('s3')
rekognition = boto3.client('rekognition', region_name=rekognition_region)

def handler(event, context):
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = urllib.parse.unquote_plus(
    event['Records'][0]['s3']['object']['key'], encoding='utf-8')
    s3_res = s3.get_object(Bucket=bucket, Key=key)
    rekognition_res = rekognition.detect_faces(Image={"Bytes": s3_res['Body'].read()}, Attributes=['ALL'])
    print(json.dumps(rekognition_res))

Merk at den foregående kodebiten fungerer direkte for JPEG- eller PNG-formater. For andre bildeformater, som BMP, er ekstra bildebehandling nødvendig for å konvertere det til JPEG- eller PNG-byte før det sendes til Amazon Rekognition. Følgende kode konverterer BMP til JPEG-byte:

import io
from PIL import Image

s3_res = s3.get_object(Bucket=bucket, Key=key)
bmp_img = Image.open(io.BytesIO(s3_res['Body'].read()))
buffered = io.BytesIO()
rgb_img = bmp_img.convert('RGB')
rgb_img.save(buffered, format="JPEG")
rekognition_res = rekognition.detect_faces(Image={"Bytes": buffered.getvalue()}, Attributes=['ALL'])

Skaler opp statsløse API-ers TPS ved å spre API-kall til flere regioner

Et annet brukstilfelle av Bytes alternativet er at du kan skalere opp de statsløse API-enes TPS ved å spre API-kallene til flere regioner. På denne måten er du ikke begrenset av den regionale tjenestekvoten til API-et fordi du kan få ytterligere TPS fra andre regioner.

I det følgende eksempelet opprettes en Lambda-funksjon for å kalle Amazon Rekognition DetectLabels API med Bytes alternativ. For å skalere opp maksimal TPS kan du spre API-kallene til flere regioner med vekter. Maksimal TPS du kan oppnå beregnes med: min(region_1_max_tps/region_1_weight, region_2_max_tps/region_2_weight, … region_n_max_tps/region_n_weight). Følgende eksempel bruker us-east-1 og us-west-2 Regioner.

Kodebiten for å kalle DetectLabels API er som følger:

region_1 = os.getenv("REKOGNITION_REGION_1")
region_2 = os.getenv("REKOGNITION_REGION_2")
region_1_traffic_percentage = int(os.getenv("REGION_1_TRAFFIC_PERCENTAGE"))

# randomly generate a number between 1, 100
random_num = random.randint(1, 100)
region = region_1 if random_num <= region_1_traffic_percentage else region_2
rekognition = boto3.client('rekognition', region_name=region)
response = rekognition.detect_labels(Image={"Bytes": image_bytes})
print(response)

Fordi us-east-1 og us-west-2 begge har maksimalt 50 TPS for Amazon Rekognition DetectFaces API, du kan jevnt fordele API-kallene med 50/50 vekt ved å sette miljøvariabelen REGION_1_TRAFFIC_PERCENTAGE til 50. På denne måten kan du oppnå min(50/50%, 50/50%) = 100 TPS i teorien.

For å validere ideen er Lambda-funksjonen eksponert som en REST API med Amazon API-gateway. da JMeter brukes til å lastetesting av API.

REGION_1_TRAFFIC_PERCENTAGE er først satt til 100, på denne måten alle DetectFaces API-kall sendes til us-east-1 bare. I teorien er den maksimale TPS som kan oppnås begrenset av tjenestekvoten i us-east-1, som er 50 TPS. Lasttest på det tilpassede API-endepunktet, starter med 50 samtidige tråder, legg til trinnvis 5 tråder til ProvisionedThroughputExceededException returnert fra Amazon Rekognition observeres.

REGION_1_TRAFFIC_PERCENTAGE er da satt til 50, på denne måten alt DetectLabels API-kall sendes jevnt til us-east-1 og us-west-2. I teorien er den maksimale TPS som kan oppnås tjenestekvoten som de to regionene kombinerer, som er 100 TPS. Start belastningstesten på nytt fra 100 tråder for å finne maksimal TPS.

Tabellen nedenfor oppsummerer resultatene av lasttestingen.

konklusjonen

Mange kunder bruker Amazon Rekognition Image statsløse APIer for ulike brukstilfeller, inkludert identitetsbekreftelse, innholdsmoderering, mediebehandling og mer. Dette innlegget diskuterte de to alternativene for å sende bilder og hvordan du bruker alternativet råbyte for følgende brukstilfeller:

• Amazon Rekognition Regional tilgjengelighet
• Kundedataopphold
• Oppskalering av Amazon Rekognition statsløse APIs TPS

Sjekk ut hvordan Amazon Rekognition brukes i forskjellige bruksområder for datasyn og start din innovasjonsreise.

Om forfatterne

Sharon Lic er en løsningsarkitekt ved AWS, basert i Boston, MA-området. Hun jobber med bedriftskunder, hjelper dem med å løse vanskelige problemer og bygge videre på AWS. Utenom jobben liker hun å tilbringe tid med familien og utforske lokale restauranter.

Vaibhav Shah er en Senior Solutions Architect med AWS og liker å hjelpe kundene sine med alt skyen og aktivere deres skyadopsjonsreise. Utenom jobben elsker han å reise, utforske nye steder og restauranter, lage mat, følge sport som cricket og fotball, se filmer og serier (Marvel-fan) og eventyrlige aktiviteter som fotturer, fallskjermhopping, og listen fortsetter.