Արագացրեք ինտերնետի հարցումները և հանգիստ քնեք

Netflix-ը առաջատարն է ինտերնետ հեռուստատեսության շուկայում՝ ընկերությունը, որը ստեղծել և ակտիվորեն զարգացնում է այս հատվածը: Netflix-ը հայտնի է ոչ միայն ֆիլմերի և հեռուստասերիալների իր ընդարձակ կատալոգով, որոնք հասանելի են մոլորակի գրեթե բոլոր անկյուններից և էկրանով ցանկացած սարքով, այլև իր հուսալի ենթակառուցվածքով և եզակի ինժեներական մշակույթով:

Netflix-ի մոտեցման հստակ օրինակ՝ բարդ համակարգերի մշակման և աջակցության համար, ներկայացվել է DevOops 2019-ին։ Սերգեյ Ֆեդորով - Netflix-ի զարգացման գծով տնօրեն: Նիժնի Նովգորոդի պետական ​​համալսարանի հաշվողական մաթեմատիկայի և մաթեմատիկայի ֆակուլտետի շրջանավարտ: Լոբաչևսկին, Սերգեյը Open Connect - CDN թիմի առաջին ինժեներներից մեկն է Netflix-ում: Նա կառուցեց վիդեո տվյալների մոնիտորինգի և վերլուծության համակարգեր, գործարկեց ինտերնետ կապի արագության գնահատման հանրաճանաչ ծառայություն FAST.com, և վերջին մի քանի տարիների ընթացքում աշխատում էր ինտերնետի հարցումների օպտիմալացման վրա, որպեսզի Netflix հավելվածը հնարավորինս արագ աշխատի օգտատերերի համար:

Զեկույցը ստացել է համաժողովի մասնակիցների լավագույն ակնարկները, և մենք ձեզ համար պատրաստել ենք տեքստային տարբերակը:

Իր զեկույցում Սերգեյը մանրամասն խոսել է

• այն մասին, թե ինչն է ազդում հաճախորդի և սերվերի միջև ինտերնետ հարցումների հետաձգման վրա.
• ինչպես նվազեցնել այս ուշացումը;
• ինչպես նախագծել, պահպանել և վերահսկել սխալներին հանդուրժող համակարգեր;
• ինչպես հասնել արդյունքների կարճ ժամանակում և բիզնեսի համար նվազագույն ռիսկով.
• ինչպես վերլուծել արդյունքները և սովորել սխալներից:

Այս հարցերի պատասխաններն անհրաժեշտ են ոչ միայն նրանց, ովքեր աշխատում են խոշոր կորպորացիաներում։

Ներկայացված սկզբունքներն ու տեխնիկան պետք է իմանան և կիրառվեն բոլորի կողմից, ովքեր մշակում և աջակցում են ինտերնետի արտադրանքներին:

Հաջորդը խոսողի տեսանկյունից պատմվածքն է:

Ինտերնետի արագության կարևորությունը

Ինտերնետի հարցումների արագությունն ուղղակիորեն կապված է բիզնեսի հետ: Դիտարկենք գնումների արդյունաբերությունը՝ Amazon-ը 2009 թ ասացոր 100ms ուշացումը հանգեցնում է վաճառքի 1%-ի կորստի:

Կան ավելի ու ավելի շատ բջջային սարքեր, որոնց հաջորդում են բջջային կայքերն ու հավելվածները: Եթե ​​ձեր էջի բեռնումը տևում է ավելի քան 3 վայրկյան, դուք կկորցնեք ձեր օգտատերերի մոտ կեսը: ՀԵՏ 2018 թվականի հուլիս Google-ը հաշվի է առնում ձեր էջի բեռնման արագությունը որոնման արդյունքներում. որքան արագ է էջը, այնքան բարձր է նրա դիրքը Google-ում:

Միացման արագությունը նույնպես կարևոր է ֆինանսական հաստատություններում, որտեղ ուշացումը կարևոր է: 2015 թվականին Hibernia Networks ավարտված 400 միլիոն դոլար արժողությամբ մալուխ Նյու Յորքի և Լոնդոնի միջև՝ քաղաքների միջև ուշացումը 6 մվ-ով նվազեցնելու համար: Պատկերացրեք 66 միլիոն դոլար 1 մվ հետաձգման կրճատման համար:

Ըստ հետազոտություն, 5 Մբիթ/վրկ-ից բարձր կապի արագությունն այլևս ուղղակիորեն չի ազդում սովորական կայքի բեռնման արագության վրա։ Այնուամենայնիվ, կապի հետաձգման և էջի բեռնման արագության միջև գծային հարաբերություն կա.

Այնուամենայնիվ, Netflix-ը տիպիկ արտադրանք չէ: Լատենտության և արագության ազդեցությունը օգտագործողի վրա վերլուծության և զարգացման ակտիվ ոլորտ է: Կա հավելվածների բեռնում և բովանդակության ընտրություն, որոնք կախված են հետաձգումից, սակայն ստատիկ տարրերի բեռնումը և հոսքը նույնպես կախված են կապի արագությունից: Օգտատիրոջ փորձի վրա ազդող հիմնական գործոնների վերլուծությունը և օպտիմիզացումը Netflix-ի մի քանի թիմերի զարգացման ակտիվ ոլորտ է: Նպատակներից մեկը Netflix սարքերի և ամպային ենթակառուցվածքի միջև հարցումների հետաձգման նվազեցումն է։

Զեկույցում մենք կկենտրոնանանք հատկապես ուշացման նվազեցման վրա՝ օգտագործելով Netflix ենթակառուցվածքի օրինակը: Եկեք դիտարկենք գործնական տեսանկյունից, թե ինչպես մոտենալ բարդ բաշխված համակարգերի նախագծման, մշակման և շահագործման գործընթացներին և ժամանակ ծախսել նորարարությունների և արդյունքների վրա, այլ ոչ թե գործառնական խնդիրների և խափանումների ախտորոշման վրա:

Netflix-ի ներսում

Հազարավոր տարբեր սարքեր աջակցում են Netflix հավելվածներին: Դրանք մշակված են չորս տարբեր թիմերի կողմից, որոնք պատրաստում են հաճախորդի առանձին տարբերակներ Android-ի, iOS-ի, հեռուստատեսության և վեբ բրաուզերների համար։ Եվ մենք մեծ ջանքեր ենք ծախսում օգտատերերի փորձի բարելավման և անհատականացման վրա: Դա անելու համար մենք զուգահեռաբար կատարում ենք հարյուրավոր A/B թեստեր:

