Pabilisin ang mga kahilingan sa internet at matulog nang mapayapa

Ang Netflix ang nangunguna sa merkado ng telebisyon sa Internet - ang kumpanyang lumikha at aktibong bumubuo ng segment na ito. Ang Netflix ay kilala hindi lamang sa malawak nitong katalogo ng mga pelikula at serye sa TV na available sa halos lahat ng sulok ng planeta at anumang device na may display, kundi pati na rin sa maaasahang imprastraktura at natatanging kultura ng engineering.

Ang isang malinaw na halimbawa ng diskarte sa Netflix sa pagbuo at pagsuporta sa mga kumplikadong sistema ay ipinakita sa DevOops 2019 Sergey Fedorov - Direktor ng Pag-unlad sa Netflix. Nagtapos ng Faculty of Computational Mathematics at Mathematics ng Nizhny Novgorod State University. Lobachevsky, Sergey isa sa mga unang inhinyero sa Open Connect - pangkat ng CDN sa Netflix. Bumuo siya ng mga system para sa pagsubaybay at pagsusuri ng data ng video, naglunsad ng isang sikat na serbisyo para sa pagtatasa ng bilis ng koneksyon sa Internet FAST.com, at sa nakalipas na ilang taon ay nagsusumikap sa pag-optimize ng mga kahilingan sa Internet upang ang Netflix na application ay gumana nang mabilis hangga't maaari para sa mga user.

Nakatanggap ang ulat ng pinakamahusay na mga pagsusuri mula sa mga kalahok sa kumperensya, at naghanda kami ng isang bersyon ng teksto para sa iyo.

Sa kanyang ulat, nagsalita si Sergei nang detalyado

• tungkol sa kung ano ang nakakaapekto sa pagkaantala ng mga kahilingan sa Internet sa pagitan ng kliyente at server;
• kung paano bawasan ang pagkaantala na ito;
• kung paano magdisenyo, magpanatili at magmonitor ng mga sistemang mapagparaya sa error;
• kung paano makamit ang mga resulta sa maikling panahon, at may kaunting panganib sa negosyo;
• kung paano pag-aralan ang mga resulta at matuto mula sa mga pagkakamali.

Ang mga sagot sa mga tanong na ito ay kailangan hindi lamang ng mga nagtatrabaho sa malalaking korporasyon.

Ang ipinakita na mga prinsipyo at pamamaraan ay dapat na malaman at gawin ng lahat na bumuo at sumusuporta sa mga produkto ng Internet.

Susunod ay ang pagsasalaysay mula sa pananaw ng tagapagsalita.

Ang kahalagahan ng bilis ng internet

Ang bilis ng mga kahilingan sa Internet ay direktang nauugnay sa negosyo. Isaalang-alang ang industriya ng pamimili: Amazon noong 2009 nagsalitana ang pagkaantala ng 100ms ay nagreresulta sa pagkawala ng 1% ng mga benta.

Parami nang parami ang mga mobile device, na sinusundan ng mga mobile site at application. Kung ang iyong pahina ay tumatagal ng higit sa 3 segundo upang ma-load, nawawala sa iyo ang halos kalahati ng iyong mga user. SA Hulyo 2018 Isinasaalang-alang ng Google ang bilis ng paglo-load ng iyong page sa mga resulta ng paghahanap: mas mabilis ang page, mas mataas ang posisyon nito sa Google.

Mahalaga rin ang bilis ng koneksyon sa mga institusyong pinansyal kung saan kritikal ang latency. Noong 2015, Hibernia Networks tapos na isang $400 milyong cable sa pagitan ng New York at London upang bawasan ang latency sa pagitan ng mga lungsod ng 6ms. Isipin ang $66 milyon para sa 1 ms ng pagbabawas ng latency!

Ayon sa pagsaliksik, ang bilis ng koneksyon sa itaas ng 5 Mbit/s ay hindi na direktang nakakaapekto sa bilis ng paglo-load ng isang tipikal na website. Gayunpaman, mayroong isang linear na ugnayan sa pagitan ng latency ng koneksyon at bilis ng paglo-load ng pahina:

Gayunpaman, ang Netflix ay hindi isang tipikal na produkto. Ang epekto ng latency at bilis sa gumagamit ay isang aktibong lugar ng pagsusuri at pag-unlad. Mayroong paglo-load ng application at pagpili ng nilalaman na nakadepende sa latency, ngunit nakadepende rin sa bilis ng koneksyon ang paglo-load ng mga static na elemento at streaming. Ang pagsusuri at pag-optimize sa mga pangunahing salik na nakakaimpluwensya sa karanasan ng gumagamit ay isang aktibong bahagi ng pag-unlad para sa ilang mga koponan sa Netflix. Isa sa mga layunin ay bawasan ang latency ng mga kahilingan sa pagitan ng mga Netflix device at ng cloud infrastructure.

Sa ulat, partikular na tututukan namin ang pagbabawas ng latency gamit ang halimbawa ng imprastraktura ng Netflix. Isaalang-alang natin mula sa isang praktikal na pananaw kung paano lapitan ang mga proseso ng disenyo, pagbuo at pagpapatakbo ng mga kumplikadong distributed system at gumugol ng oras sa pagbabago at mga resulta, kaysa sa pag-diagnose ng mga problema sa pagpapatakbo at mga breakdown.

Sa loob ng Netflix

