Netflix Internet-televideniye bozorida etakchi hisoblanadi - bu segmentni yaratgan va faol rivojlantirayotgan kompaniya. Netflix nafaqat sayyoramizning deyarli barcha burchaklaridan va displeyli har qanday qurilmadan sotiladigan keng qamrovli filmlar va seriallar katalogi, balki ishonchli infratuzilmasi va noyob muhandislik madaniyati bilan ham tanilgan.
Murakkab tizimlarni ishlab chiqish va qo‘llab-quvvatlashga Netflix yondashuvining yaqqol namunasi DevOops 2019 ko‘rgazmasida taqdim etildi. - Netflixning rivojlanish bo'yicha direktori. Nijniy Novgorod davlat universitetining hisoblash matematika va matematika fakulteti bitiruvchisi. Lobachevskiy, Sergey Open Connect-dagi birinchi muhandislardan biri - Netflix-dagi CDN jamoasi. U videoma'lumotlarni kuzatish va tahlil qilish tizimlarini qurdi, Internetga ulanish tezligini baholash uchun mashhur xizmatni ishga tushirdi FAST.com va so'nggi bir necha yil davomida Netflix ilovasi foydalanuvchilar uchun imkon qadar tezroq ishlashi uchun Internet so'rovlarini optimallashtirish ustida ishlamoqda.
Hisobot konferentsiya ishtirokchilarining eng yaxshi sharhlarini oldi va biz siz uchun matnli variantni tayyorladik.
O'z ma'ruzasida Sergey batafsil gapirdi
- mijoz va server o'rtasidagi Internet so'rovlarining kechikishiga nima ta'sir qilishi haqida;
- bu kechikishni qanday kamaytirish mumkin;
- xatolarga chidamli tizimlarni qanday loyihalash, saqlash va monitoring qilish;
- qisqa vaqt ichida va biznes uchun minimal xavf bilan natijalarga qanday erishish mumkin;
- natijalarni qanday tahlil qilish va xatolardan saboq olish.
Bu savollarga javoblar nafaqat yirik korporatsiyalarda ishlaydiganlarga kerak.
Taqdim etilgan tamoyillar va usullarni Internet mahsulotlarini ishlab chiquvchi va qo'llab-quvvatlovchi har bir kishi bilishi va qo'llashi kerak.
Keyingisi - ma'ruzachi nuqtai nazaridan.
Internet tezligining ahamiyati
Internet so'rovlarining tezligi biznes bilan bevosita bog'liq. Savdo sanoatini ko'rib chiqing: Amazon 2009 yilda 100 ms kechikish savdoning 1% yo'qotilishiga olib keladi.
Mobil qurilmalar ko'payib bormoqda, undan keyin mobil saytlar va ilovalar. Agar sizning sahifangizni yuklash uchun 3 soniyadan ko'proq vaqt kerak bo'lsa, siz foydalanuvchilarning yarmini yo'qotasiz. BILAN Google qidiruv natijalarida sahifangizni yuklash tezligini hisobga oladi: sahifa qanchalik tez bo'lsa, uning Googledagi o'rni shunchalik yuqori bo'ladi.
Kechikish juda muhim bo'lgan moliyaviy institutlarda ulanish tezligi ham muhimdir. 2015 yilda Hibernia Networks Nyu-York va London o'rtasidagi 400 million dollarlik kabel shaharlar orasidagi kechikishni 6 ms ga qisqartirish uchun. Tasavvur qiling-a, 66 ms kechikishni kamaytirish uchun 1 million dollar!
Shunga ko'ra , 5 Mbit/s dan yuqori ulanish tezligi endi odatiy veb-saytni yuklash tezligiga bevosita ta'sir qilmaydi. Biroq, ulanishning kechikishi va sahifani yuklash tezligi o'rtasida chiziqli bog'liqlik mavjud:
Biroq, Netflix odatiy mahsulot emas. Kechikish va tezlikning foydalanuvchiga ta'siri faol tahlil va ishlab chiqish sohasidir. Kechikish vaqtiga bog'liq bo'lgan ilovalarni yuklash va kontentni tanlash mavjud, ammo statik elementlarni yuklash va oqim ham ulanish tezligiga bog'liq. Foydalanuvchi tajribasiga ta'sir qiluvchi asosiy omillarni tahlil qilish va optimallashtirish Netflix-dagi bir nechta jamoalar uchun faol rivojlanish sohasidir. Maqsadlardan biri Netflix qurilmalari va bulutli infratuzilma o'rtasidagi so'rovlarning kechikishini kamaytirishdir.
Hisobotda biz Netflix infratuzilmasi misolidan foydalanib, kechikishni kamaytirishga alohida e'tibor qaratamiz. Amaliy nuqtai nazardan, murakkab taqsimlangan tizimlarni loyihalash, ishlab chiqish va ishlatish jarayonlariga qanday yondashish va operatsion muammolar va buzilishlarni tashxislashdan ko'ra, innovatsiyalar va natijalarga vaqt sarflashni ko'rib chiqaylik.
Netflix ichida
Minglab turli qurilmalar Netflix ilovalarini qo'llab-quvvatlaydi. Ular Android, iOS, TV va veb-brauzerlar uchun mijozning alohida versiyalarini yaratadigan to'rt xil jamoa tomonidan ishlab chiqilgan. Va biz foydalanuvchi tajribasini yaxshilash va shaxsiylashtirish uchun ko'p kuch sarflaymiz. Buning uchun biz parallel ravishda yuzlab A/B testlarini o'tkazamiz.
Shaxsiylashtirish AWS bulutidagi yuzlab mikroservislar tomonidan qo'llab-quvvatlanadi, ular shaxsiylashtirilgan foydalanuvchi ma'lumotlari, so'rovlarni jo'natish, telemetriya, katta ma'lumotlar va kodlashni ta'minlaydi. Trafik vizualizatsiyasi quyidagicha ko'rinadi:
Chap tomonda kirish nuqtasi, so'ngra trafik turli xil backend guruhlari tomonidan qo'llab-quvvatlanadigan bir necha yuz mikroservislar orasida taqsimlanadi.
Bizning infratuzilmamizning yana bir muhim komponenti - bu oxirgi foydalanuvchiga statik tarkibni - videolar, rasmlar, mijoz kodi va boshqalarni etkazib beruvchi Open Connect CDN. CDN maxsus serverlarda (OCA - Open Connect Appliance) joylashgan. Ichkarida NGINX va xizmatlar to'plami bilan optimallashtirilgan FreeBSD bilan ishlaydigan SSD va HDD drayvlar massivlari mavjud. Biz apparat va dasturiy ta'minot komponentlarini shunday CDN serveri foydalanuvchilarga imkon qadar ko'proq ma'lumot yuborishi uchun loyihalashtiramiz va optimallashtiramiz.
Ushbu serverlarning Internet-trafik almashish nuqtasida (Internet eXchange - IX) "devori" quyidagicha ko'rinadi:
Internet almashinuvi Internet provayderlari va kontent provayderlari uchun Internetda to'g'ridan-to'g'ri ma'lumot almashish uchun bir-biri bilan "ulanish" imkoniyatini beradi. Dunyo bo'ylab bizning serverlarimiz o'rnatilgan taxminan 70-80 Internet almashinuv punktlari mavjud va biz ularni mustaqil ravishda o'rnatamiz va ularga xizmat ko'rsatamiz:
Bundan tashqari, biz to'g'ridan-to'g'ri Internet-provayderlarga o'z tarmog'iga o'rnatadigan serverlarni taqdim etamiz, bu esa Netflix trafigining lokalizatsiyasini va foydalanuvchilar uchun oqim sifatini yaxshilaydi:
AWS xizmatlari to'plami mijozlardan CDN serverlariga video so'rovlarni jo'natish, shuningdek, serverlarning o'zini sozlash - tarkibni, dastur kodini, sozlamalarni va boshqalarni yangilash uchun javobgardir. Ikkinchisi uchun biz Internet almashinuv nuqtalaridagi serverlarni AWS bilan bog'laydigan magistral tarmoqni ham qurdik. Magistral tarmoq - bu bizning ehtiyojlarimiz asosida loyihalashimiz va sozlashimiz mumkin bo'lgan optik tolali kabellar va routerlarning global tarmog'idir.
haqida , bizning CDN infratuzilmamiz dunyodagi Internet-trafikning taxminan ⅛ qismini eng yuqori soatlarda va trafikning ⅓ qismini Netflix eng uzoq vaqt davomida bo'lgan Shimoliy Amerikada yetkazib beradi. Ta'sirli raqamlar, lekin men uchun eng ajoyib yutuqlardan biri shundaki, butun CDN tizimi 150 dan kam odamdan iborat jamoa tomonidan ishlab chiqilgan va qo'llab-quvvatlanadi.
Dastlab, CDN infratuzilmasi video ma'lumotlarni yetkazib berish uchun mo'ljallangan edi. Biroq, vaqt o'tishi bilan biz undan AWS bulutidagi mijozlarning dinamik so'rovlarini optimallashtirish uchun ham foydalanishimiz mumkinligini angladik.
Internet tezlashtirish haqida
Bugungi kunda Netflix 3 ta AWS hududiga ega va bulutga so'rovlarning kechikishi mijozning eng yaqin mintaqadan qanchalik uzoqda ekanligiga bog'liq bo'ladi. Shu bilan birga, bizda statik tarkibni etkazib berish uchun ishlatiladigan ko'plab CDN serverlari mavjud. Dinamik so'rovlarni tezlashtirish uchun ushbu ramkadan foydalanishning biron bir usuli bormi? Biroq, afsuski, bu so‘rovlarni keshlashning iloji yo‘q – APIlar shaxsiylashtirilgan va har bir natija noyobdir.
Keling, CDN serverida proksi-server yarataylik va u orqali trafikni jo'natishni boshlaymiz. Tezroq bo'ladimi?
Materiel
Keling, tarmoq protokollari qanday ishlashini eslaylik. Bugungi kunda Internetdagi ko'pchilik trafik quyi qatlam protokollari TCP va TLSga bog'liq bo'lgan HTTP-lardan foydalanadi. Mijoz serverga ulanishi uchun u qoʻl siqishini amalga oshiradi va xavfsiz ulanishni oʻrnatish uchun mijoz server bilan uch marta xabar almashishi va maʼlumotlarni uzatish uchun kamida yana bir marta boʻlishi kerak. 100 ms ga teng bo'lgan har bir sayohat uchun kechikish bilan ma'lumotlarning birinchi bitini olish uchun bizga 400 ms kerak bo'ladi:
Agar biz sertifikatlarni CDN serveriga joylashtirsak, CDN yaqinroq bo'lsa, mijoz va server o'rtasidagi qo'l siqish vaqti sezilarli darajada qisqarishi mumkin. Faraz qilaylik, CDN serverining kechikish vaqti 30ms. Keyin birinchi bitni olish uchun 220 ms kerak bo'ladi:
Ammo afzalliklar shu bilan tugamaydi. Ulanish o'rnatilgandan so'ng, TCP tirbandlik oynasini oshiradi (bu ulanish orqali parallel ravishda uzatishi mumkin bo'lgan ma'lumotlar miqdori). Agar ma'lumotlar paketi yo'qolsa, TCP protokolining klassik ilovalari (masalan, TCP New Reno) ochiq "oyna" ni yarmiga qisqartiradi. Tiklanish oynasining o'sishi va uni yo'qotishdan tiklash tezligi yana serverga kechikish (RTT) ga bog'liq. Agar bu ulanish faqat CDN serverigacha davom etsa, bu tiklanish tezroq bo'ladi. Shu bilan birga, paketlarni yo'qotish standart hodisadir, ayniqsa simsiz tarmoqlar uchun.
Internetning o'tkazish qobiliyati, ayniqsa, eng yuqori soatlarda, foydalanuvchilarning tirbandligi tufayli kamayishi mumkin, bu esa tirbandlikka olib kelishi mumkin. Biroq, Internetda ba'zi so'rovlarni boshqalardan ustun qo'yishning hech qanday usuli yo'q. Misol uchun, tarmoqni yuklaydigan "og'ir" ma'lumotlar oqimlariga nisbatan kichik va kechikishga sezgir so'rovlarga ustunlik bering. Biroq, bizning holatlarimizda, o'z magistral tarmog'iga ega bo'lish bizga buni so'rov yo'lining bir qismida - CDN va bulut o'rtasida amalga oshirishga imkon beradi va biz uni to'liq sozlashimiz mumkin. Kichik va kechikishga sezgir bo'lgan paketlar ustuvor ekanligiga ishonch hosil qilishingiz mumkin va katta ma'lumotlar oqimlari biroz keyinroq ketadi. CDN mijozga qanchalik yaqin bo'lsa, samaradorlik shunchalik yuqori bo'ladi.
Ilova darajasidagi protokollar (OSI Level 7) ham kechikishga ta'sir qiladi. HTTP/2 kabi yangi protokollar parallel so'rovlarning ishlashini optimallashtiradi. Biroq, bizda yangi protokollarni qo'llab-quvvatlamaydigan eski qurilmalarga ega Netflix mijozlari bor. Barcha mijozlarni yangilash yoki optimal tarzda sozlash mumkin emas. Shu bilan birga, CDN proksi-server va bulut o'rtasida to'liq nazorat va yangi, optimal protokollar va sozlamalardan foydalanish imkoniyati mavjud. Eski protokollar bilan samarasiz qism faqat mijoz va CDN server o'rtasida ishlaydi. Bundan tashqari, biz TCP darajasida ulanishdan foydalanishni yaxshilagan holda CDN va bulut o'rtasida allaqachon o'rnatilgan aloqada multipleks so'rovlarni amalga oshirishimiz mumkin:
Biz o'lchaymiz
Nazariya yaxshilanishlarni va'da qilsa ham, biz darhol tizimni ishlab chiqarishda ishga tushirishga shoshilmaymiz. Buning o'rniga, avvalo, g'oyaning amalda ishlashini isbotlashimiz kerak. Buning uchun siz bir nechta savollarga javob berishingiz kerak:
- tezlik: proksi tezroq bo'ladimi?
- Ishonchlilik: Tez-tez buziladimi?
- Murakkablik: ilovalar bilan qanday integratsiya qilish mumkin?
- qiymati: Qo'shimcha infratuzilmani joylashtirish qancha turadi?
Keling, birinchi nuqtani baholashga yondashuvimizni batafsil ko'rib chiqaylik. Qolganlari ham xuddi shunday tarzda hal qilinadi.
So'rovlar tezligini tahlil qilish uchun biz barcha foydalanuvchilar uchun ma'lumotlarni ishlab chiqishga ko'p vaqt sarflamasdan va ishlab chiqarishni buzmasdan olishni xohlaymiz. Buning uchun bir nechta yondashuvlar mavjud:
- RUM yoki passiv so'rov o'lchovi. Biz foydalanuvchilarning joriy so'rovlarini bajarish vaqtini o'lchaymiz va foydalanuvchilarning to'liq qamrab olinishini ta'minlaymiz. Kamchilik shundaki, signal ko'p omillar tufayli juda barqaror emas, masalan, turli xil so'rov o'lchamlari, server va mijozda ishlov berish vaqti. Bundan tashqari, siz yangi konfiguratsiyani ishlab chiqarishda ta'sir qilmasdan sinab ko'ra olmaysiz.
- Laboratoriya sinovlari. Mijozlarni taqlid qiluvchi maxsus serverlar va infratuzilma. Ularning yordami bilan biz kerakli testlarni o'tkazamiz. Shunday qilib, biz o'lchov natijalarini va aniq signalni to'liq nazorat qilamiz. Ammo qurilmalar va foydalanuvchilarning joylashuvi to'liq qamrab olinmaydi (ayniqsa, butun dunyo bo'ylab xizmat ko'rsatish va minglab qurilmalar modellarini qo'llab-quvvatlash bilan).
Qanday qilib ikkala usulning afzalliklarini birlashtira olasiz?
Jamoamiz yechim topdi. Biz dasturimizga o'rnatgan kichik kod qismini - namunani yozdik. Problar bizga qurilmalarimizdan to'liq boshqariladigan tarmoq sinovlarini o'tkazish imkonini beradi. Bu shunday ishlaydi:
- Ilovani yuklagandan va dastlabki faoliyatni tugatgandan so'ng, biz tekshiruvlarimizni ishga tushiramiz.
- Mijoz serverga so'rov yuboradi va test uchun "retsept" oladi. Retsept HTTP(lar)ga so'rov yuborilishi kerak bo'lgan URL manzillar ro'yxati. Bundan tashqari, retsept so'rov parametrlarini sozlaydi: so'rovlar orasidagi kechikishlar, so'ralgan ma'lumotlar miqdori, HTTP(lar) sarlavhalari va boshqalar. Shu bilan birga, biz bir nechta turli retseptlarni parallel ravishda sinab ko'rishimiz mumkin - konfiguratsiyani so'rashda biz qaysi retseptni chiqarishni tasodifiy aniqlaymiz.
- Probni ishga tushirish vaqti mijozda tarmoq resurslaridan faol foydalanishga zid kelmaslik uchun tanlanadi. Asosan, vaqt mijoz faol bo'lmaganda tanlanadi.
- Retseptni olgandan so'ng, mijoz har bir URL manziliga parallel ravishda so'rov yuboradi. Manzillarning har biriga so'rov takrorlanishi mumkin - deb ataladi. "impulslar". Birinchi zarbada biz ulanishni o'rnatish va ma'lumotlarni yuklab olish uchun qancha vaqt ketganini o'lchaymiz. Ikkinchi zarbada biz allaqachon o'rnatilgan ulanish orqali ma'lumotlarni yuklash uchun zarur bo'lgan vaqtni o'lchaymiz. Uchinchidan oldin biz kechikishni o'rnatishimiz va qayta ulanish tezligini o'lchashimiz mumkin va hokazo.
Sinov paytida biz qurilma olishi mumkin bo'lgan barcha parametrlarni o'lchaymiz:
- DNS so'rovi vaqti;
- TCP ulanishini sozlash vaqti;
- TLS ulanishini sozlash vaqti;
- ma'lumotlarning birinchi baytini qabul qilish vaqti;
- umumiy yuklash vaqti;
- holat natijasi kodi.
- Barcha impulslar bajarilgandan so'ng, namuna tahlil uchun barcha o'lchovlarni yuklaydi.
Asosiy nuqtalar - mijozga mantiqqa minimal bog'liqlik, serverda ma'lumotlarni qayta ishlash va parallel so'rovlarni o'lchash. Shunday qilib, biz so'rovlar samaradorligiga ta'sir qiluvchi turli omillar ta'sirini ajratib olish va sinab ko'rish, ularni bitta retsept bo'yicha o'zgartirish va haqiqiy mijozlardan natijalarni olish imkoniyatiga egamiz.
Ushbu infratuzilma so'rovlar unumdorligini tahlil qilishdan ko'ra ko'proq foydali ekanligini isbotladi. Hozirda bizda 14 ta faol retsept mavjud, soniyada 6000 dan ortiq namunalar, dunyoning barcha burchaklaridan ma'lumotlarni qabul qilish va qurilmani to'liq qamrab olish. Agar Netflix uchinchi tomondan shunga o'xshash xizmatni sotib olgan bo'lsa, u yiliga millionlab dollarga tushadi, bu esa ancha yomonroq qamrov bilan.
Amaliyotda sinov nazariyasi: prototip
Bunday tizim yordamida biz CDN proksi-serverlarining so'rovning kechikishi bo'yicha samaradorligini baholashga muvaffaq bo'ldik. Endi sizga kerak:
- proksi prototipini yaratish;
- prototipni CDN-ga joylashtiring;
- mijozlarni ma'lum bir CDN serveridagi proksi-serverga qanday yo'naltirishni aniqlash;
- Proksisiz AWS so'rovlari bilan unumdorlikni solishtiring.
Vazifa taklif etilayotgan yechimning samaradorligini imkon qadar tezroq baholashdan iborat. Yaxshi tarmoq kutubxonalari mavjudligi sababli prototipni amalga oshirish uchun Go-ni tanladik. Har bir CDN serverida bog'liqlikni kamaytirish va integratsiyani soddalashtirish uchun prototip proksini statik ikkilik sifatida o'rnatdik. Dastlabki amalga oshirishda biz imkon qadar standart komponentlardan foydalandik va HTTP/2 ulanishni birlashtirish va so'rovni multiplekslash uchun kichik o'zgartirishlardan foydalandik.
AWS hududlari o'rtasida muvozanatni saqlash uchun biz mijozlarni muvozanatlash uchun ishlatiladigan geografik DNS ma'lumotlar bazasidan foydalandik. Mijoz uchun CDN serverini tanlash uchun biz Internet Exchange (IX) serverlari uchun TCP Anycast dan foydalanamiz. Ushbu parametrda biz barcha CDN-serverlar uchun bitta IP-manzildan foydalanamiz va mijoz eng kam IP-hopsli CDN serveriga yo'naltiriladi. Internet provayderlari (ISP) tomonidan o'rnatilgan CDN serverlarida biz TCP Anycast-ni sozlash uchun yo'riqnoma ustidan nazoratga ega emasmiz, shuning uchun biz foydalanamiz , bu mijozlarni video oqimi uchun Internet-provayderlarga yo'naltiradi.
Shunday qilib, bizda uchta turdagi so'rov yo'llari mavjud: ochiq Internet orqali bulutga, IX-dagi CDN-server orqali yoki Internet-provayderda joylashgan CDN-server orqali. Bizning maqsadimiz qaysi yo'l yaxshiroq ekanligini va so'rovlar ishlab chiqarishga qanday yuborilishi bilan solishtirganda proksi-serverdan qanday foyda borligini tushunishdir. Buning uchun biz quyidagi tarzda namuna olish tizimidan foydalanamiz:
Yo'llarning har biri alohida nishonga aylanadi va biz olgan vaqtga qaraymiz. Tahlil qilish uchun biz proksi-server natijalarini bitta guruhga birlashtiramiz (IX va ISP proksi-serverlari o'rtasida eng yaxshi vaqtni tanlang) va ularni proksi-serversiz bulutga so'rovlar vaqti bilan solishtiramiz:
Ko'rib turganingizdek, natijalar aralashdi - ko'p hollarda proksi-server yaxshi tezlikni beradi, ammo vaziyat sezilarli darajada yomonlashadigan etarli miqdordagi mijozlar ham mavjud.
Natijada biz bir nechta muhim ishlarni qildik:
- Biz CDN proksi-server orqali mijozlardan bulutga so'rovlarning kutilayotgan samaradorligini baholadik.
- Biz haqiqiy mijozlardan, barcha turdagi qurilmalardan ma'lumotlarni oldik.
- Biz nazariya 100% tasdiqlanmaganligini va CDN proksi-server bilan dastlabki taklif biz uchun ishlamasligini tushundik.
- Biz tavakkal qilmadik - mijozlar uchun ishlab chiqarish konfiguratsiyasini o'zgartirmadik.
- Hech narsa buzilmadi.
Prototip 2.0
Shunday qilib, chizilgan taxtaga qayting va jarayonni yana takrorlang.
G'oya shundan iboratki, 100% proksi-serverdan foydalanish o'rniga biz har bir mijoz uchun eng tezkor yo'lni aniqlaymiz va u erga so'rovlar yuboramiz - ya'ni mijozni boshqarish deb ataladigan narsani qilamiz.
Buni qanday amalga oshirish kerak? Biz server tomonida mantiqdan foydalana olmaymiz, chunki... Maqsad - bu serverga ulanish. Mijozda buni qilishning qandaydir yo'li bo'lishi kerak. Va ideal holda, ko'p sonli mijoz platformalari bilan integratsiya masalasini hal qilmaslik uchun buni minimal miqdordagi murakkab mantiq bilan bajaring.
Javob DNS-dan foydalanishdir. Bizning holatda, bizning DNS infratuzilmamiz bor va biz serverlarimiz avtoritar bo'ladigan domen zonasini o'rnatishimiz mumkin. Bu shunday ishlaydi:
- Mijoz DNS serveriga xost yordamida so'rov yuboradi, masalan, api.netflix.xom.
- So'rov bizning DNS serverimizga keladi
- DNS-server ushbu mijoz uchun qaysi yo'l eng tez ekanligini biladi va tegishli IP-manzilni beradi.
Yechim qo'shimcha murakkablikka ega: avtoritar DNS provayderlari mijozning IP-manzilini ko'rmaydilar va faqat mijoz foydalanadigan rekursiv hal qiluvchining IP-manzilini o'qiy oladilar.
Natijada, bizning avtoritar hal qiluvchimiz individual mijoz uchun emas, balki rekursiv hal qiluvchiga asoslangan mijozlar guruhi uchun qaror qabul qilishi kerak.
Yechish uchun biz bir xil namunalardan foydalanamiz, har bir rekursiv hal qiluvchi uchun mijozlardan olingan o'lchov natijalarini jamlaymiz va ularning ushbu guruhini qaerga yuborishni hal qilamiz - TCP Anycast yordamida IX orqali proksi-server, ISP proksi-serveri orqali yoki to'g'ridan-to'g'ri bulutga.
Biz quyidagi tizimni olamiz:
Olingan DNS boshqaruv modeli mijozlardan bulutga ulanish tezligining tarixiy kuzatuvlari asosida mijozlarni yo'naltirish imkonini beradi.
Yana savol tug'iladi, bu yondashuv qanchalik samarali ishlaydi? Javob berish uchun biz yana prob tizimimizdan foydalanamiz. Shuning uchun biz taqdimotchi konfiguratsiyasini sozlaymiz, bu erda maqsadlardan biri DNS boshqaruvi yo'nalishi bo'yicha, ikkinchisi to'g'ridan-to'g'ri bulutga o'tadi (joriy ishlab chiqarish).
Natijada biz natijalarni taqqoslaymiz va samaradorlik bahosini olamiz:
Natijada biz bir nechta muhim narsalarni bilib oldik:
- Biz DNS Steering-dan foydalanib, mijozlarning bulutga bo'lgan so'rovlarining kutilayotgan samaradorligini baholadik.
- Biz haqiqiy mijozlardan, barcha turdagi qurilmalardan ma'lumotlarni oldik.
- Taklif etilayotgan g'oyaning samaradorligi isbotlangan.
- Biz tavakkal qilmadik - mijozlar uchun ishlab chiqarish konfiguratsiyasini o'zgartirmadik.
- Hech narsa buzilmadi.
Endi qiyin qism haqida - biz uni ishlab chiqarishda ishga tushiramiz
Endi oson qism tugadi - ishlaydigan prototip mavjud. Endi qiyin qismi 150 million foydalanuvchi, minglab qurilmalar, yuzlab mikroservislar va doimiy o'zgarib turadigan mahsulot va infratuzilmani qamrab oluvchi Netflix-ning barcha trafigi uchun yechimni ishga tushirishdir. Netflix serverlari soniyada millionlab so'rovlarni qabul qiladi va beparvolik bilan xizmatni buzish oson. Shu bilan birga, biz Internetdagi minglab CDN serverlari orqali trafikni dinamik ravishda yo'naltirishni xohlaymiz, bu erda biror narsa doimiy ravishda o'zgarib turadi va buziladi.
Va bularning barchasi bilan jamoada tizimni ishlab chiqish, joylashtirish va to'liq qo'llab-quvvatlash uchun mas'ul bo'lgan 3 ta muhandis mavjud.
Shuning uchun biz tinch va sog'lom uyqu haqida gapirishni davom ettiramiz.
Qanday qilib rivojlanishni davom ettirish va barcha vaqtingizni qo'llab-quvvatlashga sarflamaslik kerak? Bizning yondashuvimiz 3 tamoyilga asoslanadi:
- Biz buzilishlarning potentsial ko'lamini (portlash radiusi) kamaytiramiz.
- Biz kutilmagan hodisalarga tayyorlanyapmiz - sinov va shaxsiy tajribaga qaramay, nimadir buzishini kutamiz.
- Aqlli degradatsiya - agar biror narsa to'g'ri ishlamasa, u eng samarali tarzda bo'lmasa ham, avtomatik ravishda tuzatilishi kerak.
Ma'lum bo'lishicha, bizning holatlarimizda muammoga bunday yondashuv bilan biz oddiy va samarali yechim topishimiz va tizimni qo'llab-quvvatlashni sezilarli darajada soddalashtirishimiz mumkin. Biz mijozga kichik bir kod qismini qo'shishimiz va ulanish muammolari tufayli tarmoq so'rovi xatolarini kuzatishimiz mumkinligini tushundik. Tarmoqdagi xatolar bo'lsa, biz to'g'ridan-to'g'ri bulutga qaytamiz. Ushbu yechim mijozlar guruhlari uchun katta kuch talab qilmaydi, lekin biz uchun kutilmagan buzilishlar va kutilmagan hodisalar xavfini sezilarli darajada kamaytiradi.
Albatta, orqaga qaytishga qaramay, biz rivojlanish jarayonida aniq intizomga amal qilamiz:
- Sinov namunasi.
- A/B testi yoki Kanareykalar.
- Progressiv tarqatish.
Namunalar bilan yondashuv tasvirlangan - o'zgarishlar birinchi navbatda moslashtirilgan retsept yordamida sinovdan o'tkaziladi.
Kanareykalarni sinab ko'rish uchun biz o'zgarishlardan oldin va keyin tizim qanday ishlashini taqqoslashimiz mumkin bo'lgan taqqoslanadigan server juftlarini olishimiz kerak. Buni amalga oshirish uchun ko'plab CDN saytlarimizdan taqqoslanadigan trafikni qabul qiladigan server juftlarini tanlaymiz:
Keyin Canary serveridagi o'zgarishlar bilan tuzilmani o'rnatamiz. Natijalarni baholash uchun biz taxminan 100-150 ko'rsatkichni Nazorat serverlari namunasi bilan taqqoslaydigan tizimni ishga tushiramiz:
Agar Canary testi muvaffaqiyatli bo'lsa, biz uni asta-sekin, to'lqinlarda chiqaramiz. Biz har bir saytdagi serverlarni bir vaqtning o'zida yangilamaymiz - muammolar tufayli butun saytni yo'qotish turli joylarda bir xil miqdordagi serverlarni yo'qotishdan ko'ra foydalanuvchilar uchun xizmatga sezilarli ta'sir qiladi.
Umuman olganda, ushbu yondashuvning samaradorligi va xavfsizligi to'plangan ko'rsatkichlarning miqdori va sifatiga bog'liq. So'rovlarni tezlashtirish tizimi uchun biz barcha mumkin bo'lgan komponentlardan ko'rsatkichlarni yig'amiz:
- mijozlardan - seanslar va so'rovlar soni, qaytarish stavkalari;
- proksi - so'rovlar soni va vaqti bo'yicha statistika;
- DNS - so'rovlar soni va natijalari;
- bulut chekkasi - bulutdagi so'rovlarni qayta ishlash uchun raqam va vaqt.
Bularning barchasi bitta quvurda to'planadi va ehtiyojlarga qarab, biz aniqroq diagnostika uchun qaysi ko'rsatkichlarni real vaqt tahliliga, qaysi birini Elasticsearch yoki Big Data-ga yuborishni hal qilamiz.
Biz kuzatamiz
Bizning holatda, biz mijoz va server o'rtasidagi so'rovlarning muhim yo'lida o'zgarishlar qilamiz. Shu bilan birga, mijozda, serverda va Internet orqali yo'lda turli xil komponentlar soni juda ko'p. Mijoz va serverdagi o'zgarishlar doimiy ravishda sodir bo'ladi - o'nlab jamoalar ishi va ekotizimdagi tabiiy o'zgarishlar. Biz o'rtadamiz - muammolarni tashxislashda biz ishtirok etishimiz uchun yaxshi imkoniyat bor. Shuning uchun biz muammolarni tezda ajratib olish uchun ko'rsatkichlarni qanday aniqlash, to'plash va tahlil qilishni aniq tushunishimiz kerak.
Ideal holda, real vaqtda barcha turdagi ko'rsatkichlar va filtrlarga to'liq kirish. Ammo ko'rsatkichlar juda ko'p, shuning uchun narx masalasi tug'iladi. Bizning holatlarimizda biz ko'rsatkichlar va ishlab chiqish vositalarini quyidagicha ajratamiz:
Muammolarni aniqlash va aniqlash uchun biz o'z ochiq manbali real vaqt tizimimizdan foydalanamiz и - vizualizatsiya uchun. U yig'ilgan ko'rsatkichlarni xotirada saqlaydi, ishonchli va ogohlantirish tizimi bilan birlashadi. Mahalliylashtirish va diagnostika uchun biz Elasticsearch va Kibana jurnallaridan foydalanishimiz mumkin. Statistik tahlil va modellashtirish uchun biz Tableau-da katta ma'lumotlar va vizualizatsiyadan foydalanamiz.
Ko'rinishidan, bu yondashuv bilan ishlash juda qiyin. Biroq, ko'rsatkichlar va vositalarni ierarxik tarzda tashkil qilish orqali biz muammoni tezda tahlil qilishimiz, muammo turini aniqlashimiz va keyin batafsil ko'rsatkichlarni chuqurlashtirishimiz mumkin. Umuman olganda, buzilish manbasini aniqlash uchun taxminan 1-2 daqiqa vaqt sarflaymiz. Shundan so'ng, biz diagnostika bo'yicha ma'lum bir guruh bilan ishlaymiz - o'nlab daqiqalardan bir necha soatgacha.
Tashxis tezda amalga oshirilsa ham, biz bu tez-tez sodir bo'lishini xohlamaymiz. Ideal holda, biz faqat xizmatga sezilarli ta'sir ko'rsatganda muhim ogohlantirish olamiz. So'rovlarni tezlashtirish tizimi uchun bizda faqat ikkita ogohlantirish mavjud:
- Client Fallback foizi - mijozning xatti-harakatlarini baholash;
- foiz Prob xatolar - tarmoq komponentlarining barqarorligi ma'lumotlari.
Ushbu muhim ogohlantirishlar tizim ko'pchilik foydalanuvchilar uchun ishlayotganligini nazorat qiladi. Qancha mijozlar so'rovni tezlashtirishni ololmasa, qayta tiklashdan foydalanganini ko'rib chiqamiz. Tizimda ko'plab o'zgarishlar ro'y berayotgan bo'lsa-da, biz haftasiga o'rtacha 1 martadan kam tanqidiy ogohlantirish olamiz. Nima uchun bu biz uchun etarli?
- Proksi-serverimiz ishlamasa, mijozning orqaga qaytishi mavjud.
- Muammolarga javob beradigan avtomatik boshqaruv tizimi mavjud.
Ikkinchisi haqida batafsil ma'lumot. Bizning sinov tizimimiz va mijozdan bulutga so'rovlar uchun maqbul yo'lni avtomatik ravishda aniqlash tizimi bizga ba'zi muammolarni avtomatik ravishda hal qilish imkonini beradi.
Keling, namunaviy konfiguratsiyaga va 3 yo'l toifasiga qaytaylik. Yuklash vaqtiga qo'shimcha ravishda biz etkazib berish faktini ham ko'rib chiqishimiz mumkin. Agar ma'lumotlarni yuklashning iloji bo'lmasa, unda turli yo'llar bo'ylab natijalarga qarab, biz qaerda va nima buzilganligini va so'rov yo'lini o'zgartirish orqali uni avtomatik ravishda tuzatishimiz mumkinligini aniqlashimiz mumkin.
misollar:
Bu jarayonni avtomatlashtirish mumkin. Uni boshqaruv tizimiga qo'shing. Va uni ishlash va ishonchlilik muammolariga javob berishga o'rgating. Agar biror narsa buzila boshlasa, yaxshiroq variant bo'lsa, munosabat bildiring. Shu bilan birga, mijozlarning orqaga qaytishi tufayli darhol reaktsiya muhim emas.
Shunday qilib, tizimni qo'llab-quvvatlash tamoyillarini quyidagicha shakllantirish mumkin:
- buzilishlar ko'lamini kamaytirish;
- ko'rsatkichlarni yig'ish;
- Iloji bo'lsa, buzilishlarni avtomatik ravishda tuzatamiz;
- agar qila olmasa, sizni xabardor qilamiz;
- Tez javob berish uchun asboblar paneli va triage asboblar to'plami ustida ishlayapmiz.
O'rganilgan saboqlar
Prototipni yozish ko'p vaqtni talab qilmaydi. Bizning holatda, u 4 oydan keyin tayyor edi. U bilan biz yangi ko'rsatkichlarni oldik va rivojlanish boshlanganidan 10 oy o'tgach, biz birinchi ishlab chiqarish trafigini oldik. Keyin zerikarli va juda qiyin ish boshlandi: tizimni asta-sekin ishlab chiqarish va kengaytirish, asosiy trafikni ko'chirish va xatolardan saboq olish. Biroq, bu samarali jarayon chiziqli bo'lmaydi - barcha sa'y-harakatlarga qaramay, hamma narsani oldindan aytib bo'lmaydi. Tez takrorlash va yangi ma'lumotlarga javob berish ancha samaraliroq.
Bizning tajribamizga asoslanib, biz quyidagilarni tavsiya qilishimiz mumkin:
- Intuitsiyangizga ishonmang.
Jamoamiz a'zolarining katta tajribasiga qaramay, intuitivligimiz bizni doimo muvaffaqiyatsizlikka uchratdi. Masalan, biz CDN proksi-serveridan yoki TCP Anycast xatti-harakatidan foydalanish kutilgan tezlikni noto'g'ri taxmin qildik.
- Ishlab chiqarishdan ma'lumotlarni oling.
Hech bo'lmaganda kichik hajmdagi ishlab chiqarish ma'lumotlariga imkon qadar tezroq kirish uchun muhim ahamiyatga ega. Laboratoriya sharoitida noyob holatlar, konfiguratsiyalar va sozlamalar sonini olish deyarli mumkin emas. Natijalarga tezkor kirish mumkin bo'lgan muammolarni tezda bilib olish va ularni tizim arxitekturasida hisobga olish imkonini beradi.
- Boshqa odamlarning maslahatlari va natijalariga amal qilmang - o'z ma'lumotlaringizni to'plang.
Ma'lumotlarni to'plash va tahlil qilish tamoyillariga rioya qiling, lekin boshqalarning natijalari va bayonotlarini ko'r-ko'rona qabul qilmang. Sizning foydalanuvchilaringiz uchun nima ishlayotganini faqat siz bilishingiz mumkin. Tizimlaringiz va mijozlaringiz boshqa kompaniyalardan sezilarli darajada farq qilishi mumkin. Yaxshiyamki, tahlil vositalari endi mavjud va ulardan foydalanish oson. Siz olgan natijalar Netflix, Facebook, Akamai va boshqa kompaniyalar da'vo qilganidek bo'lmasligi mumkin. Bizning holatda, TLS, HTTP2 yoki DNS so'rovlari bo'yicha statistik ma'lumotlarning ishlashi Facebook, Uber, Akamai natijalaridan farq qiladi - chunki bizda turli xil qurilmalar, mijozlar va ma'lumotlar oqimlari mavjud.
- Moda tendentsiyalariga keraksiz ergashmang va samaradorlikni baholang.
Oddiy boshlang. Sizga kerak bo'lmagan komponentlarni ishlab chiqishga katta vaqt sarflashdan ko'ra, qisqa vaqt ichida oddiy ishchi tizimni yaratish yaxshiroqdir. O'lchovlaringiz va natijalaringiz asosida muhim vazifalar va muammolarni hal qiling.
- Yangi ilovalarga tayyorlaning.
Barcha muammolarni bashorat qilish qiyin bo'lgani kabi, foyda va ilovalarni oldindan aytish qiyin. Startaplardan namuna oling - ularning mijozlar sharoitlariga moslashish qobiliyati. Sizning holatlaringizda siz yangi muammolar va ularning echimlarini topishingiz mumkin. Loyihamizda biz so'rovning kechikishini kamaytirishni maqsad qilib qo'yganmiz. Biroq, tahlil va muhokamalar davomida biz proksi-serverlardan ham foydalanishimiz mumkinligini angladik:
- AWS mintaqalari bo'ylab trafikni muvozanatlash va xarajatlarni kamaytirish;
- CDN barqarorligini modellashtirish;
- DNS-ni sozlash;
- TLS/TCP ni sozlash uchun.
xulosa
Hisobotda men Netflix mijozlar va bulut o'rtasidagi Internet so'rovlarini tezlashtirish muammosini qanday hal qilishini tasvirlab berdim. Mijozlar bo'yicha namuna olish tizimi yordamida ma'lumotlarni qanday yig'amiz va to'plangan tarixiy ma'lumotlardan mijozlardan ishlab chiqarish so'rovlarini Internetdagi eng tezkor yo'l orqali yo'naltirish uchun foydalanamiz. Ushbu vazifani bajarish uchun biz tarmoq protokollari, CDN infratuzilmamiz, magistral tarmoq va DNS serverlarimiz tamoyillaridan qanday foydalanamiz.
Biroq, bizning yechimimiz Netflix-da bunday tizimni qanday amalga oshirganimizga misoldir. Biz uchun nima ishladi. Mening hisobotimning siz uchun qo'llaniladigan qismi - bu biz amal qiladigan va yaxshi natijalarga erishadigan rivojlanish va qo'llab-quvvatlash tamoyillari.
Muammoni hal qilishimiz sizga mos kelmasligi mumkin. Biroq, sizning CDN infratuzilmangiz bo'lmasa yoki u biznikidan sezilarli darajada farq qilsa ham, nazariya va dizayn tamoyillari saqlanib qoladi.
Biznes so'rovlari tezligining ahamiyati ham muhim bo'lib qolmoqda. Va hatto oddiy xizmat uchun siz tanlov qilishingiz kerak: bulutli provayderlar, server joylashuvi, CDN va DNS provayderlari o'rtasida. Sizning tanlovingiz mijozlaringiz uchun Internet so'rovlarining samaradorligiga ta'sir qiladi. Va bu ta'sirni o'lchash va tushunish siz uchun muhimdir.
Oddiy echimlar bilan boshlang, mahsulotni qanday o'zgartirishingiz haqida qayg'uring. Mijozlaringiz, infratuzilmangiz va biznesingiz maʼlumotlari asosida oʻrganing va tizimni yaxshilang. Dizayn jarayonida kutilmagan buzilishlar ehtimoli haqida o'ylab ko'ring. Va keyin siz rivojlanish jarayonini tezlashtirishingiz, yechim samaradorligini oshirishingiz, keraksiz yordam yukidan qochishingiz va tinch uxlashingiz mumkin.
Shu yili onlayn formatda. Siz DevOps otalaridan biri Jon Uillisning o'ziga savollar berishingiz mumkin!
Manba: www.habr.com