Жош Эванс Netflix микро үйлчилгээний замбараагүй, өнгөлөг ертөнцийн талаар, бичил үйлчилгээний анатоми, тархсан системтэй холбоотой бэрхшээлүүд, тэдгээрийн ашиг тус зэрэг үндсэн ойлголтуудаас эхлээд ярьдаг. Энэхүү суурь дээр тулгуурлан тэрээр бичил үйлчилгээг эзэмшихэд хүргэдэг соёл, архитектур, үйл ажиллагааны туршлагыг судалдаг.
Үйл ажиллагааны шилжилтээс ялгаатай нь үйлчилгээг олон улсын түвшинд хүргэх шинэ хэл, сав зэрэг шинэ технологийг нэвтрүүлэх нь хүрээлэн буй орчинд шинэ төвөгтэй байдлыг бий болгох ухамсартай шийдвэр юм. Миний үйл ажиллагааны баг Netflix-ийн шилдэг технологийн замын зураглалыг стандартчилсан бөгөөд үүнийг Java болон EC2 дээр суурилсан урьдчилан тодорхойлсон шилдэг туршлагууд болгон боловсруулсан боловч бизнес хөгжихийн хэрээр хөгжүүлэгчид Python, Ruby, Node-JS, Docker зэрэг шинэ бүрэлдэхүүн хэсгүүдийг нэмж эхэлсэн.
Хэрэглэгчийн гомдлыг хүлээлгүйгээр бүтээгдэхүүнээ сайн ажиллуулахын төлөө бид анхлан санаачилсандаа би маш их бахархаж байна. Энэ бүхэн маш энгийнээр эхэлсэн - бид Python дээр ажилладаг програмууд, Ruby-д хэд хэдэн арын албаны програмуудтай байсан ч манай вэб хөгжүүлэгчид JVM-ээс татгалзаж, вэбийг зөөх гэж байгаагаа зарласнаар бүх зүйл илүү сонирхолтой болсон. Node програм хангамжийн платформд зориулсан програм.js. Докерыг нэвтрүүлсний дараа бүх зүйл илүү төвөгтэй болсон. Бид логикийг дагасан бөгөөд бидний бодож олсон технологи нь маш их утга учиртай байсан тул хэрэглэгчдэд зориулж хэрэгжүүлэхэд бодитой болсон. Яагаад ийм болсныг би танд хэлье.
API Gateway нь үнэндээ UI хөгжүүлэгчдийн төгсгөлийн цэг болж чадах гайхалтай скриптүүдийг нэгтгэх чадвартай. Тэд эдгээр скрипт бүрийг өөрчилсний дараа тэдгээрийг үйлдвэрлэлд, дараа нь хэрэглэгчийн төхөөрөмжүүдэд байршуулах байдлаар хөрвүүлсэн бөгөөд эдгээр бүх өөрчлөлтүүд нь API гарц дээр ажилладаг төгсгөлийн цэгүүдтэй синхрончлогдсон.
Гэсэн хэдий ч энэ нь API үйлчилгээ нь кодоор хэт ачаалалтай байсан тул шинэ цул үүсгэх асуудлыг давтсан бөгөөд ингэснээр янз бүрийн бүтэлгүйтлийн хувилбарууд гарч ирэв. Жишээлбэл, зарим төгсгөлийн цэгүүдийг устгасан эсвэл скриптүүд нь ямар нэг зүйлийн маш олон хувилбарыг санамсаргүйгээр үүсгэсэн тул хувилбарууд нь API үйлчилгээний боломжтой бүх санах ойг эзэлдэг.
Эдгээр төгсгөлийн цэгүүдийг авч API үйлчилгээнээс гаргах нь логиктой байсан. Үүнийг хийхийн тулд бид Docker контейнерт жижиг програмууд хэлбэрээр ажилладаг Node.js бүрэлдэхүүн хэсгүүдийг үүсгэсэн. Энэ нь эдгээр зангилааны програмуудаас үүдэлтэй аливаа асуудал, эвдрэлийг тусгаарлах боломжийг бидэнд олгосон.
Эдгээр өөрчлөлтийн өртөг нь нэлээд том бөгөөд дараахь хүчин зүйлээс бүрдэнэ.
- Бүтээмжийн хэрэгсэл. Шинэ технологиудыг удирдахад шинэ хэрэгслүүд шаардлагатай байсан, учир нь UI багийнхан үр ашигтай загвар бүтээхийн тулд маш сайн скрипт ашиглаж, дэд бүтцийг удирдахад их цаг зарцуулах шаардлагагүй, зөвхөн скрипт бичиж, тэдгээрийн ажиллагааг шалгах хэрэгтэй байв.
Opportunity Insight and Sorting - Гол жишээ бол гүйцэтгэлийн драйверын мэдээллийг илрүүлэхэд шаардлагатай шинэ хэрэгслүүд юм. Процессор хэр их хүчин чадалтай, санах ойг хэрхэн ашиглаж байгааг мэдэх шаардлагатай байсан бөгөөд энэ мэдээллийг цуглуулахад өөр өөр хэрэгсэл шаардлагатай байв. - Үндсэн зургуудын хуваагдал - энгийн суурь AMI нь илүү хуваагдмал, мэргэшсэн.
- Зангилааны удирдлага. Үүлэн дэх зангилааг удирдах боломж олгох ямар ч бэлэн архитектур, технологи байхгүй тул бид Amazon AWS-тай өргөтгөх боломжтой, найдвартай чингэлэг байршуулах, үүлэн нэгтгэх боломжийг олгодог Titus хэмээх контейнер менежментийн платформыг бүтээсэн.
- Номын сан эсвэл платформын давхардал. Платформын ижил үндсэн функц бүхий шинэ технологиор хангахын тулд үүнийг үүлэн дээр суурилсан Node.js хөгжүүлэгчийн хэрэгсэл болгон хуулбарлах шаардлагатай байв.
- Сурах муруй ба үйлдвэрлэлийн туршлага. Шинэ технологи нэвтрүүлэх нь зайлшгүй даван туулах, суралцах ёстой шинэ сорилтуудыг бий болгодог.
Тиймээс бид ганцхан "засмал зам"-аар хязгаарлагдахгүй, технологио ахиулах шинэ арга замыг байнга бий болгох шаардлагатай болсон. Зардлаа бууруулахын тулд бид төвлөрсөн дэмжлэгийг хязгаарлаж, JVM, шинэ зангилаа болон Docker дээр анхаарлаа хандуулсан. Бид үр дүнтэй нөлөөллийг нэн тэргүүнд тавьж, багуудад шийдвэрийнхээ зардлын талаар мэдээлэл өгч, өөрсдийн боловсруулсан өндөр үр нөлөө бүхий шийдлүүдийг дахин ашиглах арга замыг эрэлхийлэхэд урамшуулсан. Бид бүтээгдэхүүнийг олон улсын үйлчлүүлэгчдэд хүргэхийн тулд үйлчилгээг гадаад хэл рүү орчуулахдаа энэ аргыг ашигласан. Жишээ нь автоматаар үүсгэгдэх харьцангуй энгийн клиент номын сангууд багтдаг бөгөөд ингэснээр Python хувилбар, Ruby хувилбар, Java хувилбар гэх мэтийг үүсгэхэд хялбар байдаг.
Бид нэг газар болон бусад ижил төстэй нөхцөл байдалд өөрийгөө нотолсон, батлагдсан технологийг ашиглах боломжийг байнга эрэлхийлж байсан.
Сүүлийн элемент болох өөрчлөлт, өөрчлөлтийн талаар ярилцъя. Манай бүтээгдэхүүний хэрэглээ долоо хоногийн өдөр, өдрийн цагаар хэрхэн жигд бус өөрчлөгдөж байгааг хараарай. Өглөөний 9 цаг бол Netflix-ийн хувьд системийн ачаалал дээд цэгтээ хүрдэг хамгийн хэцүү цаг гэж хэлж болно.
Програм хангамжийн шинэчлэлийг хэрэгжүүлэх өндөр хурдтай, өөрөөр хэлбэл системд байнга шинэ өөрчлөлтүүд хийж, үйлчилгээ үзүүлэхэд саад учруулахгүйгээр, үйлчлүүлэгчдэд хүндрэл учруулахгүйгээр хэрхэн яаж хүрэх вэ? Netflix үүндээ Spinnaker буюу дэлхийн үүлэнд суурилсан удирдлага, тасралтгүй хүргэлт (CD) платформыг ашигласнаар хүрсэн.
Хамгийн чухал нь, Spinnaker нь бидний шилдэг туршлагыг нэгтгэх зорилготой байсан бөгөөд ингэснээр бид бүрэлдэхүүн хэсгүүдийг үйлдвэрлэлд нэвтрүүлэх үед гаралтыг медиа дамжуулах технологидоо шууд нэгтгэх боломжтой болно.
Бид өндөр үнэлдэг хоёр технологийг хүргэх шугамандаа оруулж чадсан: автоматжуулсан канарын шинжилгээ болон үе шаттай байршуулалт. Канарын шинжилгээ гэдэг нь бид хөдөлгөөний урсгалыг кодын шинэ хувилбар руу чиглүүлж, үйлдвэрлэлийн бусад урсгалыг хуучин хувилбараар дамжуулдаг гэсэн үг юм. Дараа нь бид шинэ код нь даалгаврыг хэрхэн даван туулж байгааг шалгадаг - одоо байгаа кодоос илүү сайн эсвэл муу.
Шат шаталсан хувилбар гэдэг нь хэрэв нэг бүс нутагт хэрэглүүрт асуудал гарвал бид өөр бүс нутагт нэвтрүүлэх рүү шилжинэ гэсэн үг. Энэ тохиолдолд дээр дурдсан хяналтын хуудсыг үйлдвэрлэлийн шугамд оруулах ёстой. Би танд цаг заваа хэмнэж, хэрэв та энэ сэдвийг гүнзгийрүүлэн судлах сонирхолтой байгаа бол миний өмнөх илтгэл болох "Cloud in the Global Netflix Operations Engineering"-ийг үзэхийг зөвлөж байна. Илтгэлийн видео бичлэгийг слайдын доод талд байгаа линкээр орж үзэх боломжтой.
Ярианы төгсгөлд би Netflix-ийн зохион байгуулалт, архитектурын талаар товч ярих болно. Бид хамгийн эхэнд NRDP 1.x медиа урсгалын анхны хувилбар болох Цахим хүргэлт хэмээх схемтэй байсан. Эхлээд хэрэглэгч зөвхөн дараа нь төхөөрөмж дээр дахин тоглуулах контентыг татаж авах боломжтой тул "арын урсгал" гэсэн нэр томъёог энд ашиглаж болно. Netflix-ийн хамгийн анхны дижитал түгээлтийн платформ нь 2009 онд иймэрхүү харагдаж байв.
Хэрэглэгчийн төхөөрөмж нь NRDP платформ - Netflix Ready Device Platform дээр суурилсан UI интерфейс, хамгаалалтын модулиуд, үйлчилгээг идэвхжүүлэх, тоглуулах зэргээс бүрдсэн Netflix програмыг агуулж байв.
Тэр үед хэрэглэгчийн интерфэйс маш энгийн байсан. Энэ нь Queque Reader гэж нэрлэгддэг зүйлийг агуулж байсан бөгөөд хэрэглэгч Queque-д ямар нэг зүйл нэмэхийн тулд сайт руу орж, дараа нь нэмсэн контентыг төхөөрөмж дээрээ үзэх болно. Эерэг тал нь урд талын баг болон арын хэсгийн баг нь нэг Цахим хүргэлтийн байгууллагад харьяалагддаг бөгөөд ойр дотно харилцаатай байсан. Ачааллыг XML дээр үндэслэн үүсгэсэн. Үүний зэрэгцээ DVD бизнест зориулсан Netflix API-г бүтээсэн бөгөөд энэ нь гуравдагч талын програмуудыг манай үйлчилгээ рүү траффик чиглүүлэхэд түлхэц болсон.
Гэсэн хэдий ч Netflix API нь бүх контентын мета өгөгдөл, ямар кино байгаа талаарх мэдээллийг агуулсан шинэлэг хэрэглэгчийн интерфэйсээр бидэнд туслахаар маш сайн бэлтгэгдсэн бөгөөд энэ нь үзэх жагсаалт үүсгэх боломжийг бий болгосон. Энэ нь JSON схем дээр суурилсан ерөнхий REST API, орчин үеийн архитектурт ашигладаг HTTP хариу арга хэмжээ, OAuth аюулгүй байдлын загвартай байсан бөгөөд энэ нь тухайн үед урд талын хэрэглээнд шаардлагатай байсан юм. Энэ нь агуулгын дамжуулалтын нийтийн загвараас хувийн хэвшилд шилжих боломжтой болсон.
Шилжилтийн асуудал нь хуваагдмал байсан тул одоо манай систем тэс өөр үйлдлийн зарчим дээр суурилсан хоёр үйлчилгээг ажиллуулж байна - нэг нь Rest, JSON болон OAuth дээр, нөгөө нь RPC, XML дээр, мөн NTBA токен систем дээр суурилсан хэрэглэгчийн аюулгүй байдлын механизм дээр ажилладаг. Энэ бол анхны эрлийз архитектур байв.
Манай хоёр багийн хооронд үндсэндээ галт хана байсан, учир нь API нь анх NCCP-тэй таарахгүй байсан бөгөөд энэ нь багуудын хооронд маргаан үүсгэсэн. Ялгаа нь үйлчилгээ, протокол, хэлхээ, хамгаалалтын модулиудад байсан бөгөөд хөгжүүлэгчид огт өөр контекст хооронд шилжих шаардлагатай болдог.
Үүнтэй холбогдуулан би компанийн ахлах инженерүүдийн нэгтэй ярилцаж, "Урт хугацааны архитектур нь юу байх ёстой вэ?" гэсэн асуултыг асуусан бөгөөд тэрээр "Та илүү их санаа зовж байгаа байх. Зохион байгуулалтын үр дагаврын талаар - хэрэв бид эдгээр зүйлсийг нэгтгэж, бидний сайн хийж сурсан зүйлийг эвдвэл юу болох вэ? Энэ арга нь Конвейн хуульд маш их хамааралтай: "Системийг зохион бүтээх нь тухайн байгууллагын харилцааны бүтцийг хуулбарласан загвараар хязгаарлагддаг." Энэ бол маш хийсвэр тодорхойлолт тул би "Аливаа програм хангамж нь түүнийг үүсгэсэн байгууллагын бүтцийг тусгадаг" гэсэн илүү тодорхой тодорхойлолтыг илүүд үздэг. Эрик Рэймондын хэлсэн миний хамгийн дуртай ишлэл энд байна: "Хэрэв танд дөрвөн баг хөрвүүлэгч дээр ажиллаж байгаа бол дөрвөн дамжлагатай хөрвүүлэгчтэй болно." За, Netflix нь дөрвөн дамжлагатай хөрвүүлэгчтэй бөгөөд бид ингэж ажилладаг.
Энэ тохиолдолд сүүл нь нохойгоо сэгсэрч байна гэж бид хэлж чадна. Бидний нэн тэргүүний зорилт бол шийдэл биш, харин зохион байгуулалт, энэ бол бидний байгаа архитектурыг удирдаж буй байгууллага юм. Аажмаар олон төрлийн үйлчилгээнээс бид Blade Runner гэж нэрлэсэн архитектур руу шилжсэн, учир нь энд бид захын үйлчилгээнүүд болон NCCP-ийг Zuul прокси, API гарц болон холбогдох функцэд шууд салгаж, нэгтгэх чадварын тухай ярьж байна. "Хэсгүүд" нь илүү дэвшилтэт хамгаалалт, дахин тоглуулах, өгөгдөл эрэмбэлэх гэх мэт функц бүхий шинэ микро үйлчилгээ болгон хувиргасан.
Тиймээс хэлтсийн бүтэц, компанийн динамик нь системийн дизайныг төлөвшүүлэхэд чухал үүрэг гүйцэтгэдэг бөгөөд өөрчлөлтийг дэмжих эсвэл саад болдог хүчин зүйл гэж хэлж болно. Микро үйлчилгээний архитектур нь нарийн төвөгтэй, органик бөгөөд түүний эрүүл мэнд нь сахилга бат, эмх замбараагүй байдал дээр суурилдаг.
Бага зэрэг сурталчилгаа
Бидэнтэй хамт байсанд баярлалаа. Манай нийтлэл танд таалагдаж байна уу? Илүү сонирхолтой контент үзэхийг хүсч байна уу? Захиалга өгөх эсвэл найзууддаа санал болгох замаар биднийг дэмжээрэй, , Бидний танд зориулж бүтээсэн анхны түвшний серверүүдийн өвөрмөц аналоги: (RAID1 болон RAID10, 24 хүртэлх цөм, 40 ГБ хүртэл DDR4-тэй байх боломжтой).
Амстердам дахь Equinix Tier IV дата төвд Dell R730xd 2 дахин хямд байна уу? Зөвхөн энд Нидерландад! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллараас! тухай уншина уу
Эх сурвалж: www.habr.com