Libu-libong iba't ibang device ang sumusuporta sa mga Netflix app. Ang mga ito ay binuo ng apat na magkakaibang koponan, na gumagawa ng magkahiwalay na bersyon ng kliyente para sa Android, iOS, TV at mga web browser. At gumugugol kami ng maraming pagsisikap sa pagpapabuti at pag-personalize ng karanasan ng user. Para magawa ito, nagpapatakbo kami ng daan-daang A/B na pagsubok nang magkatulad.

Ang pag-personalize ay sinusuportahan ng daan-daang microservice sa AWS cloud, na nagbibigay ng personalized na data ng user, query dispatch, telemetry, Big Data at Encoding. Mukhang ganito ang visualization ng trapiko:

Link sa video na may demonstrasyon (6:04-6:23)

Sa kaliwa ay ang entry point, at pagkatapos ay ibinahagi ang trapiko sa ilang daang microservice na sinusuportahan ng iba't ibang backend team.

Ang isa pang mahalagang bahagi ng aming imprastraktura ay ang Open Connect CDN, na naghahatid ng static na content sa end user - mga video, larawan, client code, atbp. Ang CDN ay matatagpuan sa mga custom na server (OCA - Open Connect Appliance). Sa loob ay may mga array ng SSD at HDD drive na tumatakbo sa optimized na FreeBSD, na may NGINX at isang set ng mga serbisyo. Kami ay nagdidisenyo at nag-o-optimize ng mga bahagi ng hardware at software upang ang naturang CDN server ay makapagpadala ng mas maraming data hangga't maaari sa mga user.

Ang "pader" ng mga server na ito sa Internet traffic exchange point (Internet eXchange - IX) ay ganito ang hitsura:

Nagbibigay ang Internet Exchange ng kakayahan para sa mga Internet service provider at content provider na "kumonekta" sa isa't isa upang mas direktang makipagpalitan ng data sa Internet. Mayroong humigit-kumulang 70-80 Internet Exchange point sa buong mundo kung saan naka-install ang aming mga server, at independiyente naming ini-install at pinapanatili ang mga ito:

Bilang karagdagan, nagbibigay din kami ng mga server nang direkta sa mga tagapagbigay ng Internet, na kanilang ini-install sa kanilang network, pagpapabuti ng lokalisasyon ng trapiko sa Netflix at ang kalidad ng streaming para sa mga gumagamit:

Ang isang hanay ng mga serbisyo ng AWS ay responsable para sa pagpapadala ng mga kahilingan sa video mula sa mga kliyente patungo sa mga server ng CDN, pati na rin ang pag-configure ng mga server mismo - pag-update ng nilalaman, code ng programa, mga setting, atbp. Para sa huli, bumuo din kami ng backbone network na nag-uugnay sa mga server sa mga Internet Exchange point sa AWS. Ang backbone network ay isang pandaigdigang network ng mga fiber optic cable at router na maaari naming idisenyo at i-configure batay sa aming mga pangangailangan.

Sa Mga pagtatantya ng Sandvine, ang aming imprastraktura ng CDN ay naghahatid ng humigit-kumulang ⅛ ng trapiko sa Internet sa mundo sa mga oras ng kasaganaan at ⅓ ng trapiko sa North America, kung saan ang Netflix ay naging pinakamatagal. Kahanga-hangang mga numero, ngunit para sa akin ang isa sa mga pinakakahanga-hangang tagumpay ay ang buong sistema ng CDN ay binuo at pinananatili ng isang pangkat na wala pang 150 katao.

Sa una, ang imprastraktura ng CDN ay idinisenyo upang maghatid ng data ng video. Gayunpaman, sa paglipas ng panahon napagtanto namin na magagamit din namin ito para i-optimize ang mga dynamic na kahilingan mula sa mga kliyente sa AWS cloud.

Tungkol sa Internet acceleration

Ngayon, ang Netflix ay may 3 AWS na rehiyon, at ang latency ng mga kahilingan sa cloud ay depende sa kung gaano kalayo ang customer mula sa pinakamalapit na rehiyon. Kasabay nito, mayroon kaming maraming mga server ng CDN na ginagamit upang maghatid ng static na nilalaman. Mayroon bang anumang paraan upang magamit ang balangkas na ito upang mapabilis ang mga dynamic na query? Gayunpaman, sa kasamaang-palad, imposibleng i-cache ang mga kahilingang ito - ang mga API ay isinapersonal at ang bawat resulta ay natatangi.

Gumawa tayo ng proxy sa CDN server at magsimulang magpadala ng trapiko sa pamamagitan nito. Ito ba ay magiging mas mabilis?

materyal

Tandaan natin kung paano gumagana ang mga protocol ng network. Ngayon, karamihan sa trapiko sa Internet ay gumagamit ng mga HTTP, na nakadepende sa mas mababang layer ng mga protocol na TCP at TLS. Upang makakonekta ang isang kliyente sa server, nagsasagawa ito ng pakikipagkamay, at upang makapagtatag ng isang secure na koneksyon, ang kliyente ay kailangang makipagpalitan ng mga mensahe sa server nang tatlong beses at hindi bababa sa isang beses pa upang maglipat ng data. Sa latency per round trip (RTT) na 100 ms, aabutin kami ng 400 ms upang matanggap ang unang bit ng data:

Kung ilalagay namin ang mga sertipiko sa server ng CDN, ang oras ng pakikipagkamay sa pagitan ng kliyente at ng server ay maaaring makabuluhang bawasan kung mas malapit ang CDN. Ipagpalagay natin na ang latency sa CDN server ay 30ms. Pagkatapos ay aabutin ng 220 ms upang matanggap ang unang bit:

Ngunit ang mga pakinabang ay hindi nagtatapos doon. Kapag naitatag na ang isang koneksyon, pinapataas ng TCP ang window ng congestion (ang dami ng impormasyong maipapadala nito sa koneksyon na iyon nang magkatulad). Kung nawala ang isang data packet, ang mga klasikong pagpapatupad ng TCP protocol (tulad ng TCP New Reno) ay babawasan ng kalahati ang bukas na "window". Ang paglaki ng window ng congestion, at ang bilis ng pagbawi nito mula sa pagkawala muli ay nakasalalay sa pagkaantala (RTT) sa server. Kung hanggang sa CDN server lang ang koneksyong ito, magiging mas mabilis ang pagbawi na ito. Kasabay nito, ang pagkawala ng packet ay isang karaniwang kababalaghan, lalo na para sa mga wireless network.

Maaaring bawasan ang bandwidth ng internet, lalo na sa mga oras ng kasiyahan, dahil sa trapiko mula sa mga user, na maaaring humantong sa mga traffic jam. Gayunpaman, walang paraan sa Internet na bigyang-priyoridad ang ilang kahilingan kaysa sa iba. Halimbawa, bigyang-priyoridad ang maliliit at latency-sensitive na mga kahilingan kaysa sa "mabibigat" na stream ng data na naglo-load sa network. Gayunpaman, sa aming kaso, ang pagkakaroon ng aming sariling backbone network ay nagpapahintulot sa amin na gawin ito sa bahagi ng landas ng kahilingan - sa pagitan ng CDN at ng cloud, at maaari naming ganap na i-configure ito. Maaari mong tiyakin na ang maliliit at latency-sensitive na mga packet ay binibigyang-priyoridad, at ang malalaking daloy ng data ay napupunta sa ibang pagkakataon. Kung mas malapit ang CDN sa kliyente, mas malaki ang kahusayan.

Ang mga protocol sa antas ng aplikasyon (OSI Level 7) ay mayroon ding epekto sa latency. Ang mga bagong protocol tulad ng HTTP/2 ay nag-o-optimize sa pagganap ng mga parallel na kahilingan. Gayunpaman, mayroon kaming mga kliyente ng Netflix na may mga mas lumang device na hindi sumusuporta sa mga bagong protocol. Hindi lahat ng kliyente ay maaaring ma-update o mahusay na i-configure. Kasabay nito, sa pagitan ng CDN proxy at ng cloud ay mayroong kumpletong kontrol at kakayahang gumamit ng bago, pinakamainam na mga protocol at setting. Ang hindi epektibong bahagi na may mga lumang protocol ay gagana lamang sa pagitan ng kliyente at ng CDN server. Bukod dito, maaari kaming gumawa ng mga multiplex na kahilingan sa isang naitatag nang koneksyon sa pagitan ng CDN at cloud, na nagpapahusay sa paggamit ng koneksyon sa antas ng TCP:

Sinusukat namin

Sa kabila ng katotohanan na ang teorya ay nangangako ng mga pagpapabuti, hindi kami kaagad nagmamadali upang ilunsad ang sistema sa produksyon. Sa halip, kailangan muna nating patunayan na ang ideya ay gagana sa pagsasanay. Upang gawin ito, kailangan mong sagutin ang ilang mga katanungan:

• bilis: mas mabilis ba ang proxy?
• Pagkamaaasahan: Mas madalas ba itong masira?
• Kahirapan: paano isama sa mga application?
• Gastos: Magkano ang gastos sa pag-deploy ng karagdagang imprastraktura?

Isaalang-alang natin nang detalyado ang ating diskarte sa pagtatasa ng unang punto. Ang natitira ay hinarap sa katulad na paraan.

Upang pag-aralan ang bilis ng mga kahilingan, gusto naming makakuha ng data para sa lahat ng mga user, nang hindi gumugugol ng maraming oras sa pag-develop at nang hindi sinisira ang produksyon. Mayroong ilang mga diskarte para dito:

1. RUM, o passive na pagsukat ng kahilingan. Sinusukat namin ang oras ng pagpapatupad ng mga kasalukuyang kahilingan mula sa mga user at tinitiyak namin ang buong saklaw ng user. Ang kawalan ay ang signal ay hindi masyadong matatag dahil sa maraming mga kadahilanan, halimbawa, dahil sa iba't ibang laki ng kahilingan, oras ng pagproseso sa server at kliyente. Bilang karagdagan, hindi mo maaaring subukan ang isang bagong configuration nang walang epekto sa produksyon.
2. Mga pagsubok sa laboratoryo. Mga espesyal na server at imprastraktura na ginagaya ang mga kliyente. Sa kanilang tulong isinasagawa namin ang mga kinakailangang pagsubok. Sa ganitong paraan makakakuha tayo ng ganap na kontrol sa mga resulta ng pagsukat at isang malinaw na signal. Ngunit walang kumpletong saklaw ng mga device at lokasyon ng user (lalo na sa pandaigdigang serbisyo at suporta para sa libu-libong modelo ng device).

Paano mo pagsasamahin ang mga pakinabang ng parehong pamamaraan?

Nakahanap ng solusyon ang aming team. Sumulat kami ng isang maliit na piraso ng code - isang sample - na binuo namin sa aming aplikasyon. Nagbibigay-daan sa amin ang mga probe na gumawa ng ganap na kontroladong mga pagsubok sa network mula sa aming mga device. Ito ay gumagana tulad nito:

1. Di-nagtagal pagkatapos i-load ang application at kumpletuhin ang paunang aktibidad, pinapatakbo namin ang aming mga probe.
2. Gumagawa ang kliyente ng kahilingan sa server at tumatanggap ng "recipe" para sa pagsubok. Ang recipe ay isang listahan ng mga URL kung saan kailangang gumawa ng HTTP (mga) kahilingan. Bilang karagdagan, kino-configure ng recipe ang mga parameter ng kahilingan: mga pagkaantala sa pagitan ng mga kahilingan, dami ng hiniling na data, (mga) header ng HTTP, atbp. Kasabay nito, maaari naming subukan ang ilang magkakaibang mga recipe nang magkatulad - kapag humihiling ng isang pagsasaayos, random naming tinutukoy kung aling recipe ang ilalabas.
3. Ang oras ng paglunsad ng probe ay pinili upang hindi sumalungat sa aktibong paggamit ng mga mapagkukunan ng network sa kliyente. Mahalaga, ang oras ay pinili kapag ang kliyente ay hindi aktibo.
4. Pagkatapos matanggap ang recipe, ang kliyente ay gumagawa ng mga kahilingan sa bawat isa sa mga URL, nang magkatulad. Ang kahilingan sa bawat isa sa mga address ay maaaring ulitin - ang tinatawag na. "mga pulso". Sa unang pulso, sinusukat namin kung gaano katagal bago magtatag ng koneksyon at mag-download ng data. Sa pangalawang pulso, sinusukat namin ang oras na kinakailangan upang mai-load ang data sa isang naitatag nang koneksyon. Bago ang pangatlo, maaari tayong magtakda ng pagkaantala at sukatin ang bilis ng muling pagkonekta, atbp.

   Sa panahon ng pagsubok, sinusukat namin ang lahat ng mga parameter na maaaring makuha ng device:

   • Oras ng paghiling ng DNS;
   • oras ng pag-setup ng koneksyon sa TCP;
   • Oras ng pag-setup ng koneksyon sa TLS;
   • oras ng pagtanggap ng unang byte ng data;
   • kabuuang oras ng paglo-load;
   • code ng resulta ng katayuan.
5. Matapos makumpleto ang lahat ng mga pulso, nilo-load ng sample ang lahat ng mga sukat para sa pagsusuri.

Ang mga pangunahing punto ay kaunting pag-asa sa lohika sa kliyente, pagproseso ng data sa server at ang pagsukat ng mga parallel na kahilingan. Kaya, nagagawa naming ihiwalay at subukan ang impluwensya ng iba't ibang salik na nakakaapekto sa pagganap ng query, pag-iba-iba ang mga ito sa loob ng isang recipe, at makakuha ng mga resulta mula sa mga tunay na kliyente.

Ang imprastraktura na ito ay napatunayang kapaki-pakinabang para sa higit pa sa pagsusuri ng pagganap ng query. Sa kasalukuyan, mayroon kaming 14 na aktibong recipe, higit sa 6000 sample bawat segundo, na tumatanggap ng data mula sa lahat ng sulok ng mundo at buong saklaw ng device. Kung ang Netflix ay bumili ng katulad na serbisyo mula sa isang ikatlong partido, ito ay nagkakahalaga ng milyun-milyong dolyar sa isang taon, na may mas masahol na saklaw.

Teorya ng pagsubok sa pagsasanay: prototype

Sa ganoong sistema, nagawa naming suriin ang pagiging epektibo ng mga proxy ng CDN sa latency ng kahilingan. Ngayon ay kailangan mo:

• lumikha ng proxy prototype;
• ilagay ang prototype sa isang CDN;
• matukoy kung paano idirekta ang mga kliyente sa isang proxy sa isang partikular na server ng CDN;
• Ihambing ang pagganap sa mga kahilingan sa AWS nang walang proxy.

Ang gawain ay suriin ang pagiging epektibo ng iminungkahing solusyon sa lalong madaling panahon. Pinili namin ang Go para ipatupad ang prototype dahil sa pagkakaroon ng magagandang networking library. Sa bawat CDN server, na-install namin ang prototype proxy bilang isang static na binary upang mabawasan ang mga dependency at pasimplehin ang pagsasama. Sa paunang pagpapatupad, gumamit kami ng mga karaniwang bahagi hangga't maaari at maliliit na pagbabago para sa pagsasama-sama ng koneksyon sa HTTP/2 at paghiling ng multiplexing.

Upang balansehin ang pagitan ng mga rehiyon ng AWS, gumamit kami ng isang geographic na DNS database, ang parehong ginamit upang balansehin ang mga kliyente. Upang pumili ng CDN server para sa kliyente, ginagamit namin ang TCP Anycast para sa mga server sa Internet Exchange (IX). Sa opsyong ito, gumagamit kami ng isang IP address para sa lahat ng CDN server, at ang kliyente ay ididirekta sa CDN server na may pinakamababang bilang ng mga IP hop. Sa mga CDN server na naka-install ng mga Internet provider (ISP), wala kaming kontrol sa router para i-configure ang TCP Anycast, kaya ginagamit namin parehong lohika, na nagdidirekta sa mga customer sa mga Internet provider para sa video streaming.