Անհատականացումը աջակցվում է AWS ամպի հարյուրավոր միկրոծառայությունների կողմից՝ տրամադրելով անհատականացված օգտատերերի տվյալներ, հարցումների ուղարկում, հեռաչափություն, մեծ տվյալներ և կոդավորում: Երթևեկության արտացոլումն ունի հետևյալ տեսքը.

Հղում դեպի տեսանյութը ցուցադրությամբ (6:04-6:23)

Ձախ կողմում մուտքի կետն է, այնուհետև երթևեկությունը բաշխվում է մի քանի հարյուր միկրոծառայությունների միջև, որոնք աջակցվում են տարբեր ետին թիմերի կողմից:

Մեր ենթակառուցվածքի մեկ այլ կարևոր բաղադրիչ է Open Connect CDN-ն, որը վերջնական օգտագործողին է տրամադրում ստատիկ բովանդակություն՝ տեսանյութեր, պատկերներ, հաճախորդի կոդը և այլն: CDN-ը գտնվում է մաքսային սերվերների վրա (OCA - Open Connect Appliance): Ներսում կան SSD և HDD կրիչներ, որոնք աշխատում են օպտիմիզացված FreeBSD-ով, NGINX-ով և մի շարք ծառայություններով: Մենք նախագծում և օպտիմիզացնում ենք ապարատային և ծրագրային բաղադրիչները, որպեսզի նման CDN սերվերը կարողանա հնարավորինս շատ տվյալներ ուղարկել օգտվողներին:

Այս սերվերների «պատը» ինտերնետ տրաֆիկի փոխանակման կետում (Internet eXchange - IX) ունի հետևյալ տեսքը.

Ինտերնետ փոխանակումը ինտերնետ ծառայություններ մատուցողներին և բովանդակության մատակարարներին հնարավորություն է տալիս «կապվել» միմյանց հետ՝ ինտերնետում ավելի անմիջականորեն տվյալներ փոխանակելու համար: Աշխարհում կան մոտավորապես 70-80 Ինտերնետ փոխանակման կետեր, որտեղ տեղադրված են մեր սերվերները, և մենք ինքնուրույն տեղադրում և պահպանում ենք դրանք.

Բացի այդ, մենք նաև սերվերներ ենք տրամադրում անմիջապես ինտերնետ պրովայդերներին, որոնք նրանք տեղադրում են իրենց ցանցում՝ բարելավելով Netflix-ի տրաֆիկի տեղայնացումը և օգտատերերի հոսքի որակը.

AWS ծառայությունների մի շարք պատասխանատու է հաճախորդներից վիդեո հարցումները CDN սերվերներ ուղարկելու, ինչպես նաև սերվերների կազմաձևման համար՝ թարմացնելով բովանդակությունը, ծրագրի կոդը, կարգավորումները և այլն: Վերջինիս համար մենք նաև կառուցել ենք հիմնական ցանց, որը միացնում է սերվերները Internet Exchange կետերում AWS-ով։ Հիմնական ցանցը օպտիկամանրաթելային մալուխների և երթուղիչների համաշխարհային ցանց է, որը մենք կարող ենք նախագծել և կարգավորել՝ ելնելով մեր կարիքներից:

On Sandvine գնահատականներ, մեր CDN ենթակառուցվածքն ապահովում է աշխարհի ինտերնետ տրաֆիկի մոտավորապես ⅛-ը պիկ ժամերին և թրաֆիկի ⅓-ը Հյուսիսային Ամերիկայում, որտեղ Netflix-ն ամենաերկարն է եղել: Տպավորիչ թվեր, բայց ինձ համար ամենահիասքանչ ձեռքբերումներից մեկն այն է, որ ամբողջ CDN համակարգը մշակված և պահպանվում է 150 հոգուց պակաս թիմի կողմից:

Սկզբում CDN ենթակառուցվածքը նախատեսված էր վիդեո տվյալներ տրամադրելու համար: Այնուամենայնիվ, ժամանակի ընթացքում մենք հասկացանք, որ մենք կարող ենք նաև օգտագործել այն AWS ամպում հաճախորդների դինամիկ հարցումները օպտիմալացնելու համար:

Ինտերնետի արագացման մասին

Այսօր Netflix-ն ունի 3 AWS տարածաշրջան, և ամպին ուղղված հարցումների ուշացումը կախված կլինի նրանից, թե հաճախորդը որքան հեռու է մոտակա տարածաշրջանից: Միևնույն ժամանակ, մենք ունենք բազմաթիվ CDN սերվերներ, որոնք օգտագործվում են ստատիկ բովանդակություն մատուցելու համար: Կա՞ որևէ միջոց այս շրջանակն օգտագործելու դինամիկ հարցումներն արագացնելու համար: Սակայն, ցավոք, անհնար է քեշավորել այս հարցումները. API-ները անհատականացված են, և յուրաքանչյուր արդյունք եզակի է:

Եկեք պրոքսի պատրաստենք CDN սերվերի վրա և սկսենք դրա միջոցով տրաֆիկ ուղարկել։ Ավելի արագ կլինի՞:

Նյութ

Եկեք հիշենք, թե ինչպես են աշխատում ցանցային արձանագրությունները: Այսօր ինտերնետում տրաֆիկի մեծ մասը օգտագործում է HTTP, որը կախված է TCP և TLS ստորին շերտերի արձանագրություններից: Որպեսզի հաճախորդը միանա սերվերին, այն կատարում է ձեռքսեղմում, իսկ անվտանգ կապ հաստատելու համար հաճախորդը պետք է երեք անգամ հաղորդագրություններ փոխանակի սերվերի հետ և առնվազն ևս մեկ անգամ՝ տվյալներ փոխանցելու համար: 100 ms մեկ շրջադարձի (RTT) հետաձգման դեպքում մեզանից կպահանջվի 400 ms տվյալների առաջին բիթ ստանալու համար.

Եթե ​​մենք տեղադրենք վկայագրերը CDN սերվերի վրա, ապա հաճախորդի և սերվերի միջև ձեռքսեղմման ժամանակը կարող է զգալիորեն կրճատվել, եթե CDN-ն ավելի մոտ է: Ենթադրենք, որ CDN սերվերի հետաձգումը 30ms է: Այնուհետև առաջին բիթը ստանալու համար կպահանջվի 220 ms.

