Netflix интернет телекөрсөтүү рыногунда лидер - бул сегментти жараткан жана жигердүү өнүктүргөн компания. Netflix планетанын дээрлик бардык бурчунан жана дисплейи бар бардык түзмөктөрдө жеткиликтүү болгон тасмалардын жана сериалдардын кеңири каталогу менен гана эмес, ишенимдүү инфраструктурасы жана уникалдуу инженердик маданияты менен да белгилүү.
Татаал системаларды иштеп чыгууга жана колдоого Netflix мамилесинин айкын мисалы DevOops 2019да көрсөтүлдү - Netflixтин өнүктүрүү боюнча директору. Нижний Новгород мамлекеттик университетинин эсептөө математика-математика факультетинин бүтүрүүчүсү. Лобачевский, Сергей Open Connectдеги биринчи инженерлердин бири - Netflixтеги CDN командасы. Ал видеомаалыматтарды көзөмөлдөө жана талдоо системаларын курду, интернетке туташуу ылдамдыгын баалоо боюнча популярдуу кызматты ишке киргизди FAST.com жана акыркы бир нече жылдан бери Netflix тиркемеси колдонуучулар үчүн мүмкүн болушунча тезирээк иштеши үчүн интернет суроо-талаптарын оптималдаштыруунун үстүндө иштеп жатат.
Баяндама конференциянын катышуучуларынын эң жакшы сын-пикирлерин алды жана биз сиздер үчүн тексттик версиясын даярдадык.
Сергей езунун докладында толук айтып берди
- кардар менен сервердин ортосундагы интернет-суроолордун кечигишине эмне таасир этээри жөнүндө;
- бул кечиктирүүнү кантип азайтуу керек;
- каталарга чыдамдуу системаларды кантип долбоорлоо, тейлөө жана мониторинг жүргүзүү;
- кыска убакытта жана бизнес үчүн минималдуу тобокелдик менен натыйжаларга кантип жетүүгө болот;
- натыйжаларды талдоо жана каталардан кантип үйрөнүү керек.
Бул суроолорго жооп ири корпорацияларда иштегендерге гана керек эмес.
Сунушталган принциптерди жана ыкмаларды Интернет продуктуларын иштеп чыккан жана колдогон ар бир адам билиши жана колдонуусу керек.
Кийинки спикердин көз карашынан баяндоо.
Интернет ылдамдыгынын мааниси
Интернет-суроолордун ылдамдыгы бизнеске түздөн-түз байланыштуу. Соода тармагын карап көрөлү: Amazon 2009-жылы 100 мс кечиктирүү сатуунун 1% жоготууга алып келет.
Барган сайын мобилдик түзүлүштөр, андан кийин мобилдик сайттар жана тиркемелер бар. Эгер сиздин баракчаңызды жүктөөгө 3 секунддан ашык убакыт кетсе, колдонуучуларыңыздын жарымына жакынын жоготуп жатасыз. МЕНЕН Google издөө натыйжаларында баракчаңыздын жүктөө ылдамдыгын эске алат: барак канчалык ылдам болсо, анын Googleдагы орду ошончолук жогору болот.
Туташуу ылдамдыгы кечигүү өтө маанилүү болгон каржы институттарында да маанилүү. 2015-жылы, Hibernia Networks Нью-Йорк менен Лондондун ортосундагы 400 миллион долларлык кабель шаарлар ортосундагы кечиктирүүнү 6 мс кыскартуу үчүн. 66 мс кечиктирүүнү кыскартуу үчүн 1 миллион долларды элестетиңиз!
ылайык , 5 Мбит/секден жогору туташуу ылдамдыгы типтүү веб-сайттын жүктөө ылдамдыгына түздөн-түз таасирин тийгизбейт. Бирок, туташуу кечигүү жана баракты жүктөө ылдамдыгы ортосунда сызыктуу байланыш бар:
Бирок, Netflix типтүү продукт эмес. Колдонуучуга кечигүү жана ылдамдыктын таасири талдоо жана иштеп чыгуунун активдүү чөйрөсү болуп саналат. Кечирүү убактысына жараша тиркемени жүктөө жана мазмунду тандоо бар, бирок статикалык элементтерди жүктөө жана агым да туташуу ылдамдыгынан көз каранды. Колдонуучунун тажрыйбасына таасир этүүчү негизги факторлорду талдоо жана оптималдаштыруу Netflixтеги бир нече командалар үчүн активдүү өнүгүү багыты болуп саналат. Максаттардын бири - Netflix түзмөктөрү менен булут инфраструктурасынын ортосундагы суроо-талаптардын кечигүү убактысын азайтуу.
Отчетто биз Netflix инфраструктурасынын мисалын колдонуу менен кечиктирүүнү кыскартууга өзгөчө көңүл бурабыз. Татаал бөлүштүрүлгөн системаларды долбоорлоо, иштеп чыгуу жана эксплуатациялоо процесстерине кантип мамиле кылууну жана операциялык көйгөйлөрдү жана бузулууларды диагностикалоонун ордуна инновацияларга жана натыйжаларга убакыт коротууну практикалык көз караштан карап көрөлү.
Netflix ичинде
Миңдеген ар кандай түзмөктөр Netflix колдонмолорун колдойт. Алар Android, iOS, ТВ жана веб-браузерлер үчүн кардардын өзүнчө версияларын түзгөн төрт башка команда тарабынан иштелип чыккан. Жана биз колдонуучу тажрыйбасын жакшыртуу жана жекелештирүү үчүн көп күч жумшайбыз. Бул үчүн, биз параллелдүү жүздөгөн A/B тесттерин жүргүзөбүз.
Персоналдаштыруу AWS булутундагы жүздөгөн микросервистер тарабынан колдоого алынат, алар жекелештирилген колдонуучу маалыматтарын, сурамдарды жөнөтүүнү, телеметрияны, чоң маалыматтарды жана коддоону камсыз кылат. Трафиктин визуализациясы төмөнкүдөй көрүнөт:
Сол жакта кирүү чекити жайгашкан, андан кийин трафик ар кандай бэкенд топтору тарабынан колдоого алынган бир нече жүз микросервистерге бөлүштүрүлөт.
Биздин инфраструктуранын дагы бир маанилүү компоненти бул Open Connect CDN, ал акыркы колдонуучуга статикалык мазмунду - видеолорду, сүрөттөрдү, кардар кодун ж.б. CDN ыңгайлаштырылган серверлерде (OCA - Open Connect Appliance) жайгашкан. Ичинде NGINX жана кызматтардын топтому менен оптималдаштырылган FreeBSD менен иштеген SSD жана HDD дисктеринин массивдери бар. Биз мындай CDN сервери колдонуучуларга мүмкүн болушунча көбүрөөк маалыматтарды жөнөтө алышы үчүн аппараттык жана программалык камсыздоо компоненттерин иштеп чыгабыз жана оптималдаштырабыз.
Бул серверлердин Интернет-трафик алмашуу түйүнүндөгү (Internet eXchange - IX) "дубалы" төмөнкүдөй көрүнөт:
Internet Exchange Интернет-провайдерлерине жана контент провайдерлерине Интернетте маалымат алмашуу үчүн бири-бири менен "байланышууга" мүмкүнчүлүк берет. Дүйнө жүзү боюнча биздин серверлер орнотулган болжол менен 70-80 Интернет алмашуу түйүндөрү бар жана биз аларды өз алдынча орнотуп жана тейлейбиз:
Мындан тышкары, биз ошондой эле Netflix трафиктин локализациясын жана колдонуучулар үчүн агымдын сапатын жакшыртып, өз тармагына орноткон Интернет-провайдерлерге серверлерди түз беребиз:
AWS кызматтарынын топтому кардарлардан CDN серверлерине видео сурамдарды жөнөтүүгө, ошондой эле серверлердин өздөрүн конфигурациялоого - мазмунду, программалык кодду, жөндөөлөрдү ж.б. жаңыртуу үчүн жооптуу. Акыркысы үчүн, биз ошондой эле Интернет алмашуу пункттарындагы серверлерди AWS менен туташтырган магистралдык тармакты курдук. Магистралдык тармак – бул биздин муктаждыктарыбыздын негизинде долбоорлоо жана конфигурациялоо мүмкүн болгон була-оптикалык кабелдердин жана роутерлердин глобалдык тармагы.
боюнча , биздин CDN инфраструктурасы дүйнөдөгү интернет трафигинин болжол менен ⅛ бөлүгүн эң көп сааттарда жана трафиктин ⅓ бөлүгүн Netflix эң узакка созулган Түндүк Америкага жеткирет. Таасирдүү сандар, бирок мен үчүн эң таң калыштуу жетишкендиктердин бири - бүт CDN тутуму 150дөн аз кишиден турган команда тарабынан иштелип чыккан жана колдоого алынган.
Алгач CDN инфраструктурасы видеомаалыматтарды жеткирүү үчүн иштелип чыккан. Бирок, убакыттын өтүшү менен биз аны AWS булутундагы кардарлардын динамикалык суроо-талаптарын оптималдаштыруу үчүн да колдоно аларыбызды түшүндүк.
Интернетти тездетүү жөнүндө
Бүгүнкү күндө Netflixте 3 AWS аймагы бар жана булуттагы суроо-талаптардын кечигүү мөөнөтү кардардын жакынкы аймактан канчалык алыс экенине жараша болот. Ошол эле учурда бизде статикалык мазмунду жеткирүү үчүн колдонулган көптөгөн CDN серверлери бар. Динамикалык сурамдарды тездетүү үчүн бул негизди колдонуунун кандайдыр бир жолу барбы? Бирок, тилекке каршы, бул сурамдарды кэштөө мүмкүн эмес - API'лер жекелештирилген жана ар бир натыйжа уникалдуу.
CDN серверинде прокси жасап, ал аркылуу трафикти жөнөтө баштайлы. Тезирээк болобу?
Materiel
Тармактык протоколдор кантип иштээрин эстеп көрөлү. Бүгүнкү күндө Интернеттеги трафиктин көпчүлүгү төмөнкү катмардагы TCP жана TLS протоколдоруна көз каранды болгон HTTP'лерди колдонот. Кардар серверге туташуу үчүн, ал кол алышып учурашат жана коопсуз байланышты орнотуу үчүн кардар сервер менен үч жолу билдирүүлөрдү алмашуусу керек жана маалыматтарды өткөрүп берүү үчүн дагы бир жолудан кем эмес. 100 мс барабар сапар үчүн кечигүү (RTT) менен, маалыматтын биринчи битин алуу үчүн бизге 400 мс керектелет:
Эгерде биз сертификаттарды CDN серверине жайгаштырсак, анда CDN жакыныраак болсо, кардар менен сервердин кол алышуу убактысы бир топ кыскарышы мүмкүн. CDN серверинин күтүү убактысы 30 мс деп коёлу. Андан кийин биринчи битти алуу үчүн 220 мс талап кылынат:
Бирок артыкчылыктар муну менен эле бүтпөйт. Туташуу орнотулгандан кийин, TCP тыгын терезесин көбөйтөт (ал ошол туташуу аркылуу параллелдүү түрдө өткөрө турган маалыматтын көлөмү). Эгерде маалымат пакети жоголсо, анда TCP протоколунун классикалык ишке ашыруулары (мисалы, TCP New Reno) ачык "терезени" эки эсеге кыскартат. Тыгын терезесинин өсүшү жана аны жоготуудан калыбына келтирүү ылдамдыгы серверге кечигүүдөн (RTT) көз каранды. Бул байланыш CDN серверине чейин гана барса, бул калыбына келтирүү тезирээк болот. Ошол эле учурда, пакет жоготуу өзгөчө зымсыз тармактар үчүн стандарттуу көрүнүш болуп саналат.
Интернет өткөрүү жөндөмдүүлүгү, айрыкча, эң жогорку сааттарда колдонуучулардын трафигине байланыштуу кыскарышы мүмкүн, бул жол тыгынына алып келиши мүмкүн. Бирок, Интернетте кээ бир суроо-талаптарга башкаларга караганда артыкчылык берүүгө эч кандай жол жок. Мисалы, тармакты жүктөөчү "оор" маалымат агымдарына караганда кичине жана күтүү убактысын сезгич суроо-талаптарга артыкчылык бериңиз. Бирок, биздин учурда, өзүбүздүн магистралдык тармакка ээ болуу бизге муну суроо жолунун бир бөлүгүндө - CDN менен булуттун ортосунда жасоого мүмкүндүк берет жана биз аны толугу менен конфигурациялай алабыз. Кичинекей жана күтүү убактысына сезгич пакеттерге артыкчылык берилип, чоң маалымат агымы бир аз кийинчерээк кетээрин текшере аласыз. CDN кардарга канчалык жакын болсо, ошончолук эффективдүү болот.
Колдонмо деңгээлиндеги протоколдор (OSI 7-деңгээл) да күтүү убактысына таасирин тийгизет. HTTP/2 сыяктуу жаңы протоколдор параллелдүү сурамдардын иштешин оптималдаштырат. Бирок, бизде жаңы протоколдорду колдоого албаган эски түзмөктөрү бар Netflix кардарлары бар. Бардык кардарларды жаңыртуу же оптималдуу конфигурациялоо мүмкүн эмес. Ошол эле учурда, CDN прокси менен булуттун ортосунда толук башкаруу жана жаңы, оптималдуу протоколдорду жана орнотууларды колдонуу мүмкүнчүлүгү бар. Эски протоколдор менен натыйжасыз бөлүк кардар менен CDN серверинин ортосунда гана иштейт. Мындан тышкары, биз TCP деңгээлинде байланышты колдонууну жакшыртып, CDN менен булуттун ортосунда мурунтан эле орнотулган байланыш боюнча мультиплекстик суроо-талаптарды жасай алабыз:
Биз өлчөйбүз
Теория жакшыртууну убада кылгандыгына карабастан, биз системаны өндүрүшкө киргизүүгө дароо шашпайбыз. Андан көрө алгач идеянын иш жүзүндө ишке ашарын далилдешибиз керек. Бул үчүн сиз бир нече суроолорго жооп беришиңиз керек:
- ылдамдык: прокси тезирээк болобу?
- ишенимдүүлүк: Ал тез-тез бузулабы?
- татаалдыгы: тиркемелер менен кантип интеграциялоо керек?
- баасы: Кошумча инфраструктураны жайылтуу канча турат?
Биринчи пунктту баалоого болгон мамилебизди майда-чүйдөсүнө чейин карап көрөлү. Калгандары да ушундай жол менен каралат.
Сурамдардын ылдамдыгын талдоо үчүн, биз иштеп чыгууга көп убакыт коротпостон жана өндүрүштү бузбастан, бардык колдонуучулар үчүн маалыматтарды алууну каалайбыз. Бул үчүн бир нече ыкмалар бар:
- RUM, же пассивдүү суроо-талап өлчөө. Биз колдонуучулардын учурдагы суроо-талаптарын аткаруу убактысын өлчөп, колдонуучунун толук камтылышын камсыз кылабыз. Кемчилиги - сигналдын көптөгөн факторлордон улам, мисалы, суроо-талаптын ар кандай өлчөмдөрүнөн, серверде жана кардарда иштетүү убактысынан улам өтө туруктуу эмес. Мындан тышкары, сиз жаңы конфигурацияны өндүрүштө эффектсиз сынай албайсыз.
- Лабораториялык тесттер. Кардарларды окшоштурган атайын серверлер жана инфраструктура. Алардын жардамы менен биз керектүү анализдерди жүргүзөбүз. Мына ушундай жол менен биз өлчөө жыйынтыктарын толук көзөмөлдөп, так сигнал алабыз. Бирок түзмөктөрдү жана колдонуучу жайгашкан жерлерди толук камтуу жок (айрыкча бүткүл дүйнө жүзү боюнча кызмат көрсөтүү жана миңдеген түзмөк моделдерин колдоо менен).
Кантип эки ыкманын артыкчылыктарын айкалыштыра аласыз?
Биздин команда бир чечим тапты. Биз коддун кичинекей бөлүгүн жаздык - үлгү - аны биз колдонмобузга киргиздик. Зонддор биздин түзмөктөрдөн толугу менен башкарылган тармак сыноолорун жүргүзүүгө мүмкүндүк берет. Ал мындай иштейт:
- Тиркемени жүктөгөндөн жана баштапкы иш-аракетти аяктагандан көп өтпөй, биз изилдөөлөрүбүздү иштетебиз.
- Кардар серверге суроо-талап кылат жана тесттин "рецепт" алат. Рецепт бул HTTP(лер) сурамы жасалышы керек болгон URL даректеринин тизмеси. Мындан тышкары, рецепт сурамдын параметрлерин конфигурациялайт: сурамдардын ортосундагы кечигүү, суралган маалыматтардын көлөмү, HTTP(лардын) аталыштары ж.б. Ошол эле учурда, биз параллелдүү түрдө бир нече түрдүү рецепттерди сынай алабыз - конфигурацияны сураганда, кайсы рецептти чыгарууну туш келди аныктайбыз.
- Зондду ишке киргизүү убактысы кардардагы тармак ресурстарын активдүү колдонуу менен карама-каршы келбөө үчүн тандалат. Негизи, убакыт кардар активдүү болбогондо тандалат.
- Рецептти алгандан кийин кардар параллелдүү түрдө URL даректеринин ар бирине суроо-талаптарды берет. Даректердин ар бирине суроо-талап кайталанышы мүмкүн - деп аталган. "импульстар". Биринчи импульсте биз байланышты орнотууга жана маалыматтарды жүктөп алууга канча убакыт кеткенин өлчөйбүз. Экинчи импульс боюнча биз буга чейин орнотулган байланыш аркылуу маалыматтарды жүктөөгө кеткен убакытты өлчөйбүз. Үчүнчүсүнө чейин биз кечиктирүүнү коюп, кайра туташуунун ылдамдыгын өлчөй алабыз ж.б.
Сыноо учурунда биз аппарат ала турган бардык параметрлерди өлчөйбүз:
- DNS суроо убактысы;
- TCP байланышын орнотуу убактысы;
- TLS туташуусун орнотуу убактысы;
- маалыматтардын биринчи байт алуу убактысы;
- жалпы жүктөө убактысы;
- статустун натыйжасы коду.
- Бардык импульстар аяктагандан кийин, үлгү анализ үчүн бардык өлчөөлөрдү жүктөйт.
Негизги пункттар - кардардан логикага минималдуу көз карандылык, серверде маалыматтарды иштетүү жана параллелдүү суроо-талаптарды өлчөө. Ошентип, биз сурамдардын аткарылышына таасир этүүчү ар кандай факторлордун таасирин обочолонтуп, сынай алабыз, аларды бир рецепт боюнча өзгөртүп, чыныгы кардарлардан жыйынтыктарды ала алабыз.
Бул инфраструктура суроо-талаптын натыйжалуулугун талдоо үчүн гана пайдалуу экенин далилдеди. Учурда бизде 14 активдүү рецепттер, секундасына 6000ден ашык үлгүлөр бар, алар жердин бардык булуң-бурчтарынан маалыматтарды алууда жана аппаратты толук камтууда. Эгерде Netflix үчүнчү тараптан окшош кызматты сатып алса, анда ал жылына миллиондогон долларга чыгымдалып, андан да жаман камтууга ээ болмок.
Теорияны практикада сыноо: прототип
Мындай система менен биз CDN проксилеринин эффективдүүлүгүн суроо-талаптын кечигүү убактысында баалай алдык. Эми сизге керек:
- прототибин түзүү;
- прототибин CDNге жайгаштыруу;
- кардарларды белгилүү бир CDN сервериндеги проксиге кантип багыттоо керектигин аныктоо;
- Проксисиз AWSдеги сурамдар менен майнаптуулукту салыштырыңыз.
Сунуш кылынган чечимдин натыйжалуулугун мүмкүн болушунча тезирээк баалоо милдети турат. Биз жакшы тармактык китепканалардын болушуна байланыштуу прототибин ишке ашыруу үчүн Goну тандадык. Ар бир CDN серверинде көз карандылыкты азайтуу жана интеграцияны жөнөкөйлөтүү үчүн прототиби прототипти статикалык бинардык катары орноттук. Алгачкы ишке ашырууда биз стандарттык компоненттерди мүмкүн болушунча колдондук жана HTTP/2 туташуусун бириктирүү жана мультиплекстештирүү үчүн кичине өзгөртүүлөрдү колдондук.
AWS аймактарынын ортосундагы тең салмактуулук үчүн биз кардарларды тең салмактоо үчүн колдонулган географиялык DNS маалымат базасын колдондук. Кардар үчүн CDN серверин тандоо үчүн Internet Exchange (IX) серверлери үчүн TCP Anycast колдонобуз. Бул параметрде биз бардык CDN серверлери үчүн бир IP даректи колдонобуз жана кардар эң аз IP хоп саны менен CDN серверине багытталат. Интернет провайдерлери (ISP) орноткон CDN серверлеринде TCP Anycast конфигурациялоо үчүн роутерди көзөмөлдөй албайбыз, ошондуктан биз колдонобуз , ал кардарларды видео агым үчүн Интернет провайдерлерине багыттайт.
Ошентип, бизде суроо-талап жолдорунун үч түрү бар: ачык Интернет аркылуу булутка, IXтеги CDN сервери аркылуу же Интернет провайдеринде жайгашкан CDN сервери аркылуу. Биздин максат - суроо-талаптар өндүрүшкө кантип жөнөтүлгөнүнө салыштырмалуу, кайсы жол жакшыраак экенин жана проксидин кандай пайдасы бар экенин түшүнүү. Бул үчүн, биз төмөнкүдөй үлгү алуу системасын колдонобуз:
Ар бир жол өзүнчө бутага айланат, биз алган убакытты карайбыз. Талдоо үчүн биз прокси натыйжаларын бир топко бириктиребиз (IX жана ISP проксилеринин ортосундагы эң жакшы убакытты тандаңыз) жана аларды проксисиз булутка суроо-талаптардын убактысы менен салыштырабыз:
Көрүнүп тургандай, натыйжалар аралашкан - көпчүлүк учурларда прокси жакшы ылдамдыкты берет, бирок ошондой эле жагдай бир кыйла начарлай турган кардарлардын жетиштүү саны бар.
Натыйжада, биз бир нече маанилүү иштерди жасадык:
- Биз CDN прокси аркылуу булутка кардарлардын суроо-талаптарынын күтүлгөн натыйжалуулугун бааладык.
- Биз түзмөктөрдүн бардык түрлөрүнөн реалдуу кардарлардан маалыматтарды алдык.
- Биз теория 100% тастыкталбаганын жана CDN прокси менен баштапкы сунуш биз үчүн иштебей турганын түшүндүк.
- Биз тобокелчиликке барган жокпуз - кардарлар үчүн өндүрүш конфигурацияларын өзгөрткөн жокпуз.
- Эч нерсе бузулган жок.
Прототип 2.0
Ошентип, чийме тактасына кайтып, процессти кайра кайталаңыз.
Идея 100% проксиди колдонуунун ордуна, биз ар бир кардар үчүн эң ылдам жолду аныктап, ал жакка суроо-талаптарды жөнөтөбүз, башкача айтканда, биз кардарларды башкаруу деп аталган нерсени жасайбыз.
Муну кантип ишке ашыруу керек? Логиканы сервер тарабында колдоно албайбыз, анткени... Максат бул серверге туташуу. Бул кардар үчүн кандайдыр бир жол болушу керек. Идеалында, көп сандагы кардар платформалары менен интеграция маселесин чечпес үчүн, муну минималдуу татаал логика менен жасаңыз.
Жооп DNS колдонуу болуп саналат. Биздин учурда, өзүбүздүн DNS инфраструктурабыз бар жана биз серверлерибиз авторитардык боло турган домендик зонаны түзө алабыз. Ал мындай иштейт:
- Кардар DNS серверине хост аркылуу суроо салат, мисалы api.netflix.xom.
- Сурам биздин DNS серверибизге келет
- DNS сервери бул кардар үчүн кайсы жол эң ылдам экенин билет жана тиешелүү IP дарегин берет.
Чечимдин кошумча татаалдыгы бар: авторитардык DNS провайдерлери кардардын IP дарегин көрүшпөйт жана кардар колдонгон рекурсивдүү чечүүчүнүн IP дарегин гана окуй алышат.
Натыйжада, биздин авторитардык чечүүчү чечимди жеке кардар үчүн эмес, рекурсивдүү чечүүчүгө негизделген кардарлардын тобу үчүн кабыл алышы керек.
Чечүү үчүн биз ошол эле үлгүлөрдү колдонобуз, ар бир рекурсивдүү чечүүчү үчүн кардарлардын өлчөө жыйынтыктарын топтойбуз жана алардын бул тобун кайда жөнөтүүнү чечебиз - TCP Anycast аркылуу IX аркылуу прокси, ISP прокси аркылуу же түз булутка.
Биз төмөнкү системаны алабыз:
Алынган DNS башкаруу модели кардарлардан булутка туташуу ылдамдыгын тарыхый байкоолордун негизинде кардарларды багыттоого мүмкүндүк берет.
Дагы бир суроо, бул ыкма канчалык натыйжалуу иштейт? Жооп берүү үчүн, биз кайрадан иликтөө тутумубузду колдонобуз. Ошондуктан, биз алып баруучунун конфигурациясын конфигурациялайбыз, мында максаттардын бири DNS башкаруусунун багытын ээрчийт, экинчиси түздөн-түз булутка өтөт (учурдагы өндүрүш).
Натыйжада, биз натыйжаларды салыштырып, натыйжалуулугуна баа алабыз:
Натыйжада, биз бир нече маанилүү нерселерди үйрөндүк:
- Биз DNS Steering аркылуу кардарлардын булутка болгон суроо-талаптарынын күтүлгөн натыйжалуулугун бааладык.
- Биз түзмөктөрдүн бардык түрлөрүнөн реалдуу кардарлардан маалыматтарды алдык.
- Сунушталган идеянын натыйжалуулугу далилденген.
- Биз тобокелчиликке барган жокпуз - кардарлар үчүн өндүрүш конфигурацияларын өзгөрткөн жокпуз.
- Эч нерсе бузулган жок.
Эми татаал бөлүгү жөнүндө - биз аны өндүрүшкө киргизебиз
Жөнөкөй бөлүгү бүттү - жумушчу прототиби бар. Азыр кыйын бөлүгү 150 миллион колдонуучуга, миңдеген түзмөктөргө, жүздөгөн микросервистерге жана дайыма өзгөрүп туруучу өнүм менен инфраструктурага жайылтуу менен Netflixтин бардык трафиги үчүн чечимди ишке киргизүүдө. Netflix серверлери секундасына миллиондогон суроо-талаптарды кабыл алышат жана этиятсыздык менен кызматты бузуу оңой. Ошол эле учурда биз интернеттеги миңдеген CDN серверлери аркылуу трафикти динамикалык түрдө багыттоону каалайбыз, ал жерде бир нерсе тынымсыз жана эң ылайыксыз учурда өзгөрүп, бузулат.
Ушунун бардыгы менен командада системаны иштеп чыгуу, жайылтуу жана толук колдоо үчүн жооптуу 3 инженер бар.
Ошондуктан, биз тынч жана сергек уйку тууралуу сөздү улантабыз.
Кантип өнүгүүнү улантуу керек жана бардык убактыңызды колдоо үчүн коротпоңуз? Биздин мамилебиз 3 принципке негизделген:
- Биз бузулуулардын потенциалдуу масштабын азайтабыз (жардыруу радиусу).
- Биз сюрприздерге даярданып жатабыз - сыноолорго жана жеке тажрыйбага карабастан, бир нерсе бузулат деп күтөбүз.
- Сыйкырдуу деградация - эгер бир нерсе туура эмес иштесе, ал эң эффективдүү түрдө болбосо да, автоматтык түрдө оңдолушу керек.
Көрсө, биздин учурда көйгөйгө ушундай мамиле кылуу менен биз жөнөкөй жана эффективдүү чечим таап, тутумдук колдоону кыйла жөнөкөйлөштүрө алабыз. Биз кардарга коддун кичинекей бөлүгүн кошуп, туташуулардан улам келип чыккан тармактык суроо-талаптын каталарын көзөмөлдөй аларыбызды түшүндүк. Тармактык каталар болгон учурда, биз түздөн-түз булутка кайтарып алабыз. Бул чечим кардарлардын командалары үчүн олуттуу күч-аракетти талап кылбайт, бирок биз үчүн күтүүсүз бузулуулардын жана күтүлбөгөн окуялардын коркунучун бир топ азайтат.
Албетте, артка чегинүүгө карабастан, биз иштеп чыгууда так тартипти карманабыз:
- Үлгү тест.
- A/B тестирлөө же Канария.
- Прогрессивдүү жайылтуу.
Үлгүлөр менен мамиле сүрөттөлгөн - өзгөртүүлөр адегенде ылайыкташтырылган рецепт аркылуу текшерилет.
Канариялык тестирлөө үчүн биз системанын өзгөрүүлөргө чейин жана кийин кандай иштээрин салыштыра турган салыштырылуучу жуп серверлерди алышыбыз керек. Бул үчүн, биздин көптөгөн CDN сайттарыбыздан биз салыштырмалуу трафикти алган жуп серверлерди тандайбыз:
Андан кийин биз Canary серверине өзгөртүүлөр менен курууну орнотобуз. Натыйжаларды баалоо үчүн биз болжол менен 100-150 көрсөткүчтү Башкаруу серверлеринин үлгүсү менен салыштырган системаны иштетебиз:
Канариялык тестирлөө ийгиликтүү болсо, анда биз аны акырындык менен, толкундар менен чыгарабыз. Биз ар бир сайттагы серверлерди бир эле учурда жаңыртпайбыз – көйгөйлөрдөн улам бүтүндөй сайтты жоготуу ар башка жерлерде бирдей сандагы серверлерди жоготконго караганда колдонуучулар үчүн кызматка олуттуураак таасир этет.
Жалпысынан алганда, бул ыкманын натыйжалуулугу жана коопсуздугу чогултулган көрсөткүчтөрдүн санына жана сапатына көз каранды. Суроолорду тездетүү тутумубуз үчүн биз бардык мүмкүн болгон компоненттерден көрсөткүчтөрдү чогултабыз:
- кардарлардан - сеанстардын жана суроо-талаптардын саны, кайра кайтаруу ылдамдыгы;
- прокси - суроо-талаптардын саны жана убактысы боюнча статистика;
- DNS - суроо-талаптардын саны жана натыйжалары;
- булут чети - булуттагы суроо-талаптарды иштетүү үчүн сан жана убакыт.
Мунун баары бир түтүккө чогултулат жана муктаждыктарга жараша кайсы метриканы реалдуу убакыттагы аналитикага, кайсынысын Elasticsearch же Big Dataга деталдуу диагностикага жөнөтүүнү чечебиз.
Биз мониторинг жүргүзөбүз
Биздин учурда, биз кардар менен сервердин ортосундагы суроо-талаптардын критикалык жолунда өзгөртүүлөрдү киргизип жатабыз. Ошол эле учурда кардардагы, сервердеги жана Интернет аркылуу бара жаткан ар кандай компоненттердин саны абдан көп. Кардардагы жана сервердеги өзгөрүүлөр дайыма болуп турат - ондогон командалардын иштөөсү жана экосистемадагы табигый өзгөрүүлөр. Биз ортодо турабыз - көйгөйлөрдү аныктоодо, биз тартылууга жакшы мүмкүнчүлүк бар. Ошондуктан, көйгөйлөрдү тез бөлүп алуу үчүн көрсөткүчтөрдү кантип аныктоону, чогултууну жана талдоону так түшүнүшүбүз керек.
Идеалында, реалдуу убакыт режиминде метрикалардын жана чыпкалардын бардык түрлөрүнө толук мүмкүнчүлүк. Бирок метрика көп болгондуктан, нарк маселеси туулат. Биздин учурда, биз көрсөткүчтөрдү жана өнүктүрүү куралдарын төмөнкүдөй бөлөбүз:
Көйгөйлөрдү аныктоо жана аныктоо үчүн биз өзүбүздүн ачык булактуу реалдуу убакыт тутумубузду колдонобуз и - визуализация үчүн. Ал топтолгон көрсөткүчтөрдү эс тутумда сактайт, ишенимдүү жана эскертүү системасы менен интеграцияланат. Локалдаштыруу жана диагностика үчүн биз Elasticsearch жана Kibana журналдарына кире алабыз. Статистикалык талдоо жана моделдөө үчүн биз Tableau'да чоң маалыматтарды жана визуализацияны колдонобуз.
Бул ыкма менен иштөө абдан кыйын окшойт. Бирок, метрикаларды жана инструменттерди иерархиялык иретте уюштуруу менен биз көйгөйдү тез талдап, маселенин түрүн аныктап, андан соң деталдаштырылган метрикаларды тереңдете алабыз. Жалпысынан бузулуунун булагын аныктоого 1-2 мүнөттөй убакыт сарптайбыз. Андан кийин, биз диагностика боюнча белгилүү бир команда менен иштейбиз - ондогон мүнөттөн бир нече саатка чейин.
Диагноз тез эле коюлса да, биз мунун көп болушун каалабайбыз. Идеалында, биз кызматка олуттуу таасир тийгизгенде гана сындуу эскертүү алабыз. Сурамдарды тездетүү тутумубуз үчүн бизде 2 гана эскертүү бар:
- Client Fallback пайызы - кардар жүрүм-турумун баалоо;
- пайыздык Проб каталар - тармак компоненттеринин туруктуулук маалыматтар.
Бул критикалык эскертүүлөр системанын көпчүлүк колдонуучулар үчүн иштеп жатканын көзөмөлдөйт. Канча кардар суранычты тездетүүнү ала албаса, кайра кайтарууну колдонгонун карайбыз. Системада бир нече тонна өзгөрүүлөр болуп жатканына карабастан, биз жумасына орто эсеп менен 1 критикалык сигналдан азыраак кабар алабыз. Эмне үчүн бул бизге жетиштүү?
- Биздин прокси иштебесе, кардар артка кайтуу бар.
- Көйгөйлөргө жооп берүүчү автоматтык башкаруу системасы бар.
Акыркысы жөнүндө көбүрөөк маалымат. Биздин сынамык системабыз жана кардардан булутка суроо-талаптар үчүн оптималдуу жолду автоматтык түрдө аныктоо системасы кээ бир көйгөйлөрдү автоматтык түрдө чечүүгө мүмкүндүк берет.
Үлгү конфигурациябызга жана 3 жол категориясына кайрылып көрөлү. Жүктөө убактысынан тышкары, биз жеткирүү фактысын карай алабыз. Эгер берилиштерди жүктөө мүмкүн болбосо, анда ар кандай жолдор боюнча натыйжаларды карап, биз кайда жана эмне бузулганын аныктай алабыз жана сурам жолун өзгөртүү менен аны автоматтык түрдө оңдой алабызбы.
мисалдар:
Бул процессти автоматташтырууга болот. Аны башкаруу системасына киргизиңиз. Жана аны аткаруу жана ишенимдүүлүк көйгөйлөрүнө жооп берүүгө үйрөтүңүз. Эгер бир нерсе бузула баштаса, жакшыраак вариант бар болсо, реакция кылыңыз. Ошол эле учурда, кардарлардын артка кайтарылышы үчүн дароо реакция маанилүү эмес.
Ошентип, системаны колдоо принциптери төмөнкүчө түзүлүшү мүмкүн:
- бузулуу масштабын азайтуу;
- көрсөткүчтөрдү чогултуу;
- Мүмкүн болсо, бузулган жерлерди автоматтык түрдө оңдойбуз;
- мүмкүн эмес болсо, биз сизге кабарлайбыз;
- Тез жооп берүү үчүн биз инструменттердин панелдеринде жана триаж куралдарынын үстүндө иштеп жатабыз.
Үйрөнгөн сабактар
Прототипти жазуу көп убакытты талап кылбайт. Бизде болсо 4 айдан кийин даяр болгон. Аны менен биз жаңы көрсөткүчтөрдү алдык жана иштеп чыгуу башталгандан 10 ай өткөндөн кийин биз биринчи өндүрүштүк трафикти алдык. Андан кийин тажатма жана өтө татаал иш башталды: системаны акырындык менен өндүрүп, масштабдаңыз, негизги трафикти көчүрүңүз жана каталардан сабак алыңыз. Бирок, бул натыйжалуу процесс сызыктуу болбойт - бардык аракеттерге карабастан, бардыгын алдын ала айтуу мүмкүн эмес. Жаңы маалыматтарга тез итерациялоо жана жооп берүү алда канча натыйжалуу.
Тажрыйбабыздын негизинде биз төмөнкүлөрдү сунуштай алабыз:
- Интуицияңызга ишенбеңиз.
Биздин интуиция биздин команданын мүчөлөрүнүн чоң тажрыйбасына карабастан, бизди дайыма алсыз кылды. Мисалы, биз CDN проксисин колдонуудан күтүлгөн ылдамдыкты же TCP Anycast кыймыл-аракетин туура эмес алдын ала айтканбыз.
- Өндүрүштөн маалыматтарды алуу.
Бул мүмкүн болушунча тез, жок эле дегенде, бир аз өлчөмдө өндүрүштүк маалыматтарды алуу үчүн маанилүү болуп саналат. Лабораториялык шарттарда уникалдуу учурлардын, конфигурациялардын жана орнотуулардын санын алуу дээрлик мүмкүн эмес. Натыйжаларга тез жетүү мүмкүн болуучу көйгөйлөрдү тез билүүгө жана аларды системанын архитектурасында эске алууга мүмкүндүк берет.
- Башкалардын кеңештерин жана натыйжаларын аткарбаңыз - өзүңүздүн маалыматыңызды чогултуңуз.
Маалыматтарды чогултуу жана талдоо принциптерин сактаңыз, бирок башка адамдардын жыйынтыктарын жана билдирүүлөрүн сокур түрдө кабыл албаңыз. Колдонуучуларыңыз үчүн эмне иштээрин сиз гана биле аласыз. Сиздин системаларыңыз жана кардарларыңыз башка компаниялардан бир топ айырмаланышы мүмкүн. Бактыга жараша, талдоо куралдары азыр жеткиликтүү жана колдонууга оңой. Сиз алган натыйжалар Netflix, Facebook, Akamai жана башка компаниялар ырастагандай болбошу мүмкүн. Биздин учурда, TLS, HTTP2 же DNS суроо-талаптары боюнча статистиканын иштеши Facebook, Uber, Akamai натыйжаларынан айырмаланат - анткени бизде ар кандай түзмөктөр, кардарлар жана маалымат агымдары бар.
- Мода тенденцияларын негизсиз ээрчип, эффективдүүлүктү баалай бербеңиз.
Жөнөкөй баштаңыз. Керексиз компоненттерди иштеп чыгууга көп убакыт короткондон көрө, кыска убакыттын ичинде жөнөкөй жумушчу системаны жасаган жакшы. Өлчөөңүздүн жана натыйжаларыңыздын негизинде маанилүү болгон маселелерди жана маселелерди чечиңиз.
- Жаңы колдонмолорго даяр болуңуз.
Бардык көйгөйлөрдү алдын ала айтуу кыйын болгондой эле, пайдаларды жана колдонмолорду алдын ала айтуу кыйын. Стартаптардан үлгү алыңыз - алардын кардарлардын шарттарына көнүү жөндөмдүүлүгү. Сиздин учурда, сиз жаңы көйгөйлөрдү жана аларды чечүү жолдорун таба аласыз. Биздин долбоордо биз суроо-талаптын кечигүү убактысын азайтуу максатын койдук. Бирок, талдоо жана талкуулоо учурунда биз прокси серверлерди да колдоно аларыбызды түшүндүк:
- AWS аймактары боюнча трафикти тең салмактоо жана чыгымдарды азайтуу;
- CDN туруктуулугун моделдөө;
- DNS конфигурациялоо үчүн;
- TLS/TCP конфигурациялоо үчүн.
жыйынтыктоо
Отчетто мен Netflix кардарлар менен булуттун ортосундагы интернет суроо-талаптарын тездетүү маселесин кантип чечерин сүрөттөп бердим. Кантип биз кардарлар боюнча үлгү алуу тутумун колдонуу менен маалыматтарды чогултабыз жана чогултулган тарыхый маалыматтарды кардарлардын өндүрүш суроо-талаптарын Интернеттеги эң ылдам жол аркылуу багыттоо үчүн колдонобуз. Бул милдетке жетүү үчүн тармак протоколдорунун принциптерин, CDN инфраструктурабызды, магистралдык тармакты жана DNS серверлерди кантип колдонобуз.
Бирок, биздин чечимибиз Netflixте мындай системаны кантип ишке ашырганыбыздын бир мисалы гана. Бизге эмне иштеди. Сиздер үчүн менин баяндамамдын колдонулуучу бөлүгү - бул биз карманган жана жакшы натыйжаларга жетише турган өнүгүү жана колдоо принциптери.
Биздин көйгөйдү чечүү сизге туура келбеши мүмкүн. Бирок, теория жана дизайн принциптери сиздин CDN инфраструктураңыз жок болсо дагы же ал биздикинен олуттуу айырмаланса дагы.
Бизнес суроо-талаптарынын ылдамдыгынын маанилүүлүгү да маанилүү бойдон калууда. Жөнөкөй кызмат үчүн да тандоо керек: булут провайдерлери, сервердин жайгашкан жери, CDN жана DNS провайдерлеринин ортосунда. Сиздин тандооңуз кардарларыңыз үчүн Интернет-суроолордун натыйжалуулугуна таасир этет. Жана бул таасирди өлчөө жана түшүнүү сиз үчүн маанилүү.
Жөнөкөй чечимдерден баштаңыз, буюмду кантип өзгөртүүгө кам көрүңүз. Кардарларыңыздан, инфраструктураңыздан жана бизнесиңизден алынган маалыматтардын негизинде системаны жакшыртыңыз. Долбоорлоо процессинде күтүүсүз бузулуулардын ыктымалдыгы жөнүндө ойлонуңуз. Ошондо сиз иштеп чыгуу процессиңизди тездетип, чечимдин натыйжалуулугун жакшыртып, ашыкча колдоо жүктөмүнөн алыс болуп, тынч уктай аласыз.
Ушул жылы онлайн форматта. Сиз DevOps аталарынын бири Джон Уиллистин өзүнө суроо бере аласыз!
Source: www.habr.com