Ohjelmien siirtojen hallinta raahaa ja pudota -aikataulutuksessa

Kun kysyt keneltä tahansa live-TV-operaattorilta, mitä he haluaisivat nähdä aikataulutustyökalussa, he vastaavat lähes poikkeuksetta: "Anna minun rakentaa kanava samalla tavalla kuin järjestän tiedostoja kansioon. Raahaa ohjelma sisään, pudota se haluamaani paikkaan, valmis.

Ongelmana on, että kanava-aikataulu ei ole kansio. Se on juridinen asiakirja tiukoin rajoituksin. Kaksi ohjelmaa ei voi pyöriä samaan aikaan. Encoder ei voi vaihtaa syötteitä nopeammin kuin viiden sekunnin välein. Jo alkanutta ohjelmaa ei voi muokata. Ja elokuvaa, joka jatkuu keskiyön yli, on käsiteltävä yhtenä ohjelmana, ei leikattuna päivärajaan.

Jokainen raahaa ja pudota -toiminto on potentiaalinen rajoitusrikkomus odottamassa tapahtumista. Tämä on insinööritarina siitä, miten mStudion aikataulutin muuntaa käyttäjäystävällisen raahaa ja pudota -toiminnon taatusti lailliseksi kanavan aikajanaksi AWS MediaLive:ssa – mukaan lukien hetken, jolloin operaattori pudottaa ohjelman suoraan toisen päälle – ja miksi järjestelmä ratkaisee nämä ristiriidat automaattisesti sen sijaan, että se antaisi operaattorille virheilmoituksen ja ratkaistavan pulman.

Pikaesittely

Liiketoimintaongelma: Kalenteri, joka ei ole kalenteri

Kanava-aikataulutus näyttää kalenteriohjelmistolta. Operaattorit odottavat sen toimivan samoin – raahaa elokuva klo 21:00 -paikkaan, liu'uta ohjelmia aikajanalla ylöspäin, lisää sarja erissä ja katso jaksojen asettuvan peräkkäin. Mutta live-kanavan aikatauluun liittyy rajoituksia, joita kalenterilla ei yksinkertaisesti ole:

• Ohjelmat eivät saa olla päällekkäin. Live-TV näyttää tarkalleen yhtä asiaa kerrallaan.
• Encoderilla on minimitoimintaväli. AWS MediaLive ei vaihda syötteitä nopeammin kuin 5 sekunnin välein. Jos ajoitat kaksi ohjelmaa 4 sekunnin välein, käyttöönotto hylätään.
• Menneitä ohjelmia ei voi muokata. Lähetysaika on jo kulunut; bitit ovat jo katsojien näytöillä.
• Keskiyön yli ulottuvat ohjelmat ovat yksi yksikkö. Elokuvaa, joka esitetään klo 23:30 – 01:15, on käsiteltävä yhtenä ohjelmana, ei kahtena puolikkaana, jotka on jaettu päivärajaan.

Kahden sekunnin "melkein päällekkäisyys" ei ole operaattorin virhe – se on luonnollinen seuraus kahden ohjelman raahaamisesta, jotka melkein, mutta eivät aivan, sovi yhteen. Todellinen insinöörihaaste on kääntää "raahaa elokuva klo 21:00" muotoon "laillinen kanava-aikataulu". Jos se menee pieleen, operaattori joko törmää virheseinään jokaisessa pudotuksessa, tai – mikä pahempaa – huomaa lähetyshetkellä, että encoder hylkäsi osan aikataulusta äänettömästi.

Mitä "laillinen" tarkoittaa AWS MediaLive:ssa

Jotta aikataulu olisi laillinen MediaLive:ssa, vierekkäisten ohjelmien on oltava joko:

1. Peräkkäin – nolla väliä niiden välillä, tai
2. Erotettu vähintään 5 sekunnilla – encoderin minimitoimintaväli.

Ansa on kaikki siltä väliltä. 1 sekunnin aukko, 3 sekunnin aukko, 4,9 sekunnin aukko – kaikki näyttävät täysin hyviltä UI:ssa, ja kaikki hylätään käyttöönottohetkellä. Mikä pahempaa, hylkääminen ei ole puhdas, atominen vika; se voi johtaa osittain käyttöönotettuun kanavaan, jossa osa aikataulutoiminnoista päätyi MediaLive:lle ja toiset eivät.

Lisäämällä 1 sekunnin turvamarginaali kellodriftille sovelluspalvelimien ja AWS:n välillä, käytännön alaraja nousee 6 sekuntiin, ei 5:een. Tämä yksi luku – MIN_NEIGHBOUR_GAP_MS = 6000 – on ainoa vakio, jonka ympärille koko ristiriitojen ratkaisujärjestelmä on rakennettu.