Բայց առավելություններն այսքանով չեն ավարտվում: Կապ հաստատվելուց հետո TCP-ն մեծացնում է գերբեռնվածության պատուհանը (տեղեկատվության քանակությունը, որը կարող է փոխանցել այդ կապի վրա զուգահեռ): Եթե ​​տվյալների փաթեթը կորչում է, ապա TCP արձանագրության դասական իրականացումները (ինչպես TCP New Reno) կիսով չափ կրճատում են բաց «պատուհանը»: Խցանումների պատուհանի աճը և կորստից վերականգնելու արագությունը կրկին կախված է սերվերի հետաձգումից (RTT): Եթե ​​այս կապը հասնի միայն CDN սերվերին, ապա այս վերականգնումն ավելի արագ կլինի: Միևնույն ժամանակ, փաթեթների կորուստը ստանդարտ երևույթ է, հատկապես անլար ցանցերի համար:

Ինտերնետի թողունակությունը կարող է կրճատվել, հատկապես պիկ ժամերին, օգտվողների կողմից տրաֆիկի պատճառով, ինչը կարող է հանգեցնել խցանումների: Այնուամենայնիվ, ինտերնետում չկա որևէ կերպ առաջնահերթություն տալ որոշ խնդրանքներին մյուսների նկատմամբ: Օրինակ՝ առաջնահերթություն տվեք փոքր և հետաձգման նկատմամբ զգայուն հարցումներին՝ ցանցը բեռնող տվյալների «ծանր» հոսքերի փոխարեն: Այնուամենայնիվ, մեր դեպքում, մեր սեփական ողնաշարային ցանց ունենալը թույլ է տալիս դա անել հարցումների ուղու մի մասում՝ CDN-ի և ամպի միջև, և մենք կարող ենք ամբողջությամբ կարգավորել այն: Դուք կարող եք համոզվել, որ փոքր և հետաձգման նկատմամբ զգայուն փաթեթները առաջնահերթ են, և տվյալների մեծ հոսքերը մի փոքր ուշ են գնում: Որքան մոտ է CDN-ն հաճախորդին, այնքան մեծ է արդյունավետությունը:

Կիրառման մակարդակի արձանագրությունները (OSI մակարդակ 7) նույնպես ազդեցություն ունեն ուշացման վրա: Նոր արձանագրությունները, ինչպիսիք են HTTP/2-ը, օպտիմալացնում են զուգահեռ հարցումների կատարումը: Այնուամենայնիվ, մենք ունենք Netflix-ի հաճախորդներ ավելի հին սարքերով, որոնք չեն աջակցում նոր արձանագրությունները: Ոչ բոլոր հաճախորդները կարող են թարմացվել կամ օպտիմալ կերպով կազմաձևվել: Միևնույն ժամանակ, CDN վստահված անձի և ամպի միջև կա ամբողջական վերահսկողություն և նոր, օպտիմալ արձանագրություններ և կարգավորումներ օգտագործելու հնարավորություն: Հին արձանագրություններով անարդյունավետ մասը կգործի միայն հաճախորդի և CDN սերվերի միջև: Ավելին, մենք կարող ենք մուլտիպլեքսային հարցումներ կատարել CDN-ի և ամպի միջև արդեն հաստատված կապի վրա՝ բարելավելով կապի օգտագործումը TCP մակարդակում.

Մենք չափում ենք

Չնայած այն հանգամանքին, որ տեսությունը բարելավումներ է խոստանում, մենք անմիջապես չենք շտապում համակարգը գործարկել արտադրության մեջ: Փոխարենը նախ պետք է ապացուցել, որ գաղափարը գործնականում կաշխատի։ Դա անելու համար հարկավոր է պատասխանել մի քանի հարցերի.

• ԲարեմաղթելԱրդյո՞ք վստահված անձը ավելի արագ կլինի:
• Հուսալիություն:Այն ավելի հաճախ կկոտրվի՞:
• ԲարդությունԻնչպե՞ս ինտեգրվել հավելվածներին:
• ԱրժենալԻնչքա՞ն արժե լրացուցիչ ենթակառուցվածքի տեղակայումը:

Եկեք մանրամասն քննարկենք առաջին կետը գնահատելու մեր մոտեցումը: Մնացածը նույն կերպ են վարվում։

Հարցումների արագությունը վերլուծելու համար մենք ցանկանում ենք ստանալ տվյալներ բոլոր օգտատերերի համար՝ առանց մշակման վրա շատ ժամանակ ծախսելու և առանց արտադրությունը խախտելու։ Դրա համար կան մի քանի մոտեցումներ.

1. RUM կամ պասիվ պահանջի չափում: Մենք չափում ենք օգտատերերի ընթացիկ հարցումների կատարման ժամանակը և ապահովում օգտատերերի ամբողջական ծածկույթը: Թերությունն այն է, որ ազդանշանը շատ կայուն չէ բազմաթիվ գործոնների պատճառով, օրինակ՝ տարբեր հարցումների չափերի, սերվերի և հաճախորդի վրա մշակման ժամանակի պատճառով: Բացի այդ, դուք չեք կարող փորձարկել նոր կոնֆիգուրացիան առանց արտադրության մեջ ազդեցության:
2. Լաբորատոր թեստեր. Հատուկ սերվերներ և ենթակառուցվածք, որոնք մոդելավորում են հաճախորդներին: Նրանց օգնությամբ մենք իրականացնում ենք անհրաժեշտ հետազոտությունները։ Այս կերպ մենք ստանում ենք լիարժեք վերահսկողություն չափումների արդյունքների վրա և հստակ ազդանշան: Սակայն սարքերի և օգտատերերի գտնվելու վայրի ամբողջական ծածկույթ չկա (հատկապես ամբողջ աշխարհում սպասարկմամբ և հազարավոր սարքերի մոդելների աջակցությամբ):

Ինչպե՞ս կարող եք համատեղել երկու մեթոդների առավելությունները:

Մեր թիմը գտել է լուծումը. Մենք գրել ենք մի փոքրիկ կոդ՝ նմուշ, որը մենք ներկառուցել ենք մեր հավելվածում: Զոնդերը մեզ թույլ են տալիս կատարել ամբողջովին վերահսկվող ցանցային թեստեր մեր սարքերից: Այն աշխատում է այսպես.