Kaya, mayroon kaming tatlong uri ng mga path ng kahilingan: sa cloud sa pamamagitan ng bukas na Internet, sa pamamagitan ng CDN server sa IX, o sa pamamagitan ng CDN server na matatagpuan sa isang Internet provider. Ang aming layunin ay maunawaan kung aling paraan ang mas mahusay, at ano ang pakinabang ng isang proxy, kumpara sa kung paano ipinapadala ang mga kahilingan sa produksyon. Upang gawin ito, gumagamit kami ng sampling system tulad ng sumusunod:

Ang bawat isa sa mga landas ay nagiging isang hiwalay na target, at tinitingnan namin ang oras na nakuha namin. Para sa pagsusuri, pinagsama namin ang mga resulta ng proxy sa isang pangkat (piliin ang pinakamahusay na oras sa pagitan ng IX at ISP na mga proxy), at ihambing ang mga ito sa oras ng mga kahilingan sa cloud nang walang proxy:

Tulad ng nakikita mo, ang mga resulta ay halo-halong - sa karamihan ng mga kaso ang proxy ay nagbibigay ng isang mahusay na bilis, ngunit mayroon ding isang sapat na bilang ng mga kliyente kung saan ang sitwasyon ay lalala nang malaki.

Bilang resulta, gumawa kami ng ilang mahahalagang bagay:

1. Sinuri namin ang inaasahang pagganap ng mga kahilingan mula sa mga kliyente hanggang sa cloud sa pamamagitan ng isang proxy ng CDN.
2. Nakatanggap kami ng data mula sa mga tunay na kliyente, mula sa lahat ng uri ng device.
3. Napagtanto namin na ang teorya ay hindi 100% nakumpirma at ang paunang alok na may CDN proxy ay hindi gagana para sa amin.
4. Hindi kami nakipagsapalaran - hindi namin binago ang mga configuration ng produksyon para sa mga kliyente.
5. Walang nasira.

Prototype 2.0

Kaya, bumalik sa drawing board at ulitin muli ang proseso.

Ang ideya ay sa halip na gumamit ng 100% proxy, tutukuyin namin ang pinakamabilis na landas para sa bawat kliyente, at magpapadala kami ng mga kahilingan doon - iyon ay, gagawin namin ang tinatawag na client steering.

Paano ito ipatupad? Hindi kami maaaring gumamit ng lohika sa panig ng server, dahil... Ang layunin ay kumonekta sa server na ito. Kailangang may ilang paraan upang gawin ito sa kliyente. At sa isip, gawin ito sa isang minimum na halaga ng kumplikadong lohika, upang hindi malutas ang isyu ng pagsasama sa isang malaking bilang ng mga platform ng kliyente.

Ang sagot ay gumamit ng DNS. Sa aming kaso, mayroon kaming sariling imprastraktura ng DNS, at maaari kaming mag-set up ng domain zone kung saan magiging awtoritaryan ang aming mga server. Ito ay gumagana tulad nito:

1. Gumagawa ang kliyente ng kahilingan sa DNS server gamit ang isang host, halimbawa api.netflix.xom.
2. Dumating ang kahilingan sa aming DNS server
3. Alam ng DNS server kung aling landas ang pinakamabilis para sa kliyenteng ito at nagbibigay ng kaukulang IP address.

Ang solusyon ay may karagdagang kumplikado: hindi nakikita ng mga authoritarian DNS provider ang IP address ng kliyente at mababasa lang nila ang IP address ng recursive resolver na ginagamit ng kliyente.

Bilang resulta, ang aming authoritarian resolver ay dapat gumawa ng desisyon hindi para sa isang indibidwal na kliyente, ngunit para sa isang grupo ng mga kliyente batay sa recursive resolver.

Upang malutas, ginagamit namin ang parehong mga sample, pinagsama-sama ang mga resulta ng pagsukat mula sa mga kliyente para sa bawat isa sa mga recursive na solver at magpasya kung saan ipapadala ang grupong ito ng mga ito - isang proxy sa pamamagitan ng IX gamit ang TCP Anycast, sa pamamagitan ng isang ISP proxy, o direkta sa cloud.

Nakukuha namin ang sumusunod na sistema:

Ang resultang DNS steering model ay nagbibigay-daan sa iyo na idirekta ang mga kliyente batay sa mga makasaysayang obserbasyon sa bilis ng mga koneksyon mula sa mga kliyente patungo sa cloud.

Muli, ang tanong ay kung gaano kaepektibo ang pamamaraang ito? Para sumagot, muli naming ginagamit ang aming probe system. Samakatuwid, i-configure namin ang configuration ng nagtatanghal, kung saan ang isa sa mga target ay sumusunod sa direksyon mula sa DNS steering, ang isa ay direktang pumupunta sa cloud (kasalukuyang produksyon).

Bilang resulta, inihahambing namin ang mga resulta at nakakakuha ng pagtatasa ng pagiging epektibo:

Bilang resulta, natutunan namin ang ilang mahahalagang bagay:

1. Sinuri namin ang inaasahang pagganap ng mga kahilingan mula sa mga kliyente hanggang sa cloud gamit ang DNS Steering.
2. Nakatanggap kami ng data mula sa mga tunay na kliyente, mula sa lahat ng uri ng device.
3. Napatunayan na ang bisa ng iminungkahing ideya.
4. Hindi kami nakipagsapalaran - hindi namin binago ang mga configuration ng produksyon para sa mga kliyente.
5. Walang nasira.

Ngayon tungkol sa mahirap na bahagi - inilunsad namin ito sa produksyon

