Palvelimeton lähestymistapa toimivan videopalvelun nopeaan kehittämiseen

Palvelimeton lähestymistapa toimivan videopalvelun nopeaan kehittämiseen

Työskentelen ulkoistamisessa, jossa pääperiaatetta voi kuvata lauseella "myy paljon, tee se nopeasti". Mitä nopeammin teemme sen, sitä enemmän ansaitsemme. Ja on toivottavaa, että kaikki ei toimi kainalosauvoilla ja räkällä, vaan hyväksyttävällä laatutasolla. Kerron kokemuksestani, kun oli tarpeen kehittää promootiopalvelu lyhyessä ajassa.

ilmoittautua: juuritili AWS:ssä, ei rajoituksia teknologiapinon valinnassa, yksi taustajärjestelmä ja yksi kuukausi kehitystä varten.

tavoite: toteuttaa mainospalvelu, jossa käyttäjät lataavat yhdestä neljään videota, jotka kestävät yhdestä neljään sekuntia, jotka sitten upotetaan alkuperäiseen videosarjaan.

päätös

Oman pyöräpalvelun kirjoittaminen näin lyhyessä ajassa ei ole hyvä idea. Lisäksi, jotta palvelu kestäisi kuormitusta ja että kaikki saisivat halutun videon, tarvitaan infrastruktuuria. Eikä mielellään lentokoneen hintalappulla. Siksi keskitymme välittömästi valmiisiin ratkaisuihin, joissa on mahdollisimman vähän räätälöintiä.

Vakioratkaisu videon kanssa työskentelyyn on FFmpeg, monialustainen konsoliapuohjelma, jonka avulla voit leikata ja kopioida ääntä argumenttien avulla. Ei jää muuta kuin kirjoittaa kääre ja vapauttaa se elämään. Kirjoitamme prototyypin, joka yhdistää kaksi videota, ja... hauskuus alkaa. Kirjasto perustuu .NET Core 2:een, sen pitäisi toimia missä tahansa virtuaalikoneessa, joten otamme AWS EC2 -esiintymän ja kaikki toimii

Piilotettu tekstiei, se ei toimi
.
Vaikka FFmpeg yksinkertaistaa tehtävää, todella toimivaa ratkaisua varten sinun on luotava EC2-instanssi ja suunniteltava sille verkkoinfrastruktuuri, mukaan lukien Load Balancer. Tyhjästä käyttöönoton yksinkertainen tehtävä muuttuu "hieman" monimutkaisemmaksi, ja infrastruktuuri alkaa vaatia rahaa välittömästi - joka tunti ajonaikaisen summan määrä nostetaan asiakastililtä.

Palvelumme ei sisällä pitkiä prosesseja, ei vaadi suurta ja paksua relaatiotietokantaa ja sopii täydellisesti tapahtumapohjaiseen arkkitehtuuriin mikropalvelukutsujen ketjulla. Ratkaisu ehdottaa itseään – voimme luopua EC2:sta ja ottaa käyttöön todellisen palvelimettoman sovelluksen, kuten tavallisen AWS Lambdaan perustuvan Image Resizerin.

Muuten, huolimatta siitä, että AWS-kehittäjät eivät pidä .NET:istä, he tukevat .NET Core 2.1:tä ajonaikana, mikä tarjoaa täyden valikoiman kehitysmahdollisuuksia.

Ja kirsikka kakun päällä - AWS tarjoaa erillisen palvelun videotiedostojen käsittelyyn - AWS Elemental MediaConvert.

Työn olemus on uskomattoman yksinkertainen: otamme S3-linkin lähtevään videoon, kirjoitamme AWS-konsolin, .NET SDK:n tai yksinkertaisesti JSONin kautta, mitä haluamme tehdä videolla ja kutsumme palveluun. Se itse toteuttaa jonoja saapuvien pyyntöjen käsittelemiseksi, lataa tuloksen itse S3:een ja mikä tärkeintä, luo CloudWatch-tapahtuman jokaiselle tilamuutokselle. Tämän avulla voimme toteuttaa lambda-laukaisimia videon käsittelyn suorittamiseksi loppuun.

