Pag-iskedyul ng Maramihang Programa sa Isang Click — Paglampas sa 15-Minutong Limitasyon ng AWS Lambda
Isang operator ng FAST channel ang nag-iiskedyul ng isang buwang programa at isang beses na pinipindot ang Deploy. Sa likod ng isang click na iyon, daan-daang programa ang nagiging libu-libong MediaLive schedule actions na kailangang mapunta sa AWS nang sunud-sunod, lahat sa loob ng fifteen-minute execution ceiling ng Lambda — at anumang pagkabigo sa gitna ay nag-iiwan ng live channel na may mga butas. Narito kung paano namin ginawang maaasahan ang one-click deployment ng malalaking playlist, at kung bakit ang susunod na hakbang ay isang iba't ibang runtime, hindi isang mas malaking Lambda.
Mabilis na pangkalahatang-ideya
| Aspekto | Detayle |
|---|---|
| Runtime | AWS Lambda (single invocation), 615s backend timeout |
| Target ng Output | MediaLive BatchUpdateScheduleCommand |
| Batching | Hanggang 200 MediaLive actions bawat request — ~25 programa sa praktika |
| Mga aksyon bawat programa | ~7–8 (input switch + 4 watermarks bawat rendition + 2 SCTE-35), mas marami sa mga ad break |
| Fallback | Pag-retry bawat programa sa anumang pagtanggi ng batch |
| Naobserbahan | 195 programang na-deploy sa loob ng ~44 segundo (lokal na pagsukat) |
| Dokumentadong target | 360 programa sa ≤90 segundo |
| Scale-out path | Step Functions chunking para sa >1-buwan na playlist — nakaplano, hindi pa nai-ship |
Ang Hamon
Ang pag-deploy ng playlist ay hindi isang write — ito ay isang orchestration. Para sa bawat programang iniskedyul ng operator, kailangang malaman ng MediaLive kung kailan eksaktong magpapalit ng input, kailan i-o-on ang watermark para sa bawat rendition, kailan ipapasok ang SCTE-35 cue points, at kailan maglalagay ng mga ad. Ang mga istrukturang panggigipit ay:
- Ang bilang ng aksyon ay multiplicative, hindi additive. Ang bawat programa ay naglalabas ng ~7–8 actions bago ang mga ad break — isang input switch, apat na watermark activations (isa bawat rendition dahil ang StaticImageOutputActivate ay gumagamit ng output-pixel coordinates), at dalawang SCTE-35 markers. Ang mga ad break ay nagdadagdag ng tatlong aksyon bawat isa. Ang isang buwan na may 360-programa ay halos 2,800 aksyon sa wire.
- Pinapatupad ng MediaLive ang pag-o-order bawat channel. Ang mga schedule action ay naka-angkla sa oras at nagre-reference sa isa't isa; hindi mo maaaring i-parallelize ang mga writes sa parehong channel nang hindi ito tinatanggihan ng API bilang magkasalungat.
- Ang AWS Lambda ay may matigas na 15-minutong limitasyon. Hindi isang soft limit, hindi isang configuration. Ang orchestrator ay dapat matapos sa loob ng limitasyong iyon o ang channel ay magiging half-deployed.
- Ang bahagyang pagkabigo ay hindi katanggap-tanggap sa operasyon. Kung ang programa 174 ng 360 ay mabigo at matigil ang pagpapatakbo, walang diff view ang operator kung ano ang natapos at kung ano ang hindi. Ang channel ay magiging live na may mga butas; makikita ng mga manonood ang slate kung saan sila umaasa ng content.
- Ang unang bersyon ay nagpadala ng isang BatchUpdateSchedule bawat programa na may 200ms na pagtulog sa pagitan ng mga programa. Iyan ay ~2.5 segundo ng wall time bawat programa. Sa 360 programa, lumampas ka na sa Lambda ceiling bago pa man magawa ng MediaLive ang anumang tunay na trabaho.
Ang trabaho, kung gayon, ay hindi mas mabilis na magsulat. Ito ay mas kaunting beses magsulat, makaligtas sa bahagyang pagkabigo, at manatili sa loob ng isang invocation — nang hindi nawawala ang mga ordering guarantee na hinihingi ng MediaLive.
Bakit Nabibigo ang mga Kasalukuyang Pamamaraan
Ang mga malinaw na pagtakas ay nabibigo lahat dahil sa mga dahilan na istruktural, hindi problema sa pag-tune.
- "Taasan lang ang Lambda timeout." Hindi mo kaya. Ang labinlimang minuto ay isang mahigpit na limitasyon na ipinapataw ng AWS sa pagpapatupad ng Lambda; hindi ito isang knob sa console. Kahit na kaya, lumalaki ang gastos bawat programa kasama ang catalog — ang pagbili ng mas maraming wall time ay nagpapaliban lamang sa susunod na limitasyon.
- "Lumipat sa ECS Fargate o EC2." Isinaalang-alang namin ito at tinanggihan. Ang mga long-running container ay nangangahulugang kami ang nagmamay-ari ng runtime: health checks, autoscaling, cold-start vs. warm-pool tradeoffs, IAM scoping, at on-call rotation para sa isang serbisyo na tumatakbo nang pira-piraso. Binibigyan kami ng Lambda ng per-invocation isolation at zero idle cost para sa isang likas na bursty workload. Hindi kami handang isuko iyon para ayusin ang isang bottleneck.
- "I-parallelize ang mga writes ng MediaLive." Ang MediaLive ay nagsasa-serialize ng mga update sa iskedyul bawat channel. Ang magkasabay na BatchUpdateSchedule calls laban sa parehong channel ay nagkakaroon ng race condition sa action timeline at tinatanggihan. Ang tanging lehitimong parallelism ay sa loob ng isang batch, hindi sa buong batches.
- "Hayaan lang itong mag-crash at hayaang subukang muli ng operator." Ito ang pinakamasamang opsyon. Kapag ang isang deploy ay tumigil sa programa N, ang channel ay nasa isang estado na walang makakapaglarawan mula sa UI. Ang mga operator ay hindi nakakakuha ng diff; nakakakuha sila ng isang black box at isang live channel na may mga butas. Ang sistema ay kailangang i-land ang lahat o i-land ang bahagyang resulta na may status bawat programa na maaaring kumilos ang operator.
Ang lever na natitira sa amin ay ang hugis ng trabaho mismo: mas kaunti, mas malalaking writes, isinasagawa nang sunud-sunod, na may fallback na bumababa sa row-level granularity lamang kapag tinanggihan ang isang batch.
Ang Aming Solusyon
Ilipat ang gastos palabas ng Lambda bago magsimula ang loop, pagsamahin ang mga MediaLive writes sa loob ng loop, at bumaba sa per-program submission lamang kapag nabigo ang isang batch. Tatlong ideya, sa ganoong pagkakasunod-sunod — at isang sadyang desisyon na ang 15-minutong limitasyon ay sapat para sa mga laki ng catalog na aktwal naming ine-deploy ngayon. Kapag lumaki ang mga playlist na lampas sa isang invocation, ang sagot ay hindi isang mas malaking Lambda; ito ay isang iba't ibang runtime.
Arkitektura
- NestJS backend (schedule.service.ts) — ini-pre-warm ang deploy: isang Mongo round trip para sa lahat ng natatanging video, isa para sa lahat ng ad markers, pagkatapos ay parallel ffprobe sa mga natatanging URL ng video na may mga resulta na naka-cache para sa enrichment loop.
- Lambda orchestrator (fastChannel-lambda-fun/index.js) — nagmamay-ari ng batching loop, ng per-batch throttle, ng per-program fallback, at ng orphan sweep.
- MediaLive BatchUpdateScheduleCommand — ang tanging write surface. Ang bawat aksyon — input switch, watermark, SCTE-35, ad splice — ay dumadaan dito.
- MongoDB — ang pinagmulan ng katotohanan para sa mga programa, video, at ad markers; hindi kailanman kinukuha sa loob ng inner loop.
- scheduleResults map — per-program scheduled / error status na ibinalik sa backend upang makakuha ang operator ng diff, hindi isang stack trace.
Mga Pangunahing Desisyon sa Engineering
1. I-pre-warm ang mabagal na bahagi bago tumakbo ang loop. Ang orihinal na code ay gumagawa ng per-schedule Mongo lookup at isang per-schedule ffprobe call sa loob ng enrichment loop — isang klasikong N+1 na dalawang beses nabayaran. Ang kasalukuyang backend ay sabay-sabay na kumukuha ng bawat natatanging video at ad marker sa isang round trip bawat isa, pagkatapos ay nagpapatakbo ng ffprobe nang parallel sa mga natatanging URL at iniimbak ang resulta sa isang resolution cache. Ang inner loop ay nagiging isang cache hit. Ang ffprobe latency ay binabayaran isang beses bawat natatanging URL, hindi nang sunud-sunod sa loop.
2. Pagsamahin ang mga writes ng MediaLive sa mga batch ng ~25. Sa loob ng orchestrator, ang mga aksyon ay nagtitipon sa isang BatchUpdateScheduleCommand hanggang sa 200 aksyon ang na-queue o naabot ang huling programa. Dahil ang bawat programa ay gumagawa ng ~7–8 aksyon, natural na ang mga batch ay naglalaman ng humigit-kumulang 25 programa bawat isa. Ang 200-aksyon na limitasyon ay pinili nang konserbatibo upang manatili nang mas mababa sa mga limitasyon ng payload ng MediaLive bawat request at upang mabawasan ang posibilidad na tanggihan ang isang batch dahil sa laki — sapat na malaki upang amortise ang gastos sa network, sapat na maliit upang gawing mura ang per-program fallback (susunod na desisyon) kapag kailangan itong tumakbo. Isang network round trip ang pumapalit sa dalawampu't lima. Ang 200ms throttle na dating nakalagay sa pagitan ng bawat programa ay nakalagay na ngayon sa pagitan ng bawat batch.
3. Pagbabatch para sa bilis, fallback para sa kawastuhan. Ligtas lamang ang pagsasama-sama kung ang isang masamang programa ay hindi nakakalason sa iba pang dalawampu't apat sa batch nito. Kapag ang submitProgramBatch ay nag-throw ng error, ang catch ay nag-i-invoke ng retryBatchAsIndividuals, na muling nagsumite ng bawat programa sa nabigong batch bilang sarili nitong BatchUpdateScheduleCommand, nagtatala ng status: 'scheduled' o status: 'error' bawat programa, nagpapahinga ng 200ms sa pagitan ng mga pagtatangka, at muling nag-a-anchor ng action timeline pagkatapos ng bawat bahagyang tagumpay. Ang mabilis na daanan ay batched. Ang daanan ng pagbawi ay granular. Nakakakuha ang operator ng per-program diff sa alinmang paraan.
4. Linisin ang mga orphan sa dulo, huwag pigilan ang mga ito habang tumatakbo. Ang sweepIncompleteProgramGroups ay tumatakbo isang beses sa dulo ng deploy at nagtatanggal ng anumang action group na hindi nakarating sa isang malinis na terminal state. Sadyang hindi namin sinisikap na panatilihing internally consistent ang channel habang tumatakbo ang loop — nangangahulugan iyon ng isang rollback path na kailangan ding magkasya sa 15-minutong budget. Ang paglilinis ay isang solong sweep, hindi isang transaksyon.
5. Huwag palakihin ang Lambda; palitan ito kapag lumaki ang catalog. Para sa lahat ng ine-deploy namin ngayon, ang single-invocation path ay natatapos nang maayos sa loob ng budget. Ang tapat na scale-out ay Step Functions chunking — hatiin ang playlist, patakbuhin ang mga chunks bilang parallel state machines, muling pagsamahin. Iyan ang daanan para sa >1-buwan at 6-buwan na playlist. Ito ay dinisenyo, hindi pa nai-deploy. Ang pagtawag dito na susunod na hakbang ay mas kapaki-pakinabang kaysa sa pagpapanggap na tumatakbo na ito.
Mga Resulta
- Sa internal testing, ang isang 195-program deployment ay nakumpleto sa ~44 segundo — mula sa multi-minuto, single-program-at-a-time na baseline.
- Ang dokumentadong target para sa isang 360-program (~1 buwan) na playlist ay ≤90 segundo, kumportableng nasa loob ng 615-segundong backend timeout at ng 15-minutong Lambda ceiling.
- Ang isang masamang programa sa isang batch ay hindi na nagpapahinto sa iba pang 24. Nakakakuha ang operator ng per-program status map mula sa bawat deploy.
- Ang mabagal na bahagi ng request — Mongo lookups at ffprobe — ay binabayaran isang beses bawat natatanging resource, hindi isang beses bawat schedule entry.
- Ang 15-minutong limitasyon ay hindi na ang naglilimitang salik para sa mga laki ng catalog na aktwal naming inilalabas. Kapag naging muli ito, Step Functions chunking ang sagot, hindi isang mas malaking Lambda.
Teknolohiya Stack: AWS Lambda · AWS MediaLive · NestJS · MongoDB · Node 18 · ffprobe · TypeScript · AWS SDK v3