1. Հավելվածը բեռնելուց և նախնական գործողությունն ավարտելուց անմիջապես հետո մենք գործարկում ենք մեր զոնդերը:
2. Հաճախորդը հարցում է կատարում սերվերին և ստանում «բաղադրատոմս» թեստի համար: Բաղադրատոմսը URL-ների ցանկն է, որոնց պետք է կատարվի HTTP(ներ)ի հարցում: Բացի այդ, բաղադրատոմսը կարգավորում է հարցումների պարամետրերը՝ հարցումների միջև ուշացումներ, պահանջվող տվյալների քանակը, HTTP(ներ)ի վերնագրերը և այլն: Միևնույն ժամանակ, մենք կարող ենք զուգահեռաբար փորձարկել մի քանի տարբեր բաղադրատոմսեր. կոնֆիգուրացիա խնդրելիս մենք պատահականորեն որոշում ենք, թե որ բաղադրատոմսը թողարկենք:
3. Զոնդի գործարկման ժամանակը ընտրված է այնպես, որ չհակասի հաճախորդի վրա ցանցային ռեսուրսների ակտիվ օգտագործմանը: Ըստ էության, ընտրվում է այն ժամանակը, երբ հաճախորդը ակտիվ չէ:
4. Բաղադրատոմսը ստանալուց հետո հաճախորդը հարցումներ է կատարում URL-ներից յուրաքանչյուրին՝ զուգահեռաբար: Հասցեներից յուրաքանչյուրին ուղղված հարցումը կարող է կրկնվել՝ այսպես կոչված. «զարկերակները». Առաջին զարկերակի վրա մենք չափում ենք, թե որքան ժամանակ է պահանջվել կապի հաստատման և տվյալների ներբեռնման համար: Երկրորդ իմպուլսի վրա մենք չափում ենք այն ժամանակը, որն անհրաժեշտ է տվյալների բեռնման համար արդեն հաստատված կապով: Երրորդից առաջ մենք կարող ենք ուշացում սահմանել և չափել վերամիացման հաստատման արագությունը և այլն։

   Փորձարկման ընթացքում մենք չափում ենք այն բոլոր պարամետրերը, որոնք սարքը կարող է ստանալ.

   • DNS հարցման ժամանակը;
   • TCP կապի տեղադրման ժամանակը;
   • TLS կապի տեղադրման ժամանակը;
   • տվյալների առաջին բայթ ստանալու ժամանակը.
   • ընդհանուր բեռնման ժամանակը;
   • կարգավիճակի արդյունքի կոդը:
5. Բոլոր իմպուլսների ավարտից հետո նմուշը բեռնում է բոլոր չափումները վերլուծության համար:

Հիմնական կետերն են հաճախորդից տրամաբանությունից նվազագույն կախվածությունը, սերվերի վրա տվյալների մշակումը և զուգահեռ հարցումների չափումը: Այսպիսով, մենք ի վիճակի ենք մեկուսացնել և ստուգել հարցումների կատարման վրա ազդող տարբեր գործոնների ազդեցությունը, փոփոխել դրանք մեկ բաղադրատոմսի շրջանակներում և արդյունքներ ստանալ իրական հաճախորդներից:

Այս ենթակառուցվածքն ապացուցել է, որ օգտակար է ոչ միայն հարցումների կատարողականի վերլուծության համար: Ներկայումս մենք ունենք 14 ակտիվ բաղադրատոմսեր, ավելի քան 6000 նմուշ վայրկյանում, տվյալների ստացում երկրի բոլոր անկյուններից և սարքի ամբողջական ծածկույթ: Եթե ​​Netflix-ը նման ծառայություն գներ երրորդ կողմից, ապա դա կարժենա տարեկան միլիոնավոր դոլարներ՝ շատ ավելի վատ ծածկույթով:

Փորձարկման տեսությունը գործնականում. նախատիպ

Նման համակարգով մենք կարողացանք գնահատել CDN վստահված անձանց արդյունավետությունը հարցումների հետաձգման դեպքում: Այժմ ձեզ անհրաժեշտ է.

• ստեղծել վստահված անձի նախատիպ;
• տեղադրել նախատիպը CDN-ի վրա;
• որոշել, թե ինչպես ուղղորդել հաճախորդներին վստահված անձին կոնկրետ CDN սերվերի վրա.
• Համեմատեք կատարումը առանց վստահված անձի AWS-ի հարցումների հետ:

Խնդիրն է հնարավորինս արագ գնահատել առաջարկվող լուծման արդյունավետությունը: Մենք ընտրեցինք Go՝ նախատիպն իրականացնելու համար՝ շնորհիվ լավ ցանցային գրադարանների առկայության: Յուրաքանչյուր CDN սերվերի վրա մենք տեղադրեցինք պրոքսի նախատիպը որպես ստատիկ երկուական՝ կախվածությունը նվազագույնի հասցնելու և ինտեգրումը պարզեցնելու համար: Սկզբնական ներդրման ժամանակ մենք հնարավորինս օգտագործեցինք ստանդարտ բաղադրիչներ և չնչին փոփոխություններ HTTP/2 կապի միավորման և հարցումների մուլտիպլեքսավորման համար:

AWS տարածաշրջանների միջև հավասարակշռելու համար մենք օգտագործեցինք աշխարհագրական DNS տվյալների բազա, նույնը, որն օգտագործվում էր հաճախորդներին հավասարակշռելու համար: Հաճախորդի համար CDN սերվեր ընտրելու համար մենք օգտագործում ենք TCP Anycast սերվերների համար Internet Exchange-ում (IX): Այս տարբերակում մենք օգտագործում ենք մեկ IP հասցե բոլոր CDN սերվերների համար, և հաճախորդը կուղղվի դեպի CDN սերվեր՝ նվազագույն թվով IP հոփերով: Ինտերնետ պրովայդերների (ISP) կողմից տեղադրված CDN սերվերներում մենք չենք վերահսկում երթուղիչը՝ TCP Anycast-ը կարգավորելու համար, ուստի մենք օգտագործում ենք նույն տրամաբանությունը, որը հաճախորդներին ուղղորդում է դեպի ինտերնետ պրովայդերներ՝ տեսանյութերի հոսքի համար:

