Useiden ohjelmien ajastaminen yhdellä napsautuksella – AWS Lambdan 15 minuutin aikarajan ylittäminen
FAST-kanavaoperaattori ajastaa kuukauden ohjelmat ja napsauttaa Deploy-painiketta kerran. Tämän yhden napsautuksen takana sadat ohjelmat muuttuvat tuhansiksi MediaLive-aikataulutoiminnoiksi, jotka on toimitettava AWS:ään järjestyksessä, kaikki Lambdan viidentoista minuutin suoritusajan rajoissa – ja mikä tahansa vika keskellä jättää suoran kanavan vajaaksi. Tässä kerromme, miten teimme suurten soittolistojen yhdellä napsautuksella tehtävästä käyttöönotosta luotettavan, ja miksi seuraava askel on eri ajonaikainen ympäristö, ei suurempi Lambda.
Nopea yleiskatsaus
| Ominaisuus | Yksityiskohta |
|---|---|
| Suoritusympäristö | AWS Lambda (yksi kutsu), 615s taustaohjelman aikakatkaisu |
| Tulostuskohde | MediaLive BatchUpdateScheduleCommand |
| Eräajo | Jopa 200 MediaLive-toimintoa pyyntöä kohden – käytännössä noin 25 ohjelmaa |
| Ohjelmakohtaiset toiminnot | ~7–8 (sisääntulon vaihto + 4 renderöintikohtaista vesileimaa + 2 SCTE-35), enemmän mainoskatkojen kanssa |
| Vararatkaisu | Ohjelmakohtainen uudelleenyritys minkä tahansa eräajon hylkäämisen yhteydessä |
| Havaittu | 195 ohjelmaa otettu käyttöön noin 44 sekunnissa (paikallinen mittaus) |
| Dokumentoitu tavoite | 360 ohjelmaa ≤90 sekunnissa |
| Skaalauspolku | Step Functions -pilkkominen yli 1 kuukauden soittolistoille — suunniteltu, ei toimitettu |
Haaste
Soittolistan käyttöönotto ei ole kirjoitus – se on orkestrointia. Jokaista operaattorin ajastamaa ohjelmaa varten MediaLiven on tiedettävä tarkalleen, milloin vaihtaa syötteitä, milloin käynnistää vesileima kullekin renderöinnille, milloin lisätä SCTE-35-merkkipisteet ja milloin liittää mainoksia. Rakenteelliset paineet ovat:
- Toimintojen määrä on kertova, ei summaava. Jokainen ohjelma tuottaa ~7–8 toimintoa ennen mainoskatkoja – yksi syötteen vaihto, neljä vesileiman aktivointia (yksi renderöintiä kohden, koska StaticImageOutputActivate käyttää tulostuspikselikoordinaatteja), ja kaksi SCTE-35-merkkiä. Mainoskatkot lisäävät kolme toimintoa kutakin kohti. 360 ohjelman kuukausi tarkoittaa karkeasti 2 800 toimintoa verkon yli.
- MediaLive valvoo järjestystä kanavakohtaisesti. Aikataulutoiminnot ovat aikaan sidottuja ja viittaavat toisiinsa; et voi rinnakkaistaa kirjoituksia samaan kanavaan ilman, että API hylkää ne ristiriitaisina.
- AWS Lambdalla on tiukka 15 minuutin aikaraja. Ei pehmeä raja, ei konfiguraatio. Orkestraattorin on päätyttävä tämän rajan sisällä, tai kanava jää puoliksi käyttöönotetuksi.
- Osittainen vika on toiminnallisesti sietämätön. Jos 360 ohjelmasta ohjelma 174 epäonnistuu ja keskeyttää suorituksen, operaattorilla ei ole eronäkymää siitä, mikä on julkaistu ja mikä ei. Kanava siirtyy live-tilaan aukoilla; katsojat näkevät mustan ruudun, kun he odottivat sisältöä.
- Ensimmäinen versio lähetti yhden BatchUpdateSchedule-komennon ohjelmaa kohden 200 ms:n viiveellä ohjelmien välillä. Se tarkoittaa noin 2,5 sekuntia kestoaikaa ohjelmaa kohden. 360 ohjelmalla olet jo ylittänyt Lambdan aikarajan ennen kuin MediaLive on tehnyt mitään todellista työtä.
Työ ei siis ole kirjoittaa nopeammin. Sen sijaan se on kirjoittaa harvemmin, selviytyä osittaisesta viasta ja pysyä yhden kutsun sisällä – menettämättä MediaLiven vaatimia järjestystakuita.
Miksi nykyiset lähestymistavat epäonnistuvat
Ilmeiset pakotiet epäonnistuvat kaikki rakenteellisista syistä, eivät viritysongelmien vuoksi.
- "Nosta vain Lambdan aikakatkaisua." Et voi. Viisitoista minuuttia on AWS:n asettama tiukka yläraja Lambdan suoritukselle; se ei ole säädettävä arvo konsolissa. Vaikka olisikin, ohjelmakohtainen kustannus kasvaa luettelon myötä – lisäämällä kestoaikaa vain viivyttää seuraavaa rajaa.
- "Siirry ECS Fargateen tai EC2:een." Harkitsimme sitä ja hylkäsimme sen. Pitkäkestoiset kontit tarkoittavat, että omistamme suoritusympäristön: kunnontarkistukset, automaattisen skaalauksen, kylmäkäynnistyksen vs. lämpimän poolin kompromissit, IAM-määrittelyt ja päivystysvuorot palvelulle, joka toimii purskeina. Lambda antaa meille kutsujen välisen eristyksen ja nollakustannukset joutokäynniltä luonnostaan purskeiselle työkuormalle. Emme olleet valmiita luopumaan siitä korjataksemme yhtä pullonkaulaa.
- "Rinnakkaista MediaLive-kirjoitukset." MediaLive serialisoi aikataulupäivitykset kanavakohtaisesti. Samanaikaiset BatchUpdateSchedule-kutsut samaa kanavaa vastaan kilpailevat toimintojen aikajanalla ja hylätään. Ainoa laillinen rinnakkaisuus on erän sisällä, ei eri erien välillä.
- "Anna sen vain kaatua ja anna operaattorin yrittää uudelleen." Tämä on huonoin vaihtoehto. Kun käyttöönotto keskeytyy ohjelman N kohdalla, kanava on tilassa, jota kukaan ei voi kuvata käyttöliittymästä. Operaattorit eivät saa eroja; he saavat mustan laatikon ja live-kanavan, jossa on aukkoja. Järjestelmän on joko toimitettava kaikki tai toimitettava osittaisia tuloksia ohjelmakohtaisella tilalla, johon operaattori voi reagoida.
Meillä oli jäljellä työn muoto itse: harvemmat, suuremmat kirjoitukset, jotka suoritetaan sarjamuotoisesti, vararatkaisulla, joka huononee rivitason tarkkuuteen vain, kun erä hylätään.
Ratkaisumme
Siirrä kustannukset Lambdasta ennen silmukan alkua, yhdistä MediaLive-kirjoitukset silmukan sisällä ja alenna ohjelmakohtaiseen lähetykseen vain, jos erä epäonnistuu. Kolme ideaa, tässä järjestyksessä – ja tietoinen päätös, että 15 minuutin aikaraja on hyvä käytössä olevien luetteloiden kokoluokissa. Kun soittolistat kasvavat yli yhden kutsun, vastaus ei ole suurempi Lambda; se on eri suoritusympäristö.
Arkkitehtuuri
- NestJS-taustaohjelma (schedule.service.ts) – esilämmittää käyttöönoton: yksi Mongo-edestakainen matka kaikille uniikeille videoille, yksi kaikille mainosmerkitsimille, sitten rinnakkainen ffprobe uniikkien video-URL-osoitteiden yli tulosten ollessa välimuistissa rikastussilmukkaa varten.
- Lambda-orkestraattori (fastChannel-lambda-fun/index.js) – omistaa eräajo-silmukan, eräkohtaisen kuristuksen, ohjelmakohtaisen vararatkaisun ja orpojen poiston.
- MediaLive BatchUpdateScheduleCommand – ainoa kirjoituspinta. Jokainen toiminto – syötteen vaihto, vesileima, SCTE-35, mainoksen liitos – kulkee sen kautta.
- MongoDB – ohjelmien, videoiden ja mainosmerkitsimien totuuden lähde; ei koskaan kyselytetty sisäisessä silmukassa.
- scheduleResults-kartta – ohjelmakohtainen scheduled / error -tila palautetaan taustaohjelmalle, jotta operaattori saa eronäkymän, ei pinon jäljitystä.
Keskeiset insinööripäätökset
1. Esilämmitä hitaat osat ennen silmukan käynnistymistä. Alkuperäinen koodi teki aikataulukohtaisen Mongo-haun ja aikataulukohtaisen ffprobe-kutsun rikastussilmukan sisällä – klassinen N+1 maksettu kahdesti. Nykyinen taustaohjelma noutaa kaikki uniikit videot ja mainosmerkitsimet eräajona yhdellä edestakaisella matkalla kutakin, sitten ajaa ffproben rinnakkain uniikkien URL-osoitteiden yli ja tallentaa tuloksen välimuistiin. Sisäisestä silmukasta tulee välimuistiosuma. ffproben viive maksetaan kerran per uniikki URL-osoite, ei sarjallisesti silmukassa.
2. Yhdistä MediaLive-kirjoitukset ~25 ohjelman eriksi. Orkestraattorin sisällä toiminnot kerääntyvät yhteen BatchUpdateScheduleCommandiin, kunnes 200 toimintoa on jonossa tai viimeinen ohjelma saavutetaan. Koska jokainen ohjelma tuottaa ~7–8 toimintoa, erät muodostuvat luonnostaan noin 25 ohjelman kokoisiksi. 200 toiminnon yläraja valittiin varovaisesti, jotta pysytään selvästi alle MediaLiven pyyntökohtaisten payload-rajojen ja vähennetään erän hylkäämisen mahdollisuutta koon vuoksi – riittävän suuri verkostokustannusten amortisoimiseksi, riittävän pieni, jotta ohjelmakohtainen vararatkaisu (seuraava päätös) olisi edullinen, kun se on suoritettava. Yksi verkon edestakainen matka korvaa kaksikymmentäviisi. 200 ms:n kuristus, joka aiemmin oli jokaisen ohjelman välissä, on nyt jokaisen erän välissä.
3. Eräajo nopeutta varten, vararatkaisu oikeellisuutta varten. Yhdistäminen on turvallista vain, jos yksi huono ohjelma ei pilaa muita erässään olevia ohjelmia. Kun submitProgramBatch heittää poikkeuksen, catch kutsuu retryBatchAsIndividuals-funktiota, joka lähettää uudelleen jokaisen epäonnistuneessa erässä olevan ohjelman omana BatchUpdateScheduleCommandinaan, tallentaa status: 'scheduled' tai status: 'error' ohjelmakohtaisesti, nukkuu 200 ms yritysten välillä ja ankkuroi toimintojen aikajanan uudelleen jokaisen osittaisen onnistumisen jälkeen. Nopea reitti on eräajona. Palautuspolku on rakeinen. Operaattori saa ohjelmakohtaisen eronäkymän joka tapauksessa.
4. Siivoa orvot lopussa, älä estä niitä kesken suorituksen. sweepIncompleteProgramGroups suoritetaan kerran käyttöönoton lopussa ja se poistaa kaikki toimintoryhmät, jotka eivät saavuttaneet puhdasta päättymistilaa. Emme tarkoituksella yritä pitää kanavaa sisäisesti yhtenäisenä silmukan aikana – se tarkoittaisi palautuspolkua, jonka itsensä on mahduttava 15 minuutin budjettiin. Puhdistus on yksittäinen pyyhkäisy, ei transaktio.
5. Älä kasvata Lambdaa; korvaa se kun luettelo kasvaa. Kaikessa, mitä otamme käyttöön tänään, yhden kutsun polku valmistuu hyvin budjetin sisällä. Rehellinen skaalaus on Step Functions -pilkkominen – jaa soittolista, suorita palasia rinnakkaisina tilakoneina, kokoa uudelleen. Se on polku yli 1 kuukauden ja 6 kuukauden soittolistoille. Se on suunniteltu, ei otettu käyttöön. Sen kutsuminen seuraavaksi askeleeksi on hyödyllisempää kuin teeskentely, että se on jo käynnissä.
Tulokset
- Sisäisessä testauksessa 195 ohjelman käyttöönotto valmistui noin 44 sekunnissa – laskua monen minuutin, yksi ohjelma kerrallaan -perustasosta.
- Dokumentoitu tavoite 360 ohjelman (~1 kuukauden) soittolistalle on ≤90 sekuntia, mukavasti 615 sekunnin taustaohjelman aikakatkaisun ja 15 minuutin Lambdan aikarajan sisällä.
- Yksi huono ohjelma erässä ei enää keskeytä muita 24:ää. Operaattori saa ohjelmakohtaisen tilakartan takaisin jokaisesta käyttöönotosta.
- Pyynnön hitaat osat – Mongo-haut ja ffprobe – maksetaan kerran per uniikki resurssi, ei kerran per aikataulumerkintä.
- 15 minuutin aikaraja lakkasi olemasta rajoittava tekijä nykyisin toimitettavien luetteloiden kokoluokissa. Kun se tulee jälleen sellaiseksi, Step Functions -pilkkominen on vastaus, ei suurempi Lambda.
Teknologiakasa: AWS Lambda · AWS MediaLive · NestJS · MongoDB · Node 18 · ffprobe · TypeScript · AWS SDK v3