Palvelimeton lähestymistapa toimivan videopalvelun nopeaan kehittämiseen
Lopullinen arkkitehtuuri näyttää tältä:

Koko taustaosa on sijoitettu kahteen lambdaan. Toinen on pyöriville pystysuuntaisille videoille, koska tällaista työtä ei voi tehdä yhdellä kertaa.

Asetamme etuosan JS:llä kirjoitetun ja mopsilla kootun SPA-hakemuksen muodossa julkiseen S3-ämpäriin. Itse videoiden lataamiseen emme tarvitse palvelinkoodia - meidän on vain avattava S3:n meille tarjoamat REST-päätepisteet. Ainoa asia on, että älä unohda määrittää käytännöt ja CORS.

Sudenkuopat

  • AWS MediaConvert, jostain tuntemattomasta syystä, käyttää vain ääntä jokaiseen videon fragmenttiin erikseen, mutta tarvitsemme iloisen kappaleen koko näytönsäästäjästä.
  • Pystysuuntaiset videot on käsiteltävä erikseen. AWS ei pidä mustista palkoista ja asettaa rullat 90° kulmaan.

Helppo luistinrata

Kaikesta Statelessin kauneudesta huolimatta sinun on seurattava, mitä videolla on tehtävä: liimaa tai lisää ääntä valmiiseen videojaksoon. Onneksi MediaConvert tukee metatietojen välittämistä Jobsin kautta, ja voimme aina käyttää yksinkertaista "isMasterSoundJob" -muotoista lippua, joka jäsentää nämä metatiedot missä tahansa vaiheessa.

Palvelimeton mahdollistaa täydellisesti työskentelyn NoOpsin kanssa – lähestymistapa, joka edellyttää projektiinfrastruktuurista vastaavan erillisen tiimin tarpeettomuutta. Siksi se oli pieni asia - otamme ratkaisun käyttöön AWS:ssä ilman järjestelmänvalvojien osallistumista, joilla on joka tapauksessa aina tekemistä.
Ja kaiken tämän nopeuttamiseksi automatisoimme käyttöönottoskriptin mahdollisimman paljon AWS CloudFormationissa, jonka avulla voit ottaa käyttöön yhdellä painikkeella suoraan VS:stä. Tämän seurauksena 200 koodirivin tiedosto mahdollistaa valmiin ratkaisun julkaisemisen, vaikka CloudFormation-syntaksi voi olla järkyttävä, jos et ole tottunut siihen.

Yhteensä

Palvelimeton ei ole ihmelääke. Mutta se tekee elämästä paljon helpompaa tilanteissa, joissa on kolme rajoitusta: "rajalliset resurssit - lyhyellä aikavälillä - vähän rahaa."

Palvelimettomille sovelluksille soveltuvien sovellusten ominaisuudet

  • ilman pitkiä prosesseja. API Gatewayn kova raja on 29 sekuntia, lambda kova raja on 5 minuuttia;
  • tapahtumalähtöisen arkkitehtuurin kuvaama;
  • hajoaa löyhästi kytketyiksi komponenteiksi, kuten SOA;
  • ei vaadi paljon työtä tilasi kanssa;
  • kirjoitettu .NET Coressa. Jotta voit työskennellä .NET Frameworkin kanssa, tarvitset silti vähintään Dockerin, jolla on sopiva suoritusaika.

Palvelimeton lähestymistavan edut

  • vähentää infrastruktuurikustannuksia;
  • vähentää ratkaisun toimituskustannuksia;
  • automaattinen skaalautuvuus;
  • kehitystä teknologisen kehityksen kärjessä.

Haitat, erityisellä esimerkillä

  • Hajautettu jäljitys ja kirjaaminen - osittain ratkaistu AWS X-Rayn ja AWS CloudWatchin avulla;
  • epämukava virheenkorjaus;
  • Kylmäkäynnistys, kun kuormaa ei ole;
  • AWS-käyttäjän vihamielinen käyttöliittymä on yleinen ongelma :)

Lähde: will.com

Lisää kommentti