Miksi ilmeiset lähestymistavat epäonnistuvat

Ennen automaattiseen ratkaisuun päätymistä harkittiin ja hylättiin useita ilmeisempiä strategioita:

"Hylkää kaikki ristiriidat ja pyydä operaattoria ratkaisemaan ne." Tämän vuoksi operaattoreiden on suoritettava manuaalisesti snap-matematiikka jokaisessa pudotuksessa. Viiden sekunnin raahaamisesta tulee viiden minuutin pulma, ja pulma vaikeutuu soittolistan kasvaessa. Käytännössä operaattorit luopuvat kokonaan raahaa ja pudota -toiminnosta ja palaavat taulukkolaskentaohjelmiin.

"Kohdista kaikki 5 minuutin rajoihin, jotta mikään ei mene päällekkäin." Tämä ratkaisee teknisen ongelman tuhoamalla operaattorin tarkoituksen. Ohjelman, jonka piti alkaa klo 21:03:15, ei pitäisi hiljaa hypätä klo 21:05:00. Aikataulu kuuluu operaattorille, ei pyöristysfunktiolle.

"Havaitse ristiriidat käyttöönottohetkellä pudotushetken sijaan." Tämä tuntuu nopeammalta UI:ssa, mutta se siirtää vian pahimpaan mahdolliseen hetkeen. Siihen mennessä kun operaattori klikkaa Deploy ja näkee "aikataulu hylätty ohjelmassa 47", he ovat jo mielessään siirtyneet eteenpäin muokkauksesta, joka sen aiheutti.

"Salli mikrovälit käyttöliittymässä ja anna MediaLiven hylätä ne." Tämä työntää läpinäkymättömät encoder-virheet suoraan takaisin operaattorille ja voi jättää kanavan puoliksi käyttöönotettuun tilaan, josta on aidosti vaikea palautua.

Todella toiminut vipu oli ristiriitojen automaattinen ratkaiseminen pudotushetkellä determinististen sääntöjen avulla – ja korjatun aikajanan heijastaminen takaisin operaattorille välittömästi.

Ratkaisu: Neljän säännön kohdistusalgoritmi

Jokaisella pudotuksella kohdistusalgoritmi tarkastelee kutakin vierekkäisten ohjelmien paria kyseisellä kanavalla – uusi-uuteen, uusi-olemassa olevaan tai olemassa oleva-olemassa oleva -pareja, joiden väli muuttui pudotuksen vuoksi – ja soveltaa tarkalleen yhtä neljästä säännöstä niiden välisen välin perusteella:

• Väli = 0 → ei toimenpidettä. Peräkkäin oleminen on laillista ja lähes varmasti sitä, mitä operaattori tarkoitti.
• Väli ≥ 6 sekuntia → ei toimenpidettä. Operaattori jätti tarkoituksella tilaa, luultavasti mainoskatkolle tai mainospläjäykselle.
• 0 < väli < 6 sekuntia → siirrä toista ohjelmaa taaksepäin, jotta väli sulkeutuu nollaan.
• Negatiivinen väli (päällekkäisyys) → siirrä toista ohjelmaa eteenpäin päällekkäisyyden verran.

Ratkaisevaa on, että algoritmi käsittelee vierekkäisiä pareja yhdellä eteenpäin suuntautuvalla käynnillä järjestetyn aikajanan yli. Jokainen siirretty ohjelma tulee välittömästi "edelliseksi" kohteeksi seuraavassa vertailussa – joten pudotus, joka laukaisee siirtojen ketjureaktion, ratkeaa yhdellä lineaarisella käynnillä ilman rekursiota.
Kuvio 1 · Kohdistuspäätöspuu

Järjestelmäarkkitehtuuri

Aikataulutin on rakennettu pienen, kohdennetun komponenttijoukon ympärille:

• NestJS-backend (schedule.service.ts) omistaa kohdistuskävelyn, kaskadimuistiinpanot ja kirjoitussopimuksen MediaLiven kanssa.
• Aika-alueen päällekkäisyyskysely. Kun pudotus saapuu, backend hakee kaikki olemassa olevat ohjelmat, joiden aikaikkuna koskettaa uuden erän aluetta, plus 6 sekunnin puskurin molemmilta puolilta. Koska tämä kysely toimii aika-alueilla kalenteripäivämäärien sijaan, keskiyön yli ulottuvat ohjelmat käsitellään identtisesti muiden ohjelmien kanssa – järjestelmässä ei ole erityistä päivämäärärajojen logiikkaa.
• Yhdistetty aikajana. Uudet ohjelma-DTO:t ja kysytyt olemassa olevat ohjelmat yhdistetään yhdeksi lajitelluksi listaksi. Kohdistuskävely suoritetaan tätä yhdistettyä aikajanaa vasten.
• shiftedExistings-kartta. Jokaisesta siirron koskettamasta olemassa olevasta ohjelmasta tämä kartta tallentaa sen alkuperäiset alku- ja loppuajat ensimmäisellä kosketuksella – eikä koskaan ylikirjoita niitä myöhemmillä kosketuksilla. Tämä yksi tietorakenne tekee monivaiheisista kaskadeista turvallisia.
• Lambda DELETE_PROGRAM. Kaikille siirretyille ohjelmille, jotka oli jo otettu käyttöön MediaLive:ssa, niiden alkuperäiset ajat lähetetään Lambda-funktioon puhdistusta varten ennen MongoDB:n päivitystä.

• MIN_NEIGHBOUR_GAP_MS = 6000 – ainoa vakio, johon jokainen sääntö, jokainen päällekkäisyyskysely ja jokainen turvapuskuri viittaa.

   

Keskeiset suunnittelupäätökset

1. Neljä sääntöä, yksi läpikäynti, ei erikoistapauksia. Samat neljä sääntöä kattavat kaikki skenaariot, joita operaattori voi luoda: uusi ohjelma, joka pudotetaan kahden olemassa olevan ohjelman väliin, kaksi uutta ohjelmaa, jotka ovat ristiriidassa keskenään, tai olemassa oleva ohjelma, joka työnnetään päällekkäin aiemman siirron vuoksi samassa pudotuksessa. Näille ei ole erillistä koodipolkua – jokainen tapaus supistuu "tarkastele vierekkäisten ohjelmien välistä rakoa ja sovella sääntöä".

2. Kuusi sekuntia, ei viisi. MediaLive pakottaa 5 sekunnin minimivälin aikataulutoimintojen välillä; kahden syötteen vaihtaminen 4,9 sekunnin välein aiheuttaa käyttöönoton hylkäämisen. Järjestelmä pakottaa 6 sekuntia – yhden sekunnin turvamarginaalin kellodriftille backendin kellon ja AWS:n kellon välillä. Toiminnon lähettäminen tasan 5.000 sekunnin kohdalla, kun encoderin kello lukee sen 4.997 sekuntina, tuottaa satunnaisia hylkäämisiä, jotka näyttävät verkon vioilta ja tuntuvat toistamattomilta virheiltä. Lisäsekunti muuttaa satunnaisen vikatilan sellaiseksi, joka ei yksinkertaisesti koskaan laukea.

Tähän liittyy harkittu kompromissi: 6 sekunnin alaraja tarkoittaa, että pienet (3 tai 4 sekunnin) peräkkäiset välit suljetaan nollaan sen sijaan, että ne säilytettäisiin. Tämä kompromissi hyväksyttiin tarkoituksella – peräkkäiset siirtymät ovat puhtaita MediaLive:ssa, ja näkyvä 3 sekunnin aukko näyttää katsojille yleensä häiriöltä joka tapauksessa.

3. Alkuperäisen ajan muistiinpano tekee kaskadeista turvallisia. Yksi pudotus voi laukaista siirtojen ketjun – ohjelma A siirtää B:tä, B siirtää C:tä, C siirtää D:tä. Puhdistuspuhelun MediaLive:lle on kohdistuttava kunkin ohjelman alkuperäiseen käyttöönotettuun aikaan, ei sen kaskadisiirrettyyn aikaan; väärän ajan käyttäminen saa MediaLiven vastaamaan "toimintoa ei löydy", jolloin puhdistus epäonnistuu hiljaisesti. Kävely ylläpitää karttaa programId → {oldStartTime, oldEndTime}, joka tallennetaan ensimmäisen kerran, kun ohjelmaa kosketetaan. Myöhemmät kaskadisiirrot päivittävät vain muistissa olevaa aikajanaa; muistiinpanoidut alkuperäiset pysyvät koskemattomina, ja puhdistuksessa käytetään aina juuri sitä, mitä MediaLive:lla on todellisuudessa tallessa.
Kuvio 2 · Kaskadiesimerkki
 

4. Menneen päivämäärän suojat, valvotaan kahdessa erillisessä vaiheessa. Menneiden päivämäärien muokkaukset estetään kahdesti, tarkoituksella:

• Vaihe 0, ennen kohdistuskävelyn suoritusta: mikä tahansa uusi ohjelma, jonka aloitusaika on aikaisempi kuin "nyt", hylkää koko erän suoraan, selkeällä virheellä. Kohdistuskävelyä ei edes suoriteta mahdotonta syötettä vastaan.
• Vaihe 4, kohdistuskävelyn jälkeen: kaksi erillistä alitapausta käsitellään eri tavoin. Uusi ohjelma, jonka kohdistus vahingossa veti menneisyyteen (harvinaista, mutta mahdollista pyyntöajan kellorajojen kohdalla), palautetaan hiljaisesti sen alkuperäiseen, ennen kohdistusta olleeseen aikaan – operaattorin tarkoitus säilytetään, eikä kohdistusta yksinkertaisesti sovelleta. Olemassa oleva ohjelma, jonka siirto työntäisi menneisyyteen, sen sijaan hylkää koko erän – jo alkanutta ohjelmaa ei järjestelmä koskaan hiljaisesti niele.

5. Lambda-ensimmäinen, tietokanta-toinen kirjoitussopimus. Kun kohdistus siirtää ohjelmaa, joka on jo otettu käyttöön MediaLive:ssa, MongoDB ja MediaLive ovat hetkellisesti epäsynkassa, ja täsmäytyksen järjestyksellä on merkitystä. Sopimus: Lambda ensin, MongoDB toisena. Backend kutsuu DELETE_PROGRAM Lambdaa käyttäen ohjelman alkuperäisiä aikoja; jos jokin kutsu epäonnistuu, backend heittää poikkeuksen ennen minkään tietokantakirjoituksen tapahtumista. Vasta kun jokainen poistokutsu on onnistunut, yksittäinen bulkWrite päivittää MongoDB:n uusilla ajoilla ja nollaa isDeployed: false -arvon.

Tämä tuottaa yhden puhtaan invariantin: jos MongoDB näyttää ohjelman uudessa ajassa, MediaLive on jo hyväksynyt siirron. Jos operaattori sen sijaan näkee virheen, kumpaakaan järjestelmää ei koskettu. Ei ole mahdollista tilaa, jossa MongoDB ja MediaLive olisivat hiljaa eri mieltä ohjelman ajasta.

6. Nollauspäivällä on oma omistettu turvaverkkonsa. "Nollauspäivä" poistaa kaikki ohjelmat kanavalta tietyltä kalenteripäivältä – järjestelmän yksittäinen tuhoisin toimenpide – joten siihen liittyy kaksi erityistä suojausta.

• A 2 minuutin puskuri (SAFETY_BUFFER_MS = 120000) vapauttaa kaikki ohjelmat, jotka alkavat seuraavan kahden minuutin aikana, antaen live-toistolle armoikkunan, jotta nollaus ei voi koskaan kilpailla juuri lähetykseen menevän ohjelman kanssa. 
• Siirtymän säilyttäminen jättää ulkopuolelle ohjelmat, jotka alkoivat edellisenä päivänä mutta ulottuvat tähän päivään – ne kuuluvat eilisen aikatauluun, eivät tämän päivän. 

Myös armollinen vararatkaisu on saatavilla: jos kanavaa ei ole koskaan otettu käyttöön MediaLive:ssa, Lambda palauttaa tietyn virheviestin, jonka backend ymmärtää, kirjaa sen no_infrastructure-tapahtumaksi ja suorittaa sitten vain MongoDB-pohjaisen pehmeän poiston. Nollaus onnistuu silti; AWS-vaiheesta tulee yksinkertaisesti no-op.

Miksi tämä yhdistelmä suunnittelupäätöksiä

Mitä vielä seurataan

Rehellinen suunnittelutyö tarkoittaa avoimien aukkojen nimeämistä, ei vain ratkaistujen.

• Samanaikaiset muokkaukset samalla kanavalla. Jos kaksi operaattoria napsauttaa Deploy-painiketta samalla kanavalla muutaman sadan millisekunnin sisällä toisistaan, molemmat lataavat saman tilannevedoksen, molemmat suorittavat kohdistuskävelyn itsenäisesti ja molemmat kirjoittavat MongoDB:hen. Tällä hetkellä ei ole kanavakohtaista lukitusta tai optimistista versiontarkistusta. Nykyinen lievennys on operatiivinen – yksi operaattori omistaa yhden kanavan kerrallaan – kun taas tekninen korjaus, versionkenttä kanavadokumentissa, jota tarkistetaan kirjoitushetkellä, on tiekartalla.
• Ei käyttöliittymän sisäistä palautetta siitä, mikä kohdistui. Kun kävely siirtää ohjelman kolmella sekunnilla, operaattorin näkymä päivittyy korjattuun tilaan, mutta se ei vielä näytä, mikä liikkui ja miksi. Tiedot ovat jo olemassa vastauskuormassa; seuraavaan aikatauluttajan käyttöliittymän iteraatioon on suunnitteilla toast-ilmoitus, sivupalkki tai vertailunäkymä.