Ang madaling bahagi ay tapos na ngayon - mayroong isang gumaganang prototype. Ngayon ang mahirap na bahagi ay naglulunsad ng solusyon para sa lahat ng trapiko ng Netflix, na nagde-deploy sa 150 milyong user, libu-libong device, daan-daang microservice, at patuloy na nagbabagong produkto at imprastraktura. Ang mga server ng Netflix ay tumatanggap ng milyun-milyong kahilingan sa bawat segundo, at madaling sirain ang serbisyo nang walang ingat na pagkilos. Kasabay nito, gusto naming dynamic na iruta ang trapiko sa pamamagitan ng libu-libong CDN server sa Internet, kung saan may nagbabago at nasira palagi at sa pinaka hindi angkop na sandali.

At sa lahat ng ito, ang koponan ay may 3 inhinyero na responsable para sa pagbuo, pag-deploy at buong suporta ng system.

Samakatuwid, patuloy nating pag-uusapan ang tungkol sa matahimik at malusog na pagtulog.

Paano ipagpatuloy ang pag-unlad at hindi gugulin ang lahat ng iyong oras sa suporta? Ang aming diskarte ay batay sa 3 prinsipyo:

1. Binabawasan namin ang potensyal na sukat ng mga breakdown (blast radius).
2. Naghahanda kami para sa mga sorpresa - inaasahan namin na may masisira, sa kabila ng pagsubok at personal na karanasan.
3. Graceful degradation - kung ang isang bagay ay hindi gumagana ng tama, dapat itong awtomatikong ayusin, kahit na hindi sa pinaka mahusay na paraan.

Ito ay lumabas na sa aming kaso, sa diskarteng ito sa problema, makakahanap kami ng isang simple at epektibong solusyon at makabuluhang pasimplehin ang suporta sa system. Napagtanto namin na maaari kaming magdagdag ng isang maliit na piraso ng code sa kliyente at subaybayan ang mga error sa kahilingan sa network na dulot ng mga problema sa koneksyon. Sa kaso ng mga error sa network, direkta kaming gumagawa ng fallback sa cloud. Ang solusyon na ito ay hindi nangangailangan ng malaking pagsisikap para sa mga team ng kliyente, ngunit lubos na binabawasan ang panganib ng mga hindi inaasahang pagkasira at sorpresa para sa amin.

Siyempre, sa kabila ng pagbagsak, gayunpaman, sinusunod namin ang isang malinaw na disiplina sa panahon ng pag-unlad:

1. Halimbawang pagsubok.
2. A/B testing o Canaries.
3. Progresibong paglulunsad.

Sa mga sample, ang diskarte ay inilarawan - ang mga pagbabago ay unang nasubok gamit ang isang customized na recipe.

Para sa pagsubok sa canary, kailangan nating kumuha ng mga maihahambing na pares ng mga server kung saan maaari nating ihambing kung paano gumagana ang system bago at pagkatapos ng mga pagbabago. Upang gawin ito, mula sa aming maraming mga site ng CDN, pumili kami ng mga pares ng mga server na tumatanggap ng maihahambing na trapiko:

Pagkatapos ay i-install namin ang build kasama ang mga pagbabago sa Canary server. Upang suriin ang mga resulta, nagpapatakbo kami ng system na naghahambing ng humigit-kumulang 100-150 na sukatan sa isang sample ng mga Control server:

Kung matagumpay ang pagsubok sa Canary, pagkatapos ay ilalabas namin ito nang paunti-unti, sa mga alon. Hindi kami nag-a-update ng mga server sa bawat site nang sabay-sabay - ang pagkawala ng isang buong site dahil sa mga problema ay may mas makabuluhang epekto sa serbisyo para sa mga user kaysa sa pagkawala ng parehong bilang ng mga server sa iba't ibang lokasyon.

Sa pangkalahatan, ang bisa at kaligtasan ng diskarteng ito ay nakasalalay sa dami at kalidad ng mga nakolektang sukatan. Para sa aming query acceleration system, kinokolekta namin ang mga sukatan mula sa lahat ng posibleng bahagi:

• mula sa mga kliyente - bilang ng mga session at kahilingan, mga rate ng fallback;
• proxy - mga istatistika sa bilang at oras ng mga kahilingan;
• DNS - numero at mga resulta ng mga kahilingan;
• cloud edge - numero at oras para sa pagproseso ng mga kahilingan sa cloud.

Ang lahat ng ito ay kinokolekta sa isang pipeline, at, depende sa mga pangangailangan, nagpapasya kami kung aling mga sukatan ang ipapadala sa real-time na analytics, at kung alin sa Elasticsearch o Big Data para sa mas detalyadong diagnostics.

Sinusubaybayan namin

Sa aming kaso, gumagawa kami ng mga pagbabago sa kritikal na landas ng mga kahilingan sa pagitan ng kliyente at server. Kasabay nito, ang bilang ng iba't ibang mga bahagi sa kliyente, sa server, at sa paraan sa pamamagitan ng Internet ay napakalaki. Ang mga pagbabago sa kliyente at server ay patuloy na nagaganap - sa panahon ng trabaho ng dose-dosenang mga koponan at mga natural na pagbabago sa ecosystem. Nasa gitna tayo - kapag nag-diagnose ng mga problema, malaki ang posibilidad na masangkot tayo. Samakatuwid, kailangan nating malinaw na maunawaan kung paano tukuyin, kolektahin at pag-aralan ang mga sukatan upang mabilis na ihiwalay ang mga problema.

Sa isip, ganap na access sa lahat ng uri ng mga sukatan at mga filter sa real time. Ngunit mayroong maraming mga sukatan, kaya ang tanong ng gastos ay lumitaw. Sa aming kaso, pinaghihiwalay namin ang mga sukatan at mga tool sa pag-unlad tulad ng sumusunod:

