De ce Prime Video a trecut de la microsserviții serverless la un monolit

Echipa de inginerie Amazon Prime Video a publicat recent un articol tehnic detaliind trecerea lor de la o arhitectură de microsserviții serverless la o aplicație monolitică, rezultând într-o reducere remarcabilă de 90% a costurilor operaționale. Această mutare, adesea simplificată ca abandonarea microsservițiilor, evidențiază de fapt problemele cu implementările serverless specifice pentru orchestrarea evenimentelor de înaltă frecvență. Problema principală nu a fost conceptul de microsserviții în sine, ci utilizarea ineficientă a AWS Step Functions și Lambda pentru un pipeline solicitant de analiză a calității video în timp real.

Arhitectura originală pentru serviciul Video Quality Analysis (VQA) a implicat descompunerea fluxurilor video în cadre și buffere audio, cu funcții AWS Lambda acționând ca 'Defect Detectors' pentru identificarea problemelor. AWS Step Functions a orchestrat acești pași, iar Amazon S3 a fost utilizat pentru stocarea intermediară. Deși aceasta a oferit scalabilitate teoretică și dezvoltare rapidă, s-a dovedit costisitoare și limitativă la scara Prime Video. Volumul mare de tranziții de stare în Step Functions a atins limitele contului, iar operațiunile frecvente de citire/scriere S3 pentru transferul cadrelor au generat costuri prohibitive.

Arhitectura revizuită consolidează conversia media și detectarea defectelor într-un singur proces rulând pe EC2 și ECS, eliminând Step Functions și S3 pentru transferul de date între etape. Cadrele sunt acum transmise în memorie în cadrul aceluiași proces, reducând semnificativ overhead-ul. Deși nu este un monolit tradițional, această distribuție mai grosieră a sarcinii pe mai multe sarcini ECS a rezolvat blocajele de scalare și a redus drastic cheltuielile operaționale, demonstrând importanța potrivirii tiparelor arhitecturale cu caracteristicile specifice ale sarcinii de lucru.