Այսպիսով, մենք ունենք երեք տեսակի հարցումների ուղիներ՝ դեպի ամպ բաց ինտերնետի միջոցով, CDN սերվերի միջոցով IX-ում կամ CDN սերվերի միջոցով, որը գտնվում է ինտերնետ մատակարարում: Մեր նպատակն է հասկանալ, թե որ ճանապարհն է ավելի լավ, և որն է վստահված անձի օգուտը՝ համեմատած, թե ինչպես են հարցումներն ուղարկվում արտադրությանը: Դա անելու համար մենք օգտագործում ենք նմուշառման համակարգ հետևյալ կերպ.

Ճանապարհներից յուրաքանչյուրը դառնում է առանձին թիրախ, և մենք նայում ենք մեր ստացած ժամանակին: Վերլուծության համար մենք միավորում ենք վստահված անձի արդյունքները մեկ խմբի մեջ (ընտրում ենք լավագույն ժամանակը IX և ISP պրոքսիների միջև) և համեմատում դրանք առանց վստահված անձի ամպի հարցումների ժամանակի հետ.

Ինչպես տեսնում եք, արդյունքները տարբեր էին. շատ դեպքերում վստահված անձը լավ արագություն է տալիս, բայց կան նաև բավարար թվով հաճախորդներ, որոնց համար իրավիճակը զգալիորեն կվատթարանա:

Արդյունքում մենք արեցինք մի քանի կարևոր բան.

1. Մենք գնահատել ենք հաճախորդներից ամպին ուղղված հարցումների ակնկալվող կատարումը CDN վստահված անձի միջոցով:
2. Մենք տվյալներ ենք ստացել իրական հաճախորդներից, բոլոր տեսակի սարքերից:
3. Մենք հասկացանք, որ տեսությունը 100% հաստատված չէ, և CDN վստահված անձի հետ նախնական առաջարկը մեզ մոտ չի աշխատի:
4. Մենք ռիսկի չենք դիմել. մենք չենք փոխել արտադրության կոնֆիգուրացիան հաճախորդների համար:
5. Ոչինչ չի կոտրվել։

Նախատիպ 2.0

Այսպիսով, վերադարձեք նկարչական տախտակ և կրկնեք գործընթացը նորից:

Գաղափարն այն է, որ 100% պրոքսի օգտագործելու փոխարեն մենք յուրաքանչյուր հաճախորդի համար կորոշենք ամենաարագ ճանապարհը և այնտեղ հարցումներ կուղարկենք, այսինքն՝ կանենք այն, ինչ կոչվում է հաճախորդի ղեկ:

Ինչպե՞ս դա իրականացնել: Մենք չենք կարող օգտագործել տրամաբանությունը սերվերի կողմից, քանի որ... Նպատակը այս սերվերին միանալն է: Հաճախորդի վրա դա անելու ինչ-որ ձև պետք է լինի: Իդեալում, դա արեք նվազագույն քանակությամբ բարդ տրամաբանությամբ, որպեսզի չլուծեք մեծ թվով հաճախորդների պլատֆորմների հետ ինտեգրման հարցը:

Պատասխանը DNS-ի օգտագործումն է: Մեր դեպքում մենք ունենք մեր սեփական DNS ենթակառուցվածքը և կարող ենք ստեղծել տիրույթի գոտի, որի համար մեր սերվերները կլինեն ավտորիտար։ Այն աշխատում է այսպես.

1. Հաճախորդը հարցում է կատարում DNS սերվերին՝ օգտագործելով հոսթ, օրինակ՝ api.netflix.xom:
2. Հարցումը հասնում է մեր DNS սերվերին
3. DNS սերվերը գիտի, թե որ ուղին է ամենաարագը այս հաճախորդի համար և թողարկում է համապատասխան IP հասցեն:

Լուծումն ունի լրացուցիչ բարդություն՝ ավտորիտար DNS պրովայդերները չեն տեսնում հաճախորդի IP հասցեն և կարող են կարդալ միայն ռեկուրսիվ լուծիչի IP հասցեն, որն օգտագործում է հաճախորդը:

Արդյունքում, մեր ավտորիտար լուծումը պետք է որոշում կայացնի ոչ թե առանձին հաճախորդի, այլ հաճախորդների խմբի համար՝ հիմնված ռեկուրսիվ լուծիչի վրա:

Լուծելու համար մենք օգտագործում ենք նույն նմուշները, հավաքում ենք հաճախորդներից ստացված չափումների արդյունքները ռեկուրսիվ լուծիչներից յուրաքանչյուրի համար և որոշում, թե որտեղ ուղարկել նրանց այս խումբը՝ վստահված անձ IX-ի միջոցով՝ օգտագործելով TCP Anycast, ISP վստահված անձի միջոցով կամ ուղղակիորեն դեպի ամպ:

Մենք ստանում ենք հետևյալ համակարգը.

Ստացված DNS ղեկային մոդելը թույլ է տալիս ուղղորդել հաճախորդներին՝ հիմնվելով հաճախորդներից դեպի ամպ կապի արագության պատմական դիտարկումների վրա:

Կրկին հարցն այն է, թե որքանո՞վ արդյունավետ կգործի այս մոտեցումը: Պատասխանելու համար մենք կրկին օգտագործում ենք մեր զոնդային համակարգը: Հետևաբար, մենք կազմաձևում ենք ներկայացնողի կոնֆիգուրացիան, որտեղ թիրախներից մեկը հետևում է DNS ղեկի ուղղությանը, մյուսը գնում է անմիջապես դեպի ամպ (ընթացիկ արտադրություն):

Արդյունքում մենք համեմատում ենք արդյունքները և ստանում արդյունավետության գնահատում.

Արդյունքում մենք սովորեցինք մի քանի կարևոր բան.

1. Մենք գնահատել ենք հաճախորդներից ամպային հարցումների ակնկալվող կատարումը՝ օգտագործելով DNS Steering:
2. Մենք տվյալներ ենք ստացել իրական հաճախորդներից, բոլոր տեսակի սարքերից:
3. Առաջարկվող գաղափարի արդյունավետությունն ապացուցված է։
4. Մենք ռիսկի չենք դիմել. մենք չենք փոխել արտադրության կոնֆիգուրացիան հաճախորդների համար:
5. Ոչինչ չի կոտրվել։

Այժմ դժվարին մասի մասին՝ մենք այն թողարկում ենք արտադրության մեջ