Upang matukoy at subukan ang mga problema, ginagamit namin ang aming sariling open-source na real-time na system Atlas и Lumen - para sa visualization. Nag-iimbak ito ng mga pinagsama-samang sukatan sa memorya, maaasahan at isinasama sa sistema ng pag-aalerto. Para sa localization at diagnostics, mayroon kaming access sa mga log mula sa Elasticsearch at Kibana. Para sa pagsusuri at pagmomodelo ng istatistika, gumagamit kami ng malaking data at visualization sa Tableau.

Mukhang napakahirap gamitin ang diskarteng ito. Gayunpaman, sa pamamagitan ng pag-aayos ng mga sukatan at mga tool ayon sa hierarchy, mabilis naming masusuri ang isang problema, matukoy ang uri ng problema, at pagkatapos ay mag-drill down sa mga detalyadong sukatan. Sa pangkalahatan, gumugugol kami ng humigit-kumulang 1-2 minuto upang matukoy ang pinagmulan ng pagkasira. Pagkatapos nito, nakikipagtulungan kami sa isang partikular na koponan sa mga diagnostic - mula sampu-sampung minuto hanggang ilang oras.

Kahit na mabilis na gawin ang diagnosis, hindi namin gustong mangyari ito nang madalas. Sa isip, makakatanggap lang kami ng kritikal na alerto kapag may malaking epekto sa serbisyo. Para sa aming query acceleration system, mayroon lang kaming 2 alerto na mag-aabiso:

• Porsyento ng Client Fallback - pagtatasa ng gawi ng customer;
• porsyento Mga error sa pagsisiyasat - data ng katatagan ng mga bahagi ng network.

Sinusubaybayan ng mga kritikal na alertong ito kung gumagana ang system para sa karamihan ng mga user. Tinitingnan namin kung gaano karaming mga kliyente ang gumamit ng fallback kung hindi nila nakuha ang pagbilis ng kahilingan. Kami ay may average na mas mababa sa 1 kritikal na alerto bawat linggo, kahit na mayroong isang toneladang pagbabago na nangyayari sa system. Bakit sapat na ito para sa atin?

1. Mayroong fallback ng kliyente kung hindi gumana ang aming proxy.
2. Mayroong awtomatikong sistema ng pagpipiloto na tumutugon sa mga problema.

Higit pang mga detalye tungkol sa huli. Ang aming trial system, at ang system para sa awtomatikong pagtukoy ng pinakamainam na landas para sa mga kahilingan mula sa kliyente patungo sa cloud, ay nagbibigay-daan sa aming awtomatikong makayanan ang ilang mga problema.

Bumalik tayo sa aming sample na configuration at 3 kategorya ng path. Bilang karagdagan sa oras ng pag-load, maaari naming tingnan ang katotohanan ng paghahatid mismo. Kung hindi posible na i-load ang data, pagkatapos ay sa pamamagitan ng pagtingin sa mga resulta sa iba't ibang mga landas matutukoy natin kung saan at kung ano ang nasira, at kung maaari ba nating awtomatiko itong ayusin sa pamamagitan ng pagbabago sa landas ng kahilingan.

Примеры:

Ang prosesong ito ay maaaring awtomatiko. Isama ito sa steering system. At turuan itong tumugon sa mga problema sa pagganap at pagiging maaasahan. Kung may nagsimulang masira, mag-react kung may mas magandang opsyon. Kasabay nito, ang isang agarang reaksyon ay hindi kritikal, salamat sa fallback sa mga kliyente.

Kaya, ang mga prinsipyo ng suporta sa system ay maaaring mabalangkas tulad ng sumusunod:

• pagbabawas ng laki ng mga pagkasira;
• pagkolekta ng mga sukatan;
• Awtomatiko kaming nag-aayos ng mga pagkasira kung magagawa namin;
• kung hindi ito magagawa, aabisuhan ka namin;
• Nagtatrabaho kami sa mga dashboard at triage toolset para sa mabilis na pagtugon.

Mga aral na natutunan

Hindi nangangailangan ng maraming oras upang magsulat ng isang prototype. Sa aming kaso, handa na ito pagkatapos ng 4 na buwan. Sa pamamagitan nito nakatanggap kami ng mga bagong sukatan, at 10 buwan pagkatapos ng pagsisimula ng pag-unlad natanggap namin ang unang trapiko ng produksyon. Pagkatapos ay nagsimula ang nakakapagod at napakahirap na gawain: unti-unting gawing produkto at sukatin ang system, ilipat ang pangunahing trapiko at matuto mula sa mga pagkakamali. Gayunpaman, ang epektibong prosesong ito ay hindi magiging linear - sa kabila ng lahat ng pagsisikap, ang lahat ay hindi mahulaan. Mas epektibo ang mabilis na pag-ulit at pagtugon sa bagong data.

Batay sa aming karanasan, maaari naming irekomenda ang mga sumusunod:

1. Huwag magtiwala sa iyong intuwisyon.

   Ang aming intuwisyon ay patuloy na nabigo sa amin, sa kabila ng malawak na karanasan ng mga miyembro ng aming koponan. Halimbawa, hindi namin nahulaan nang tama ang inaasahang bilis mula sa paggamit ng CDN proxy, o ang gawi ng TCP Anycast.

