Netflix on Internet-televisiomarkkinoiden johtava yritys - yritys, joka loi ja kehittää aktiivisesti tätä segmenttiä. Netflix tunnetaan paitsi laajasta elokuvien ja TV-sarjojen luettelostaan, joka on saatavilla melkein joka kolkasta planeetalla ja kaikista näytöllisistä laitteista, myös luotettavasta infrastruktuuristaan ja ainutlaatuisesta suunnittelukulttuuristaan.
Selkeä esimerkki Netflixin lähestymistavasta monimutkaisten järjestelmien kehittämiseen ja tukemiseen esiteltiin DevOops 2019 -tapahtumassa - Netflixin kehitysjohtaja. Valmistunut Nižni Novgorodin osavaltion yliopiston laskennallisen matematiikan ja matematiikan tiedekunnasta. Lobachevsky, Sergey yksi ensimmäisistä Open Connect -CDN-tiimin insinööreistä Netflixissä. Hän rakensi järjestelmiä videotietojen seurantaan ja analysointiin, lanseerasi suositun palvelun Internet-yhteyden nopeuden arviointiin FAST.com ja on viime vuodet työskennellyt Internet-pyyntöjen optimoinnissa niin, että Netflix-sovellus toimii mahdollisimman nopeasti käyttäjille.
Raportti sai parhaat arvostelut konferenssin osallistujilta, ja olemme laatineet sinulle tekstiversion.
Raportissaan Sergei puhui yksityiskohtaisesti
- siitä, mikä vaikuttaa Internet-pyyntöjen viiveeseen asiakkaan ja palvelimen välillä;
- kuinka tätä viivettä voidaan vähentää;
- kuinka suunnitella, ylläpitää ja valvoa virheensietoisia järjestelmiä;
- kuinka saavuttaa tuloksia lyhyessä ajassa ja mahdollisimman pienellä riskillä yritykselle;
- kuinka analysoida tuloksia ja oppia virheistä.
Vastauksia näihin kysymyksiin tarvitsevat muut kuin ne, jotka työskentelevät suurissa yrityksissä.
Esitetyt periaatteet ja tekniikat tulisi tuntea ja harjoitella jokaisen Internet-tuotteita kehittävän ja tukevan.
Seuraavaksi kerrotaan puhujan näkökulmasta.
Internetin nopeuden merkitys
Internet-pyyntöjen nopeus liittyy suoraan liiketoimintaan. Ajattele ostosalaa: Amazon vuonna 2009 että 100 ms:n viive johtaa 1 %:n menetykseen myynnistä.
Mobiililaitteita on yhä enemmän ja sen jälkeen mobiilisivustot ja -sovellukset. Jos sivusi latautuminen kestää yli 3 sekuntia, menetät noin puolet käyttäjistäsi. KANSSA Google ottaa huomioon sivusi latausnopeuden hakutuloksissa: mitä nopeampi sivu, sitä korkeampi sijainti Googlessa.
Yhteyden nopeus on tärkeä myös rahoituslaitoksissa, joissa latenssi on kriittinen. Vuonna 2015 Hibernia Networks 400 miljoonan dollarin kaapeli New Yorkin ja Lontoon välillä vähentää latenssia kaupunkien välillä 6 ms. Kuvittele 66 miljoonaa dollaria 1 ms:n viiveen vähentämisestä!
Mukaan , yli 5 Mbit/s yhteysnopeudet eivät enää vaikuta suoraan tyypillisen verkkosivuston latausnopeuteen. Yhteysviiveen ja sivun latausnopeuden välillä on kuitenkin lineaarinen suhde:
Netflix ei kuitenkaan ole tyypillinen tuote. Latenssin ja nopeuden vaikutus käyttäjään on aktiivinen analysointi- ja kehitysalue. Sovellusten lataus ja sisällön valinta riippuvat viiveestä, mutta staattisten elementtien lataaminen ja suoratoisto riippuvat myös yhteyden nopeudesta. Käyttäjäkokemukseen vaikuttavien keskeisten tekijöiden analysointi ja optimointi on aktiivinen kehitysalue useille Netflix-tiimeille. Yksi tavoitteista on vähentää pyyntöjen latenssia Netflix-laitteiden ja pilviinfrastruktuurin välillä.
Raportissa keskitymme erityisesti latenssin vähentämiseen Netflixin infrastruktuurin esimerkin avulla. Pohditaan käytännön näkökulmasta, kuinka lähestyä monimutkaisten hajautettujen järjestelmien suunnittelun, kehittämisen ja käytön prosesseja ja käyttää aikaa innovaatioihin ja tuloksiin toimintaongelmien ja vikojen diagnosoinnin sijaan.
Netflixin sisällä
Tuhannet erilaiset laitteet tukevat Netflix-sovelluksia. Niitä on kehittänyt neljä eri tiimiä, jotka tekevät asiakkaasta erilliset versiot Androidille, iOS:lle, TV:lle ja verkkoselaimille. Ja käytämme paljon vaivaa käyttökokemuksen parantamiseen ja personointiin. Tätä varten suoritamme satoja A/B-testejä rinnakkain.
Personointia tukevat sadat AWS-pilven mikropalvelut, jotka tarjoavat personoitua käyttäjädataa, kyselyn lähettämistä, telemetriaa, Big Dataa ja koodausta. Liikenteen visualisointi näyttää tältä:
Vasemmalla on sisääntulopiste, jonka jälkeen liikenne jaetaan useiden satojen mikropalvelujen kesken, joita eri taustatiimit tukevat.
Toinen tärkeä osa infrastruktuuriamme on Open Connect CDN, joka toimittaa staattista sisältöä loppukäyttäjälle - videoita, kuvia, asiakaskoodia jne. CDN sijaitsee mukautetuilla palvelimilla (OCA - Open Connect Appliance). Sisällä on joukko SSD- ja HDD-asemia, joissa on optimoitu FreeBSD, NGINX ja joukko palveluita. Suunnittelemme ja optimoimme laitteisto- ja ohjelmistokomponentteja niin, että tällainen CDN-palvelin voi lähettää käyttäjille mahdollisimman paljon dataa.
Näiden palvelimien "seinä" Internet-liikenteen vaihtopisteessä (Internet eXchange - IX) näyttää tältä:
Internet Exchange tarjoaa Internet-palveluntarjoajille ja sisällöntuottajille mahdollisuuden muodostaa yhteys toisiinsa ja vaihtaa tietoja suoremmin Internetissä. Maailmassa on noin 70-80 Internet Exchange -pistettä, joihin palvelimemme on asennettu, ja asennamme ja ylläpidämme niitä itsenäisesti:
Lisäksi tarjoamme palvelimia suoraan Internet-palveluntarjoajille, jotka he asentavat verkkoonsa parantaen Netflix-liikenteen lokalisointia ja käyttäjien suoratoiston laatua:
Joukko AWS-palveluita vastaa videopyyntöjen lähettämisestä asiakkailta CDN-palvelimille sekä itse palvelinten konfiguroinnista - sisällön, ohjelmakoodin, asetusten jne. päivittämisestä. Jälkimmäistä varten rakensimme myös runkoverkon, joka yhdistää Internet Exchange -pisteissä olevat palvelimet AWS:n kanssa. Runkoverkko on globaali valokuitukaapeleiden ja reitittimien verkko, jonka voimme suunnitella ja konfiguroida tarpeidemme mukaan.
Päälle , CDN-infrastruktuurimme toimittaa noin ⅛ maailman Internet-liikenteestä ruuhka-aikoina ja ⅓ liikenteestä Pohjois-Amerikassa, jossa Netflix on ollut pisimpään. Vaikuttavat luvut, mutta minulle yksi upeimmista saavutuksista on se, että koko CDN-järjestelmää kehittää ja ylläpitää alle 150 hengen tiimi.
Alun perin CDN-infrastruktuuri oli suunniteltu toimittamaan videodataa. Ajan mittaan ymmärsimme kuitenkin, että voimme käyttää sitä myös AWS-pilven asiakkaiden dynaamisten pyyntöjen optimointiin.
Tietoja Internetin kiihtyvyydestä
Nykyään Netflixillä on 3 AWS-aluetta, ja pilveen lähetettyjen pyyntöjen latenssi riippuu siitä, kuinka kaukana asiakas on lähimmästä alueesta. Samaan aikaan meillä on monia CDN-palvelimia, joita käytetään staattisen sisällön toimittamiseen. Onko mitään tapaa käyttää tätä kehystä dynaamisten kyselyjen nopeuttamiseen? Valitettavasti näitä pyyntöjä on mahdotonta tallentaa välimuistiin - API:t ovat henkilökohtaisia ja jokainen tulos on ainutlaatuinen.
Tehdään välityspalvelin CDN-palvelimelle ja aletaan lähettää liikennettä sen kautta. Onko se nopeampi?
materiel
Muistetaan kuinka verkkoprotokollat toimivat. Nykyään suurin osa Internetin liikenteestä käyttää HTTP:tä, joka riippuu alemman kerroksen protokollista TCP ja TLS. Jotta asiakas voi muodostaa yhteyden palvelimeen, se tekee kättelyn, ja suojatun yhteyden muodostamiseksi asiakkaan on vaihdettava viestejä palvelimen kanssa kolme kertaa ja vähintään kerran vielä tiedonsiirtoon. Kun meno-paluuviive (RTT) on 100 ms, ensimmäisen databitin vastaanottaminen kestäisi 400 ms:
Jos sijoitamme varmenteet CDN-palvelimelle, asiakkaan ja palvelimen välinen kättelyaika voidaan lyhentää merkittävästi, jos CDN on lähempänä. Oletetaan, että CDN-palvelimen viive on 30 ms. Sitten ensimmäisen bitin vastaanottaminen kestää 220 ms:
Mutta edut eivät lopu tähän. Kun yhteys on muodostettu, TCP lisää ruuhkaikkunaa (informaation määrää, jonka se voi lähettää kyseisen yhteyden kautta rinnakkain). Jos datapaketti katoaa, TCP-protokollan perinteiset toteutukset (kuten TCP New Reno) vähentävät avointa "ikkunaa" puoleen. Ruuhkaikkunan kasvu ja sen häviöstä toipumisen nopeus riippuu jälleen viiveestä (RTT) palvelimelle. Jos tämä yhteys menee vain CDN-palvelimeen asti, palautus on nopeampaa. Samaan aikaan pakettihäviö on tavallinen ilmiö erityisesti langattomissa verkoissa.
Internetin kaistanleveys saattaa pienentyä etenkin ruuhka-aikoina käyttäjien liikenteen vuoksi, mikä voi johtaa liikenneruuhkiin. Internetissä ei kuitenkaan ole mahdollista antaa etusijalle toisia pyyntöjä. Aseta esimerkiksi pienet ja viiveherkät pyynnöt etusijalle "raskaita" tietovirtoja, jotka kuormittavat verkkoa. Kuitenkin meidän tapauksessamme oma runkoverkkomme antaa meille mahdollisuuden tehdä tämä osassa pyyntöpolkua - CDN:n ja pilven välillä, ja voimme määrittää sen täysin. Voit varmistaa, että pienet ja viiveherkät paketit priorisoidaan ja suuret tietovirrat menevät hieman myöhemmin. Mitä lähempänä CDN on asiakasta, sitä suurempi tehokkuus.
Sovellustason protokollat (OSI-taso 7) vaikuttavat myös latenssiin. Uudet protokollat, kuten HTTP/2, optimoivat rinnakkaisten pyyntöjen suorituskyvyn. Meillä on kuitenkin Netflix-asiakkaita vanhemmilla laitteilla, jotka eivät tue uusia protokollia. Kaikkia asiakkaita ei voida päivittää tai määrittää optimaalisesti. Samaan aikaan CDN-välityspalvelimen ja pilven välillä on täydellinen hallinta ja mahdollisuus käyttää uusia, optimaalisia protokollia ja asetuksia. Tehoton osa vanhoilla protokollilla toimii vain asiakkaan ja CDN-palvelimen välillä. Lisäksi voimme tehdä multipleksointipyyntöjä jo muodostetulle yhteydelle CDN:n ja pilven välillä, mikä parantaa yhteyden käyttöä TCP-tasolla:
Me mittaamme
Huolimatta siitä, että teoria lupaa parannuksia, emme heti kiirehdi ottamaan järjestelmää tuotantoon. Sen sijaan meidän on ensin todistettava, että idea toimii käytännössä. Tätä varten sinun on vastattava useisiin kysymyksiin:
- Nopeus: tuleeko välityspalvelin nopeammaksi?
- Luotettavuus: Meneekö se rikki useammin?
- monimutkaisuus: kuinka integroida sovellusten kanssa?
- Maksaa: Kuinka paljon lisäinfrastruktuurin käyttöönotto maksaa?
Tarkastellaanpa yksityiskohtaisesti lähestymistapaamme ensimmäisen kohdan arvioimiseen. Loput käsitellään samalla tavalla.
Pyyntöjen nopeuden analysoimiseksi haluamme saada tietoja kaikille käyttäjille kuluttamatta paljon aikaa kehitykseen ja rikkomatta tuotantoa. Tähän on olemassa useita lähestymistapoja:
- RUM tai passiivinen pyyntömittaus. Mittaamme käyttäjien tämänhetkisten pyyntöjen suoritusajan ja varmistamme täyden käyttäjien kattavuuden. Haittapuolena on, että signaali ei ole kovin vakaa monista tekijöistä johtuen, esimerkiksi erilaisten pyyntökokojen, palvelimen ja asiakkaan käsittelyajan vuoksi. Lisäksi et voi testata uutta kokoonpanoa ilman vaikutusta tuotannossa.
- Laboratoriokokeita. Erikoispalvelimet ja infrastruktuuri, jotka simuloivat asiakkaita. Heidän avullaan suoritamme tarvittavat testit. Näin saamme täyden hallinnan mittaustuloksista ja selkeän signaalin. Laitteista ja käyttäjien sijainneista ei kuitenkaan ole täydellistä kattavuutta (etenkään maailmanlaajuisen palvelun ja tuhansien laitemallien tuen ansiosta).
Kuinka voit yhdistää molempien menetelmien edut?
Tiimimme on löytänyt ratkaisun. Kirjoitimme pienen koodinpätkän - näytteen - jonka rakensimme sovellukseemme. Anturin avulla voimme tehdä täysin ohjattuja verkkotestejä laitteistamme. Se toimii näin:
- Pian sen jälkeen, kun sovellus on ladattu ja aloitustoiminto on suoritettu, suoritamme analyysimme.
- Asiakas tekee pyynnön palvelimelle ja saa "reseptin" testiä varten. Resepti on luettelo URL-osoitteista, joihin HTTP-pyyntö on tehtävä. Lisäksi resepti määrittää pyyntöparametrit: pyyntöjen väliset viiveet, pyydetyn tiedon määrä, HTTP(t)-otsikot jne. Samaan aikaan voimme testata useita eri reseptejä rinnakkain - konfigurointia pyydettäessä päätämme satunnaisesti, mikä resepti julkaistaan.
- Tutkimuksen käynnistysaika valitaan siten, ettei se ole ristiriidassa asiakkaan verkkoresurssien aktiivisen käytön kanssa. Pohjimmiltaan valitaan aika, jolloin asiakas ei ole aktiivinen.
- Saatuaan reseptin asiakas tekee pyyntöjä jokaiselle URL-osoitteelle rinnakkain. Pyyntö jokaiseen osoitteeseen voidaan toistaa - ns. "pulssit". Ensimmäisellä pulssilla mitataan kuinka kauan kesti yhteyden muodostaminen ja tietojen lataaminen. Toisella pulssilla mittaamme ajan, joka kuluu tietojen lataamiseen jo muodostetun yhteyden kautta. Ennen kolmatta voimme asettaa viiveen ja mitata uudelleenyhteyden muodostusnopeuden jne.
Testin aikana mittaamme kaikki parametrit, jotka laite voi saada:
- DNS-pyyntöaika;
- TCP-yhteyden asetusaika;
- TLS-yhteyden määritysaika;
- ensimmäisen datatavun vastaanottoaika;
- kokonaislatausaika;
- tilan tuloskoodi.
- Kun kaikki pulssit ovat päättyneet, näyte lataa kaikki mittaukset analyysiä varten.
Keskeisiä kohtia ovat minimaalinen riippuvuus asiakkaan logiikasta, tiedonkäsittely palvelimella ja rinnakkaisten pyyntöjen mittaaminen. Pystymme siten eristämään ja testaamaan erilaisten kyselyn suorituskykyyn vaikuttavien tekijöiden vaikutuksen, muuntelemaan niitä yhden reseptin sisällä ja saamaan tuloksia oikeilta asiakkailta.
Tämä infrastruktuuri on osoittautunut hyödylliseksi muuhunkin kuin kyselyn suorituskyvyn analysointiin. Tällä hetkellä meillä on 14 aktiivista reseptiä, yli 6000 näytettä sekunnissa, vastaanottaen dataa joka puolelta maapalloa ja täyden laitteen peiton. Jos Netflix ostaisi vastaavan palvelun kolmannelta osapuolelta, se maksaisi miljoonia dollareita vuodessa paljon huonommalla kattavuudella.
Testausteoria käytännössä: prototyyppi
Tällaisella järjestelmällä pystyimme arvioimaan CDN-välityspalvelinten tehokkuuden pyynnöstä viiveellä. Nyt tarvitset:
- luoda välityspalvelimen prototyyppi;
- aseta prototyyppi CDN:lle;
- määrittää, kuinka asiakkaat ohjataan tietyn CDN-palvelimen välityspalvelimelle;
- Vertaa suorituskykyä AWS:n pyyntöihin ilman välityspalvelinta.
Tehtävänä on arvioida ehdotetun ratkaisun tehokkuus mahdollisimman nopeasti. Valitsimme Go toteuttamaan prototyypin hyvien verkkokirjastojen saatavuuden vuoksi. Asensimme jokaiseen CDN-palvelimeen prototyypin välityspalvelimen staattisena binaarina riippuvuuksien minimoimiseksi ja integroinnin yksinkertaistamiseksi. Alkutoteutuksessa käytimme mahdollisimman paljon vakiokomponentteja ja pieniä muutoksia HTTP/2-yhteyksien yhdistämiseen ja pyyntöjen multipleksointiin.
AWS-alueiden tasapainottamiseksi käytimme maantieteellistä DNS-tietokantaa, jota käytettiin asiakkaiden tasapainottamiseen. CDN-palvelimen valitsemiseksi asiakkaalle käytämme Internet Exchangen (IX) palvelimille TCP Anycastia. Tässä vaihtoehdossa käytämme yhtä IP-osoitetta kaikille CDN-palvelimille, ja asiakas ohjataan CDN-palvelimelle, jolla on vähiten IP-hyppejä. Internet-palveluntarjoajien (ISP:t) asentamissa CDN-palvelimissa emme voi hallita reititintä TCP Anycastin määrittämiseksi, joten käytämme , joka ohjaa asiakkaat Internet-palveluntarjoajille videon suoratoistoa varten.
Meillä on siis kolmenlaisia pyyntöpolkuja: pilveen avoimen Internetin kautta, IX:n CDN-palvelimen kautta tai Internet-palveluntarjoajan CDN-palvelimen kautta. Tavoitteenamme on ymmärtää, mikä tapa on parempi ja mitä hyötyä välityspalvelimesta on verrattuna siihen, miten pyynnöt lähetetään tuotantoon. Tätä varten käytämme näytteenottojärjestelmää seuraavasti:
Jokaisesta polusta tulee erillinen kohde, ja katsomme saamiamme aikaa. Analyysiä varten yhdistämme välityspalvelimen tulokset yhteen ryhmään (valitse paras aika IX- ja ISP-välityspalvelinten välillä) ja vertaamme niitä pilveen ilman välityspalvelinta tehtyjen pyyntöjen aikaan:
Kuten näette, tulokset olivat ristiriitaisia - useimmissa tapauksissa välityspalvelin antaa hyvän vauhdin, mutta löytyy myös riittävä määrä asiakkaita, joiden tilanne huononee merkittävästi.
Tämän seurauksena teimme useita tärkeitä asioita:
- Arvioimme asiakkaiden pilveen CDN-välityspalvelimen kautta tulevien pyyntöjen odotetun suorituskyvyn.
- Saimme tietoja oikeilta asiakkailta, kaikenlaisista laitteista.
- Ymmärsimme, että teoria ei ollut 100-prosenttisesti vahvistettu ja alkuperäinen tarjous CDN-välityspalvelimella ei toimi meille.
- Emme ottaneet riskejä – emme muuttaneet asiakkaiden tuotantokokoonpanoja.
- Mikään ei mennyt rikki.
Prototyyppi 2.0
Joten palaa piirustuspöydälle ja toista prosessi uudelleen.
Ajatuksena on, että 100 % välityspalvelimen sijaan määritämme kullekin asiakkaalle nopeimman polun ja lähetämme sinne pyynnöt - eli teemme niin sanottua asiakasohjausta.
Miten tämä toteutetaan? Emme voi käyttää logiikkaa palvelinpuolella, koska... Tavoitteena on muodostaa yhteys tähän palvelimeen. Asiakkaalla on oltava jokin tapa tehdä tämä. Ja ihannetapauksessa tee tämä mahdollisimman vähän monimutkaista logiikkaa, jotta et ratkaise integraatiokysymystä useiden asiakasalustojen kanssa.
Vastaus on DNS:n käyttö. Meidän tapauksessamme meillä on oma DNS-infrastruktuurimme, ja voimme perustaa toimialuevyöhykkeen, jolle palvelimemme ovat autoritaarisia. Se toimii näin:
- Asiakas tekee pyynnön DNS-palvelimelle isäntäkoneella, esimerkiksi api.netflix.xom.
- Pyyntö saapuu DNS-palvelimellemme
- DNS-palvelin tietää, mikä polku on nopein tälle asiakkaalle ja antaa vastaavan IP-osoitteen.
Ratkaisussa on lisämonimutkaisuus: autoritaariset DNS-palveluntarjoajat eivät näe asiakkaan IP-osoitetta ja voivat lukea vain asiakkaan käyttämän rekursiivisen ratkaisejan IP-osoitteen.
Tästä johtuen autoritaarisen ratkaisejamme ei tarvitse tehdä päätöstä yksittäisen asiakkaan, vaan asiakasryhmän puolesta rekursiivisen ratkaisejan perusteella.
Ratkaisua varten käytämme samoja näytteitä, yhdistämme asiakkaiden mittaustulokset jokaiselle rekursiiviselle ratkaisijalle ja päätämme, minne tämä ryhmä lähetetään - välityspalvelimen IX:n kautta TCP Anycastia käyttämällä, ISP-välityspalvelimen kautta tai suoraan pilveen.
Saamme seuraavan järjestelmän:
Tuloksena olevan DNS-ohjausmallin avulla voit ohjata asiakkaita historiallisten havaintojen perusteella asiakkaiden välisten yhteyksien nopeudesta pilveen.
Jälleen kysymys kuuluu, kuinka tehokkaasti tämä lähestymistapa toimii? Vastataksemme käytämme jälleen anturijärjestelmäämme. Siksi konfiguroimme esittäjän kokoonpanon, jossa yksi kohteista seuraa DNS-ohjauksen suuntaa, toinen menee suoraan pilveen (nykyinen tuotanto).
Tämän seurauksena vertaamme tuloksia ja saamme arvion tehokkuudesta:
Tämän seurauksena opimme useita tärkeitä asioita:
- Arvioimme asiakkailta pilveen tulevien pyyntöjen odotetun suorituskyvyn DNS-ohjauksen avulla.
- Saimme tietoja oikeilta asiakkailta, kaikenlaisista laitteista.
- Ehdotetun idean tehokkuus on todistettu.
- Emme ottaneet riskejä – emme muuttaneet asiakkaiden tuotantokokoonpanoja.
- Mikään ei mennyt rikki.
Nyt vaikeasta osasta - käynnistämme sen tuotantoon
Helppo osa on nyt ohi – toimiva prototyyppi on olemassa. Nyt vaikein osa on tuoda markkinoille Netflixin koko liikenteelle ratkaisu, joka otetaan käyttöön 150 miljoonalle käyttäjälle, tuhansille laitteille, sadoille mikropalveluille ja jatkuvasti muuttuvalle tuotteelle ja infrastruktuurille. Netflix-palvelimet saavat miljoonia pyyntöjä sekunnissa, ja palvelu on helppo katkaista huolimattomilla toimilla. Samalla haluamme reitittää liikennettä dynaamisesti tuhansien CDN-palvelimien läpi Internetissä, joissa jokin muuttuu ja katkeaa jatkuvasti ja sopimattomimmalla hetkellä.
Ja kaiken tämän vuoksi tiimissä on 3 insinööriä, jotka vastaavat järjestelmän kehittämisestä, käyttöönotosta ja täyden tuesta.
Siksi puhumme jatkossakin levollisista ja terveellisistä unista.
Kuinka jatkaa kehitystä ja olla käyttämättä kaikkea aikaa tukemiseen? Lähestymistapamme perustuu kolmeen periaatteeseen:
- Vähennämme mahdollisten rikkoutumisten laajuutta (räjähdyssäde).
- Valmistaudumme yllätyksiin - odotamme, että jokin menee rikki, testauksista ja henkilökohtaisesta kokemuksesta huolimatta.
- Graceful degradation - jos jokin ei toimi oikein, se pitäisi korjata automaattisesti, vaikka ei tehokkaimmalla tavalla.
Kävi ilmi, että meidän tapauksessamme tällä lähestymistavalla ongelmaan voimme löytää yksinkertaisen ja tehokkaan ratkaisun ja yksinkertaistaa merkittävästi järjestelmätukea. Ymmärsimme, että voimme lisätä asiakkaaseen pienen koodinpätkän ja valvoa yhteysongelmien aiheuttamia verkkopyyntövirheitä. Verkkovirheiden sattuessa teemme palautuksen suoraan pilveen. Tämä ratkaisu ei vaadi asiakastiimeiltä merkittäviä ponnisteluja, mutta vähentää merkittävästi odottamattomien rikkoutumisten ja yllätysten riskiä meille.
Tietysti noudatamme varmuuden vuoksi selkeää kurinalaisuutta kehityksen aikana:
- Näytetesti.
- A/B-testaus tai Kanariansaaret.
- Progressiivinen käyttöönotto.
Näytteillä lähestymistapaa on kuvattu - muutokset testataan ensin räätälöidyn reseptin avulla.
Canary-testausta varten meidän on hankittava vertailukelpoiset palvelinparit, joilla voimme verrata järjestelmän toimintaa ennen ja jälkeen muutoksia. Tätä varten valitsemme monilta CDN-sivustoiltamme palvelinparit, jotka vastaanottavat vertailukelpoista liikennettä:
Sitten asennamme koontiversion muutoksineen Canary-palvelimelle. Tulosten arvioimiseksi käytämme järjestelmää, joka vertaa noin 100–150 mittaria otokseen ohjauspalvelimista:
Jos Canary-testaus onnistuu, vapautamme sen vähitellen, aaltoina. Emme päivitä jokaisen sivuston palvelimia samaan aikaan - kokonaisen sivuston menettäminen ongelmien vuoksi vaikuttaa käyttäjien kannalta palveluun enemmän kuin saman määrän palvelimien menettäminen eri paikoissa.
Yleensä tämän lähestymistavan tehokkuus ja turvallisuus riippuu kerättyjen mittareiden määrästä ja laadusta. Kyselykiihdytysjärjestelmäämme varten keräämme mittareita kaikista mahdollisista komponenteista:
- asiakkailta - istuntojen ja pyyntöjen määrä, varaosuudet;
- välityspalvelin - tilastot pyyntöjen lukumäärästä ja ajasta;
- DNS - pyyntöjen numero ja tulokset;
- cloud edge - pyyntöjen käsittelyn määrä ja aika pilvessä.
Kaikki tämä kootaan yhteen putkeen, ja tarpeiden mukaan päätämme mitkä mittarit lähetetään reaaliaikaiseen analytiikkaan ja mitkä Elasticsearchiin tai Big Dataan tarkempaa diagnostiikkaa varten.
Me valvomme
Meidän tapauksessamme teemme muutoksia kriittiseen pyyntöjen polkuun asiakkaan ja palvelimen välillä. Samanaikaisesti eri komponenttien määrä asiakkaalla, palvelimella ja matkalla Internetin kautta on valtava. Muutoksia asiakkaalla ja palvelimella tapahtuu jatkuvasti - kymmenien tiimien työn ja ekosysteemin luonnollisten muutosten aikana. Olemme puolivälissä – kun diagnosoimme ongelmia, meillä on hyvä mahdollisuus olla mukana. Siksi meidän on ymmärrettävä selvästi, kuinka määritellä, kerätä ja analysoida mittareita ongelmien eristämiseksi nopeasti.
Ihannetapauksessa täysi pääsy kaikentyyppisiin mittareihin ja suodattimiin reaaliajassa. Mutta mittareita on paljon, joten kysymys kustannuksista herää. Meidän tapauksessamme erottelemme mittarit ja kehitystyökalut seuraavasti:
Käytämme omaa avoimen lähdekoodin reaaliaikaista järjestelmäämme havaitaksemme ja ratkaistaksemme ongelmat и - visualisointia varten. Se tallentaa aggregoituja mittareita muistiin, on luotettava ja integroituu hälytysjärjestelmään. Lokalisointia ja diagnostiikkaa varten meillä on pääsy Elasticsearchin ja Kibanan lokeihin. Tilastolliseen analyysiin ja mallintamiseen käytämme Tableaussa big dataa ja visualisointia.
Vaikuttaa siltä, että tämän lähestymistavan kanssa on erittäin vaikea työskennellä. Järjestämällä mittarit ja työkalut hierarkkisesti voimme kuitenkin analysoida ongelman nopeasti, määrittää ongelman tyypin ja perehtyä sitten yksityiskohtaisiin mittareihin. Käytämme yleensä noin 1-2 minuuttia vian lähteen tunnistamiseen. Tämän jälkeen teemme diagnostiikkatyötä tietyn tiimin kanssa - kymmenistä minuuteista useisiin tunteihin.
Vaikka diagnoosi tehdään nopeasti, emme halua tämän tapahtuvan usein. Ihannetapauksessa saamme vain kriittisen hälytyksen, kun palvelulla on merkittävä vaikutus. Kyselykiihdytysjärjestelmässämme on vain 2 hälytystä, jotka ilmoittavat:
- Asiakkaan palautusprosentti - asiakkaan käyttäytymisen arviointi;
- Probe errors prosenttiosuus - verkkokomponenttien vakaustiedot.
Nämä tärkeät hälytykset valvovat, toimiiko järjestelmä useimpien käyttäjien kohdalla. Tarkastelemme, kuinka moni asiakas käytti varatoimintoa, jos he eivät saaneet pyyntökiihdytystä. Saatamme keskimäärin alle yhden kriittisen hälytyksen viikossa, vaikka järjestelmässä on meneillään paljon muutoksia. Miksi tämä riittää meille?
- Jos välityspalvelimemme ei toimi, on olemassa asiakasvaraus.
- Siellä on automaattinen ohjausjärjestelmä, joka reagoi ongelmiin.
Tarkemmat tiedot jälkimmäisestä. Kokeilujärjestelmämme ja järjestelmä, joka määrittää automaattisesti optimaalisen polun asiakkaalta pilveen tehtäville pyynnöille, antavat meille mahdollisuuden selviytyä joistakin ongelmista automaattisesti.
Palataan esimerkkikokoonpanoomme ja kolmeen polkuluokkaan. Latausajan lisäksi voimme tarkastella itse toimitusasiaa. Jos dataa ei voitu ladata, niin eri polkuja tarkastelemalla voidaan päätellä missä ja mikä rikki ja voimmeko korjata sen automaattisesti vaihtamalla pyyntöpolkua.
Esimerkkejä:
Tämä prosessi voidaan automatisoida. Sisällytä se ohjausjärjestelmään. Ja opeta se reagoimaan suorituskyky- ja luotettavuusongelmiin. Jos jokin alkaa rikkoutua, reagoi, jos on parempi vaihtoehto. Samanaikaisesti välitön reaktio ei ole kriittinen, kiitos asiakkaiden varallisuuden.
Siten järjestelmätuen periaatteet voidaan muotoilla seuraavasti:
- vikojen määrän vähentäminen;
- mittareiden kerääminen;
- Korjaamme viat automaattisesti, jos voimme;
- jos se ei onnistu, ilmoitamme sinulle;
- Työskentelemme kojelaudoilla ja triage-työkaluilla nopeaa vastausta varten.
Opittua
Prototyypin kirjoittaminen ei vie paljon aikaa. Meidän tapauksessamme se oli valmis 4 kuukauden kuluttua. Sen avulla saimme uusia mittareita ja 10 kuukautta kehityksen alkamisen jälkeen saimme ensimmäisen tuotantoliikenteen. Sitten alkoi työläs ja erittäin vaikea työ: tuotteista ja skaalaa järjestelmä vähitellen, siirrä pääliikenne ja opi virheistä. Tämä tehokas prosessi ei kuitenkaan ole lineaarinen - kaikesta huolimatta kaikkea ei voida ennustaa. On paljon tehokkaampaa iteroida nopeasti ja vastata uusiin tietoihin.
Kokemuksemme perusteella voimme suositella seuraavaa:
- Älä luota intuitioosi.
Intuitiomme petti meidät jatkuvasti tiimimme jäsenten laajasta kokemuksesta huolimatta. Ennustimme esimerkiksi väärin CDN-välityspalvelimen käytön odotetun nopeuden tai TCP Anycastin käyttäytymisen.
- Hanki tiedot tuotannosta.
On tärkeää saada käsiksi ainakin pieni määrä tuotantotietoja mahdollisimman nopeasti. Ainutlaatuisten tapausten, kokoonpanojen ja asetusten määrää on lähes mahdotonta saada laboratorio-olosuhteissa. Nopea pääsy tuloksiin antaa sinun nopeasti oppia mahdollisista ongelmista ja ottaa ne huomioon järjestelmäarkkitehtuurissa.
- Älä seuraa muiden neuvoja ja tuloksia – kerää omat tietosi.
Noudata tiedonkeruun ja -analyysin periaatteita, mutta älä hyväksy sokeasti muiden tuloksia ja lausuntoja. Vain sinä voit tietää tarkalleen, mikä toimii käyttäjillesi. Järjestelmäsi ja asiakkaasi voivat erota merkittävästi muista yrityksistä. Onneksi analyysityökalut ovat nyt saatavilla ja helppokäyttöisiä. Saadut tulokset eivät välttämättä ole sitä, mitä Netflix, Facebook, Akamai ja muut yritykset väittävät. Meidän tapauksessamme TLS:n, HTTP2:n tai DNS-pyyntöjen tilastojen suorituskyky eroaa Facebookin, Uberin, Akamain tuloksista - koska meillä on erilaisia laitteita, asiakkaita ja tietovirtoja.
- Älä turhaan seuraa muotitrendejä ja arvioi tehokkuutta.
Aloita yksinkertaisesta. On parempi tehdä yksinkertainen toimiva järjestelmä lyhyessä ajassa kuin käyttää valtavasti aikaa tarpeettomien komponenttien kehittämiseen. Ratkaise tärkeitä tehtäviä ja ongelmia mittausten ja tulosten perusteella.
- Valmistaudu uusiin sovelluksiin.
Aivan kuten kaikkia ongelmia on vaikea ennustaa, on vaikea ennustaa etuja ja sovelluksia etukäteen. Ota esimerkki startupeista – niiden kyvystä sopeutua asiakasolosuhteisiin. Sinun tapauksessasi saatat löytää uusia ongelmia ja niiden ratkaisuja. Projektissamme asetimme tavoitteeksi vähentää pyyntöjen latenssia. Analyysin ja keskustelujen aikana huomasimme kuitenkin, että voimme käyttää myös välityspalvelimia:
- tasapainottaa liikennettä AWS-alueiden välillä ja vähentää kustannuksia;
- mallintaa CDN-stabiiliutta;
- määrittää DNS;
- määrittääksesi TLS/TCP:n.
Johtopäätös
Raportissa kuvailin, kuinka Netflix ratkaisee Internet-pyyntöjen kiihtymisen asiakkaiden ja pilven välillä. Kuinka keräämme tietoja käyttämällä asiakkaiden otantajärjestelmää ja käytämme kerättyä historiatietoa asiakkaiden tuotantopyyntöjen ohjaamiseen Internetin nopeimman polun kautta. Kuinka käytämme verkkoprotokollien, CDN-infrastruktuurimme, runkoverkkomme ja DNS-palvelimien periaatteita tämän tehtävän saavuttamiseksi.
Ratkaisumme on kuitenkin vain esimerkki siitä, kuinka me Netflixissä toteutimme tällaisen järjestelmän. Mikä toimi meillä. Raporttini sovellettu osa sinulle on kehittämisen ja tuen periaatteet, joita noudatamme ja saavutamme hyviä tuloksia.
Ratkaisumme ongelmaan ei välttämättä sovi sinulle. Teoria ja suunnitteluperiaatteet kuitenkin säilyvät, vaikka sinulla ei olisi omaa CDN-infrastruktuuria tai se eroaisi merkittävästi meidän omasta.
Myös liiketoimintapyyntöjen nopeuden merkitys on edelleen tärkeä. Ja jopa yksinkertaista palvelua varten sinun on tehtävä valinta: pilvipalveluntarjoajien, palvelimen sijainnin, CDN- ja DNS-palveluntarjoajien välillä. Valintasi vaikuttaa Internet-kyselyjen tehokkuuteen asiakkaidesi kannalta. Ja sinun on tärkeää mitata ja ymmärtää tämä vaikutus.
Aloita yksinkertaisilla ratkaisuilla, välitä siitä, kuinka muutat tuotetta. Opi samalla ja paranna järjestelmää asiakkaidesi, infrastruktuurisi ja yrityksesi tietojen perusteella. Ajattele odottamattomien vikojen mahdollisuutta suunnitteluprosessin aikana. Ja sitten voit nopeuttaa kehitysprosessiasi, parantaa ratkaisujen tehokkuutta, välttää turhaa tukitaakkaa ja nukkua rauhassa.
Tänä vuonna online-muodossa. Voit esittää kysymyksiä yhdelle DevOpsin isille, John Willisille itselleen!
Lähde: will.com