Հեշտ մասն այժմ ավարտված է՝ կա աշխատանքային նախատիպ: Այժմ դժվար մասը լուծում է Netflix-ի ողջ տրաֆիկի համար՝ տեղակայելով 150 միլիոն օգտատերերի, հազարավոր սարքերի, հարյուրավոր միկրոծառայությունների և անընդհատ փոփոխվող արտադրանքի և ենթակառուցվածքների համար: Netflix-ի սերվերները վայրկյանում միլիոնավոր հարցումներ են ստանում, և անզգույշ գործողություններով հեշտ է կոտրել ծառայությունը։ Միևնույն ժամանակ, մենք ցանկանում ենք դինամիկ երթևեկել ինտերնետի հազարավոր CDN սերվերների միջոցով, որտեղ ինչ-որ բան փոխվում և կոտրվում է անընդհատ և ամենաանպատեհ պահին:

Եվ այս ամենի հետ մեկտեղ թիմն ունի 3 ինժեներ, որոնք պատասխանատու են համակարգի զարգացման, տեղակայման և ամբողջական աջակցության համար:

Ուստի մենք կշարունակենք խոսել հանգիստ և առողջ քնի մասին։

Ինչպե՞ս շարունակել զարգացումը և ամբողջ ժամանակը չծախսել աջակցության վրա: Մեր մոտեցումը հիմնված է 3 սկզբունքների վրա.

1. Մենք նվազեցնում ենք խափանումների հնարավոր մասշտաբները (պայթյունի շառավիղը):
2. Մենք պատրաստվում ենք անակնկալների. ակնկալում ենք, որ ինչ-որ բան կկոտրվի՝ չնայած փորձություններին և անձնական փորձին:
3. Նրբագեղ դեգրադացիա. եթե ինչ-որ բան ճիշտ չի աշխատում, այն պետք է ինքնաբերաբար շտկվի, նույնիսկ եթե ոչ ամենաարդյունավետ ձևով:

Պարզվեց, որ մեր դեպքում խնդրին այս մոտեցմամբ մենք կարող ենք գտնել պարզ և արդյունավետ լուծում և զգալիորեն պարզեցնել համակարգային աջակցությունը։ Մենք հասկացանք, որ կարող ենք հաճախորդին ավելացնել կոդի փոքր հատված և հետևել ցանցի հարցումների սխալներին, որոնք առաջացել են կապի խնդիրների պատճառով: Ցանցի սխալների դեպքում մենք հետադարձ ենք կատարում անմիջապես ամպին: Այս լուծումը չի պահանջում զգալի ջանք հաճախորդների թիմերի համար, բայց զգալիորեն նվազեցնում է մեզ համար անսպասելի խափանումների և անակնկալների ռիսկը:

Իհարկե, չնայած հետադարձին, մենք, այնուամենայնիվ, մշակման ընթացքում հետևում ենք հստակ կարգապահությանը.

1. Նմուշի թեստ.
2. A/B թեստավորում կամ Canaries.
3. Պրոգրեսիվ թողարկում:

Նմուշներով մոտեցումը նկարագրված է. փոփոխությունները նախ փորձարկվում են հարմարեցված բաղադրատոմսի միջոցով:

Դեղձանիկի փորձարկման համար մենք պետք է ստանանք համեմատելի զույգ սերվերներ, որոնց վրա մենք կարող ենք համեմատել, թե ինչպես է համակարգը աշխատում փոփոխություններից առաջ և հետո: Դա անելու համար մեր բազմաթիվ CDN կայքերից մենք ընտրում ենք սերվերների զույգեր, որոնք ստանում են համեմատելի տրաֆիկ.

Այնուհետև մենք տեղադրում ենք build-ը՝ փոփոխություններով Canary սերվերի վրա։ Արդյունքները գնահատելու համար մենք գործարկում ենք մի համակարգ, որը համեմատում է մոտավորապես 100-150 չափումներ Control սերվերների նմուշի հետ.

Եթե ​​Canary-ի փորձարկումը հաջող է, ապա մենք այն թողարկում ենք աստիճանաբար, ալիքներով: Մենք չենք թարմացնում սերվերները յուրաքանչյուր կայքում միաժամանակ. խնդիրների պատճառով ամբողջ կայքի կորցնելն ավելի էական ազդեցություն է ունենում օգտատերերի համար ծառայության վրա, քան տարբեր վայրերում նույն թվով սերվերների կորուստը:

Ընդհանուր առմամբ, այս մոտեցման արդյունավետությունն ու անվտանգությունը կախված է հավաքված չափումների քանակից և որակից: Մեր հարցումների արագացման համակարգի համար մենք չափումներ ենք հավաքում բոլոր հնարավոր բաղադրիչներից.

• հաճախորդներից - նիստերի և հարցումների քանակը, հետադարձ տոկոսադրույքները.
• վստահված անձ - հարցումների քանակի և ժամանակի վիճակագրություն.
• DNS - հարցումների քանակը և արդյունքները;
• ամպի եզր - ամպում հարցումների մշակման համարը և ժամանակը:

Այս ամենը հավաքվում է մեկ խողովակաշարի մեջ, և, կախված կարիքներից, մենք որոշում ենք, թե որ ցուցանիշներն ուղարկել իրական ժամանակի վերլուծություններին, և որոնք՝ Elasticsearch-ին կամ Big Data-ին՝ ավելի մանրամասն ախտորոշման համար:

Մենք վերահսկում ենք

Մեր դեպքում մենք փոփոխություններ ենք կատարում հաճախորդի և սերվերի միջև հարցումների կրիտիկական ճանապարհին: Միևնույն ժամանակ, հաճախորդի, սերվերի և ինտերնետի ճանապարհին տարբեր բաղադրիչների քանակը հսկայական է: Հաճախորդի և սերվերի փոփոխությունները տեղի են ունենում անընդհատ՝ տասնյակ թիմերի աշխատանքի և էկոհամակարգի բնական փոփոխությունների ընթացքում: Մենք մեջտեղում ենք. խնդիրները ախտորոշելիս մեծ հավանականություն կա, որ մենք ներգրավվենք: Հետևաբար, մենք պետք է հստակ հասկանանք, թե ինչպես սահմանել, հավաքել և վերլուծել չափումները՝ խնդիրներն արագ մեկուսացնելու համար:

Իդեալում, իրական ժամանակում բոլոր տեսակի չափումների և զտիչների լիարժեք հասանելիություն: Բայց չափիչները շատ են, ուստի ծախսերի հարց է առաջանում: Մեր դեպքում մենք առանձնացնում ենք չափումները և զարգացման գործիքները հետևյալ կերպ.

Խնդիրները հայտնաբերելու և ստուգելու համար մենք օգտագործում ենք մեր սեփական բաց կոդով իրական ժամանակի համակարգը Ատլաս и Lumen - վիզուալիզացիայի համար: Այն պահպանում է ագրեգացված ցուցանիշները հիշողության մեջ, հուսալի է և ինտեգրվում է ահազանգման համակարգին: Տեղայնացման և ախտորոշման համար մենք մուտք ունենք Elasticsearch-ի և Kibana-ի տեղեկամատյանները: Վիճակագրական վերլուծության և մոդելավորման համար մենք օգտագործում ենք մեծ տվյալներ և պատկերացում Tableau-ում:

Թվում է, թե այս մոտեցման հետ աշխատելը շատ դժվար է։ Այնուամենայնիվ, չափիչները և գործիքները հիերարխիկորեն կազմակերպելով՝ մենք կարող ենք արագ վերլուծել խնդիրը, որոշել խնդրի տեսակը և այնուհետև խորանալ մանրամասն չափումների մեջ: Ընդհանուր առմամբ, մենք ծախսում ենք մոտ 1-2 րոպե փլուզման աղբյուրը բացահայտելու համար: Դրանից հետո մենք աշխատում ենք կոնկրետ թիմի հետ ախտորոշման վրա՝ տասնյակ րոպեներից մինչև մի քանի ժամ:

Նույնիսկ եթե ախտորոշումն արագ արվի, մենք չենք ցանկանում, որ դա հաճախ տեղի ունենա: Իդեալում, մենք կստանանք միայն կրիտիկական ահազանգ, երբ ծառայության վրա զգալի ազդեցություն լինի: Մեր հարցումների արագացման համակարգի համար մենք ունենք միայն 2 ահազանգ, որոնք կտեղեկացնեն.

• Հաճախորդի հետադարձ տոկոսադրույքը - հաճախորդի վարքագծի գնահատում;
• տոկոսային զոնդերի սխալներ - ցանցի բաղադրիչների կայունության տվյալներ:

Այս կարևոր ազդանշանները վերահսկում են, թե արդյոք համակարգը աշխատում է օգտվողների մեծամասնության համար: Մենք նայում ենք, թե քանի հաճախորդ է օգտագործել հետադարձ կապը, եթե նրանք չեն կարողացել ստանալ հարցումների արագացում: Մենք շաբաթական միջինը 1 կրիտիկական ահազանգ ենք ստանում, չնայած որ համակարգում տեղի են ունենում տոննա փոփոխություններ: Ինչու՞ է սա մեզ բավարար:

1. Հաճախորդի հետադարձ կապ կա, եթե մեր վստահված անձը չի աշխատում:
2. Կա ղեկի ավտոմատ համակարգ, որն արձագանքում է խնդիրներին։

Վերջինիս մասին առավել մանրամասն։ Մեր փորձնական համակարգը և հաճախորդից դեպի ամպ հարցումների օպտիմալ ուղին ավտոմատ կերպով որոշելու համակարգը թույլ է տալիս մեզ ավտոմատ կերպով հաղթահարել որոշ խնդիրներ:

Եկեք վերադառնանք մեր նմուշի կոնֆիգուրացիային և 3 ուղիների կատեգորիաներին: Բացի բեռնման ժամանակից, մենք կարող ենք դիտել հենց առաքման փաստը: Եթե ​​հնարավոր չեղավ բեռնել տվյալները, ապա տարբեր ուղիներով արդյունքները դիտելով մենք կարող ենք որոշել, թե որտեղ և ինչն է կոտրվել, և արդյոք կարող ենք ավտոմատ կերպով ուղղել այն՝ փոխելով հարցումների ուղին:

Օրինակներ

Այս գործընթացը կարող է ավտոմատացված լինել: Ներառեք այն ղեկի համակարգում: Եվ սովորեցրեք նրան արձագանքել աշխատանքի և հուսալիության խնդիրներին: Եթե ​​ինչ-որ բան սկսում է կոտրվել, արձագանքեք, եթե կա ավելի լավ տարբերակ: Միևնույն ժամանակ, անհապաղ արձագանքը կարևոր չէ՝ շնորհիվ հաճախորդների հետադարձ կապի:

Այսպիսով, համակարգի աջակցության սկզբունքները կարող են ձևակերպվել հետևյալ կերպ.

• խափանումների մասշտաբների կրճատում;
• չափումների հավաքում;
• Մենք ավտոմատ կերպով վերանորոգում ենք վթարները, եթե կարող ենք.
• եթե դա չի կարող, մենք ձեզ տեղեկացնում ենք.
• Մենք աշխատում ենք վահանակների և տրիաժային գործիքների վրա՝ արագ արձագանքելու համար:

Քաղված դասերը

Նախատիպը գրելը շատ ժամանակ չի պահանջում: Մեր դեպքում այն ​​պատրաստ էր 4 ամիս անց։ Դրանով մենք ստացանք նոր չափումներ, իսկ զարգացման մեկնարկից 10 ամիս անց մենք ստացանք առաջին արտադրական տրաֆիկը։ Այնուհետև սկսվեց հոգնեցուցիչ և շատ դժվար աշխատանքը. աստիճանաբար արտադրեք և ընդլայնեք համակարգը, տեղափոխեք հիմնական տրաֆիկը և սովորեք սխալներից: Սակայն այս արդյունավետ գործընթացը գծային չի լինելու. չնայած բոլոր ջանքերին, ամեն ինչ հնարավոր չէ կանխատեսել։ Շատ ավելի արդյունավետ է արագ կրկնել և պատասխանել նոր տվյալներին:

Ելնելով մեր փորձից՝ մենք կարող ենք խորհուրդ տալ հետևյալը.

1. Մի վստահեք ձեր ինտուիցիային։

   Մեր ինտուիցիան անընդհատ ձախողում էր մեզ՝ չնայած մեր թիմի անդամների հսկայական փորձին: Օրինակ՝ մենք սխալ կանխատեսել ենք CDN վստահված անձի օգտագործման ակնկալվող արագությունը կամ TCP Anycast-ի վարքագիծը:

2. Ստացեք տվյալներ արտադրությունից:

   Կարևոր է հնարավորինս արագ մուտք ունենալ արտադրության առնվազն փոքր քանակությամբ տվյալների: Լաբորատոր պայմաններում գրեթե անհնար է ստանալ եզակի դեպքերի, կոնֆիգուրացիաների և պարամետրերի քանակը: Արդյունքների արագ մուտքը թույլ կտա արագ ծանոթանալ հնարավոր խնդիրների մասին և հաշվի առնել դրանք համակարգի ճարտարապետության մեջ:

3. Մի հետևեք այլ մարդկանց խորհուրդներին և արդյունքներին. հավաքեք ձեր սեփական տվյալները:

   Հետևեք տվյալների հավաքագրման և վերլուծության սկզբունքներին, բայց կուրորեն մի ընդունեք այլ մարդկանց արդյունքներն ու հայտարարությունները: Միայն դուք կարող եք հստակ իմանալ, թե ինչն է աշխատում ձեր օգտատերերի համար: Ձեր համակարգերը և ձեր հաճախորդները կարող են զգալիորեն տարբերվել այլ ընկերություններից: Բարեբախտաբար, վերլուծության գործիքներն այժմ հասանելի են և հեշտ օգտագործման համար: Ձեր ստացած արդյունքները կարող են չլինել այն, ինչ պնդում են Netflix-ը, Facebook-ը, Akamai-ն և այլ ընկերություններ: Մեր դեպքում, TLS-ի, HTTP2-ի կամ DNS հարցումների վիճակագրության կատարումը տարբերվում է Facebook-ի, Uber-ի, Akamai-ի արդյունքներից, քանի որ մենք ունենք տարբեր սարքեր, հաճախորդներ և տվյալների հոսքեր:

4. Մի հետևեք նորաձևության միտումներին և գնահատեք արդյունավետությունը:

   Սկսեք պարզ: Ավելի լավ է կարճ ժամանակում ստեղծել պարզ աշխատանքային համակարգ, քան հսկայական ժամանակ ծախսել բաղադրիչների մշակման վրա, որոնք ձեզ պետք չեն: Լուծեք խնդիրներ և խնդիրներ, որոնք կարևոր են ձեր չափումների և արդյունքների հիման վրա:

5. Պատրաստվեք նոր հավելվածներին։

   Ինչպես դժվար է կանխատեսել բոլոր խնդիրները, այնպես էլ դժվար է կանխատեսել առավելություններն ու կիրառությունները նախապես։ Վերցրեք հուշում սկսնակ ձեռնարկություններից՝ հաճախորդների պայմաններին հարմարվելու նրանց կարողությունը: Ձեր դեպքում կարող եք բացահայտել նոր խնդիրներ և դրանց լուծումներ։ Մեր նախագծում մենք նպատակ ենք դրել նվազեցնել հարցումների հետաձգումը: Այնուամենայնիվ, վերլուծության և քննարկումների ընթացքում մենք հասկացանք, որ մենք կարող ենք նաև օգտագործել պրոքսի սերվերներ.

   • հավասարակշռել երթևեկությունը AWS տարածաշրջաններում և նվազեցնել ծախսերը.
   • CDN կայունության մոդելավորում;
   • կարգավորել DNS;
   • TLS/TCP կարգավորելու համար:

Ամփոփում

Զեկույցում ես նկարագրեցի, թե ինչպես է Netflix-ը լուծում հաճախորդների և ամպի միջև ինտերնետի հարցումների արագացման խնդիրը: Ինչպես ենք մենք հավաքում տվյալներ՝ օգտագործելով հաճախորդների վրա ընտրանքային համակարգ և օգտագործում հավաքագրված պատմական տվյալները՝ հաճախորդներից արտադրական հարցումները ինտերնետի ամենաարագ ճանապարհով ուղղորդելու համար: Ինչպես ենք մենք օգտագործում ցանցային արձանագրությունների սկզբունքները, մեր CDN ենթակառուցվածքը, հիմնական ցանցը և DNS սերվերները այս առաջադրանքին հասնելու համար:

Այնուամենայնիվ, մեր լուծումը պարզապես օրինակ է, թե ինչպես մենք Netflix-ում ներդրեցինք նման համակարգ: Ինչն աշխատեց մեզ մոտ: Իմ զեկույցի կիրառական մասը ձեզ համար զարգացման և աջակցության սկզբունքներն են, որոնց մենք հետևում ենք և լավ արդյունքների ենք հասնում:

Խնդրի մեր լուծումը կարող է չհամապատասխանել ձեզ: Այնուամենայնիվ, տեսությունը և դիզայնի սկզբունքները մնում են, նույնիսկ եթե դուք չունեք ձեր սեփական CDN ենթակառուցվածքը, կամ եթե այն զգալիորեն տարբերվում է մերից:

Կարևոր է մնում նաև բիզնես հարցումների արագության կարևորությունը: Եվ նույնիսկ պարզ ծառայության համար դուք պետք է ընտրություն կատարեք՝ ամպային մատակարարների, սերվերի գտնվելու վայրի, CDN և DNS մատակարարների միջև: Ձեր ընտրությունը կազդի ձեր հաճախորդների համար ինտերնետային հարցումների արդյունավետության վրա: Եվ ձեզ համար կարևոր է չափել և հասկանալ այս ազդեցությունը:

Սկսեք պարզ լուծումներից, մտածեք, թե ինչպես եք փոխում ապրանքը: Սովորեք, ինչպես գնում եք և բարելավեք համակարգը՝ հիմնվելով ձեր հաճախորդների, ձեր ենթակառուցվածքի և ձեր բիզնեսի տվյալների վրա: Մտածեք նախագծման գործընթացում անսպասելի խափանումների հնարավորության մասին: Եվ հետո դուք կարող եք արագացնել ձեր զարգացման գործընթացը, բարելավել լուծման արդյունավետությունը, խուսափել ավելորդ աջակցության բեռից և հանգիստ քնել:

Այս տարի համաժողովը կանցկացվի հուլիսի 6-ից 10-ը առցանց ձևաչափով։ Դուք կարող եք հարցեր տալ DevOps-ի հայրերից մեկին՝ անձամբ Ջոն Ուիլիսին:

Source: www.habr.com