2. Kumuha ng data mula sa produksyon.

   Mahalagang makakuha ng access sa hindi bababa sa isang maliit na halaga ng data ng produksyon sa lalong madaling panahon. Halos imposibleng makuha ang bilang ng mga natatanging kaso, pagsasaayos, at setting sa mga kondisyon ng laboratoryo. Ang mabilis na pag-access sa mga resulta ay magbibigay-daan sa iyo upang mabilis na matutunan ang tungkol sa mga potensyal na problema at isaalang-alang ang mga ito sa arkitektura ng system.

3. Huwag sundin ang payo at resulta ng ibang tao - kolektahin ang iyong sariling data.

   Sundin ang mga prinsipyo para sa pagkolekta at pagsusuri ng data, ngunit huwag bulag na tanggapin ang mga resulta at pahayag ng ibang tao. Ikaw lang ang makakaalam kung ano mismo ang gumagana para sa iyong mga user. Ang iyong mga system at ang iyong mga customer ay maaaring malaki ang pagkakaiba sa ibang mga kumpanya. Sa kabutihang palad, ang mga tool sa pagsusuri ay magagamit na ngayon at madaling gamitin. Ang mga resultang makukuha mo ay maaaring hindi kung ano ang sinasabi ng Netflix, Facebook, Akamai at iba pang kumpanya. Sa aming kaso, ang pagganap ng TLS, HTTP2 o mga istatistika sa mga kahilingan sa DNS ay naiiba sa mga resulta ng Facebook, Uber, Akamai - dahil mayroon kaming iba't ibang mga device, kliyente at daloy ng data.

4. Huwag sundin ang mga uso sa fashion nang hindi kinakailangan at suriin ang pagiging epektibo.

   Magsimula nang simple. Mas mahusay na gumawa ng isang simpleng sistema ng pagtatrabaho sa isang maikling panahon kaysa sa gumugol ng isang malaking halaga ng oras sa pagbuo ng mga sangkap na hindi mo kailangan. Lutasin ang mga gawain at problemang mahalaga batay sa iyong mga sukat at resulta.

5. Maghanda para sa mga bagong application.

   Kung paanong mahirap hulaan ang lahat ng mga problema, mahirap hulaan ang mga benepisyo at aplikasyon nang maaga. Kumuha ng cue mula sa mga startup - ang kanilang kakayahang umangkop sa mga kondisyon ng customer. Sa iyong kaso, maaari kang makatuklas ng mga bagong problema at ang kanilang mga solusyon. Sa aming proyekto, nagtakda kami ng layunin na bawasan ang latency ng kahilingan. Gayunpaman, sa panahon ng pagsusuri at mga talakayan, napagtanto namin na maaari rin kaming gumamit ng mga proxy server:

   • upang balansehin ang trapiko sa mga rehiyon ng AWS at bawasan ang mga gastos;
   • upang imodelo ang katatagan ng CDN;
   • upang i-configure ang DNS;
   • upang i-configure ang TLS/TCP.

Konklusyon

Sa ulat, inilarawan ko kung paano nilulutas ng Netflix ang problema sa pagpapabilis ng mga kahilingan sa Internet sa pagitan ng mga kliyente at ng cloud. Paano namin kinokolekta ang data gamit ang isang sampling system sa mga kliyente, at ginagamit ang nakolektang makasaysayang data upang iruta ang mga kahilingan sa produksyon mula sa mga kliyente sa pinakamabilis na landas sa Internet. Paano namin ginagamit ang mga prinsipyo ng mga protocol ng network, aming imprastraktura ng CDN, backbone network, at mga DNS server upang makamit ang gawaing ito.

Gayunpaman, ang aming solusyon ay isang halimbawa lamang kung paano namin ipinatupad sa Netflix ang naturang sistema. Ano ang nagtrabaho para sa amin. Ang inilapat na bahagi ng aking ulat para sa iyo ay ang mga prinsipyo ng pag-unlad at suporta na aming sinusunod at nakakamit ng magagandang resulta.

Ang aming solusyon sa problema ay maaaring hindi angkop sa iyo. Gayunpaman, nananatili ang teorya at mga prinsipyo ng disenyo, kahit na wala kang sariling imprastraktura ng CDN, o kung malaki ang pagkakaiba nito sa amin.

Ang kahalagahan ng bilis ng mga kahilingan sa negosyo ay nananatiling mahalaga. At kahit para sa isang simpleng serbisyo kailangan mong pumili: sa pagitan ng mga cloud provider, lokasyon ng server, CDN at DNS provider. Ang iyong pinili ay makakaimpluwensya sa pagiging epektibo ng mga query sa Internet para sa iyong mga customer. At mahalaga para sa iyo na sukatin at maunawaan ang impluwensyang ito.

Magsimula sa mga simpleng solusyon, pakialam kung paano mo babaguhin ang produkto. Matuto habang lumalakad ka at pahusayin ang system batay sa data mula sa iyong mga customer, iyong imprastraktura, at iyong negosyo. Isipin ang posibilidad ng mga hindi inaasahang pagkasira sa panahon ng proseso ng disenyo. At pagkatapos ay maaari mong pabilisin ang iyong proseso ng pag-unlad, pagbutihin ang kahusayan ng solusyon, maiwasan ang hindi kinakailangang pasanin sa suporta at matulog nang mapayapa.

Sa taong ito gaganapin ang kumperensya mula Hulyo 6 hanggang 10 sa online na format. Maaari kang magtanong sa isa sa mga ama ng DevOps, si John Willis mismo!

Pinagmulan: www.habr.com