Planlægning af Flere Programmer Med Ét Klik — Overgåelse af AWS Lambdas 15-Minutters Grænse
En FAST channel-operatør planlægger en måneds programmering og trykker Deploy én gang. Bag dette ene klik bliver hundredvis af programmer til tusindvis af MediaLive-planlægningshandlinger, der skal lande i AWS i den rigtige rækkefølge, alt sammen inden for Lambdas femten-minutters udførelsesgrænse — og enhver fejl midtvejs efterlader en live channel med huller i. Her er hvordan vi gjorde one-click implementering af store spillelister pålidelig, og hvorfor det næste skridt er en anden runtime, ikke en større Lambda.
Hurtigt overblik
| Aspekt | Detalje |
|---|---|
| Runtime | AWS Lambda (enkeltkald), 615s backend timeout |
| Output-mål | MediaLive BatchUpdateScheduleCommand |
| Batching | Op til 200 MediaLive-handlinger pr. anmodning — ~25 programmer i praksis |
| Handlinger pr. program | ~7–8 (inputskift + 4 vandmærker pr. rendition + 2 SCTE-35), mere med reklamepauser |
| Fallback | Genforsøg pr. program ved afvisning af batch |
| Observeret | 195 programmer implementeret på ~44 sekunder (lokal måling) |
| Dokumenteret mål | 360 programmer på ≤90 sekunder |
| Skaleringsvej | Step Functions-opdeling for spillelister på >1 måned — planlagt, ikke leveret |
Udfordringen
Implementering af en spilleliste er ikke en skrivning — det er en orkestrering. For hvert program operatøren har planlagt, skal MediaLive vide præcis, hvornår der skal skiftes input, hvornår vandmærket skal slås til for hver rendition, hvornår SCTE-35 cue points skal indsættes, og hvornår reklamer skal indklippes. De strukturelle pres er:
- Antallet af handlinger er multiplikativt, ikke additivt. Hvert program udsender ~7–8 handlinger før reklamepauser — et inputskift, fire vandmærkeaktiveringer (én pr. rendition, fordi StaticImageOutputActivate bruger output-pixelkoordinater), og to SCTE-35-markører. Reklamepauser tilføjer tre yderligere handlinger hver. En 360-programs måned er groft sagt 2.800 handlinger på netværket.
- MediaLive håndhæver rækkefølge pr. kanal. Planlægningshandlinger er tidsforankrede og refererer til hinanden; du kan ikke parallelisere skrivninger til den samme kanal uden at API'en afviser dem som modstridende.
- AWS Lambda har en hård 15-minutters grænse. Ikke en blød grænse, ikke en konfiguration. Orkestratoren skal afslutte inden for den grænse, ellers ender kanalen halvt implementeret.
- Delvis fejl er operationelt uacceptabelt. Hvis program 174 af 360 fejler og afbryder kørslen, har operatøren intet diff-overblik over, hvad der er landet, og hvad der ikke er. Kanalen går live med huller; seere ser sort skærm, hvor de forventede indhold.
- Den første version sendte én BatchUpdateSchedule pr. program med en 200ms pause mellem programmerne. Det er ~2,5 sekunder 'wall time' pr. program. Ved 360 programmer er man allerede over Lambda-grænsen, før MediaLive har udført noget reelt arbejde.
Opgaven er altså ikke at skrive hurtigere. Det er at skrive færre gange, overleve delvis fejl og forblive inden for et enkelt kald — uden at miste de ordensgarantier, MediaLive kræver.
Hvorfor eksisterende tilgange fejler
De åbenlyse undslippelsesmetoder fejler alle af strukturelle årsager, ikke tuning-problemer.
- "Bare hæv Lambda timeout'en." Det kan man ikke. Femten minutter er en af AWS pålagt hård grænse for Lambda-udførelse; det er ikke en knap i konsollen. Selv hvis det var, vokser omkostningen pr. program med kataloget — at købe mere 'wall time' udskyder kun den næste grænse.
- "Flyt til ECS Fargate eller EC2." Vi overvejede det og afviste det. Langtids-kørende containere betyder, at vi ejer runtime: sundhedstjek, autoscaling, afvejninger mellem cold-start og warm-pool, IAM-afgrænsning og vagtplan for en tjeneste, der kører i bursts. Lambda giver os isolation pr. kald og ingen omkostning ved inaktivitet for en iboende bursty arbejdsbyrde. Vi var ikke klar til at opgive det for at løse én flaskehals.
- "Paralleliser MediaLive-skrivningerne." MediaLive serialiserer planlægningsopdateringer pr. kanal. Samtidige BatchUpdateSchedule-kald mod den samme kanal konkurrerer på handlingstidslinjen og bliver afvist. Den eneste legitime parallelisering er inden for en batch, ikke på tværs af batches.
- "Lad det bare crashe og lad operatøren prøve igen." Dette er den værste mulighed. Når en implementering afbrydes ved program N, er kanalen i en tilstand, som ingen kan beskrive fra brugerfladen. Operatører får ikke et diff; de får en sort boks og en live channel med huller i. Systemet skal enten levere alt eller levere delvise resultater med status pr. program, som operatøren kan handle på.
Den løftestang, vi havde tilbage, var selve arbejdets form: færre, større skrivninger, udført serielt, med en fallback, der degraderer til række-niveau granularitet kun når en batch afvises.
Vores Løsning
Flyt omkostningen ud af Lambda, før løkken starter, saml MediaLive-skrivningerne inde i løkken, og degrader til indsendelse pr. program kun når en batch fejler. Tre idéer, i den rækkefølge — og en bevidst beslutning om, at 15-minutters grænsen er fin for de katalogstørrelser, vi faktisk implementerer i dag. Når spillelister vokser ud over et enkelt kald, er svaret ikke en større Lambda; det er en anden runtime.
Arkitektur
- NestJS backend (schedule.service.ts) — forvarmer implementeringen: én Mongo-rundtur for alle unikke videoer, én for alle reklamemarkører, derefter parallel ffprobe på tværs af unikke video-URL'er med resultaterne cachelagret til berigelsesløkken.
- Lambda-orkestrator (fastChannel-lambda-fun/index.js) — ejer batching-løkken, throttle pr. batch, fallback pr. program og 'orphan sweep'.
- MediaLive BatchUpdateScheduleCommand — den eneste skriveflade. Hver handling — inputskift, vandmærke, SCTE-35, reklameindsættelse — flyder gennem den.
- MongoDB — kilden til sandhed for programmer, videoer og reklamemarkører; aldrig forespurgt inde i den indre løkke.
scheduleResults map — status pr. program (scheduled / error) returneres til backend, så operatøren får et diff, ikke en stack trace.
Nøglebeslutninger inden for engineering
1. Forvarm de langsomme dele, før løkken kører. Den originale kode udførte et Mongo-opslag pr. planlægning og et ffprobe-kald pr. planlægning inde i berigelsesløkken — en klassisk N+1, der blev betalt to gange. Den nuværende backend bulk-henter hver unik video og reklamemarkør i én rundtur hver, kører derefter ffprobe parallelt på tværs af unikke URL'er og gemmer resultatet i en opløsningscache. Den indre løkke bliver et cache-hit. ffprobe-latency betales én gang pr. unik URL, ikke serielt i løkken.
2. Saml MediaLive-skrivninger i batches af ~25. Inde i orkestratoren akkumuleres handlinger i en enkelt BatchUpdateScheduleCommand, indtil 200 handlinger er i kø, eller det sidste program er nået. Da hvert program producerer ~7–8 handlinger, lander batches naturligt omkring 25 programmer hver. Grænsen på 200 handlinger blev valgt konservativt for at holde sig langt under MediaLives payload-grænser pr. anmodning og reducere chancen for, at en batch afvises på grund af størrelse — stor nok til at amortisere netværksomkostningerne, lille nok til at gøre fallback pr. program (næste beslutning) billig, når den skal køre. Én netværksrundtur erstatter femogtyve. Den 200ms throttle, der tidligere sad mellem hvert program, sidder nu mellem hver batch.
3. Batching for hastighed, fallback for korrekthed. Samling er kun sikkert, hvis et enkelt dårligt program ikke forgifter de andre fireogtyve i sin batch. Når submitProgramBatch kaster en fejl, kalder catch retryBatchAsIndividuals, som genindsendte hvert program i den fejlslagne batch som sin egen BatchUpdateScheduleCommand, registrerer status: 'scheduled' eller status: 'error' pr. program, holder pause i 200ms mellem forsøg, og genforankrer handlingstidslinjen efter hver delvise succes. Den hurtige vej er batched. Genoprettelsesvejen er granular. Operatøren får et diff pr. program uanset hvad.
4. Ryd op i forældreløse elementer til sidst, undgå at forhindre dem undervejs. sweepIncompleteProgramGroups kører én gang i slutningen af implementeringen og fjerner enhver handlingsgruppe, der ikke nåede en ren terminal tilstand. Vi forsøger bevidst ikke at holde kanalen internt konsistent under løkken — det ville betyde en rollback-vej, der selv skal passe ind i 15-minutters budgettet. Oprydning er en enkelt sweep, ikke en transaktion.
5. Lad ikke Lambda'en vokse; udskift den, når kataloget gør. For alt, hvad vi implementerer i dag, fuldføres 'single-invocation' vejen godt inden for budgettet. Den ærlige skalering er Step Functions-opdeling — opdel spillelisten, kør dele som parallelle state machines, saml dem igen. Det er vejen for spillelister på >1 måned og 6 måneder. Det er designet, ikke implementeret. At kalde det næste skridt er mere nyttigt end at foregive, at det allerede kører.
Resultater
- I intern test blev en implementering af 195 programmer gennemført på ~44 sekunder — ned fra den flerminutters, enkelt-program-ad-gangen baseline.
- Det dokumenterede mål for en 360-programs (~1 måned) spilleliste er ≤90 sekunder, komfortabelt inden for den 615-sekunders backend timeout og den 15-minutters Lambda-grænse.
- Et dårligt program i en batch afbryder ikke længere de andre 24. Operatøren får et status-map pr. program tilbage fra hver implementering.
- De langsomme dele af anmodningen — Mongo-opslag og ffprobe — betales én gang pr. unik ressource, ikke én gang pr. planlægningspost.
- Den 15-minutters grænse stoppede med at være den begrænsende faktor for de katalogstørrelser, vi faktisk leverer. Når det bliver det igen, er Step Functions-opdeling svaret, ikke en større Lambda.
Teknologistak: AWS Lambda · AWS MediaLive · NestJS · MongoDB · Node 18 · ffprobe · TypeScript · AWS SDK v3
