Netflix İnternet televiziya bazarında liderdir - bu seqmenti yaradan və fəal şəkildə inkişaf etdirən şirkətdir. Netflix təkcə planetin demək olar ki, hər yerindən və displeyi olan istənilən cihazdan əldə edilə bilən geniş film və serial kataloqu ilə deyil, həm də etibarlı infrastrukturu və unikal mühəndislik mədəniyyəti ilə tanınır.
Mürəkkəb sistemlərin işlənib hazırlanması və dəstəklənməsi üçün Netflix yanaşmasının bariz nümunəsi DevOops 2019-da təqdim olunub. - Netflix-in İnkişaf direktoru. Nijni Novqorod Dövlət Universitetinin hesablama riyaziyyatı və riyaziyyat fakültəsinin məzunu. Lobachevsky, Sergey Open Connect-in ilk mühəndislərindən biri - Netflix-də CDN komandası. O, video məlumatların monitorinqi və təhlili üçün sistemlər qurdu, İnternetə qoşulma sürətinin qiymətləndirilməsi üçün məşhur xidmət FAST.com-u işə saldı və son bir neçə il ərzində Netflix tətbiqinin istifadəçilər üçün mümkün qədər tez işləməsi üçün İnternet sorğularının optimallaşdırılması üzərində işləyir.
Hesabat konfrans iştirakçılarından ən yaxşı rəyləri aldı və biz sizin üçün mətn variantını hazırlamışıq.
Sergey məruzəsində ətraflı danışıb
- müştəri və server arasında İnternet sorğularının gecikməsinə nə təsir etdiyi haqqında;
- bu gecikməni necə azaltmaq olar;
- səhvlərə dözümlü sistemlərin necə layihələndirilməsi, saxlanması və monitorinqi;
- qısa müddətdə və biznes üçün minimal risklə nəticə əldə etmək;
- nəticələri təhlil etmək və səhvlərdən öyrənmək.
Bu suallara cavablar təkcə iri korporasiyalarda işləyənlərə lazım deyil.
Təqdim olunan prinsiplər və üsullar İnternet məhsullarını inkişaf etdirən və dəstəkləyən hər kəs tərəfindən bilməli və tətbiq edilməlidir.
Sonrakı, natiqin nöqteyi-nəzərindən rəvayətdir.
İnternet sürətinin əhəmiyyəti
İnternet sorğularının sürəti birbaşa bizneslə bağlıdır. Alış-veriş sənayesini nəzərdən keçirin: 2009-cu ildə Amazon 100 ms gecikmə satışın 1% itkisi ilə nəticələnir.
Getdikcə daha çox mobil qurğular, sonra isə mobil saytlar və proqramlar gəlir. Səhifənizin yüklənməsi 3 saniyədən çox çəkirsə, istifadəçilərinizin təxminən yarısını itirmiş olursunuz. İLƏ Google axtarış nəticələrində səhifənizin yüklənmə sürətini nəzərə alır: səhifə nə qədər sürətli olarsa, onun Google-da mövqeyi bir o qədər yüksəkdir.
Bağlantı sürəti gecikmənin kritik olduğu maliyyə institutlarında da vacibdir. 2015-ci ildə Hibernia Networks Nyu-York və London arasında 400 milyon dollarlıq kabel, şəhərlər arasında gecikməni 6 ms azaltmaq üçün. 66 ms gecikmənin azaldılması üçün 1 milyon dolları təsəvvür edin!
Uyğun olaraq , 5 Mbit/s-dən yuxarı qoşulma sürəti artıq tipik veb saytın yükləmə sürətinə birbaşa təsir göstərmir. Bununla belə, əlaqə gecikməsi və səhifə yükləmə sürəti arasında xətti əlaqə var:
Bununla belə, Netflix tipik bir məhsul deyil. Gecikmə və sürətin istifadəçiyə təsiri aktiv təhlil və inkişaf sahəsidir. Tətbiqlərin yüklənməsi və gecikmə müddətindən asılı olan məzmun seçimi var, lakin statik elementlərin yüklənməsi və axın da əlaqə sürətindən asılıdır. İstifadəçi təcrübəsinə təsir edən əsas amillərin təhlili və optimallaşdırılması Netflix-də bir neçə komanda üçün aktiv inkişaf sahəsidir. Məqsədlərdən biri Netflix cihazları və bulud infrastrukturu arasında sorğuların gecikməsini azaltmaqdır.
Hesabatda biz Netflix infrastrukturunun nümunəsindən istifadə edərək gecikmənin azaldılmasına xüsusi diqqət yetirəcəyik. Mürəkkəb paylanmış sistemlərin layihələndirilməsi, inkişafı və istismarı proseslərinə necə yanaşmaq və əməliyyat problemləri və nasazlıqların diaqnostikasından çox, yeniliklərə və nəticələrə vaxt sərf etməyi praktiki baxımdan nəzərdən keçirək.
Netflix daxilində
Minlərlə müxtəlif cihaz Netflix proqramlarını dəstəkləyir. Onlar Android, iOS, TV və veb brauzerlər üçün müştərinin ayrı-ayrı versiyalarını hazırlayan dörd fərqli komanda tərəfindən hazırlanır. Biz istifadəçi təcrübəsini təkmilləşdirmək və fərdiləşdirmək üçün çox səy sərf edirik. Bunun üçün paralel olaraq yüzlərlə A/B testi həyata keçiririk.
Fərdiləşdirmə AWS buludunda yüzlərlə mikroservis tərəfindən dəstəklənir, fərdiləşdirilmiş istifadəçi məlumatı, sorğu göndərilməsi, telemetriya, Böyük Məlumat və Kodlaşdırma təmin edilir. Trafik vizualizasiyası belə görünür:
Solda giriş nöqtəsi var və sonra trafik müxtəlif backend komandaları tərəfindən dəstəklənən bir neçə yüz mikroservis arasında paylanır.
İnfrastrukturumuzun digər mühüm komponenti son istifadəçiyə statik məzmunu - videolar, şəkillər, müştəri kodu və s. çatdıran Open Connect CDN-dir. CDN xüsusi serverlərdə yerləşir (OCA - Open Connect Appliance). İçəridə NGINX və bir sıra xidmətlər ilə optimallaşdırılmış FreeBSD ilə işləyən SSD və HDD diskləri massivləri var. Biz aparat və proqram komponentlərini belə bir CDN serverinin istifadəçilərə mümkün qədər çox məlumat göndərə bilməsi üçün dizayn edir və optimallaşdırırıq.
Bu serverlərin İnternet trafik mübadiləsi nöqtəsində (Internet eXchange - IX) "divarı" belə görünür:
İnternet Mübadiləsi İnternet xidmət təminatçıları və məzmun provayderləri üçün İnternetdə daha birbaşa məlumat mübadiləsi aparmaq üçün bir-biri ilə "qoşulmaq" imkanı verir. Dünyada serverlərimizin quraşdırıldığı təxminən 70-80 İnternet Mübadilə nöqtəsi var və biz onları müstəqil şəkildə quraşdırır və saxlayırıq:
Bundan əlavə, biz Netflix trafikinin lokallaşdırılmasını və istifadəçilər üçün axın keyfiyyətini yaxşılaşdıraraq, öz şəbəkələrində quraşdırdıqları serverləri birbaşa İnternet provayderlərinə təqdim edirik:
AWS xidmətləri dəsti müştərilərdən CDN serverlərinə video sorğuların göndərilməsinə, həmçinin serverlərin özünün konfiqurasiyasına cavabdehdir - məzmunun, proqram kodunun, parametrlərin yenilənməsi və s. Sonuncu üçün biz həmçinin İnternet Mübadilə nöqtələrindəki serverləri AWS ilə birləşdirən magistral şəbəkə qurmuşuq. Magistral şəbəkə ehtiyaclarımıza əsaslanaraq dizayn və konfiqurasiya edə biləcəyimiz fiber optik kabellər və marşrutlaşdırıcıların qlobal şəbəkəsidir.
Haqqında , bizim CDN infrastrukturumuz pik saatlarda dünya İnternet trafikinin təxminən ⅛ hissəsini və Netflix-in ən uzun müddət olduğu Şimali Amerikada trafikin ⅓ hissəsini təmin edir. Təsirli rəqəmlər, lakin mənim üçün ən heyrətamiz nailiyyətlərdən biri odur ki, bütün CDN sistemi 150 nəfərdən az olan bir komanda tərəfindən işlənib hazırlanır.
Əvvəlcə CDN infrastrukturu video məlumatların çatdırılması üçün nəzərdə tutulmuşdu. Bununla belə, zaman keçdikcə biz ondan AWS buludunda müştərilərin dinamik sorğularını optimallaşdırmaq üçün də istifadə edə biləcəyimizi başa düşdük.
İnternet sürətləndirilməsi haqqında
Bu gün Netflix-in 3 AWS bölgəsi var və buluda sorğuların gecikməsi müştərinin ən yaxın bölgədən nə qədər uzaq olmasından asılı olacaq. Eyni zamanda, statik məzmunu çatdırmaq üçün istifadə olunan çoxlu CDN serverlərimiz var. Dinamik sorğuları sürətləndirmək üçün bu çərçivədən istifadə etməyin hər hansı bir yolu varmı? Lakin, təəssüf ki, bu sorğuları keş etmək mümkün deyil - API-lər fərdiləşdirilmişdir və hər bir nəticə unikaldır.
CDN serverində proxy yaradaq və onun vasitəsilə trafik göndərməyə başlayaq. Daha sürətli olacaq?
Materiel
Şəbəkə protokollarının necə işlədiyini xatırlayaq. Bu gün İnternetdəki əksər trafik aşağı səviyyə protokollarından TCP və TLS-dən asılı olan HTTP-lərdən istifadə edir. Müştərinin serverə qoşulması üçün o, əl sıxma edir və təhlükəsiz əlaqə yaratmaq üçün müştəri serverlə üç dəfə mesaj mübadiləsi aparmalı və verilənlərin ötürülməsi üçün ən azı bir dəfə daha olmalıdır. Hər gediş üçün gecikmə (RTT) 100 ms ilə ilk məlumat bitini qəbul etmək bizə 400 ms vaxt aparacaq:
Sertifikatları CDN serverinə yerləşdirsək, CDN daha yaxın olarsa, müştəri ilə server arasında əl sıxma vaxtı əhəmiyyətli dərəcədə azaldıla bilər. Fərz edək ki, CDN serverinin gecikmə müddəti 30 ms-dir. Sonra ilk biti almaq üçün 220 ms vaxt lazımdır:
Ancaq üstünlüklər bununla bitmir. Bağlantı qurulduqdan sonra TCP sıxlıq pəncərəsini artırır (paralel olaraq həmin əlaqə üzərindən ötürə biləcəyi məlumatın miqdarı). Məlumat paketi itirilərsə, TCP protokolunun klassik tətbiqləri (məsələn, TCP New Reno) açıq "pəncərəni" yarıya endirir. Tıxac pəncərəsinin böyüməsi və itkidən bərpa sürəti yenidən serverə gecikmədən (RTT) asılıdır. Bu əlaqə yalnız CDN serverinə qədər gedirsə, bu bərpa daha sürətli olacaq. Eyni zamanda, paket itkisi xüsusilə simsiz şəbəkələr üçün standart bir hadisədir.
Xüsusilə pik saatlarda istifadəçilərdən gələn trafik səbəbindən internetin ötürmə qabiliyyəti azala bilər ki, bu da tıxaclara səbəb ola bilər. Bununla belə, İnternetdə bəzi istəkləri digərlərindən üstün tutmaq üçün heç bir yol yoxdur. Məsələn, şəbəkəni yükləyən “ağır” məlumat axınlarına nisbətən kiçik və gecikmə müddətinə həssas sorğulara üstünlük verin. Bununla belə, bizim vəziyyətimizdə, öz magistral şəbəkəmizə sahib olmaq bizə bunu sorğu yolunun bir hissəsində - CDN və bulud arasında etməyə imkan verir və biz onu tam şəkildə konfiqurasiya edə bilərik. Kiçik və gecikməyə həssas paketlərə üstünlük verildiyinə və böyük məlumat axınlarının bir az sonra getdiyinə əmin ola bilərsiniz. CDN müştəriyə nə qədər yaxındırsa, səmərəlilik də bir o qədər yüksəkdir.
Tətbiq səviyyəsinin protokolları (OSI Level 7) gecikmə müddətinə də təsir edir. HTTP/2 kimi yeni protokollar paralel sorğuların performansını optimallaşdırır. Bununla belə, yeni protokolları dəstəkləməyən köhnə cihazları olan Netflix müştərilərimiz var. Bütün müştərilər yenilənə və ya optimal şəkildə konfiqurasiya edilə bilməz. Eyni zamanda, CDN proksi ilə bulud arasında tam nəzarət və yeni, optimal protokol və parametrlərdən istifadə etmək imkanı var. Köhnə protokollarla səmərəsiz hissə yalnız müştəri ilə CDN serveri arasında işləyəcək. Bundan əlavə, biz TCP səviyyəsində əlaqə istifadəsini təkmilləşdirərək, CDN və bulud arasında artıq qurulmuş əlaqə üzrə multipleks sorğular edə bilərik:
Ölçürük
Nəzəriyyənin təkmilləşdirmələr vəd etməsinə baxmayaraq, biz dərhal sistemi istehsalda işə salmağa tələsmirik. Əvəzində ilk öncə ideyanın praktikada işləyəcəyini sübut etməliyik. Bunu etmək üçün bir neçə suala cavab verməlisiniz:
- Sürət: proxy daha sürətli olacaq?
- Etibarlılıq: Daha tez-tez pozulacaq?
- Mürəkkəblik: proqramlarla necə inteqrasiya etmək olar?
- dəyəri: Əlavə infrastrukturun yerləşdirilməsi nə qədər başa gəlir?
Birinci məqamı qiymətləndirməyə yanaşmamızı ətraflı nəzərdən keçirək. Qalanları oxşar şəkildə həll olunur.
Sorğuların sürətini təhlil etmək üçün biz inkişafa çox vaxt sərf etmədən və istehsalı pozmadan bütün istifadəçilər üçün məlumat əldə etmək istəyirik. Bunun üçün bir neçə yanaşma var:
- RUM və ya passiv sorğunun ölçülməsi. Biz istifadəçilərdən gələn cari sorğuların icra müddətini ölçür və tam istifadəçi əhatəsini təmin edirik. Dezavantaj odur ki, siqnal bir çox amillərə görə çox sabit deyil, məsələn, müxtəlif sorğu ölçüləri, serverdə və müştəridə emal müddəti. Bundan əlavə, istehsalda təsiri olmadan yeni konfiqurasiyanı sınaqdan keçirə bilməzsiniz.
- Laboratoriya testləri. Müştəriləri simulyasiya edən xüsusi serverlər və infrastruktur. Onların köməyi ilə biz lazımi testləri həyata keçiririk. Bu yolla ölçmə nəticələrinə tam nəzarət və aydın siqnal əldə edirik. Lakin cihazların və istifadəçi yerlərinin tam əhatə dairəsi yoxdur (xüsusilə dünya miqyasında xidmət və minlərlə cihaz modelləri üçün dəstək ilə).
Hər iki üsulun üstünlüklərini necə birləşdirə bilərsiniz?
Komandamız bir həll tapdı. Tətbiqimizə daxil etdiyimiz kiçik bir kod parçası - nümunə yazdıq. Zondlar bizə cihazlarımızdan tam idarə olunan şəbəkə testləri etməyə imkan verir. Bu belə işləyir:
- Proqramı yüklədikdən və ilkin fəaliyyəti tamamladıqdan qısa müddət sonra biz problarımızı işə salırıq.
- Müştəri serverə sorğu göndərir və test üçün “resept” alır. Resept HTTP(lər) sorğusunun edilməsi lazım olan URL-lərin siyahısıdır. Bundan əlavə, resept sorğu parametrlərini konfiqurasiya edir: sorğular arasındakı gecikmələr, tələb olunan məlumatların miqdarı, HTTP(lər) başlıqları və s. Eyni zamanda, biz paralel olaraq bir neçə müxtəlif resepti sınaqdan keçirə bilərik - konfiqurasiya tələb edərkən, biz təsadüfi olaraq hansı reseptin buraxılacağını müəyyənləşdiririk.
- Probun işə salınma vaxtı müştəridə şəbəkə resurslarının aktiv istifadəsi ilə ziddiyyət təşkil etməmək üçün seçilir. Əsasən, vaxt müştərinin aktiv olmadığı zaman seçilir.
- Resepti aldıqdan sonra müştəri paralel olaraq URL-lərin hər birinə sorğu göndərir. Ünvanların hər birinə sorğu təkrarlana bilər - sözdə. "nəbzlər". İlk nəbzdə əlaqə qurmaq və məlumat yükləmək üçün nə qədər vaxt lazım olduğunu ölçürük. İkinci nəbzdə, artıq qurulmuş bir əlaqə üzərindən məlumatların yüklənməsi üçün lazım olan vaxtı ölçürük. Üçüncüsündən əvvəl biz gecikmə təyin edə və yenidən əlaqə qurma sürətini ölçə bilərik və s.
Test zamanı cihazın əldə edə biləcəyi bütün parametrləri ölçürük:
- DNS sorğu vaxtı;
- TCP bağlantısının qurulması vaxtı;
- TLS bağlantısının qurulması vaxtı;
- məlumatın ilk baytını qəbul etmə vaxtı;
- ümumi yükləmə müddəti;
- statusun nəticəsi kodu.
- Bütün impulslar tamamlandıqdan sonra nümunə analiz üçün bütün ölçmələri yükləyir.
Əsas məqamlar müştəridən məntiqdən minimal asılılıq, serverdə məlumatların işlənməsi və paralel sorğuların ölçülməsidir. Beləliklə, biz sorğunun yerinə yetirilməsinə təsir edən müxtəlif amillərin təsirini təcrid edə və sınaqdan keçirə, onları bir resept çərçivəsində dəyişdirə və real müştərilərdən nəticələr əldə edə bilirik.
Bu infrastruktur yalnız sorğu performans təhlili üçün deyil, daha çox faydalı olduğunu sübut etdi. Hal-hazırda 14 aktiv reseptimiz, saniyədə 6000-dən çox nümunəmiz var, dünyanın bütün guşələrindən məlumat alır və cihazın tam əhatə dairəsi. Netflix üçüncü tərəfdən oxşar bir xidmət alsaydı, bu, daha pis əhatə dairəsi ilə ildə milyonlarla dollara başa gələcək.
Təcrübədə sınaq nəzəriyyəsi: prototip
Belə bir sistemlə biz sorğu gecikmə müddətində CDN proksilərinin effektivliyini qiymətləndirə bildik. İndi sizə lazımdır:
- proxy prototipini yaratmaq;
- prototipi CDN-ə yerləşdirin;
- müştərilərin müəyyən bir CDN serverindəki proksiyə necə yönləndiriləcəyini müəyyənləşdirin;
- Performansı proxy olmadan AWS-dəki sorğularla müqayisə edin.
Vəzifə təklif olunan həllin effektivliyini mümkün qədər tez qiymətləndirməkdir. Yaxşı şəbəkə kitabxanalarının mövcudluğuna görə prototipi həyata keçirmək üçün Go-nu seçdik. Hər bir CDN serverində asılılıqları minimuma endirmək və inteqrasiyanı sadələşdirmək üçün prototip proksisini statik binar kimi quraşdırdıq. İlkin tətbiqdə biz mümkün qədər standart komponentlərdən və HTTP/2 əlaqənin birləşdirilməsi və sorğu multipleksasiyası üçün kiçik dəyişikliklərdən istifadə etdik.
AWS bölgələri arasında tarazlıq yaratmaq üçün biz müştəriləri balanslaşdırmaq üçün istifadə edilən coğrafi DNS verilənlər bazasından istifadə etdik. Müştəri üçün CDN server seçmək üçün biz Internet Exchange (IX) serverləri üçün TCP Anycast istifadə edirik. Bu seçimdə biz bütün CDN serverləri üçün bir IP ünvanından istifadə edirik və müştəri ən az IP atlama sayı ilə CDN serverinə yönləndiriləcək. İnternet provayderləri (ISP) tərəfindən quraşdırılmış CDN serverlərində TCP Anycast-ı konfiqurasiya etmək üçün marşrutlaşdırıcıya nəzarətimiz yoxdur, ona görə də istifadə edirik , bu da müştəriləri video axını üçün İnternet provayderlərinə yönləndirir.
Beləliklə, üç növ sorğu yollarımız var: açıq İnternet vasitəsilə buluda, IX-də CDN server vasitəsilə və ya İnternet provayderində yerləşən CDN server vasitəsilə. Məqsədimiz, sorğuların istehsala necə göndərilməsi ilə müqayisədə hansı yolun daha yaxşı olduğunu və proxy-nin nə faydası olduğunu anlamaqdır. Bunu etmək üçün nümunə götürmə sistemindən aşağıdakı kimi istifadə edirik:
Yolların hər biri ayrı bir hədəfə çevrilir və əldə etdiyimiz vaxta baxırıq. Təhlil üçün biz proksi nəticələrini bir qrupda birləşdiririk (IX və ISP proksiləri arasında ən yaxşı vaxtı seçin) və onları proksisiz buludda sorğuların vaxtı ilə müqayisə edirik:
Gördüyünüz kimi, nəticələr qarışıq idi - əksər hallarda proksi yaxşı sürətləndirir, lakin vəziyyətin əhəmiyyətli dərəcədə pisləşəcəyi kifayət qədər sayda müştərilər də var.
Nəticədə bir neçə vacib iş gördük:
- CDN proksisi vasitəsilə müştərilərdən buluda edilən sorğuların gözlənilən performansını qiymətləndirdik.
- Biz real müştərilərdən, bütün növ cihazlardan məlumat aldıq.
- Nəzəriyyənin 100% təsdiqlənmədiyini və CDN proxy ilə ilkin təklifin bizim üçün işləməyəcəyini başa düşdük.
- Biz risk etmədik - müştərilər üçün istehsal konfiqurasiyalarını dəyişmədik.
- Heç nə pozulmayıb.
Prototip 2.0
Beləliklə, rəsm lövhəsinə qayıdın və prosesi yenidən təkrarlayın.
İdeya ondan ibarətdir ki, 100% proksidən istifadə etmək əvəzinə, biz hər bir müştəri üçün ən sürətli yolu müəyyənləşdirəcəyik və ora sorğular göndərəcəyik - yəni müştərinin idarə edilməsi deyilən işi edəcəyik.
Bunu necə həyata keçirmək olar? Biz server tərəfində məntiqdən istifadə edə bilmərik, çünki... Məqsəd bu serverə qoşulmaqdır. Müştəridə bunu etmək üçün bir yol olmalıdır. Və ideal olaraq, çox sayda müştəri platforması ilə inteqrasiya məsələsini həll etməmək üçün bunu minimum miqdarda mürəkkəb məntiqlə edin.
Cavab DNS istifadə etməkdir. Bizim vəziyyətimizdə öz DNS infrastrukturumuz var və serverlərimizin avtoritar olacağı bir domen zonası qura bilərik. Bu belə işləyir:
- Müştəri hostdan istifadə edərək DNS serverinə sorğu göndərir, məsələn, api.netflix.xom.
- Sorğu DNS serverimizə çatır
- DNS serveri bu müştəri üçün hansı yolun ən sürətli olduğunu bilir və müvafiq IP ünvanını verir.
Həllin əlavə mürəkkəbliyi var: avtoritar DNS provayderləri müştərinin IP ünvanını görmür və yalnız müştərinin istifadə etdiyi rekursiv həlledicinin IP ünvanını oxuya bilir.
Nəticədə, avtoritar həlledicimiz fərdi müştəri üçün deyil, rekursiv həlledici əsasında bir qrup müştəri üçün qərar verməlidir.
Həll etmək üçün biz eyni nümunələrdən istifadə edirik, rekursiv həlledicilərin hər biri üçün müştərilərin ölçmə nəticələrini ümumiləşdiririk və onların bu qrupunu hara göndərəcəyimizə qərar veririk - TCP Anycast istifadə edərək IX vasitəsilə proksi, ISP proksisi vasitəsilə və ya birbaşa bulud.
Aşağıdakı sistemi alırıq:
Nəticədə ortaya çıxan DNS idarəetmə modeli müştərilərdən buludla əlaqə sürətinin tarixi müşahidələri əsasında müştəriləri yönləndirməyə imkan verir.
Yenə sual yaranır ki, bu yanaşma nə dərəcədə effektiv işləyəcək? Cavab vermək üçün biz yenidən sonda sistemimizdən istifadə edirik. Buna görə də, biz aparıcının konfiqurasiyasını konfiqurasiya edirik, burada hədəflərdən biri DNS idarəçiliyindən istiqaməti izləyir, digəri birbaşa buluda (cari istehsal) gedir.
Nəticədə, nəticələri müqayisə edirik və effektivliyin qiymətləndirilməsini alırıq:
Nəticədə bir neçə vacib şeyi öyrəndik:
- Biz DNS Steering-dən istifadə edərək müştərilərdən buludlara edilən sorğuların gözlənilən performansını qiymətləndirdik.
- Biz real müştərilərdən, bütün növ cihazlardan məlumat aldıq.
- Təklif olunan ideyanın effektivliyi sübut edilmişdir.
- Biz risk etmədik - müştərilər üçün istehsal konfiqurasiyalarını dəyişmədik.
- Heç nə pozulmayıb.
İndi çətin hissə haqqında - biz onu istehsala buraxırıq
Asan hissə artıq bitdi - işləyən prototip var. İndi çətin hissə 150 milyon istifadəçiyə, minlərlə cihaza, yüzlərlə mikro xidmətə və daim dəyişən məhsul və infrastruktura yerləşdirərək Netflix-in bütün trafiki üçün həlli işə salmaqdır. Netflix serverləri saniyədə milyonlarla sorğu qəbul edir və diqqətsiz hərəkətlə xidməti pozmaq asandır. Eyni zamanda, biz internetdə nəyinsə daim və ən uyğun olmayan anda dəyişdiyi və pozulduğu minlərlə CDN serverləri vasitəsilə dinamik şəkildə trafik yönləndirmək istəyirik.
Bütün bunlarla birlikdə komandada sistemin inkişafı, yerləşdirilməsi və tam dəstəklənməsi üçün məsul olan 3 mühəndis var.
Buna görə də biz dincəl və sağlam yuxu haqqında danışmağa davam edəcəyik.
İnkişafı necə davam etdirmək və bütün vaxtınızı dəstəyə sərf etməmək olar? Bizim yanaşmamız 3 prinsipə əsaslanır:
- Biz qəzaların potensial miqyasını azaldır (partlayış radiusu).
- Sürprizlərə hazırlaşırıq - sınaqlara və şəxsi təcrübəyə baxmayaraq, nəyinsə qırılacağını gözləyirik.
- Zərif deqradasiya - bir şey düzgün işləmirsə, ən səmərəli şəkildə olmasa belə, avtomatik olaraq düzəldilməlidir.
Məlum oldu ki, bizim vəziyyətimizdə problemə bu cür yanaşma ilə sadə və effektiv həll yolu tapa və sistem dəstəyini əhəmiyyətli dərəcədə sadələşdirə bilərik. Biz başa düşdük ki, müştəriyə kiçik bir kod parçası əlavə edə və əlaqə problemlərinin yaratdığı şəbəkə sorğusu xətalarına nəzarət edə bilərik. Şəbəkə xətaları halında, biz birbaşa buludda geri dönüş edirik. Bu həll müştəri komandaları üçün ciddi səy tələb etmir, lakin bizim üçün gözlənilməz nasazlıqlar və sürprizlər riskini xeyli azaldır.
Əlbəttə ki, geriləmələrə baxmayaraq, biz inkişaf zamanı aydın bir nizam-intizamı izləyirik:
- Test nümunəsi.
- A/B testi və ya Kanarya adaları.
- Proqressiv yayım.
Nümunələr ilə yanaşma təsvir edilmişdir - dəyişikliklər əvvəlcə fərdiləşdirilmiş reseptdən istifadə etməklə sınaqdan keçirilir.
Kanareyka testi üçün sistemin dəyişikliklərdən əvvəl və sonra necə işlədiyini müqayisə edə biləcəyimiz müqayisə edilə bilən cüt serverlər əldə etməliyik. Bunu etmək üçün çoxlu CDN saytlarımızdan müqayisə olunan trafiki qəbul edən cüt serverləri seçirik:
Sonra Canary serverində dəyişikliklərlə quruluşu quraşdırırıq. Nəticələri qiymətləndirmək üçün biz təxminən 100-150 göstəricini Nəzarət serverləri nümunəsi ilə müqayisə edən sistem işlədirik:
Canary testi uğurlu olarsa, biz onu tədricən, dalğalarla buraxırıq. Biz hər bir saytdakı serverləri eyni vaxtda yeniləmirik - problemlər səbəbindən bütöv bir saytın itirilməsi müxtəlif yerlərdə eyni sayda serveri itirməkdənsə, istifadəçilər üçün xidmətə daha əhəmiyyətli təsir göstərir.
Ümumiyyətlə, bu yanaşmanın effektivliyi və təhlükəsizliyi toplanmış göstəricilərin kəmiyyət və keyfiyyətindən asılıdır. Sorğunun sürətləndirilməsi sistemimiz üçün biz bütün mümkün komponentlərdən ölçüləri toplayırıq:
- müştərilərdən - sessiyaların və sorğuların sayı, geri qaytarılma dərəcələri;
- proxy - sorğuların sayı və vaxtı haqqında statistika;
- DNS - sorğuların sayı və nəticələri;
- bulud kənarı - buludda sorğuların işlənməsi üçün nömrə və vaxt.
Bütün bunlar bir boru kəmərində toplanır və ehtiyaclardan asılı olaraq, biz hansı ölçüləri real vaxt analitikasına, hansını isə daha ətraflı diaqnostika üçün Elasticsearch və ya Big Data-ya göndərəcəyimizə qərar veririk.
Biz monitorinq edirik
Bizim vəziyyətimizdə müştəri və server arasında sorğuların kritik yolunda dəyişikliklər edirik. Eyni zamanda, müştəridə, serverdə və İnternetdən keçərkən müxtəlif komponentlərin sayı çox böyükdür. Müştəri və serverdə dəyişikliklər daim - onlarla komandanın işi və ekosistemdə təbii dəyişikliklər zamanı baş verir. Biz ortadayıq - problemlərin diaqnostikasında iştirak etmək şansımız yüksəkdir. Buna görə də, problemləri tez bir zamanda təcrid etmək üçün metrikləri necə müəyyənləşdirmək, toplamaq və təhlil etmək lazım olduğunu aydın şəkildə başa düşməliyik.
İdeal olaraq, real vaxt rejimində bütün növ ölçülərə və filtrlərə tam giriş. Ancaq bir çox göstərici var, buna görə də qiymət sualı yaranır. Bizim vəziyyətimizdə ölçüləri və inkişaf alətlərini aşağıdakı kimi ayırırıq:
Problemləri aşkar etmək və yoxlamaq üçün biz öz açıq mənbəli real vaxt sistemimizdən istifadə edirik и - vizuallaşdırma üçün. O, yığılmış ölçüləri yaddaşda saxlayır, etibarlıdır və xəbərdarlıq sistemi ilə inteqrasiya edir. Lokallaşdırma və diaqnostika üçün Elasticsearch və Kibana-dan qeydlərə girişimiz var. Statistik təhlil və modelləşdirmə üçün biz Tableau-da böyük verilənlərdən və vizuallaşdırmadan istifadə edirik.
Görünür, bu yanaşma ilə işləmək çox çətindir. Bununla belə, ölçüləri və alətləri iyerarxik şəkildə təşkil etməklə, biz problemi tez təhlil edə, problemin növünü təyin edə və sonra təfərrüatlı ölçülərə keçə bilərik. Ümumiyyətlə, qəzanın mənbəyini müəyyən etmək üçün təxminən 1-2 dəqiqə vaxt sərf edirik. Bundan sonra biz müəyyən bir qrupla diaqnostika üzrə işləyirik - on dəqiqədən bir neçə saata qədər.
Diaqnoz tez qoyulsa belə, bunun tez-tez baş verməsini istəmirik. İdeal olaraq, biz yalnız xidmətə əhəmiyyətli təsir olduqda kritik xəbərdarlıq alacağıq. Sorğu sürətləndirmə sistemimiz üçün bildiriş verəcək yalnız 2 siqnalımız var:
- Client Fallback faizi - müştəri davranışının qiymətləndirilməsi;
- faiz Probe səhvləri - şəbəkə komponentlərinin sabitlik məlumatları.
Bu kritik xəbərdarlıqlar sistemin əksər istifadəçilər üçün işlədiyini izləyir. Nə qədər müştərinin sorğu sürətləndirilməsini əldə edə bilmədiyi halda geri dönüşdən istifadə etdiyinə baxırıq. Sistemdə bir ton dəyişiklik olsa da, həftədə orta hesabla 1 kritik siqnaldan az alırıq. Niyə bu bizim üçün kifayətdir?
- Proksi işləmirsə, müştəri geri dönüşü var.
- Problemlərə cavab verən avtomatik sükan sistemi var.
Sonuncu haqqında ətraflı məlumat. Sınaq sistemimiz və müştəridən buludda olan sorğular üçün optimal yolu avtomatik müəyyən edən sistem bizə bəzi problemlərin avtomatik öhdəsindən gəlməyə imkan verir.
Nümunə konfiqurasiyamıza və 3 yol kateqoriyamıza qayıdaq. Yükləmə müddətinə əlavə olaraq, çatdırılma faktına da baxa bilərik. Məlumatları yükləmək mümkün olmadıqda, müxtəlif yollar üzrə nəticələrə baxaraq, harada və nəyin pozulduğunu və sorğu yolunu dəyişdirərək avtomatik olaraq düzəldə biləcəyimizi müəyyən edə bilərik.
Nümunələr:
Bu proses avtomatlaşdırıla bilər. Onu sükan sisteminə daxil edin. Və ona performans və etibarlılıq problemlərinə cavab verməyi öyrədin. Bir şey qırılmağa başlasa, daha yaxşı bir seçim varsa reaksiya verin. Eyni zamanda, müştərilərin geri dönüşü sayəsində dərhal reaksiya kritik deyil.
Beləliklə, sistem dəstəyinin prinsipləri aşağıdakı kimi formalaşdırıla bilər:
- qəzaların miqyasının azaldılması;
- metriklərin toplanması;
- Mümkünsə, nasazlıqları avtomatik təmir edirik;
- edə bilmirsə, sizə xəbər veririk;
- Tez cavab vermək üçün tablolar və triaj alətləri dəsti üzərində işləyirik.
Öyrənilmiş dərslər
Prototipin yazılması çox vaxt tələb etmir. Bizdə isə 4 aydan sonra hazır oldu. Bununla biz yeni ölçülər aldıq və inkişafa başlayandan 10 ay sonra ilk istehsal trafikini aldıq. Sonra yorucu və çox çətin iş başladı: sistemi tədricən istehsal edin və miqyasını artırın, əsas trafiki köçürün və səhvlərdən öyrənin. Ancaq bu effektiv proses xətti olmayacaq - bütün səylərə baxmayaraq, hər şeyi proqnozlaşdırmaq mümkün deyil. Tez təkrarlamaq və yeni məlumatlara cavab vermək daha effektivdir.
Təcrübəmizə əsaslanaraq, aşağıdakıları tövsiyə edə bilərik:
- İntuisiyanıza etibar etməyin.
Komanda üzvlərimizin böyük təcrübəsinə baxmayaraq, intuisiyamız bizi daim uğursuzluğa düçar edirdi. Məsələn, biz CDN proxy-dən və ya TCP Anycast-ın davranışından gözlənilən sürəti səhv proqnozlaşdırdıq.
- İstehsaldan məlumat əldə edin.
Ən azı az miqdarda istehsal məlumatlarına mümkün qədər tez daxil olmaq vacibdir. Laboratoriya şəraitində unikal halların, konfiqurasiyaların və parametrlərin sayını əldə etmək demək olar ki, mümkün deyil. Nəticələrə sürətli çıxış potensial problemləri tez öyrənməyə və onları sistem arxitekturasında nəzərə almağa imkan verəcək.
- Başqalarının məsləhətlərinə və nəticələrinə əməl etməyin - öz məlumatlarınızı toplayın.
Məlumatların toplanması və təhlili prinsiplərinə əməl edin, lakin digər insanların nəticələrini və ifadələrini kor-koranə qəbul etməyin. İstifadəçiləriniz üçün nəyin işlədiyini yalnız siz bilə bilərsiniz. Sistemləriniz və müştəriləriniz digər şirkətlərdən əhəmiyyətli dərəcədə fərqli ola bilər. Xoşbəxtlikdən, analiz alətləri artıq mövcuddur və istifadəsi asandır. Əldə etdiyiniz nəticələr Netflix, Facebook, Akamai və digər şirkətlərin iddia etdiyi kimi olmaya bilər. Bizim vəziyyətimizdə TLS, HTTP2 və ya DNS sorğuları üzrə statistik göstəricilərin performansı Facebook, Uber, Akamai-nin nəticələrindən fərqlənir - çünki bizdə müxtəlif cihazlar, müştərilər və məlumat axınları var.
- Gərəksiz yerə moda meyllərini izləməyin və effektivliyi qiymətləndirin.
Sadə başlayın. Ehtiyacınız olmayan komponentləri inkişaf etdirməyə çox vaxt sərf etməkdənsə, qısa müddətdə sadə bir iş sistemi düzəltmək daha yaxşıdır. Ölçmələrinizə və nəticələrinizə əsaslanaraq vacib olan tapşırıqları və problemləri həll edin.
- Yeni tətbiqlərə hazır olun.
Bütün problemləri proqnozlaşdırmaq çətin olduğu kimi, faydaları və tətbiqləri də əvvəlcədən proqnozlaşdırmaq çətindir. Startaplardan nümunə götürün - onların müştəri şərtlərinə uyğunlaşma qabiliyyəti. Sizin vəziyyətinizdə yeni problemlər və onların həlli yollarını kəşf edə bilərsiniz. Layihəmizdə sorğunun gecikməsini azaltmağı qarşımıza məqsəd qoymuşuq. Bununla belə, təhlil və müzakirələr zamanı anladıq ki, biz proxy serverlərdən də istifadə edə bilərik:
- AWS regionları arasında trafiki tarazlaşdırmaq və xərcləri azaltmaq;
- CDN sabitliyini modelləşdirmək;
- DNS-i konfiqurasiya etmək;
- TLS/TCP konfiqurasiya etmək üçün.
Nəticə
Hesabatda Netflix-in müştərilər və bulud arasında internet sorğularının sürətləndirilməsi problemini necə həll etdiyini təsvir etdim. Müştərilər haqqında seçmə sistemindən istifadə edərək məlumatları necə toplayırıq və toplanmış tarixi məlumatlardan müştərilərdən gələn istehsal sorğularını İnternetdəki ən sürətli yola yönəltmək üçün necə istifadə edirik. Bu tapşırığı yerinə yetirmək üçün şəbəkə protokollarının prinsiplərindən, CDN infrastrukturumuzdan, magistral şəbəkəmizdən və DNS serverlərimizdən necə istifadə edirik.
Bununla belə, bizim həllimiz Netflix-də belə bir sistemi necə tətbiq etdiyimizin sadəcə bir nümunəsidir. Bizim üçün nə işlədi. Hesabatımın sizə tətbiq olunan hissəsi bizim əməl etdiyimiz və yaxşı nəticələr əldə etdiyimiz inkişaf və dəstək prinsipləridir.
Problemin həlli sizə uyğun gəlməyə bilər. Bununla belə, öz CDN infrastrukturunuz olmasa da və ya bizimkindən əhəmiyyətli dərəcədə fərqlənsə belə, nəzəriyyə və dizayn prinsipləri qalır.
Biznes sorğularının sürətinin əhəmiyyəti də mühüm olaraq qalır. Və hətta sadə bir xidmət üçün seçim etmək lazımdır: bulud provayderləri, server yeri, CDN və DNS provayderləri arasında. Seçiminiz müştəriləriniz üçün İnternet sorğularının effektivliyinə təsir edəcək. Və bu təsiri ölçmək və anlamaq sizin üçün vacibdir.
Sadə həllərdən başlayın, məhsulu necə dəyişdirdiyinizə diqqət yetirin. Müştərilərinizdən, infrastrukturunuzdan və biznesinizdən əldə edilən məlumatlar əsasında sistemi öyrənin və təkmilləşdirin. Dizayn prosesində gözlənilməz nasazlıqların mümkünlüyünü düşünün. Və sonra siz inkişaf prosesinizi sürətləndirə, həllin səmərəliliyini artıra, lazımsız dəstək yükündən qaça və dinc şəkildə yata bilərsiniz.
Bu il onlayn formatda. Siz DevOps-un atalarından biri olan Con Uillisin özünə sual verə bilərsiniz!
Mənbə: www.habr.com