Förbättra skalbarheten för Amazon Rekognition statslösa API:er med flera regioner

I tidigare blogginlägg, beskrev vi en end-to-end-identitetsverifieringslösning i en enda AWS-region. Lösningen använder Amazon-erkännande API: er Detektera ansikten för ansiktsdetektion och Jämför Faces för ansiktsjämförelse. Vi tänker på dessa API:er som tillståndslösa API:er eftersom de inte är beroende av en Amazon Rekognition ansiktssamling. De är också idempotenta, vilket innebär att upprepade samtal med samma parametrar kommer att returnera samma resultat. De ger flexibla alternativ för att skicka bilder, antingen genom en Amazon enkel lagringstjänst (Amazon S3) plats eller råbyte.

I det här inlägget fokuserar vi på Amazon -igenkänningsbild statslösa API:er och diskutera två alternativ för att skicka bilder och när man ska välja den ena framför den andra ur systemarkitektursynpunkt. Sedan diskuterar vi hur man skalar de statslösa API:erna för att övervinna vissa regionala begränsningar. När vi pratar om skalbarhet hänvisar vi ofta till de maximala transaktioner per sekund (TPS) lösningen kan hantera. Till exempel, när du är värd för ett stort evenemang som använder datorseende för att upptäcka ansikten eller objektetiketter, kan du stöta på en trafikökning och du vill inte att systemet ska strypa. Det betyder att du ibland behöver öka TPS och till och med gå utöver den regionala tjänstekvoten som Amazon Rekognition API har. Det här inlägget föreslår en lösning för att öka de statslösa API:ernas TPS genom att använda flera regioner.

Amazon Rekognition statslösa API:er

Av de tillgängliga Amazon Rekognition Image API:erna, Jämför Faces, Detektera ansikten, Upptäck etiketter, DetectModerationLabels, DetectProtective Equipment, Detektera textoch Känn igen kändisar är statslösa. De tillhandahåller både Amazon S3 och råbytesalternativ för att skicka bilder. Till exempel i begäransyntaxen för DetectFaces API, det finns två alternativ att skicka till Image fält: Bytes or S3Object.

När du använder S3Object alternativ, en typisk arkitektur är följande.

Denna lösning har följande arbetsflöde:

1. Klientapplikationen får åtkomst till en webbsida som är värd för AWS förstärka.
2. Klientapplikationen är autentiserad och auktoriserad med Amazon Cognito.
3. Klientapplikationen laddar upp en bild till en S3-hink.
4. Amazon S3 triggar en AWS Lambda funktion för att anropa Amazon Rekognition.
5. Lambdafunktionen anropar Amazon Rekognition API:er med alternativet S3Object.
6. Lambdafunktionen behåller resultatet till en Amazon DynamoDB tabell.

Välj S3Object alternativ i följande scenarier:

• Bilden är antingen en PNG- eller JPEG-formaterad fil
• Du distribuerar hela stacken i samma region där Amazon Rekognition är tillgängligt
• Den regionala tjänstekvoten för Amazon Rekognition API uppfyller dina systemkrav

När du inte uppfyller alla dessa krav bör du välja Bytes alternativ.

Använd Amazon Rekognition Stateless API:er i en annan region

Ett exempel på att använda Bytes alternativet är när du vill distribuera ditt användningsfall i en region där Amazon Rekognition inte är allmänt tillgängligt, till exempel om du har kundnärvaro i Sydamerika (sa-east-1) Region. För dataresidency måste S3-hinken som du använder för att lagra användarnas bilder finnas i sa-east-1, men du vill använda Amazon Rekognition för din lösning även om den inte är allmänt tillgänglig i sa-east-1. En lösning är att använda Bytes alternativet att ringa Amazon Rekognition i en annan region där Amazon Rekognition är tillgänglig, t.ex us-east-1. Följande diagram illustrerar denna arkitektur.

Efter att Lambda-funktionen har utlösts (Steg 4), istället för att anropa Amazon Rekognition direkt med bildens S3-plats, behöver funktionen hämta bilden från S3-bucket (Steg 5), och sedan anropa Amazon Rekognition med bildens råbytes (Steg) 6). Följande är ett kodavsnitt av Lambda-funktionen:

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))

