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