Tulokset

• Operaattorit voivat pudottaa ohjelman mihin tahansa aikajanalle, ja järjestelmä tekee tuloksena olevasta aikataulusta laillisen yhdellä deterministisellä läpikäynnillä – ei ristiriitaikkunoita, ei virheseiniä, ei manuaalista kohdistusmatematiikkaa.
• Yksi neljän säännön algoritmi kattaa kaikki tapaukset – uusi vs. uusi, uusi vs. olemassa oleva ja kaskadimaiset siirrot päivärajojen yli – ilman erikoistapausten käsittelyä.
• Keskiyön yli ulottuvat ohjelmat ja DST-muutokset kulkevat saman aika-alueen päällekkäisyyskyselyn kautta kuin mikä tahansa muu tapaus; erillistä "keskiyön koodipolkua" ei tarvitse ylläpitää.
• Nollauspäivä ei voi vahingossa poistaa live-ohjelmaa lähetyksestä – 2 minuutin puskuri ja siirtymän säilyttäminen koskevat jokaista kanavaa, aina.
• Lambda-ensimmäinen / tietokanta-toinen sopimus tekee hiljaisesta aikatauludriftistä mahdotonta: MongoDB ja MediaLive ovat taatusti yhtä mieltä, tai operaattori näkee selkeän virheen.

• MIN_NEIGHBOUR_GAP_MS on ainoa säädettävä parametri. Jokainen turvamarginaali, jokainen kohdistussääntö ja jokainen päällekkäisyysikkuna viittaa siihen, joten alustan "laillisen" määritelmän säätäminen on yhden rivin muutos.

   

Loppupäätelmät

Mielenkiintoisinta tässä järjestelmässä ei ole yksittäinen sääntö – vaan se, kuinka vähän sääntöjä tarvittiin. Neljä ehdottettua aukon arvoon liittyvää ehtoa, jotka sovelletaan yhdellä eteenpäin suuntautuvalla käynnillä, kattavat kaikki ristiriidat, joita operaattori voi luoda, mukaan lukien monivaiheiset kaskadit keskiyön rajojen yli. Tämä on harkittu suunnittelutulos: monimutkaisuus siirrettiin sääntöjen kerralla oikein saamiseen, sen sijaan, että käsiteltäisiin alati kasvavaa luetteloa erikoistapauksista.

Laajempi opetus yleistyy aikataulutusohjelmistoista: kun järjestelmässä on kovia ulkoisia rajoituksia – encoderin minimiväli, tietokannan johdonmukaisuustakuut, live-lähetys, jota ei voi peruuttaa – turvallisin paikka näiden rajoitusten valvomiseksi on pieni määrä deterministisiä sääntöjä, joita sovelletaan johdonmukaisesti, eikä ad hoc -käsittelyä hajautettuna koodikantaan. Ja kun kahden tietokantajärjestelmän (tässä MongoDB ja MediaLive) on pysyttävä synkassa, kirjoitusten järjestyksen varmistaminen niin, että vika jättää ne aina tunnettuun, yhteisesti hyväksyttyyn tilaan, on sen lisäviiveen arvoinen, jonka se aiheuttaa.
 

Tietoa MicrocosmWorksista

Me MicrocosmWorksilla rakennamme tuotantotason ohjelmistoja organisaatioille, jotka ratkaisevat monimutkaisia teknisiä ongelmia.

Asiantuntemuksemme kattaa AI-sovellukset, SaaS-alustat, yritysohjelmistot, pilvinatiivit järjestelmät, mediatekniikan ja mukautetut backend-arkkitehtuurit.

Insinööriblogimme kautta jaamme käytännön oppeja, joita olemme saaneet suunnitellessamme ja operoidessamme todellisia tuotantojärjestelmiä.

Jatka lukemista

Jos pidit tästä artikkelista, saatat pitää myös seuraavista aiheista:

• Skaalautuvien SaaS-arkkitehtuurien rakentaminen
• Pilvinatiivi infrastruktuuri
• Yritysvideon käsittely FFmpegillä