{"id":84876,"date":"2020-06-11T13:43:18","date_gmt":"2020-06-11T11:43:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno"},"modified":"2020-06-11T13:43:18","modified_gmt":"2020-06-11T11:43:18","slug":"uskoryaem-internet-zaprosy-i-spim-spokojno","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","title":{"rendered":"Kiirendame internetip\u00e4ringuid ja magame rahulikult","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/07e2e32d406b8b5d6d6cb3f627a31c3a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNetflix \u2014 internetittelevisiooni turuliider \u2014 ettev\u00f5te, mis on loonud ja aktiivselt arendab seda segmenti. Netflix on tuntud mitte ainult ulatusliku filmide ja sarjade katalooge poolest, mis on kergesti k\u00e4ttesaadavad peaaegu igast maailma nurgast ja igast ekraaniga seadmest, vaid ka usaldusv\u00e4\u00e4rse infrastruktuuri ja ainulaadse insenerikultuuri poolest. <\/p>\n<p>Selge n\u00e4ide Netflixi l\u00e4henemisest keerukate s\u00fcsteemide arendamisel ja hooldamisel esitles DevOops 2019 <noindex><a rel=\"nofollow\" href=\"https:\/\/sfedov.com\">Sergei Fedorov<\/a><\/noindex> \u2014 Netflixi arenduse direktor. Lobatchevi nimelise Nizhni Novgorodi Riikliku \u00dclikooli info- ja matemaatikateaduskonna vilistlane, Sergei on \u00fcks esimesi insenere Open Connectis \u2014 Netflixi CDN meeskonnas. Ta on ehitanud videoandmete j\u00e4lgimise ja anal\u00fc\u00fcsi s\u00fcsteeme, loonud populaarse Interneti-\u00fchenduse kiirusetesti teenuse FAST.com ja viimaseid aastaid on t\u00f6\u00f6tanud Interneti-p\u00e4ringute optimeerimise nimel, et Netflixi rakendus t\u00f6\u00f6tab kasutajatele v\u00f5imalikult kiiresti.<\/p>\n<p>Ettekanne sai parimaid arvustusi konverentsi osalejatelt ja oleme valmistanud teile selle tekstiversiooni.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"n7Te9WIz1ho\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/n7Te9WIz1ho\/hqdefault.jpg\" alt=\"M\u00e4ngi videot\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h2>Ettekandes r\u00e4\u00e4kis Sergei p\u00f5hjalikult<\/h2>\n<p><\/p>\n<ul>\n<li>sellest, mis m\u00f5jutab internetip\u00e4ringute latentsust kliendi ja serveri vahel;<\/li>\n<li>kuidas seda latentsust v\u00e4hendada;<\/li>\n<li>kuidas projekteerida, hooldada ja j\u00e4lgida vigade suhtes vastupidavaid s\u00fcsteeme;<\/li>\n<li>kuidas saavutada tulemusi l\u00fchikese aja jooksul ja minimaalsete \u00e4ririskidega;<\/li>\n<li>kuidas anal\u00fc\u00fcsida tulemusi ja \u00f5ppida vigadest.<\/li>\n<\/ul>\n<p>\nNendele k\u00fcsimustele on vastused vajalikud mitte ainult neile, kes t\u00f6\u00f6tavad suurtel korporatsioonidel. <\/p>\n<p>Esitatud p\u00f5him\u00f5tteid ja tehnikaid peaks teadma ja rakendama iga\u00fcks, kes arendab ja hooldab internetitooteid.<\/p>\n<p><b>J\u00e4rgnevalt \u2014 r\u00e4\u00e4kiv h\u00e4\u00e4l esineja isikus.<\/b><\/p>\n<h2>Interneti kiirus<\/h2>\n<p>\nInterneti-p\u00e4ringute kiirus on otseselt seotud ettev\u00f5tlusega. Vaatame ostuvaldkonda: Amazon \u00fctles 2009. aastal <noindex><a rel=\"nofollow\" href=\"https:\/\/www.gigaspaces.com\/blog\/amazon-found-every-100ms-of-latency-cost-them-1-in-sales\/\">, et 100 ms viivitus toob kaasa 1% m\u00fc\u00fcgi languse.<\/a><\/noindex>Mobiilsete seadmete arv kasvab ja koos nendega ka mobiilsete veebilehtede ja rakenduste arv. Kui teie leht laadib kauem kui 3 sekundit, kaotate umbes poole kasutajatest. Alates<\/p>\n<p>juulist 2018. aastal <noindex><a rel=\"nofollow\" href=\"https:\/\/webmasters.googleblog.com\/2018\/01\/using-page-speed-in-mobile-search.html\">arvestab Google teie lehe laadimiskiirusest oma otsingutulemustes: mida kiiremini leht, seda k\u00f5rgem on selle positsioon Googles.<\/a><\/noindex> \u00dchenduse kiirus on samuti oluline ka finantsettev\u00f5tetes, kus viivitus on kriitiline. 2015. aastal l\u00f5petas Hibernia Networks<\/p>\n<p>viimased <noindex><a rel=\"nofollow\" href=\"https:\/\/www.submarinenetworks.com\/en\/systems\/trans-atlantic\/project-express\/hibernia-express-connects-new-york-to-london-in-under-58-95ms\">projektid.<\/a><\/noindex> kaabli paigaldus New Yorgi ja Londoni vahel maksab 400 miljonit dollarit, et v\u00e4hendada hilinemist linnade vahel 6 ms. Kujutage ette, 66 miljonit dollarit 1 ms edasil\u00fckkamise v\u00e4hendamiseks!<\/p>\n<p>Vastavalt <noindex><a rel=\"nofollow\" href=\"https:\/\/hpbn.co\/primer-on-web-performance\/\">uurimusele<\/a><\/noindex>, \u00fchenduse kiirus \u00fcle 5 Mbit\/s enam otseselt ei m\u00f5juta tavalise veebisaidi laadimise kiirust. Siiski on hilinemise ja lehe laadimise kiiruse vahel lineaarne seos:<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/340ca1f2c5bdd6ca95a5caf02f67e3fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKuid Netflix ei ole tavaline toode. Hilinemise ja kiirusel on kasutajale m\u00f5ju, see on aktiivne anal\u00fc\u00fcsi ja arenduse valdkond. On rakenduse laadimine ja sisu valik, mis s\u00f5ltuvad hilinemisest, kuid staatiliste elementide laadimine ja voogedastus s\u00f5ltuvad samuti \u00fchenduse kiirusest. Kvaliteedi teenuse anal\u00fc\u00fcs ja optimeerimine kasutaja jaoks on aktiivne arendusteema mitmete Netflixi meeskondade seas. \u00dcks \u00fclesanne on v\u00e4hendada p\u00e4ringute hilinemist Netflixi seadmete ja pilveinfrastruktuuri vahel.<\/p>\n<p>K\u00e4esolevas aruandes keskendume hilinemise (latency) v\u00e4hendamisele Netflixi infrastruktuuri n\u00e4itel. Vaadakem praktiliselt, kuidas l\u00e4heneda keerukate jaotatud s\u00fcsteemide projekteerimise, arendamise ja haldamise protsessidele ning kulutada aega uuendustele ja tulemustele, mitte operatiivsete probleemide ja riketega seonduvatele diagnostikatele.<\/p>\n<h2>Netflixis<\/h2>\n<p>\nTuhanded erinevad seadmed toetavad Netflixi rakendusi. Nende arendamisega tegeleb neli erinevat meeskonda, kes loovad eraldi versioonid Androidi, iOS-i, teleri ja veebibrauserite jaoks. Investeerime palju ressursse, et parandada ja isikup\u00e4rastada kasutajaliidest. Selleks korraldame korraga sadu A\/B teste.<\/p>\n<p>Isikup\u00e4rastamine toetatakse erinevatest mikroteenustest AWS-is, mis pakuvad kasutajale isikup\u00e4raseid andmeid, p\u00e4ringute suunamist, telemeetria, Big Data ja kodeerimise. Liiklusvisualiseerimine n\u00e4eb v\u00e4lja selline:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/n7Te9WIz1ho?t=364\">Link videole koos demonstreerimisega (6:04-6:23)<\/a><\/noindex><\/p>\n<p>Vasakul asub entry point ja seej\u00e4rel jaotatakse liiklus mitmete sadade mikroteenuste vahel, mille taga on erinevad backendi meeskonnad.<\/p>\n<p>Teine oluline komponent meie infrastruktuuris on Open Connect CDN, mis toimetab l\u00f5puni kasutajani staatilist sisu \u2013 videoid, pilte, kliendi jaoks m\u00f5eldud koodi jne. CDN asub kohandatud serverites (OCA \u2013 Open Connect Appliance). Nendes on SSD- ja HDD-kettad, mida juhib optimeeritud FreeBSD koos NGINX-i ja teenuste kogumiga. Me projekteerime ja optimeerime riist- ja tarkvarakomponente nii, et selline CDN-server suudab edastada v\u00f5imalikult palju andmeid kasutajatele. <\/p>\n<p>Need serverid on Interneti liikluse vahetuspunktis (Internet eXchange \u2013 IX) sellised:<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/8155601c344acb1eb05b925193af8f9a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nInternet Exchange v\u00f5imaldab interneti teenusepakkujatel ja sisu tarnijatel omavahel \"\u00fchenduda\", et vahetada andmeid internetis otse. \u00dcle kogu maailma on umbes 70\u201380 Internet Exchange'i punkti, kus asuvad meie serverid, ja me teeme nende paigaldamise ja hooldamise ise.<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/77a2465314e47c0b2c90dbf7a2fb5e6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLisaks sellele pakume servereid otse interneti teenusepakkujatele, kes paigaldavad need oma v\u00f5rgus, parandades Netflixi liikluse lokaliseerimist ja streaming-kvaliteeti kasutajatele.<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/63e077d2649bfafea5c7af43a0faaf85.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAWS teenuste komplekt vastutab video p\u00e4ringute suunamise eest klientidelt CDN-serveritesse ning serverite konfigureerimise eest \u2013 sisu, tarkvara, seadistuste jms v\u00e4rskendamine. Selle jaoks ehitasime ka backbone-v\u00f5rgu, mis \u00fchendab serverid Internet Exchange'i punktides AWS-iga. Backbone-v\u00f5rk on globaalne optiliste kiudude ja ruuterite v\u00f5rk, mida saame projekteerida ja konfigureerida vastavalt meie vajadustele.<\/p>\n<p>Ajal <noindex><a rel=\"nofollow\" href=\"https:\/\/www.sandvine.com\/hubfs\/Sandvine_Redesign_2019\/Downloads\/Internet%20Phenomena\/Internet%20Phenomena%20Report%20Q32019%2020190910.pdf\">Sandvine'i hinnangud<\/a><\/noindex>, meie CDN infrastruktuur toimetab tipptundidel umbes \u215b osa maailma interneti liiklusest ja \u2153 liiklusest P\u00f5hja-Ameerikas, kus Netflix on eksisteerinud k\u00f5ige kauem. Need on muljetavaldavad numbrid, kuid minu arust on k\u00f5ige \u00fcllatavam saavutus see, et kogu CDN s\u00fcsteem on v\u00e4lja t\u00f6\u00f6tatud ja hooldatud v\u00e4hem kui 150 inimesest koosneva meeskonna poolt.<\/p>\n<p>Alguses oli CDN infrastruktuur projekteeritud meediaandmete edastamiseks. Kuid aja jooksul saime aru, et saame seda kasutada ka d\u00fcnaamiliste p\u00e4ringute optimeerimiseks klientidelt AWS-i pilve.<\/p>\n<h2>Internetikiirus<\/h2>\n<p>\nT\u00e4na on Netflixil 3 AWS piirkonda ja pilve p\u00e4ringute viivitus s\u00f5ltub sellest, kui kaugel klient asub l\u00e4himast piirkonnast. Samuti on meil palju CDN-servereid, mida kasutatakse staatilise sisu edastamiseks. Kas seda infrastruktuuri saaks kasutada d\u00fcnaamiliste p\u00e4ringute kiirendamiseks? Kahjuks ei saa me neid p\u00e4ringuid vahem\u00e4lustada - API-d on isikup\u00e4rased ja iga tulemus on ainulaadne.<\/p>\n<p>Teeme CDN-serveris proksi ja hakkame l\u00e4bi selle liiklust suunama. Kas see oleks kiirem?<\/p>\n<h2>Tehnilised \u00fcksikasjad<\/h2>\n<p>\nKohandame meeles, kuidas v\u00f5rgu protokollid t\u00f6\u00f6tavad. T\u00e4na kasutab suurem osa interneti liiklust HTTPs, mis s\u00f5ltub alumiste tasemete protokollidest TCP ja TLS. Et klient saaks serveriga \u00fchendust, peab ta tegema handshake'i ja turvalise \u00fchenduse loomise jaoks peab klient vahetama s\u00f5numeid serveriga kolm korda ning veel v\u00e4hemalt \u00fche korra andmete edastamiseks. Kui \u00fche vahetuse viivitus (RTT) on 100 ms, siis vajame esimest bitsi andmete saamiseks 400 ms:<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/ab12024f5a9940ca470f27821ca3c631.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKui sertifikaadid asuvad CDN-serveris, saame oluliselt v\u00e4hendada kliendi ja serveri vahelise \u201ek\u00e4tlemise\u201d aega, kui CDN on l\u00e4hemal. Oletame, et viivitus CDN-serverisse on 30 ms. Siis vajame esimese bitsi saamiseks juba 220 ms:<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/d63134bb51592aaa6a5e0c86f1a070e0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKuid kasu sellega ei l\u00f5ppe. P\u00e4rast \u00fchenduse loomist suurendab TCP congestion window'i (teabe kogus, mida saab selle \u00fchenduse kaudu paralleelselt edastada). Kui andmepakett kaob, v\u00e4hendavad traditsioonilised TCP protokollide rakendused (nt TCP New Reno) avatud \u201eaken\u201d poole v\u00f5rra. Congestion window'i kasv ja kadumise taastumise kiirus s\u00f5ltuvad taas serverisse suunatud viivitusest (RTT). Kui \u00fchendus l\u00e4heb ainult CDN-serverisse, siis taastumine toimub kiiremini. Samuti on andmepakettide kaotus tavaline n\u00e4htus, eriti traadita v\u00f5rkudes.<\/p>\n<p>Interneti l\u00e4bilaskev\u00f5ime v\u00f5ib v\u00e4hendada, eriti tipptundidel kasutajate liikluse t\u00f5ttu, mis v\u00f5ib tekitada \u201eummikuid\u201c. Internetis ei ole v\u00f5imalik anda \u00fchele p\u00e4ringule prioriteeti teiste ees. N\u00e4iteks, prioriseerida v\u00e4iksema mahuga ja viivitusest s\u00f5ltuvad p\u00e4ringud \u201erasketest\u201c andmevoogudest, mis koormavad v\u00f5rku. Kuid meie puhul v\u00f5imaldab oma selgroo olemasolu seda teie p\u00e4ringu teel \u2014 CDN ja pilve vahel, ning me saame seda t\u00e4ielikult konfigureerida. V\u00f5ime seadistada nii, et v\u00e4ikesed ja viivitusest s\u00f5ltuvad paketid oleksid prioriseeritud, ja suured andmevood saadetakse veidi hiljem. Mida l\u00e4hemal on CDN kliendile, seda suurem on efektiivsus.<\/p>\n<p>Samuti m\u00f5jutavad viivitust rakendusprotokollid (OSI tasand 7). Uued protokollid, nagu HTTP\/2, v\u00f5imaldavad optimeerida samaaegsete p\u00e4ringute t\u00f5husust. Kuid meil on Netflix, kus on kliente, kelle seadmed ei toeta uusi protokolle. Mitte k\u00f5iki kliente ei ole v\u00f5imalik uuendada v\u00f5i optimaalselt seadistada. Sellegipoolest on CDN-proksi ja pilve vahel t\u00e4ielik kontroll ning v\u00f5imalus kasutada uusi, optimaalseid protokolle ja seadistusi. Ebaefektiivne osa vanade protokollide osas toimib ainult kliendi ja CDN-serveri vahel. Veelgi enam, me saame teha p\u00e4ringute multipliiksust juba kehtestatud \u00fchenduses CDN-i ja pilve vahel, parandades TCP tasandi \u00fchenduse kasutust:<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/a05b49680734670dcfce9111f3ba1919.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>M\u00f5\u00f5dame<\/h2>\n<p>\nKuigi teooria lubab paranemist, ei kiirusta me s\u00fcsteemi tootmisse k\u00e4ivitama. Selle asemel peame k\u00f5igepealt t\u00f5estama, et idee toimib praktikas. Selleks tuleb vastata mitmele k\u00fcsimusele:<\/p>\n<ul>\n<li><b>Kiirus<\/b>: kas proksi on kiirem?<\/li>\n<li><b>Usaldusv\u00e4\u00e4rsus<\/b>: kas see katkeneb sagedamini?<\/li>\n<li><b>T\u00e4htsus<\/b>: kuidas integreerida rakendustega?<\/li>\n<li><b>Hind<\/b>: palju maksab t\u00e4iendava infrastruktuuri k\u00e4ivitamine?<\/li>\n<\/ul>\n<p>\nVaadake t\u00e4psemalt meie l\u00e4henemist esimese punkti hindamisel. \u00dclej\u00e4\u00e4nud k\u00e4sitletakse sarnasel viisil.<\/p>\n<p>K\u00fcsimuste kiirusanal\u00fc\u00fcsi jaoks soovime saada andmeid k\u00f5ikidelt kasutajatelt, kulutamata liigselt aega arendusele ja mitte purustades tootmist. Selleks on mitu l\u00e4henemist:<\/p>\n<ol>\n<li>RUM v\u00f5i passiivne p\u00e4ringute m\u00f5\u00f5tmine. Me m\u00f5\u00f5dame kasutajate praeguste p\u00e4ringute t\u00e4itmise aega ja tagame t\u00e4ieliku katvuse. Puuduseks on see, et signaal ei ole v\u00e4ga stabiilne mitmete tegurite t\u00f5ttu, n\u00e4iteks p\u00e4ringute erinevad suurused, serveri ja kliendi t\u00f6\u00f6tlemisaeg. Lisaks ei ole v\u00f5imalik uut konfigureerimist testida ilma, et see m\u00f5jutaks tootmisprotsessi.<\/li>\n<li>Laboratoorsed testid. Spetsiaalsed serverid ja infrastruktuur, mis j\u00e4ljendavad kliente. Nende abil viime l\u00e4bi vajalikke teste. Nii saame t\u00e4ieliku kontrolli m\u00f5\u00f5tmistulemuste \u00fcle ja selge signaali. Kuid seadmete ja kasutajate asukoha t\u00e4ielik katvus puudub (eriti ettev\u00f5ttele, mis tegutseb \u00fcle kogu maailma ja toetab tuhandeid seadmemudeleid).<\/li>\n<\/ol>\n<p>\nKuidas saaksme kombineerida m\u00f5lema meetodi eeliseid?<\/p>\n<p>Meie meeskond leidis lahenduse. Kirjutasime v\u00e4ikese koodi - proovi - mille integreerisime meie rakendusse. Proovid v\u00f5imaldavad meil teha t\u00e4ielikult kontrollitud v\u00f5rgu teste meie seadmetest. See t\u00f6\u00f6tab j\u00e4rgmiselt: <\/p>\n<ol>\n<li>Peale rakenduse laadimist ja esialgsete tegevuste l\u00f5petamist k\u00e4ivitame meie proovid. <\/li>\n<li>Kliendilt saadetakse p\u00e4ring serverile, et saada testirecept. Retsept koosneb URL-ade listist, kuhu tuleb teha HTTP(s) p\u00e4ring. Lisaks sellele konfigureerib retsept p\u00e4ringute parameetrid: viivitused p\u00e4ringute vahel, k\u00fcsitava andmemaht, HTTP(s) p\u00e4ised jms. Me saame samaaegselt testida mitmeid erinevaid retsepte - probleemide korral m\u00e4\u00e4ratakse juhuslikult, millist retsepti anda. <\/li>\n<li>Proovi k\u00e4ivitamise aeg valitakse nii, et see ei kattuks kliendi aktiivsete v\u00f5rguressursside kasutamisega. Sisuliselt valitakse aeg, mil klient ei ole aktiivne.<\/li>\n<li>P\u00e4rast retsepti saamist teeb klient p\u00e4ringud iga URL-aadressi peale paralleelselt. Iga aadressi p\u00e4ring v\u00f5ib korduda - nn \"pulsside\". Esimese pulsi ajal m\u00f5\u00f5dame, kui kaua kulus\u00fchenduse loomine ja andmete edastamine. Teise pulsi ajal m\u00f5\u00f5dame andmete laadimise aega juba loodud \u00fchenduse kaudu. Enne kolmandat pulti saame seada viivituse ja m\u00f5\u00f5ta uuesti \u00fchenduse loomise kiirus jne.\n<p>Testi k\u00e4igus m\u00f5\u00f5dame k\u00f5iki parameetreid, mida seade v\u00f5ib saada:<\/p>\n<ul>\n<li>DNS p\u00e4ringu aeg;<\/li>\n<li>TCP \u00fchenduse loomise aeg;<\/li>\n<li>TLS \u00fchenduse loomise aeg;<\/li>\n<li>esimese andmebaidi saamise aeg;<\/li>\n<li>kokku laadimisaja;<\/li>\n<li>tulemuse seisukood.<\/li>\n<\/ul>\n<\/li>\n<li> K\u00f5ikide pulsits\u00fcklite l\u00f5ppedes laadib proov anal\u00fc\u00fcsiks kokku k\u00f5ik m\u00f5\u00f5tmistulemused.<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/fff11d487b7c7725707cdeeca0734296.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPeamised aspektid on minimaalne s\u00f5ltuvus kliendi loogikast, andmete t\u00f6\u00f6tlemisest serveris ja paralleelsete p\u00e4ringute m\u00f5\u00f5tmine. Nii saame v\u00f5imaluse isoleerida ja testida erinevate tegurite m\u00f5ju p\u00e4ringute j\u00f5udlusele, varieerida neid \u00fche retsepti piires ning saada tulemusi reaalsetelt klientidelt.<\/p>\n<p>T\u00e4nane infrastruktuur osutus kasulikuks mitte ainult p\u00e4ringute j\u00f5udluse anal\u00fc\u00fcsimiseks. Meil on hetkel 14 aktiivset retsepti, rohkem kui 6000 proovi sekundis, mis saavad andmeid k\u00f5ikjatest nurkadest ja katab t\u00e4ielikult seadmeid. Kui Netflix ostaks sarnase teenuse kolmandatelt ettev\u00f5tetelt, maksaks see miljoneid dollareid aastas, kuid oluliselt halvemate katvuste korral.<\/p>\n<h2>Kontrollime teooriat praktikas: protot\u00fc\u00fcp<\/h2>\n<p>\nSellise s\u00fcsteemiga saime v\u00f5imaluse hinnata CDN-proksi efektiivsust p\u00e4ringute latentsuse osas. N\u00fc\u00fcd on vaja:<\/p>\n<ul>\n<li>luua proksi protot\u00fc\u00fcp;<\/li>\n<li>paigutada protot\u00fc\u00fcp CDN-i;<\/li>\n<li>m\u00e4\u00e4rata, kuidas suunata kliente konkreetse CDN-serveri proksile;<\/li>\n<li>v\u00f5rrelda j\u00f5udlust AWS p\u00e4ringutega ilma proksita.<\/li>\n<\/ul>\n<p>\n\u00dclesanne on v\u00f5imalikult kiiresti hinnata pakutud lahenduse efektiivsust. Protot\u00fc\u00fcbi implementeerimiseks valisime Go, t\u00e4nu hea v\u00f5rgu kogumite olemasolule. Iga CDN-serverisse paigaldasime proksi protot\u00fc\u00fcbi staatilise binaarina, et minimeerida s\u00f5ltuvusi ja lihtsustada integreerimist. Algse rakenduse puhul kasutasime maksimaalselt standardkomponente ja v\u00e4iksemaid modifikatsioone HTTP\/2 \u00fchenduse haldamiseks ja p\u00e4ringute mitmeastmeliseks t\u00f6\u00f6tlemiseks.<\/p>\n<p>AWS piirkondade vahel tasakaalu saavutamiseks kasutasime geograafilist DNS andmebaasi, sama, mida kasutatakse klienditasakaalu jaoks. CDN-serveri valimiseks kliendi jaoks kasutame TCP Anycasti Internet Exchange (IX) serverite jaoks. Sellisel juhul kasutame k\u00f5igi CDN-serverite jaoks \u00fchte IP-aadressi, mille korral klient suunatakse k\u00f5ige v\u00e4hem IP h\u00fcppega CDN-serverisse. Meil ei ole kontrolli ISP-de juures asuvate CDN-serverite marsruutimise \u00fcle TCP Anycasti seadistamiseks, seet\u00f5ttu rakendame <noindex><a rel=\"nofollow\" href=\"https:\/\/www.infoq.com\/presentations\/netflix-streaming-arch\/\">sama loogikat<\/a><\/noindex>, mille alusel kliendid suunatakse interneti pakkujate kaudu videostreamingu jaoks.<\/p>\n<p>Nii et meil on kolm t\u00fc\u00fcpi teid p\u00e4ringu jaoks: pilve kaudu avatud internetti, l\u00e4bi CDN-serveri IX-is v\u00f5i l\u00e4bi CDN-serveri, mis asub interneti pakkuja juures. Meie eesm\u00e4rk on m\u00f5ista, milline tee on parem ja milline on kasu proksist v\u00f5rreldes sellega, kuidas p\u00e4ringud l\u00e4hevad tootmisse. Selleks kasutame katsete s\u00fcsteemi j\u00e4rgmiselt:<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/51b64d5be0aaf0f141484ee0fd373396.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIga tee muutub eraldi sihtkohaks ja vaatame saadud aega. Anal\u00fc\u00fcsimiseks \u00fchendame proksi tulemused \u00fchte r\u00fchma (valime parima aja IX ja ISP proksi vahel) ja v\u00f5rdleme seda pilve p\u00e4ringute ajaga ilma proksita:<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/ec01690f6a312e61649282b0e6208778.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNagu n\u00e4ha, olid tulemused ebamugavad - enamiku juhtumite korral annab proks hea kiiruskasvu, kuid on ka piisavalt palju kliente, kelle jaoks olukord halveneb. <\/p>\n<p>Kokkuv\u00f5ttes tegime mitmeid olulisi asju:<\/p>\n<ol>\n<li>Hindasime oodatavat p\u00e4ringute j\u00f5udlust klientidelt pilve kaudu CDN proksi.<\/li>\n<li>Saime andmeid t\u00f5elistelt klientidelt, k\u00f5ikide seadme t\u00fc\u00fcpide kohta.<\/li>\n<li>M\u00f5istsime, et teooria ei kinnitunud 100% ja esialgne ettepanek CDN-proksi jaoks ei toimi.<\/li>\n<li>Me ei riskinud - ei muutnud tootmisconfiguratsiooni klientide jaoks.<\/li>\n<li>Me ei rikkunud midagi. <\/li>\n<\/ol>\n<p><\/p>\n<h2>Protot\u00fc\u00fcp 2.0<\/h2>\n<p>\nN\u00fc\u00fcd naaseme joonistustahvli juurde ja kordame protsessi uuesti.<\/p>\n<p>Idee on - 100% proksi asemel m\u00e4\u00e4ratleme iga kliendi jaoks kiireima tee ja suuname p\u00e4ringud sinna - see t\u00e4hendab, et teeme seda, mida nimetatakse kliendi suunamiseks.<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/780817f48a4d2b292d5545e0aa1ccc50.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKuidas seda rakendada? Me ei saa kasutada serveripoolset loogikat, kuna eesm\u00e4rk on \u00fchendada see server. Peame kuidagi tegema seda kliendi poolel. Ja ideaaljuhul tuleks see teha minimaalse keerulise loogikaga, et v\u00e4ltida laia kliendiplatvormide integreerimise k\u00fcsimust. <\/p>\n<p>Vastus on DNS-i kasutamine. Meie puhul on meil oma DNS-infrastruktuur ja me saame seadistada domeenin\u00f6\u00f6ri, mille jaoks meie serverid on autoriteetsed. See t\u00f6\u00f6tab nii:<\/p>\n<ol>\n<li>Kliendi k\u00fcsimus saadetakse DNS-serverisse, kasutades hosti, n\u00e4iteks api.netflix.com.<\/li>\n<li>K\u00fcsimus j\u00f5uab meie DNS-serverisse.<\/li>\n<li>DNS-server teab, milline tee on selle kliendi jaoks k\u00f5ige kiirem, ja annab vastavad IP-aadressid. <\/li>\n<\/ol>\n<p>\nLahenduses on lisaks veel \u00fcks keerukus: autoriteetsed DNS-teenuse pakkujad ei n\u00e4e kliendi IP-aadressi ja saavad arvesse v\u00f5tta ainult rekursiivse resolveri IP-aadressi, mida klient kasutab. <\/p>\n<p>Seet\u00f5ttu peab meie autoriteetne resolver v\u00f5tma otsuse mitte \u00fcksikselle kliendi jaoks, vaid r\u00fchma klientide p\u00f5hjal rekursiivse resolveri j\u00e4rgi. <\/p>\n<p>Lahendamiseks kasutame samu proove, koondame saadud m\u00f5\u00f5tmiste tulemused klientidelt iga rekursiivse resolveri kohta ja otsustame, kuhu see r\u00fchm suunata \u2014 kas proxy kaudu IX kasutades TCP Anycast, l\u00e4bi ISP proxy v\u00f5i otse pilve.<\/p>\n<p>Me saame sellise s\u00fcsteemi:<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/ad23219938d1cb7b6eef498671c3e151.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSaadud DNS-i suunamismudel v\u00f5imaldab suunata kliente ajalooliste vaatlustelt p\u00f5hinevate \u00fchenduste kiirusest klientide ja pilve vahel. <\/p>\n<p>K\u00fcsimus on j\u00e4lle \u2014 kui efektiivselt see l\u00e4henemine t\u00f6\u00f6tab? Vastuse saamiseks kasutame j\u00e4lle meie proovide s\u00fcsteemi. Seet\u00f5ttu seadistame hilise konfiguratsiooni, kus \u00fcks sihtkoht j\u00e4rgib DNS-i suunamist, teine \u2014 l\u00e4heb otse pilve (praegune tootmine).<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/ceb2ded9367ebd0aa0ede46191a89a88.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKokkuv\u00f5ttes v\u00f5rdleme tulemusi ja saame efektiivsuse hinnangu:<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/ca0db88461d5f2cb0f3f7c07eae14f10.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKokkuv\u00f5tteks saime teada mitu olulist asja:<\/p>\n<ol>\n<li>Hindasime oodatavat p\u00e4ringute j\u00f5udlust klientidest pilve kasutades DNS-i suunamist.<\/li>\n<li>Saime andmeid t\u00f5elistelt klientidelt, k\u00f5ikide seadme t\u00fc\u00fcpide kohta.<\/li>\n<li>T\u00f5estasime pakutud idee efektiivsust.<\/li>\n<li>Me ei riskinud - ei muutnud tootmisconfiguratsiooni klientide jaoks.<\/li>\n<li>Me ei rikkunud midagi.<\/li>\n<\/ol>\n<p><\/p>\n<h2>N\u00fc\u00fcd keerulisest osast \u2014 k\u00e4ivitame tootmises.<\/h2>\n<p>\nKergem osa on n\u00fc\u00fcd selja taga \u2014 meil on t\u00f6\u00f6tav protot\u00fc\u00fcp. N\u00fc\u00fcd on keeruline osa \u2014 rakendada lahendus kogu Netflixi liikluse jaoks, kasutades 150 miljoni kasutaja, tuhandete seadmete, sadade mikroteenuste ja pidevalt muutuva toote ning infrastruktuuri jaoks. Netflixi serveritesse j\u00f5uab miljoneid p\u00e4ringuid sekundis ja meie teenust on lihtne rikkuda \u00fchesuguse tegevusega. Samuti soovime suunata liiklust d\u00fcnaamiliselt l\u00e4bi tuhandete CDN serverite, internetis, kus k\u00f5ik muutub ja katki l\u00e4heb pidevalt ja k\u00f5ige ebasobivamal hetkel. <\/p>\n<p>Ja k\u00f5ik see ajal on meeskonnas 3 inseneri, kes vastutavad s\u00fcsteemi arendamise, juurutamise ja t\u00e4ieliku toe eest.<\/p>\n<p>Seet\u00f5ttu r\u00e4\u00e4gime edasi rahulikust ja tervislikust unest.<\/p>\n<p>Kuidas j\u00e4tkata arendamist, mitte kulutada kogu aega toe pakkumisele? Meie l\u00e4henemise aluseks on 3 p\u00f5him\u00f5tet:<\/p>\n<ol>\n<li>V\u00e4hendame potentsiaalsete rikke ulatust (blast radius). <\/li>\n<li>Oleme valmis \u00fcllatusteks \u2014 ootame, et midagi l\u00e4heb katki, vaatamata testimisele ja isiklikule kogemusele.<\/li>\n<li>Aeglane degradeerumine (graceful degradation) \u2014 kui midagi ei t\u00f6\u00f6ta \u00f5igesti, peaks see automaatselt korda minema, ehkki mitte k\u00f5ige t\u00f5husamal viisil.<\/li>\n<\/ol>\n<p>\nSelgus, et meie puhul, sellise probleemi k\u00e4sitlemise l\u00e4henemisega, on v\u00f5imalik leida lihtne ja t\u00f5hus lahendus ning oluliselt lihtsustada s\u00fcsteemi hooldust. Meie m\u00f5istsime, et saame klienti lisada v\u00e4ikese koodil\u00f5igu ja j\u00e4lgida v\u00f5rgu p\u00e4ringute vigu, mis on p\u00f5hjustatud \u00fchendusprobleemidest. Vera v\u00f5rgu vigade korral teeme otsese fallback lahenduse pilve. Selline lahendus ei n\u00f5ua kliendi meeskondadelt suuri pingutusi, kuid v\u00e4hendab oluliselt ootamatute rikke ja \u00fcllatuste riski meie jaoks.<\/p>\n<p>Muidugi, hoolimata fallback lahendusest, j\u00e4rgime siiski ranget distsipliini arendamise k\u00e4igus:<\/p>\n<ol>\n<li>Proovide testimine.<\/li>\n<li>A\/B testimine v\u00f5i Canary testimine.<\/li>\n<li>Aeglane vabastamine (progressive rollout).<\/li>\n<\/ol>\n<p>\nProovide osas on l\u00e4henemine kirjeldatud \u2014 muudatused testitakse k\u00f5igepealt seadistatud retsepti abil.<\/p>\n<p>Canary testimiseks peame saama v\u00f5rreldavad serveripaarid, millel saab v\u00f5rrelda, kuidas s\u00fcsteem t\u00f6\u00f6tab enne ja p\u00e4rast muudatusi. Selleks valime meie arvukatest CDN saitidest serveripaarid, millel on sarnane liiklus:<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/eef504f5c81aa985b78339fd5f913d14.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSeej\u00e4rel paneme muudatuste kogumi Canary-serveritesse. Tulemuste hindamiseks k\u00e4ivitame s\u00fcsteemi, mis v\u00f5rdleb umbes 100-150 m\u00f5\u00f5dikut Control-serveritega:<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/898edb0a5bd493d6ef228cd116c1a939.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKui Canary-testimine on edukas, teeme avalikkusele viidatud v\u00e4ljaande j\u00e4rk-j\u00e4rgult. Igal veebisaidil ei uuenda me servereid korraga \u2014 \u00fchte veebisaiti kaotades p\u00f5hjustab probleem palju suuremat m\u00f5ju kasutajate teenusele kui sama arvu serverite kadumine, kuid erinevates kohtades.<\/p>\n<p>\u00dcldiselt s\u00f5ltub sellise l\u00e4henemise t\u00f5husus ja ohutus kogutud m\u00f5\u00f5dikutest nii kvaliteedi kui ka koguse poolest. Meie p\u00e4ringute kiirusete s\u00fcsteemi jaoks kogume m\u00f5\u00f5dikud k\u00f5igilt v\u00f5imalikelt komponentidelt: <\/p>\n<ul>\n<li>kliendilt \u2014 seansside ja p\u00e4ringute arv, tagasimakse m\u00e4\u00e4r; <\/li>\n<li>proksi \u2014 p\u00e4ringute arvu ja aja statistika;<\/li>\n<li>DNS \u2014 p\u00e4ringute arv ja tulemused;<\/li>\n<li>cloud edge \u2014 p\u00e4ringute t\u00f6\u00f6tlemise aeg ja arv pilves.<\/li>\n<\/ul>\n<p>\nK\u00f5ik see kogutakse \u00fchte pipeline'i ja olenevalt vajadustest otsustame, millised m\u00f5\u00f5dikud saata reaalajas anal\u00fc\u00fcsiks ja millised Elasticsearchi v\u00f5i suurandmete jaoks detailsemaks diagnostikaks.<\/p>\n<h2>J\u00e4lgime<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/ff8b00b1239a20f85e96ce23c2d7c2d0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMeie juhul teeme muudatusi p\u00e4ringute kriitilisel teel kliendi ja serveri vahel. Samal ajal on kliendi, serveri ja interneti kaudu liikudes palju erinevaid komponente. Kliendis ja serveris toimuvaid muudatusi on pidevalt \u2014 k\u00fcmnete meeskondade t\u00f6\u00f6 ja \u00f6kos\u00fcsteemi loomulike muutuste tulemusena. Me oleme keskel \u2014 probleemide diagnoosimisel on suur t\u00f5en\u00e4osus, et osaleme selles. Seet\u00f5ttu peame selgelt m\u00f5istma, kuidas m\u00e4\u00e4rata, koguda ja anal\u00fc\u00fcsida m\u00f5\u00f5dikuid probleemide kiireks lokaliseerimiseks. <\/p>\n<p>Ideaalis on meil t\u00e4ielik juurdep\u00e4\u00e4s k\u00f5igile m\u00f5\u00f5dikut\u00fc\u00fcpidele ja filtritele reaalajas. Kuid m\u00f5\u00f5dikuid on v\u00e4ga palju, seet\u00f5ttu tekib kulude k\u00fcsimus. Meie juhul jagame m\u00f5\u00f5dikud ja arendusvahendid j\u00e4rgmisteks:<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/0b4a15776f3b44331652adc14ea87390.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nProbleemide avastamiseks ja triage'iks kasutame oma avatud l\u00e4htekoodiga reaalajas s\u00fcsteemi <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Netflix\/atlas\">Atlas<\/a><\/noindex> ja <noindex><a rel=\"nofollow\" href=\"https:\/\/netflixtechblog.com\/lumen-custom-self-service-dashboarding-for-netflix-8c56b541548c\">Lumen<\/a><\/noindex> \u2014 visualiseerimiseks. See hoiab m\u00e4lus kogutud m\u00f5\u00f5dikud, on usaldusv\u00e4\u00e4rne ja integreerub h\u00e4irete s\u00fcsteemiga. Lokaliseerimise ja diagnostika jaoks on meil juurdep\u00e4\u00e4s logidele Elasticsearchis ja Kibanasse. Statistiliseks anal\u00fc\u00fcsiks ja modelleerimiseks kasutame suurandmeid ja visualiseerimist Tableau's.<\/p>\n<p>Tundub, et sellise l\u00e4henemisega on v\u00e4ga keeruline t\u00f6\u00f6tada. Kuid hierarhilise m\u00f5\u00f5dikute ja t\u00f6\u00f6riistade organisatsiooni korral saame probleemi kiiresti anal\u00fc\u00fcsida, probleemi t\u00fc\u00fcbi m\u00e4\u00e4rata ja seej\u00e4rel s\u00fcveneda detailsetesse m\u00f5\u00f5dikutesse. Veakohte tuvastamiseks kulutame keskmiselt umbes 1-2 minutit. P\u00e4rast seda tegeleme juba konkreetse meeskonnaga diagnostikaga - alates k\u00fcmnetest minutidest kuni mitme tunnini.<\/p>\n<p>Isegi kui diagnostikat tehakse kiiresti, ei soovi me, et see juhtuks tihti. Ideaalses olukorras saame kriitilise teate ainult siis, kui teenusele on m\u00e4rkimisv\u00e4\u00e4rne m\u00f5ju. Meie p\u00e4ringute kiirendamise s\u00fcsteemis on meil vaid 2 alerta, mis aitavad meid teavitada:<\/p>\n<ul>\n<li>Client Fallback protsent - kliendik\u00e4itumise hindamine;<\/li>\n<li>Probe errorite protsent - andmed v\u00f5rgu komponentide stabiilsusest.<\/li>\n<\/ul>\n<p>\nNeed kriitilised alertid j\u00e4lgivad, kas s\u00fcsteem t\u00f6\u00f6tab enamikule kasutajatest. Me vaatame, kui palju kliente kasutas fallback'i, kui nad ei suutnud p\u00e4ringute kiirendust saada. Meil on keskmiselt v\u00e4hem kui 1 kriitiline teade n\u00e4dalas, kuigi s\u00fcsteemis toimub tohutult muudatusi. Miks piisab meile sellest?<\/p>\n<ol>\n<li>On olemas client fallback juhul, kui meie proxy ei t\u00f6\u00f6ta.<\/li>\n<li>On automaatne steering s\u00fcsteem, mis reageerib probleemidele.<\/li>\n<\/ol>\n<p>\nViimase kohta natuke rohkem. Meie s\u00fcsteemid, mis teevad proove, ja automaatne parima marsruudi m\u00e4\u00e4ramise s\u00fcsteem kliendi p\u00e4ringute jaoks pilve, v\u00f5imaldavad automaatselt teatud probleemidega toime tulla. <\/p>\n<p>Naaseme meie proovis\u00fcsteemi ja 3 marsruudi kategooria juurde. Lisaks laadimisaegadele saame vaadata ka andmete kohaletoimetamise fakti. Kui andmeid ei \u00f5nnestu laadida, saame vaadata erinevate marsruutide tulemusi ja m\u00e4\u00e4rata, kus ja mis on katki, ning kas saame seda automaatselt parandada, muutes p\u00e4ringu marsruuti.<\/p>\n<p>N\u00e4ited:<\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/7d935da82aaca53af87f05fbdf215c4c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/f74ef9d3de953099921a68fbc65cb187.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/3c77cbd47813d3320efbf339a0690c53.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSeda protsessi on v\u00f5imalik automatiseerida. Sisse l\u00fclitada steering s\u00fcsteemi. Ja \u00f5petada seda reageerima j\u00f5udluse ja usaldusv\u00e4\u00e4rsuse probleemidele. Kui midagi hakkab lagunema - reageerida, kui on parem v\u00f5imalus. Samal ajal pole kohene reageerimine kriitiline, t\u00e4nu fallback'ile klientidele.<\/p>\n<p>Seega, s\u00fcsteemi toetamise p\u00f5him\u00f5tted v\u00f5iks kokku v\u00f5tta j\u00e4rgmiselt:<\/p>\n<ul>\n<li>v\u00e4hendame rikke ulatust;<\/li>\n<li>kogume m\u00f5\u00f5dikud;<\/li>\n<li>parandame rikkeid automaatselt, kui saame;<\/li>\n<li>kui ei suuda - teavitame;<\/li>\n<li>T\u00f6\u00f6tame dashboards'i ja triage-t\u00f6\u00f6riistade kallal kiireks reageerimiseks.<\/li>\n<\/ul>\n<p><\/p>\n<h2>\u00d5pitud \u00f5ppetunnid<\/h2>\n<p>\nProtot\u00fc\u00fcbi kirjutamiseks ei kulu palju aega. Meie puhul oli see valmis juba 4 kuu p\u00e4rast. Sellega saime uusi m\u00f5\u00f5dikuid ja 10 kuu m\u00f6\u00f6dudes arenduse algusest said valminud esimesed production liiklusandmed. Siis algas igav ja v\u00e4ga keeruline t\u00f6\u00f6: j\u00e4rkj\u00e4rguline tootmine ja s\u00fcsteemi skaleerimine, p\u00f5hilise liikluse migratsioon ja \u00f5ppimine vigadest. Samas ei toimu see efektiivne protsess lineaarselt \u2014 hoolimata k\u00f5igist pingutustest ei saa k\u00f5ike ette ennustada. Oluliselt t\u00f5husam on kiire iteratsioon ja reageerimine uutele andmetele. <\/p>\n<p><img decoding=\"async\" alt=\"Kiirendame internetip\u00e4ringuid ja magame rahulikult\" src=\"\/wp-content\/uploads\/2020\/06\/c9c182a1a4fa048b1f1b2a82a4db65e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMeie kogemusest saame soovitada j\u00e4rgmist:<\/p>\n<ol>\n<li>\u00c4rge uskuge oma intuitsiooni.\n<p>Meie intuitsioon on meid pidevalt alt vedanud, hoolimata meie meeskonna liikmete suurest kogemusest. N\u00e4iteks ennustasime valesti oodatavat kiirus\u00fchet CDN-prokside kasutamisest v\u00f5i TCP Anycast'i k\u00e4itumist.<\/li>\n<li>Hankige andmed production'ist.\n<p>Oluline on v\u00f5imalikult kiiresti saada ligip\u00e4\u00e4s v\u00e4hemalt v\u00e4ikesele hulgale production andmetele. Ainult laboratoorses keskkonnas on peaaegu v\u00f5imatu saada unikaalsete juhtumite, konfiguratsioonide ja seadetega. Kiire ligip\u00e4\u00e4s tulemustele v\u00f5imaldab kiiremini teada saada potentsiaalsetest probleemidest ja arvestada nendega s\u00fcsteemi arhitektuuris.<\/li>\n<li>\u00c4rge j\u00e4rgige teiste n\u00f5uandeid ja tulemusi \u2014 koguge oma andmeid.\n<p>J\u00e4rgige andmete kogumise ja anal\u00fc\u00fcsimise printsiipe, kuid \u00e4rge v\u00f5tke pimesi teiste tulemusi ja v\u00e4iteid. Ainult teie saate t\u00e4pselt teada, mis teie kasutajatele t\u00f6\u00f6tab. Teie s\u00fcsteemid ja teie kliendid v\u00f5ivad oluliselt erineda teistest ettev\u00f5tetest. T\u00e4nu sellele, et anal\u00fc\u00fcsit\u00f6\u00f6riistad on praegu kergesti k\u00e4ttesaadavad ja kasutatavad. Teie saadud tulemused v\u00f5ivad erineda sellest, mida v\u00e4idavad Netflix, Facebook, Akamai ja teised ettev\u00f5tted. Meie puhul on TLS-i, HTTP2 v\u00f5i DNS-i p\u00e4ringute statistika tulemus erinev Facebooki, Uberi, Akamai tulemustest \u2014 sest meil on erinevad seadmed, kliendid ja andmevood.<\/li>\n<li>\u00c4rge p\u00fc\u00fcdke j\u00e4rgida moe trende ilma vajaduse ja efektiivsuse hindamiseta.\n<p>Alustage lihtsalt. Paremini on luua lihtne ja toimiv s\u00fcsteem l\u00fchikese aja jooksul, kui kulutada tohutult aega teile vajalikest komponentidest loobumisele. Lahendage probleeme ja k\u00fcsimusi, mis on teie m\u00f5\u00f5tmiste ja tulemuste p\u00f5hjal olulised. <\/li>\n<li>Valmistuge uute rakenduste jaoks.\n<p>Nagu on keeruline ette n\u00e4ha k\u00f5iki probleeme, on keeruline ka ette ennustada eeliseid ja rakendusi. V\u00f5tke \u00f5ppust start-up\u2019idest \u2014 nende v\u00f5ime kohaneda klientide n\u00f5udmistega. Teie puhul \u2014 v\u00f5ite avastada uusi probleeme ja nende lahendusi. Meie projektis seadsime eesm\u00e4rgiks v\u00e4hendada p\u00e4ringute latentsust. Kuid anal\u00fc\u00fcsi ja arutelude k\u00e4igus m\u00f5istsime, et saame kasutada ka proxiservereid:<\/p>\n<ul>\n<li>liiklusbalansseeringuks AWS piirkondade vahel ja kulude v\u00e4hendamiseks;<\/li>\n<li>CDN stabiilsuse modelleerimiseks;<\/li>\n<li>DNS-i konfigureerimiseks;<\/li>\n<li>TLS\/TCP konfigureerimiseks.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p><\/p>\n<h2>Kokkuv\u00f5te<\/h2>\n<p>\nMinu ettekandes kirjeldasin, kuidas Netflix lahendab klientide ja pilve vaheliste internetip\u00e4ringute kiirendamise \u00fclesande. Kuidas me kogume andmeid klientide kaudu proovide s\u00fcsteemi abil ja kasutame kogutud ajaloolisi andmeid, et suunata tootmisp\u00e4ringud klientidelt k\u00f5ige kiirema marsruudi kaudu internetis. Kuidas me rakendame v\u00f5rguprotokollide t\u00f6\u00f6p\u00f5him\u00f5tteid, meie CDN infrastruktuuri, selgroogv\u00f5rku ja DNS servereid, et seda \u00fclesannet t\u00e4ita.<\/p>\n<p>Siiski, meie lahendus on vaid n\u00e4idis sellest, kuidas me Netflixis sellist s\u00fcsteemi rakendasime. Mis t\u00f6\u00f6tas meie jaoks. Minu ettekande praktiline osa teie jaoks \u2014 arendamise ja toetamise p\u00f5him\u00f5tted, mida j\u00e4rgime ja millega saavutame h\u00e4id tulemusi.<\/p>\n<p>Meie probleemilahendus v\u00f5ib teile mitte sobida. Siiski j\u00e4\u00e4vad teooria ja arendamise p\u00f5him\u00f5tted kehtima, isegi kui teil ei ole oma CDN infrastruktuuri v\u00f5i kui see erineb oluliselt meie omast. <\/p>\n<p>Oluline on ka p\u00e4ringute kiirus \u00e4rile. Isegi lihtsa teenuse puhul tuleb teha valik: 'pilve' pakkujate, serverite asukoha, CDN ja DNS pakkujate vahel. Teie valik m\u00f5jutab internetip\u00e4ringute efektiivsust teie klientide jaoks. Ja teie jaoks on oluline seda m\u00f5ju m\u00f5\u00f5ta ja m\u00f5ista.<\/p>\n<p>Alustage lihtsate lahendustega, muretsege, kuidas te toodet muudate. \u00d5ppige protsessi k\u00e4igus ja t\u00e4iustage s\u00fcsteemi, l\u00e4htudes teie klientide, teie infrastruktuuri ja teie \u00e4ri andmetest. M\u00f5elge v\u00f5imalikele ootamatutele rikkele disainimise k\u00e4igus. Ja siis suudate kiirendada oma arendusprotsessi, parandada lahenduse efektiivsust, v\u00e4ltida liigset koormust toetusele ja rahulikult magada.<\/p>\n<blockquote><p>Sel aastal <noindex><a rel=\"nofollow\" href=\"http:\/\/devoops-moscow.ru\/?utm_source=habr&amp;utm_medium=506106\">toimub konverents 6. kuni 10. juulini<\/a><\/noindex> veebivormis. Sa saad esitada k\u00fcsimusi DevOps'i \u00fchele isale, John Willis'ile!<\/p><\/blockquote>\n<p>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/jugru\/blog\/506106\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u0441\u043e\u0437\u0434\u0430\u0432\u0448\u0430\u044f \u0438 \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0449\u0430\u044f \u044d\u0442\u043e\u0442 \u0441\u0435\u0433\u043c\u0435\u043d\u0442. Netflix \u0438\u0437\u0432\u0435\u0441\u0442\u0435\u043d \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043e\u0431\u0448\u0438\u0440\u043d\u044b\u043c \u043a\u0430\u0442\u0430\u043b\u043e\u0433\u043e\u043c \u043a\u0438\u043d\u043e \u0438 \u0441\u0435\u0440\u0438\u0430\u043b\u043e\u0432, \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0445 \u0441 \u043f\u043e\u0447\u0442\u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0433\u043e\u043b\u043a\u0430 \u043f\u043b\u0430\u043d\u0435\u0442\u044b \u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u0441 \u0434\u0438\u0441\u043f\u043b\u0435\u0435\u043c, \u043d\u043e \u0438 \u043d\u0430\u0434\u0435\u0436\u043d\u043e\u0439 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u043e\u0439 \u0438 \u0443\u043d\u0438\u043a\u0430\u043b\u044c\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043d\u043e\u0439 \u043a\u0443\u043b\u044c\u0442\u0443\u0440\u043e\u0439. \u041d\u0430\u0433\u043b\u044f\u0434\u043d\u044b\u0439 \u043f\u0440\u0438\u043c\u0435\u0440 Netflix \u043f\u043e\u0434\u0445\u043e\u0434\u0430 \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u0438 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043d\u0430 DevOops 2019 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84877,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84876","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0423\u0441\u043a\u043e\u0440\u044f\u0435\u043c \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438 \u0441\u043f\u0438\u043c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-11T11:43:18+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-11T11:43:18+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Kiirendame internetip\u00e4ringuid ja magame rahulikult | ProHoster","description":"Netflix on internetitelevisiooni turuliider.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0423\u0441\u043a\u043e\u0440\u044f\u0435\u043c \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438 \u0441\u043f\u0438\u043c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e | ProHoster","og:description":"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-11T11:43:18+00:00","article:modified_time":"2020-06-11T11:43:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84876","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:48:22","updated":"2022-09-27 23:34:06","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/84876","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=84876"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/84876\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/84877"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=84876"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=84876"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=84876"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}