Observera att det föregående kodavsnittet fungerar direkt för JPEG- eller PNG-format. För andra bildformat, som BMP, krävs extra bildbehandling för att konvertera den till JPEG- eller PNG-byte innan den skickas till Amazon Rekognition. Följande kod konverterar BMP till 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'])

Skala upp statslösa API:ers TPS genom att sprida API-anrop till flera regioner

Ett annat användningsfall av Bytes Alternativet är att du kan skala upp de statslösa API:ernas TPS genom att sprida API-anropen till flera regioner. På så sätt begränsas du inte av API:ets regionala tjänstekvot eftersom du kan få ytterligare TPS från andra regioner.

I följande exempel skapas en Lambda-funktion för att anropa Amazon Rekognition DetectLabels API med Bytes alternativ. För att skala upp den maximala TPS kan du sprida API-anropen i flera regioner med vikter. Den maximala TPS du kan uppnå beräknas med: min(region_1_max_tps/region_1_weight, region_2_max_tps/region_2_weight, … region_n_max_tps/region_n_weight). Följande exempel använder us-east-1 och us-west-2 Regioner.

Kodavsnittet för att anropa DetectLabels API är följande:

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)

Därför att us-east-1 och us-west-2 båda har max 50 TPS för Amazon Rekognition DetectFaces API, du kan fördela API-anropen jämnt med 50/50 vikt genom att ställa in miljövariabeln REGION_1_TRAFFIC_PERCENTAGE till 50. På så sätt kan du uppnå min(50/50%, 50/50%) = 100 TPS i teorin.

För att validera idén exponeras Lambda-funktionen som ett REST API med Amazon API Gateway. Därefter JMeter används för att ladda testa API.

REGION_1_TRAFFIC_PERCENTAGE är först inställd på 100, på detta sätt alla DetectFaces API-anrop skickas till us-east-1 endast. I teorin begränsas den maximala TPS som kan uppnås av tjänstekvoten i us-east-1, vilket är 50 TPS. Ladda test på den anpassade API-slutpunkten, börjar med 50 samtidiga trådar, lägg till 5 trådar stegvis tills ProvisionedThroughputExceededException returneras från Amazon Rekognition observeras.

REGION_1_TRAFFIC_PERCENTAGE är sedan inställd på 50, så här allt DetectLabels API-anrop skickas jämnt till us-east-1 och us-west-2. I teorin är den maximala TPS som kan uppnås den tjänstekvot som de två regionerna kombinerar, vilket är 100 TPS. Starta belastningstestet igen från 100 trådar för att hitta den maximala TPS.

Följande tabell sammanfattar resultaten av lasttestningen.

Slutsats

Många kunder använder Amazon Rekognition Image statslösa API:er för olika användningsfall, inklusive identitetsverifiering, innehållsmoderering, mediebearbetning och mer. Det här inlägget diskuterade de två alternativen för att skicka bilder och hur man använder alternativet råbytes för följande användningsfall:

• Amazon Rekognition Regional tillgänglighet
• Residency för kunddata
• Skala upp Amazon Rekognition statslösa APIs TPS

Kolla in hur Amazon Rekognition används i olika användningsfall för datorseende och starta din innovationsresa.

Om författarna

Sharon Lic är en lösningsarkitekt på AWS, baserad i Boston, MA-området. Hon arbetar med företagskunder, hjälper dem att lösa svåra problem och bygga vidare på AWS. Utanför jobbet gillar hon att umgås med sin familj och utforska lokala restauranger.

Vaibhav Shah är en Senior Solutions Architect med AWS och gillar att hjälpa sina kunder med allt moln och möjliggöra deras molnadoptionsresa. Utanför jobbet älskar han att resa, utforska nya platser och restauranger, laga mat, följa sporter som cricket och fotboll, titta på filmer och serier (Marvel-fan) och äventyrliga aktiviteter som vandring, fallskärmshoppning, och listan fortsätter.