Netflix ir interneta televīzijas tirgus līderis - uzņēmums, kas izveidoja un aktīvi attīsta šo segmentu. Netflix ir pazīstams ne tikai ar savu plašo filmu un TV seriālu katalogu, kas pieejams gandrīz no katra planētas stūra un jebkuras ierīces ar displeju, bet arī ar savu uzticamo infrastruktūru un unikālo inženierijas kultūru.
Spilgts piemērs Netflix pieejai sarežģītu sistēmu izstrādei un atbalstam tika prezentēts DevOops 2019. - Netflix attīstības direktors. Ņižņijnovgorodas Valsts universitātes Skaitļošanas matemātikas un matemātikas fakultātes absolvents. Lobačevskis, Sergejs ir viens no pirmajiem Open Connect – CDN komandas inženieriem Netflix. Viņš izveidoja sistēmas video datu uzraudzībai un analīzei, ieviesa populāru pakalpojumu interneta savienojuma ātruma novērtēšanai FAST.com un pēdējos dažus gadus ir strādājis pie interneta pieprasījumu optimizēšanas, lai Netflix lietojumprogramma lietotājiem darbotos pēc iespējas ātrāk.
Ziņojums saņēma vislabākās konferences dalībnieku atsauksmes, un mēs esam sagatavojuši jums teksta versiju.
Savā ziņojumā Sergejs runāja detalizēti
- par to, kas ietekmē interneta pieprasījumu kavēšanos starp klientu un serveri;
- kā samazināt šo kavēšanos;
- как проектировать, поддерживать и мониторить устойчивые к ошибкам системы;
- kā sasniegt rezultātus īsā laikā un ar minimālu risku biznesam;
- kā analizēt rezultātus un mācīties no kļūdām.
Atbildes uz šiem jautājumiem ir vajadzīgas ne tikai lielajās korporācijās strādājošajiem.
Iesniegtie principi un paņēmieni ir jāzina un jāpraktizē ikvienam, kurš izstrādā un atbalsta interneta produktus.
Nākamais ir stāstījums no runātāja viedokļa.
Interneta ātruma nozīme
Interneta pieprasījumu ātrums ir tieši saistīts ar uzņēmējdarbību. Apsveriet iepirkšanās nozari: Amazon 2009. gadā ka 100 ms aizkaves rezultātā tiek zaudēts 1% no pārdošanas apjoma.
Arvien vairāk ir mobilo ierīču, kam seko mobilās vietnes un lietojumprogrammas. Ja lapas ielāde aizņem vairāk nekā 3 sekundes, jūs zaudējat aptuveni pusi no saviem lietotājiem. AR Google ņem vērā jūsu lapas ielādes ātrumu meklēšanas rezultātos: jo ātrāk lapa, jo augstāka ir tās pozīcija Google.
Savienojuma ātrums ir svarīgs arī finanšu iestādēs, kur latentums ir kritisks. 2015. gadā Hibernia Networks 400 miljonu dolāru kabelis starp Ņujorku un Londonu, lai samazinātu latentumu starp pilsētām par 6 ms. Iedomājieties $ 66 miljonus par 1 ms latentuma samazināšanu!
Saskaņā ar , savienojuma ātrums virs 5 Mbit/s vairs tieši neietekmē tipiskas vietnes ielādes ātrumu. Tomēr pastāv lineāra sakarība starp savienojuma latentumu un lapas ielādes ātrumu:
Однако Netflix — не типовой продукт. Влияние задержки и скорости на пользователя — активная сфера анализа и разработки. Есть загрузка приложения и выбор контента, зависящие от задержки, но загрузка статических элементов и стриминг также зависят и от скорости соединения. Анализ и оптимизация ключевых факторов, влияющих на качество сервиса для пользователя, — активная сфера разработки нескольких команд в Netflix. Одна из задач — уменьшение задержки запросов между Netflix устройствами и облачной инфраструктурой.
Pārskatā mēs īpaši pievērsīsimies latentuma samazināšanai, izmantojot Netflix infrastruktūras piemēru. Apskatīsim no praktiskā viedokļa, kā pieiet sarežģītu sadalīto sistēmu projektēšanas, izstrādes un darbības procesiem un veltīt laiku inovācijām un rezultātiem, nevis darbības problēmu un bojājumu diagnosticēšanai.
Внутри Netflix
Tūkstošiem dažādu ierīču atbalsta Netflix lietotnes. Tos izstrādā četras dažādas komandas, kas veido atsevišķas klienta versijas Android, iOS, TV un tīmekļa pārlūkprogrammām. Un mēs veltām daudz pūļu, lai uzlabotu un personalizētu lietotāja pieredzi. Lai to izdarītu, paralēli veicam simtiem A/B testu.
Personalizēšanu atbalsta simtiem mikropakalpojumu AWS mākonī, nodrošinot personalizētus lietotāja datus, vaicājumu nosūtīšanu, telemetriju, lielos datus un kodējumu. Satiksmes vizualizācija izskatās šādi:
Kreisajā pusē ir ieejas punkts, un pēc tam datplūsma tiek sadalīta starp vairākiem simtiem mikropakalpojumu, kurus atbalsta dažādas aizmugursistēmas komandas.
Еще один важный компонент нашей инфраструктуры — это Open Connect CDN, который доставляет до конечного пользователя статический контент — видео, изображения, код для клиентов и т.д. CDN расположена на кастомных серверах (OCA — Open Connect Appliance). Внутри расположены массивы SSD и HDD-дисков под управлением оптимизированной FreeBSD, с NGINX и набором сервисов. Мы проектируем и оптимизируем аппаратные и программные компоненты таким образом, чтобы такой CDN сервер мог отправлять как можно больше данных пользователям.
Šo serveru “siena” interneta trafika apmaiņas punktā (Internet eXchange - IX) izskatās šādi:
Internet Exchange nodrošina iespēju interneta pakalpojumu sniedzējiem un satura nodrošinātājiem “savienoties” vienam ar otru, lai tiešāk apmainītos ar datiem internetā. Visā pasaulē ir aptuveni 70–80 interneta apmaiņas punkti, kuros ir instalēti mūsu serveri, un mēs tos neatkarīgi instalējam un apkopjam:
Turklāt mēs arī nodrošinām serverus tieši interneta pakalpojumu sniedzējiem, kurus tie instalē savā tīklā, uzlabojot Netflix trafika lokalizāciju un lietotāju straumēšanas kvalitāti:
AWS pakalpojumu komplekts ir atbildīgs par video pieprasījumu nosūtīšanu no klientiem uz CDN serveriem, kā arī pašu serveru konfigurēšanu - satura, programmas koda, iestatījumu atjaunināšanu utt. Attiecībā uz pēdējo mēs izveidojām arī mugurkaula tīklu, kas savieno serverus interneta apmaiņas punktos ar AWS. Pamattīkls ir globāls optisko šķiedru kabeļu un maršrutētāju tīkls, ko mēs varam izstrādāt un konfigurēt atbilstoši savām vajadzībām.
Par , mūsu CDN infrastruktūra nodrošina aptuveni ⅛ no pasaules interneta trafika pīķa stundās un ⅓ no trafika Ziemeļamerikā, kur Netflix darbojas visilgāk. Iespaidīgi skaitļi, bet man viens no pārsteidzošākajiem sasniegumiem ir tas, ka visu CDN sistēmu izstrādā un uztur komanda, kurā ir mazāk nekā 150 cilvēku.
Изначально, CDN инфраструктура была спроектирована для доставки видео данных. Однако, со временем мы поняли, что мы можем использовать ее и для оптимизации динамических запросов от клиентов в AWS облако.
Par interneta paātrinājumu
Šodien Netflix ir 3 AWS reģioni, un pieprasījumu latentums mākonī būs atkarīgs no tā, cik tālu klients atrodas no tuvākā reģiona. Tajā pašā laikā mums ir daudz CDN serveru, kas tiek izmantoti statiska satura piegādei. Vai ir kāds veids, kā izmantot šo sistēmu, lai paātrinātu dinamiskos vaicājumus? Taču diemžēl šos pieprasījumus nav iespējams saglabāt kešatmiņā – API ir personalizētas un katrs rezultāts ir unikāls.
Izveidosim starpniekserveri CDN serverī un sāksim sūtīt trafiku caur to. Vai tas būs ātrāk?
Materiāls
Atcerēsimies, kā darbojas tīkla protokoli. Mūsdienās lielākā daļa trafika internetā izmanto HTTP, kas ir atkarīga no zemākā slāņa protokoliem TCP un TLS. Lai klients varētu izveidot savienojumu ar serveri, tas veic rokasspiedienu, un, lai izveidotu drošu savienojumu, klientam ir trīs reizes jāapmainās ar ziņojumiem ar serveri un vēl vismaz vienu reizi, lai pārsūtītu datus. Ja latentums vienā reisā (RTT) ir 100 ms, mums būtu nepieciešams 400 ms, lai saņemtu pirmo datu bitu:
Ja mēs ievietojam sertifikātus CDN serverī, tad rokasspiediena laiks starp klientu un serveri var ievērojami samazināties, ja CDN ir tuvāk. Pieņemsim, ka CDN servera latentums ir 30 ms. Tad pirmā bita saņemšana prasīs 220 ms:
Bet ar to priekšrocības nebeidzas. Kad savienojums ir izveidots, TCP palielina pārslodzes logu (informācijas apjomu, ko tas var pārraidīt pa šo savienojumu paralēli). Ja datu pakete tiek pazaudēta, klasiskās TCP protokola ieviešanas (piemēram, TCP New Reno) samazina atvērto “logu” uz pusi. Pārslodzes loga pieaugums un tā atgūšanas ātrums pēc zaudējumiem atkal ir atkarīgs no kavēšanās (RTT) uz serveri. Ja šis savienojums iet tikai līdz CDN serverim, šī atkopšana būs ātrāka. Tajā pašā laikā pakešu zudums ir standarta parādība, īpaši bezvadu tīkliem.
Interneta joslas platums var būt samazināts, jo īpaši sastrēguma stundās lietotāju satiksmes dēļ, kas var izraisīt satiksmes sastrēgumus. Tomēr internetā nav iespējams dažiem pieprasījumiem piešķirt prioritāti pār citiem. Piemēram, piešķiriet prioritāti maziem un latentuma jutīgiem pieprasījumiem, nevis “smagām” datu straumēm, kas noslogo tīklu. Tomēr mūsu gadījumā, ja mums ir savs mugurkaula tīkls, mēs to varam izdarīt daļā no pieprasījuma ceļa — starp CDN un mākoni, un mēs varam to pilnībā konfigurēt. Varat pārliecināties, ka mazām un latentuma jutīgām paketēm tiek piešķirta prioritāte un lielas datu plūsmas notiek nedaudz vēlāk. Jo tuvāk CDN ir klientam, jo lielāka ir efektivitāte.
Lietojumprogrammu līmeņa protokoli (OSI 7. līmenis) arī ietekmē latentumu. Jauni protokoli, piemēram, HTTP/2, optimizē paralēlo pieprasījumu veiktspēju. Tomēr mums ir Netflix klienti ar vecākām ierīcēm, kas neatbalsta jaunos protokolus. Ne visus klientus var atjaunināt vai optimāli konfigurēt. Tajā pašā laikā starp CDN starpniekserveri un mākoni ir pilnīga kontrole un iespēja izmantot jaunus, optimālus protokolus un iestatījumus. Neefektīvā daļa ar veciem protokoliem darbosies tikai starp klientu un CDN serveri. Turklāt mēs varam veikt multipleksus pieprasījumus jau izveidotā savienojumā starp CDN un mākoni, uzlabojot savienojuma izmantošanu TCP līmenī:
Mēs mēra
Neskatoties uz to, ka teorija sola uzlabojumus, mēs uzreiz nesteidzamies palaist sistēmu ražošanā. Tā vietā mums vispirms jāpierāda, ka ideja darbosies praksē. Lai to izdarītu, jums jāatbild uz vairākiem jautājumiem:
- Ātrums: vai starpniekserveris būs ātrāks?
- Uzticamība: Vai tas plīsīs biežāk?
- Sarežģītība: kā integrēties ar lietojumprogrammām?
- Izmaksāt: Cik maksā papildu infrastruktūras izvietošana?
Ļaujiet mums sīkāk apsvērt mūsu pieeju pirmā punkta novērtēšanai. Pārējie tiek risināti līdzīgi.
Lai analizētu pieprasījumu ātrumu, mēs vēlamies iegūt datus par visiem lietotājiem, netērējot daudz laika izstrādei un nepārkāpjot ražošanu. Šim nolūkam ir vairākas pieejas:
- RUM, или пассивное измерение запросов. Измеряем время выполнения текущих запросов от пользователей и обеспечиваем полное покрытие пользователей. Недостаток — не очень стабильный сигнал из-за множества факторов, например, из-за разных размеров запросов, времени обработки на сервере и клиенте. Кроме этого, нельзя протестировать новую конфигурацию без эффекта на production.
- Laboratorijas testi. Īpaši serveri un infrastruktūra, kas simulē klientus. Ar viņu palīdzību mēs veicam nepieciešamās pārbaudes. Tādā veidā mēs iegūstam pilnīgu kontroli pār mērījumu rezultātiem un skaidru signālu. Taču nav pilnīga ierīču un lietotāju atrašanās vietu pārklājuma (jo īpaši ar pakalpojumu visā pasaulē un atbalstu tūkstošiem ierīču modeļu).
Kā jūs varat apvienot abu metožu priekšrocības?
Mūsu komanda ir atradusi risinājumu. Mēs uzrakstījām nelielu koda fragmentu — paraugu —, ko iestrādājām savā lietojumprogrammā. Zondes ļauj mums veikt pilnībā kontrolētus tīkla testus no mūsu ierīcēm. Tas darbojas šādi:
- Neilgi pēc lietojumprogrammas ielādes un sākotnējās darbības pabeigšanas mēs palaižam zondes.
- Klients iesniedz pieprasījumu serverim un saņem testa “recepti”. Recepte ir vietrāžu URL saraksts, kuriem ir jāveic HTTP(-u) pieprasījums. Turklāt recepte konfigurē pieprasījuma parametrus: aizkaves starp pieprasījumiem, pieprasīto datu apjomu, HTTP(-u) galvenes utt. Vienlaikus varam paralēli testēt vairākas dažādas receptes – pieprasot konfigurāciju, nejauši nosakām, kuru recepti izdot.
- Zondes palaišanas laiks ir izvēlēts tā, lai tas nebūtu pretrunā ar aktīvo tīkla resursu izmantošanu klientam. Būtībā tiek izvēlēts laiks, kad klients nav aktīvs.
- Pēc receptes saņemšanas klients paralēli veic pieprasījumus katram no URL. Pieprasījumu uz katru no adresēm var atkārtot – t.s. "pākšaugi". Pirmajā impulsā mēs izmērām, cik ilgs laiks bija nepieciešams, lai izveidotu savienojumu un lejupielādētu datus. Otrajā impulsā mēs izmērām laiku, kas nepieciešams datu ielādei jau izveidotā savienojumā. Pirms trešā mēs varam iestatīt aizkavi un izmērīt atkārtota savienojuma izveides ātrumu utt.
Pārbaudes laikā mēs izmērām visus parametrus, ko ierīce var iegūt:
- DNS pieprasījuma laiks;
- TCP savienojuma iestatīšanas laiks;
- время установки соединения по TLS;
- datu pirmā baita saņemšanas laiks;
- kopējais ielādes laiks;
- statusa rezultāta kods.
- Kad visi impulsi ir pabeigti, paraugs ielādē visus mērījumus analīzei.
Ключевыми моментами являются минимальная зависимость от логики на клиенте, обработки данных на сервере и измерении параллельных запросов. Таким образом, мы получаем возможность изолировать и тестировать влияние различных факторов, влияющих на производительность запросов, варьировать их в пределах одного рецепта, и получать результаты с реальных клиентов.
Šī infrastruktūra ir izrādījusies noderīga ne tikai vaicājumu veiktspējas analīzei. Šobrīd mums ir 14 aktīvās receptes, vairāk nekā 6000 paraugu sekundē, datu saņemšana no visiem zemes stūriem un pilns ierīces pārklājums. Ja Netflix iegādātos līdzīgu pakalpojumu no trešās puses, tas izmaksātu miljoniem dolāru gadā ar daudz sliktāku pārklājumu.
Testēšanas teorija praksē: prototips
Izmantojot šādu sistēmu, mēs varējām novērtēt CDN starpniekserveru efektivitāti pēc pieprasījuma latentuma. Tagad jums ir nepieciešams:
- izveidot starpniekservera prototipu;
- разместить прототип на CDN;
- noteikt, kā novirzīt klientus uz starpniekserveri noteiktā CDN serverī;
- Salīdziniet veiktspēju ar pieprasījumiem AWS bez starpniekservera.
Uzdevums ir pēc iespējas ātrāk novērtēt piedāvātā risinājuma efektivitāti. Mēs izvēlējāmies Go, lai ieviestu prototipu, jo ir pieejamas labas tīkla bibliotēkas. Katrā CDN serverī mēs instalējām prototipa starpniekserveri kā statisku bināru, lai samazinātu atkarības un vienkāršotu integrāciju. Sākotnējā ieviešanā mēs, cik vien iespējams, izmantojām standarta komponentus un nelielas modifikācijas HTTP/2 savienojumu apvienošanai un pieprasījumu multipleksēšanai.
Lai līdzsvarotu AWS reģionus, mēs izmantojām ģeogrāfisko DNS datu bāzi, to pašu, kuru izmantoja klientu līdzsvarošanai. Lai klientam atlasītu CDN serveri, mēs izmantojam TCP Anycast serveriem programmā Internet Exchange (IX). Šajā opcijā mēs izmantojam vienu IP adresi visiem CDN serveriem, un klients tiks novirzīts uz CDN serveri ar vismazāko IP apiņu skaitu. Interneta pakalpojumu sniedzēju (ISP) instalētajos CDN serveros mēs nevaram kontrolēt maršrutētāju, lai konfigurētu TCP Anycast, tāpēc mēs izmantojam , kas novirza klientus pie interneta pakalpojumu sniedzējiem video straumēšanai.
Tātad mums ir trīs veidu pieprasījumu ceļi: uz mākoni caur atvērto internetu, caur CDN serveri IX vai caur CDN serveri, kas atrodas pie interneta pakalpojumu sniedzēja. Mūsu mērķis ir saprast, kurš veids ir labāks un kāds ir starpniekservera ieguvums salīdzinājumā ar to, kā pieprasījumi tiek nosūtīti uz ražošanu. Lai to izdarītu, mēs izmantojam šādu paraugu ņemšanas sistēmu:
Каждый из путей становится отдельным таргетом, и мы смотрим на время, которое у нас получилось. Для анализа объединяем прокси результаты в одну группу (выбираем лучшее время между IX и ISP прокси), и сравниваем с временем запросов в облако без прокси:
Kā redzams, rezultāti bija neviennozīmīgi – vairumā gadījumu starpniekserveris dod labu ātrumu, taču ir arī pietiekams skaits klientu, kuriem situācija būtiski pasliktināsies.
Rezultātā mēs paveicām vairākas svarīgas lietas:
- Оценили ожидаемую производительность запросов от клиентов в облако через CDN прокси.
- Datus saņēmām no reāliem klientiem, no visa veida ierīcēm.
- Mēs sapratām, ka teorija nav 100% apstiprināta un sākotnējais piedāvājums ar CDN starpniekserveri mums nederēs.
- Mēs neriskējām – nemainījām klientu ražošanas konfigurācijas.
- Nekas nebija salauzts.
Prototips 2.0
Tātad, atgriezieties pie rasēšanas dēļa un atkārtojiet procesu vēlreiz.
Ideja ir tāda, ka tā vietā, lai izmantotu 100% starpniekserveri, mēs katram klientam noteiksim ātrāko ceļu un tur nosūtīsim pieprasījumus - tas ir, mēs darīsim to, ko sauc par klienta vadīšanu.
Kā to īstenot? Mēs nevaram izmantot loģiku servera pusē, jo... Mērķis ir izveidot savienojumu ar šo serveri. Ir nepieciešams kāds veids, kā to izdarīt klientam. Un ideālā gadījumā dariet to ar minimālu sarežģītu loģiku, lai neatrisinātu integrācijas problēmu ar lielu skaitu klientu platformu.
Atbilde ir izmantot DNS. Mūsu gadījumā mums ir sava DNS infrastruktūra, un mēs varam iestatīt domēna zonu, kurai mūsu serveri būs autoritāri. Tas darbojas šādi:
- Klients veic pieprasījumu DNS serverim, izmantojot resursdatoru, piemēram, api.netflix.xom.
- Pieprasījums nonāk mūsu DNS serverī
- DNS serveris zina, kurš ceļš ir ātrākais šim klientam, un izdod atbilstošo IP adresi.
Risinājumam ir papildu sarežģītība: autoritārie DNS nodrošinātāji neredz klienta IP adresi un var nolasīt tikai klienta izmantotā rekursīvā atrisinātāja IP adresi.
Rezultātā mūsu autoritārajam atrisinātājam ir jāpieņem lēmums nevis par atsevišķu klientu, bet gan par klientu grupu, pamatojoties uz rekursīvo atrisinātāju.
Lai atrisinātu, mēs izmantojam tos pašus paraugus, apkopojam klientu mērījumu rezultātus katram rekursīvajam atrisinātājam un izlemjam, kur nosūtīt šo to grupu — starpniekserveri caur IX, izmantojot TCP Anycast, caur ISP starpniekserveri vai tieši uz mākoni.
Mēs iegūstam šādu sistēmu:
Iegūtais DNS vadības modelis ļauj virzīt klientus, pamatojoties uz vēsturiskiem novērojumiem par savienojumu ātrumu no klientiem uz mākoni.
Atkal jautājums ir par to, cik efektīvi šī pieeja darbosies? Lai atbildētu, mēs atkal izmantojam mūsu zondes sistēmu. Tāpēc mēs konfigurējam prezentētāja konfigurāciju, kur viens no mērķiem seko DNS vadības virzienam, otrs iet tieši uz mākoni (pašreizējā ražošana).
Rezultātā mēs salīdzinām rezultātus un iegūstam efektivitātes novērtējumu:
Rezultātā mēs uzzinājām vairākas svarīgas lietas:
- Mēs novērtējām paredzamo klientu pieprasījumu veiktspēju mākonī, izmantojot DNS vadību.
- Datus saņēmām no reāliem klientiem, no visa veida ierīcēm.
- Piedāvātās idejas efektivitāte ir pierādīta.
- Mēs neriskējām – nemainījām klientu ražošanas konfigurācijas.
- Nekas nebija salauzts.
Теперь о сложном — запускаем в production
Vienkāršākā daļa tagad ir beigusies – ir darba prototips. Tagad grūtākā daļa ir visa Netflix datplūsmas risinājuma palaišana, izvietojot to 150 miljoniem lietotāju, tūkstošiem ierīču, simtiem mikropakalpojumu un pastāvīgi mainīgu produktu un infrastruktūru. Netflix serveri saņem miljoniem pieprasījumu sekundē, un pakalpojumu ir viegli pārtraukt ar neuzmanīgu rīcību. Tajā pašā laikā mēs vēlamies dinamiski maršrutēt trafiku caur tūkstošiem CDN serveru internetā, kur kaut kas pastāvīgi un visnepiemērotākajā brīdī mainās un sabojājas.
Turklāt komandā ir 3 inženieri, kas atbild par sistēmas izstrādi, izvietošanu un pilnīgu atbalstu.
Tāpēc mēs turpināsim runāt par mierīgu un veselīgu miegu.
Как продолжать разработку, а не тратить все время на поддержку? В основе нашего подхода лежат 3 принципа:
- Mēs samazinām iespējamo bojājumu mērogu (sprādziena rādiusu).
- Gatavojamies pārsteigumiem – gaidām, ka kaut kas salūzīs, neskatoties uz pārbaudēm un personīgo pieredzi.
- Gracioza degradācija — ja kaut kas nedarbojas pareizi, tas ir jālabo automātiski, pat ja ne visefektīvākajā veidā.
Izrādījās, ka mūsu gadījumā ar šādu pieeju problēmai mēs varam atrast vienkāršu un efektīvu risinājumu un būtiski vienkāršot sistēmas atbalstu. Mēs sapratām, ka varam klientam pievienot nelielu koda fragmentu un pārraudzīt tīkla pieprasījumu kļūdas, ko izraisa savienojuma problēmas. Tīkla kļūdu gadījumā mēs veicam atkāpšanos tieši uz mākoni. Šis risinājums neprasa ievērojamas pūles klientu komandām, taču ievērojami samazina negaidītu avāriju un pārsteigumu risku mums.
Protams, neskatoties uz atkāpšanos, izstrādes laikā mēs ievērojam skaidru disciplīnu:
- Testa paraugs.
- A/B testēšana vai Kanāriju salas.
- Progresīvā izlaišana.
Ar paraugiem pieeja ir aprakstīta - izmaiņas vispirms tiek pārbaudītas, izmantojot pielāgotu recepti.
Kanāriju testēšanai mums ir jāiegūst salīdzināmi serveru pāri, kuros mēs varam salīdzināt, kā sistēma darbojas pirms un pēc izmaiņām. Lai to izdarītu, no mūsu daudzajām CDN vietnēm mēs atlasām serveru pārus, kas saņem salīdzināmu trafiku:
Pēc tam mēs instalējam būvējumu ar izmaiņām Canary serverī. Lai novērtētu rezultātus, mēs palaižam sistēmu, kas salīdzina aptuveni 100–150 metrikas ar vadības serveru paraugu:
Ja Kanāriju testēšana ir veiksmīga, mēs to izlaižam pakāpeniski, viļņveidīgi. Mēs neatjaunojam serverus katrā vietnē vienlaikus – visas vietnes zaudēšana problēmu dēļ ievērojami ietekmē pakalpojumu lietotājiem nekā vienāda serveru skaita zaudēšana dažādās vietās.
Kopumā šīs pieejas efektivitāte un drošība ir atkarīga no savākto rādītāju daudzuma un kvalitātes. Mūsu vaicājumu paātrināšanas sistēmai mēs apkopojam metriku no visiem iespējamajiem komponentiem:
- no klientiem - sesiju un pieprasījumu skaits, atkāpšanās likmes;
- starpniekserveris - statistika par pieprasījumu skaitu un laiku;
- DNS - pieprasījumu skaits un rezultāti;
- mākoņa mala - pieprasījumu skaits un laiks mākonī apstrādei.
Tas viss tiek apkopots vienā konveijerā, un atkarībā no vajadzībām mēs izlemjam, kuru metriku nosūtīt uz reāllaika analīzi un kādu uz Elasticsearch vai Big Data, lai iegūtu detalizētāku diagnostiku.
Мониторим
Mūsu gadījumā mēs veicam izmaiņas kritiskajā pieprasījumu ceļā starp klientu un serveri. Tajā pašā laikā dažādu komponentu skaits klientā, serverī un ceļā caur internetu ir milzīgs. Izmaiņas klientā un serverī notiek pastāvīgi - desmitiem komandu darba un ekosistēmas dabisko izmaiņu laikā. Mēs esam pa vidu — diagnosticējot problēmas, pastāv liela iespēja, ka mēs iesaistīsimies. Tāpēc mums ir skaidri jāsaprot, kā definēt, apkopot un analizēt metriku, lai ātri izolētu problēmas.
Ideālā gadījumā pilnīga piekļuve visu veidu rādītājiem un filtriem reāllaikā. Bet ir daudz rādītāju, tāpēc rodas jautājums par izmaksām. Mūsu gadījumā mēs nodalām metriku un izstrādes rīkus šādi:
Lai atklātu un sakārtotu problēmas, mēs izmantojam savu atvērtā koda reāllaika sistēmu и - vizualizācijai. Tas saglabā apkopoto metriku atmiņā, ir uzticams un integrējas ar brīdināšanas sistēmu. Lokalizācijai un diagnostikai mums ir pieejami žurnāli no Elasticsearch un Kibana. Statistiskajai analīzei un modelēšanai mēs izmantojam lielos datus un vizualizāciju Tableau.
Šķiet, ka ar šo pieeju ir ļoti grūti strādāt. Tomēr, organizējot metriku un rīkus hierarhiski, mēs varam ātri analizēt problēmu, noteikt problēmas veidu un pēc tam izpētīt detalizētu metriku. Kopumā mēs pavadām aptuveni 1-2 minūtes, lai identificētu bojājumu avotu. Pēc tam ar konkrētu komandu strādājam pie diagnostikas – no desmitiem minūšu līdz vairākām stundām.
Pat ja diagnoze tiek veikta ātri, mēs nevēlamies, lai tas notiktu bieži. Ideālā gadījumā mēs saņemsim kritisku brīdinājumu tikai tad, ja tas būtiski ietekmēs pakalpojumu. Mūsu vaicājumu paātrināšanas sistēmai mums ir tikai 2 brīdinājumi, kas informēs:
- Klienta atkāpšanās procents - klientu uzvedības novērtējums;
- procenti Zondes kļūdas - tīkla komponentu stabilitātes dati.
Šie kritiskie brīdinājumi uzrauga, vai sistēma darbojas lielākajai daļai lietotāju. Mēs aplūkojam, cik daudz klientu izmantoja atkāpšanos, ja viņi nevarēja saņemt pieprasījuma paātrinājumu. Mēs vidēji nedēļā saņemam mazāk par vienu kritisku brīdinājumu, lai gan sistēmā notiek daudz izmaiņu. Kāpēc mums ar to pietiek?
- Есть client fallback в случае если наша прокси не работает.
- Ir automātiska stūres sistēma, kas reaģē uz problēmām.
Sīkāka informācija par pēdējo. Mūsu izmēģinājuma sistēma un sistēma, kas automātiski nosaka optimālo ceļu pieprasījumiem no klienta uz mākoni, ļauj mums automātiski tikt galā ar dažām problēmām.
Atgriezīsimies pie mūsu parauga konfigurācijas un 3 ceļu kategorijām. Papildus iekraušanas laikam varam aplūkot pašu piegādes faktu. Ja nebija iespējams ielādēt datus, tad, aplūkojot rezultātus pa dažādiem ceļiem, mēs varam noteikt, kur un kas sabojājās, un vai mēs to varam automātiski salabot, mainot pieprasījuma ceļu.
Piemēri:
Šo procesu var automatizēt. Iekļaujiet to stūres sistēmā. Un iemāciet tai reaģēt uz veiktspējas un uzticamības problēmām. Ja kaut kas sāk plīst, reaģējiet, ja ir labāks risinājums. Tajā pašā laikā tūlītēja reakcija nav kritiska, pateicoties atkāpšanās no klientiem.
Tādējādi sistēmas atbalsta principus var formulēt šādi:
- bojājumu apjoma samazināšana;
- metriku vākšana;
- Ja iespējams, mēs automātiski novēršam bojājumus;
- ja tas nav iespējams, mēs jums paziņosim;
- Mēs strādājam pie informācijas paneļiem un šķirošanas rīku kopas, lai ātri reaģētu.
Gūtās mācības
Prototipa uzrakstīšana neaizņem daudz laika. Mūsu gadījumā tas bija gatavs pēc 4 mēnešiem. Ar to mēs saņēmām jaunus rādītājus, un 10 mēnešus pēc izstrādes sākuma saņēmām pirmo produkcijas trafiku. Tad sākās nogurdinošs un ļoti grūts darbs: pakāpeniski producējiet un mērogojiet sistēmu, migrējiet galveno trafiku un mācieties no kļūdām. Tomēr šis efektīvais process nebūs lineārs – neskatoties uz visiem pūliņiem, visu nevar paredzēt. Daudz efektīvāk ir ātri atkārtot un reaģēt uz jauniem datiem.
Pamatojoties uz mūsu pieredzi, mēs varam ieteikt sekojošo:
- Neuzticieties savai intuīcijai.
Наша интуиция подводила нас постоянно, несмотря на огромный опыт членов команды. Например, мы неправильно предсказывали ожидаемое ускорение от использования CDN прокси, или поведение TCP Anycast.
- Получайте данные из production.
Ir svarīgi pēc iespējas ātrāk piekļūt vismaz nelielam ražošanas datu apjomam. Laboratorijas apstākļos ir gandrīz neiespējami iegūt unikālu gadījumu, konfigurāciju un iestatījumu skaitu. Ātra piekļuve rezultātiem ļaus ātri uzzināt par iespējamām problēmām un ņemt tās vērā sistēmas arhitektūrā.
- Не следуйте чужим советам и результатам — собирайте свои данные.
Ievērojiet datu vākšanas un analīzes principus, bet akli nepieņemiet citu cilvēku rezultātus un izteikumus. Tikai jūs varat precīzi zināt, kas darbojas jūsu lietotājiem. Jūsu sistēmas un klienti var ievērojami atšķirties no citiem uzņēmumiem. Par laimi, analīzes rīki tagad ir pieejami un ērti lietojami. Iegūtie rezultāti var nebūt tādi, kādus apgalvo Netflix, Facebook, Akamai un citi uzņēmumi. Mūsu gadījumā TLS, HTTP2 vai statistikas veiktspēja DNS pieprasījumos atšķiras no Facebook, Uber, Akamai rezultātiem – jo mums ir dažādas ierīces, klienti un datu plūsmas.
- Не стремитесь за модными трендами без нужды и оценки эффективности.
Sāciet vienkārši. Labāk ir izveidot vienkāršu darba sistēmu īsā laikā, nekā tērēt milzīgu laiku, izstrādājot komponentus, kas jums nav vajadzīgi. Atrisiniet svarīgus uzdevumus un problēmas, pamatojoties uz jūsu mērījumiem un rezultātiem.
- Sagatavojieties jaunām lietojumprogrammām.
Tāpat kā visas problēmas ir grūti paredzēt, arī ieguvumus un pieteikumus ir grūti iepriekš paredzēt. Ņemiet vērā jaunuzņēmumu spēju pielāgoties klientu apstākļiem. Jūsu gadījumā jūs varat atklāt jaunas problēmas un to risinājumus. Mūsu projektā mēs izvirzījām mērķi samazināt pieprasījuma latentumu. Tomēr analīzes un diskusiju laikā mēs sapratām, ka mēs varam izmantot arī starpniekserverus:
- līdzsvarot satiksmi AWS reģionos un samazināt izmaksas;
- modelēt CDN stabilitāti;
- konfigurēt DNS;
- для конфигурирования TLS/TCP.
Secinājums
Pārskatā es aprakstīju, kā Netflix atrisina interneta pieprasījumu paātrināšanas problēmu starp klientiem un mākoni. Kā mēs apkopojam datus, izmantojot klientu paraugu ņemšanas sistēmu, un izmantojam savāktos vēsturiskos datus, lai novirzītu klientu ražošanas pieprasījumus pa ātrāko ceļu internetā. Kā mēs izmantojam tīkla protokolu principus, mūsu CDN infrastruktūru, mugurkaula tīklu un DNS serverus, lai sasniegtu šo uzdevumu.
Tomēr mūsu risinājums ir tikai piemērs tam, kā mēs Netflix ieviesām šādu sistēmu. Kas mums darbojās. Mana ziņojuma piemērotā daļa jums ir attīstības un atbalsta principi, kurus mēs ievērojam un sasniedzam labus rezultātus.
Наше решение проблемы вам может не подойти. Однако теория и принципы разработки остаются, даже если у вас нет собственной CDN инфраструктуры, или если она существенно отличается от нашей.
Также остается важность скорости запросов на бизнес. И даже для простого сервиса нужно делать выбор: между «облачными» провайдерами, местоположением серверов, CDN и DNS провайдерами. Ваш выбор будет влиять на эффективность интернет запросов для ваших клиентов. И для вас важно это влияние измерять и понимать.
Sāciet ar vienkāršiem risinājumiem, rūpējieties par to, kā mainīt produktu. Mācieties un uzlabojiet sistēmu, pamatojoties uz datiem no saviem klientiem, infrastruktūras un uzņēmuma. Padomājiet par neparedzētu bojājumu iespējamību projektēšanas procesā. Un tad jūs varat paātrināt izstrādes procesu, uzlabot risinājumu efektivitāti, izvairīties no nevajadzīga atbalsta sloga un gulēt mierīgi.
Šogad tiešsaistes formātā. Varat uzdot jautājumus vienam no DevOps tēviem, pašam Džonam Vilisam!
Avots: www.habr.com