Артем Денисов ( , )
Badoo бол дэлхийн хамгийн том болзооны сайт юм. Одоогоор бид дэлхий даяар 330 сая орчим бүртгэлтэй хэрэглэгчтэй. Гэхдээ өнөөдрийн бидний ярианы хүрээнд илүү чухал зүйл бол бид 3 петабайт хэрэглэгчийн зургийг хадгалах явдал юм. Манай хэрэглэгчид өдөр бүр 3,5 сая орчим шинэ зураг байршуулдаг бөгөөд унших ачаалал их байдаг Секундэд 80 мянган хүсэлт. Энэ нь манай арын хэсгийн хувьд маш их зүйл бөгөөд заримдаа үүнд бэрхшээлтэй байдаг.
Би ерөнхийдөө зураг хадгалж, илгээдэг энэ системийн дизайны талаар ярих бөгөөд үүнийг хөгжүүлэгчийн үүднээс авч үзэх болно. Энэ нь хэрхэн хөгжсөн тухай товч эргэн тойронд байх болно, энд би гол үе шатуудыг тоймлох болно, гэхдээ би одоо ашиглаж байгаа шийдлүүдийн талаар илүү дэлгэрэнгүй ярих болно.
Одоо эхэлцгээе.
Миний хэлсэнчлэн энэ нь эргэн харах зүйл байх бөгөөд үүнийг хаа нэгтээ эхлүүлэхийн тулд хамгийн түгээмэл жишээг авч үзье.
Бидэнд нийтлэг даалгавар байгаа тул хэрэглэгчийн зургийг хүлээн авах, хадгалах, илгээх хэрэгтэй. Энэ хэлбэрээр даалгавар нь ерөнхий бөгөөд бид юу ч ашиглаж болно:
- орчин үеийн үүл хадгалах,
- хайрцагласан шийдэл, үүнээс одоо маш олон байдаг;
- Бид өгөгдлийн төвд хэд хэдэн машин суулгаж, тэдгээрт том хатуу диск байрлуулж, тэнд зураг хадгалах боломжтой.
Badoo түүхэндээ - одоо ч, тэр үед ч (дөнгөж дөнгөж эхэлж байсан үед) - өөрсдийн серверүүд дээр, манай DC-д амьдардаг. Тиймээс энэ сонголт бидний хувьд оновчтой байсан.
Бид хэд хэдэн машин авч, тэдгээрийг "зураг" гэж нэрлээд, зураг хадгалдаг кластертай болсон. Гэхдээ ямар нэг зүйл дутуу байх шиг байна. Энэ бүхэн ажиллахын тулд бид ямар гэрэл зургийг ямар машин дээр хадгалахаа тодорхойлох хэрэгтэй. Энд бас Америкийг нээх шаардлагагүй.
Бид хадгалах сандаа хэрэглэгчдийн талаарх мэдээлэл бүхий зарим талбарыг нэмдэг. Энэ нь хуваах түлхүүр байх болно. Манай тохиолдолд бид үүнийг place_id гэж нэрлэсэн бөгөөд энэ газар id нь хэрэглэгчийн зураг хадгалагддаг газрыг заадаг. Бид газрын зураг хийдэг.
Эхний шатанд үүнийг гараар ч хийж болно - ийм газартай хэрэглэгчийн зураг ийм сервер дээр буух болно гэж бид хэлж байна. Энэхүү газрын зургийн ачаар бид хэрэглэгч хэзээ зураг байршуулах, хаана хадгалах, хаанаас өгөхөө үргэлж мэддэг болсон.
Энэ бол туйлын өчүүхэн схем боловч нэлээд чухал давуу талтай. Эхнийх нь миний хэлсэнчлэн энгийн зүйл, хоёр дахь нь энэ аргын тусламжтайгаар бид зүгээр л шинэ машин хүргэж, газрын зураг дээр нэмэх замаар хэвтээ байдлаар хялбархан масштаблах боломжтой. Та өөр юу ч хийх шаардлагагүй.
Бидний хувьд хэсэг хугацаанд ийм л байсан.
Энэ нь 2009 оны орчим байсан. Тэд машин хүргэж өгсөн, хүргэсэн ...
Нэгэн цагт энэ схем нь тодорхой сул талуудтай болохыг бид анзаарч эхэлсэн. Сул тал нь юу вэ?
Юуны өмнө хязгаарлагдмал хүчин чадалтай. Бид хүссэн хэмжээгээрээ олон хатуу дискийг нэг физик серверт суулгаж чадахгүй. Энэ нь цаг хугацааны явцад болон мэдээллийн багцын өсөлттэй холбоотой тодорхой асуудал болсон.
Мөн хоёрдугаарт. Энэ нь машинуудын ердийн бус тохиргоо юм, учир нь ийм машиныг бусад кластеруудад дахин ашиглахад хэцүү байдаг; тэдгээр нь нэлээд өвөрмөц, өөрөөр хэлбэл. Тэд гүйцэтгэлийн хувьд сул байх ёстой, гэхдээ нэгэн зэрэг том хатуу дисктэй.
Энэ бүхэн 2009 онд байсан боловч зарчмын хувьд эдгээр шаардлага өнөөдөр ч хамааралтай хэвээр байна. Бид өнгөрсөн түүхтэй тул 2009 онд бүх зүйл үнэхээр муу байсан.
Мөн хамгийн сүүлийн цэг бол үнэ юм.
Тухайн үед үнэ маш өндөр байсан тул бид өөр хувилбар хайх шаардлагатай болсон. Тэдгээр. Бид ямар нэгэн байдлаар дата төвүүд болон энэ бүхэн байрладаг физик серверүүдийн зайг илүү сайн ашиглах шаардлагатай болсон. Мөн манай системийн инженерүүд олон янзын хувилбаруудыг авч үзсэн томоохон судалгааг эхлүүлсэн. Тэд мөн PolyCeph, Luster зэрэг кластер файлын системийг авч үзсэн. Гүйцэтгэлийн асуудал, нэлээд хэцүү ажиллагаа байсан. Тэд татгалзсан. Бид ямар нэгэн байдлаар томруулахын тулд бүх өгөгдлийн багцыг NFS-ээр машин бүр дээр суулгахыг оролдсон. Унших нь бас муу байсан тул бид өөр өөр борлуулагчдаас өөр шийдлүүдийг туршиж үзсэн.
Эцэст нь бид Хадгалах талбайн сүлжээг ашиглахаар шийдсэн.
Эдгээр нь их хэмжээний өгөгдөл хадгалахад зориулагдсан том хэмжээний SHD-ууд юм. Эдгээр нь эцсийн оптик гаралтын машинууд дээр суурилуулсан диск бүхий тавиурууд юм. Тэр. Бидэнд маш бага хэмжээний машинуудын сан байдаг бөгөөд эдгээр SHD-ууд нь бидний илгээх логикт ил тод байдаг, өөрөөр хэлбэл. Манай nginx эсвэл өөр хэн нэгэнд эдгээр зурагнуудын хүсэлтийг илгээнэ үү.
Энэ шийдвэр нь тодорхой давуу талтай байсан. Энэ бол SHD. Энэ нь зураг хадгалах зорилготой юм. Энэ нь машинуудыг хатуу дискээр тоноглохоос хамаагүй хямд юм.
Хоёр дахь нэмэлт.
Энэ нь хүчин чадал нь илүү том болсон, i.e. бид хамаагүй бага хэмжээгээр илүү их хадгалах багтаамжтай.
Гэхдээ маш хурдан гарч ирсэн сул талууд бас байсан. Энэ системийн хэрэглэгчдийн тоо болон ачаалал нэмэгдэхийн хэрээр гүйцэтгэлийн асуудал үүсч эхэлсэн. Энд байгаа асуудал нь маш тодорхой юм - олон зургийг бага хэмжээгээр хадгалахад зориулагдсан аливаа SHD, дүрмээр бол эрчимтэй уншдаг. Энэ нь үнэндээ ямар ч үүл хадгалах газар эсвэл бусад зүйлд үнэн юм. Одоо бидэнд хязгааргүй өргөтгөх боломжтой хамгийн тохиромжтой хадгалах сан байхгүй, та түүнд юу ч хийж болно, энэ нь уншихыг маш сайн тэсвэрлэх болно. Ялангуяа энгийн уншлага.
Манай зурагнуудын нэгэн адил, учир нь зурагнууд нь зөрчилтэй байдаг бөгөөд энэ нь тэдний гүйцэтгэлд ихээхэн нөлөөлнө.
Өнөөдрийн тоо баримтаас харахад, хэрэв бид хадгалах төхөөрөмж дээр 500-аас дээш RPS зураг авах юм бол асуудал аль хэдийн эхэлдэг. Энэ нь бидний хувьд хангалттай муу байсан, учир нь хэрэглэгчдийн тоо нэмэгдэж байгаа тул бүх зүйл улам дордох болно. Үүнийг ямар нэгэн байдлаар оновчтой болгох хэрэгтэй.
Оновчлохын тулд бид тухайн үед ачааллын профайлыг харахаар шийдсэн - ерөнхийдөө юу болж байна, юуг оновчтой болгох шаардлагатай байна.
Энд бүх зүйл бидний гарт тоглодог.
Эхний слайд дээр би аль хэдийн хэлсэн: бид секундэд 80 мянган унших хүсэлт, өдөрт ердөө 3,5 сая байршуулалт хийдэг. Өөрөөр хэлбэл, энэ нь гурван түвшний зөрүү юм. Уншихыг оновчтой болгох шаардлагатай байгаа нь ойлгомжтой бөгөөд хэрхэн яаж хийх нь бараг тодорхой юм.
Бас нэг жижиг зүйл байна. Үйлчилгээний онцлог нь тухайн хүн бүртгүүлж, зураг байршуулж, дараа нь бусад хүмүүсийг идэвхтэй харж, тэдэнд дуртай болж, бусад хүмүүст идэвхтэй харуулдаг. Дараа нь тэр ханиа олох эсвэл ханиа олохгүй, энэ нь хэрхэн гарахаас шалтгаалж, хэсэг хугацаанд үйлчилгээгээ ашиглахаа больсон. Энэ мөчид түүнийг ашиглах үед түүний зургууд маш халуухан байдаг - тэдгээр нь эрэлт хэрэгцээтэй байгаа бөгөөд олон хүмүүс тэднийг үздэг. Тэр үүнийг хийхээ больсон даруйдаа өмнөх шигээ бусад хүмүүстэй харьцахаа больсон бөгөөд түүний зургийг бараг хэзээ ч хүсдэггүй.
Тэдгээр. Бидэнд маш жижиг өгөгдлийн багц бий. Гэхдээ үүнтэй зэрэгцэн түүнд маш олон хүсэлт ирдэг. Энд бүрэн ойлгомжтой шийдэл бол кэш нэмэх явдал юм.
LRU-тай кэш нь бидний бүх асуудлыг шийдэх болно. Бид юу хийж байна вэ?
Бид хадгалах сан бүхий том кластерынхаа өмнө харьцангуй жижиг нэгийг нэмж, үүнийг фото кэш гэж нэрлэдэг. Энэ нь үндсэндээ зүгээр л кэш прокси юм.
Энэ нь дотроос хэрхэн ажилладаг вэ? Энд манай хэрэглэгч, энд хадгалах газар байна. Бүх зүйл өмнөх шигээ. Энэ хооронд бид юу нэмэх вэ?
Энэ бол зүгээр л физик локал дисктэй машин бөгөөд хурдан ажилладаг. Жишээлбэл, энэ нь SSD-тэй холбоотой. Мөн энэ диск дээр зарим төрлийн локал кэш хадгалагддаг.
Энэ юу шиг харагдаж байна? Хэрэглэгч зураг авах хүсэлт илгээдэг. NGINX үүнийг эхлээд локал кэшээс хайдаг. Хэрэв тийм биш бол манай хадгалах сан руу proxy_pass хийгээд тэндээс зургаа татаж аваад хэрэглэгчдэд өгнө үү.
Гэхдээ энэ нь маш улиг болсон бөгөөд дотор нь юу болж байгаа нь тодорхойгүй байна. Энэ нь иймэрхүү зүйл ажилладаг.
Кэш нь логикийн хувьд гурван давхаргад хуваагддаг. Би "гурван давхарга" гэж хэлэхэд энэ нь ямар нэгэн нарийн төвөгтэй систем байна гэсэн үг биш юм. Үгүй ээ, эдгээр нь файлын системийн ердөө гурван директор юм:
- Энэ нь прокси-с татаж авсан зургуудыг зөөдөг буфер юм.
- Энэ нь одоогоор идэвхтэй хүссэн зургуудыг хадгалдаг халуун кэш юм.
- Мөн цөөн тооны хүсэлт ирэх үед зургуудыг халуун кэшээс аажмаар гадагшлуулдаг хүйтэн кэш.
Үүнийг ажиллуулахын тулд бид энэ кэшийг ямар нэгэн байдлаар удирдах, доторх зургуудыг дахин байрлуулах гэх мэт хэрэгтэй. Энэ нь бас маш анхдагч үйл явц юм.
Nginx нь хүсэлт бүрийг RAMDisk access.log руу зүгээр л бичдэг бөгөөд энэ нь одоогийн байдлаар үйлчилж байгаа зураг руу очих замыг (мэдээж харьцангуй зам) болон аль хуваалтад үйлчилсэнийг заадаг. Тэдгээр. Энэ нь "зураг 1" гэж хэлээд дараа нь буфер, халуун кэш, хүйтэн кэш эсвэл прокси гэж хэлж болно.
Үүнээс хамааран бид гэрэл зургийг юу хийхээ шийдэх хэрэгтэй.
Бид машин бүр дээр ажилладаг жижиг демонтой бөгөөд энэ бүртгэлийг байнга уншиж, тодорхой гэрэл зургуудыг ашигласан статистик мэдээллийг санах ойд хадгалдаг.
Тэр зүгээр л тэнд цуглуулж, лангуугаа хадгалж, үе үе дараах зүйлсийг хийдэг. Тэрээр идэвхтэй хүссэн зургуудыг хаана ч байсан халуун кэш рүү шилжүүлдэг.
Хааяа асуудаг, цөөн удаа хүссэн зургуудыг халуун кэшээс аажмаар хүйтэнд шилжүүлдэг.
Бид кэшийн зай дуусмагц хүйтэн кэшээс бүх зүйлийг ялгалгүй устгаж эхэлдэг. Дашрамд хэлэхэд энэ нь сайн ажилладаг.
Зургийг буферт прокси хийхдээ нэн даруй хадгалахын тулд бид proxy_store удирдамжийг ашигладаг бөгөөд буфер нь мөн RAMDisk, өөрөөр хэлбэл. хэрэглэгчийн хувьд энэ нь маш хурдан ажилладаг. Энэ нь кэш серверийн дотоод хэсгүүдэд хамаатай.
Үлдсэн асуулт бол эдгээр серверүүд дээр хүсэлтийг хэрхэн хуваарилах явдал юм.
Хорин хадгалах машин, гурван кэш серверийн кластер байна гэж бодъё (энэ нь ийм болсон).
Бид ямар нэгэн байдлаар ямар зураг авах хүсэлт, хаана байрлуулахаа тодорхойлох хэрэгтэй.
Хамгийн түгээмэл сонголт бол Round Robin юм. Эсвэл санамсаргүй байдлаар хийх үү?
Энэ нь мэдээжийн хэрэг хэд хэдэн сул талуудтай тул бид кэшийг ийм нөхцөлд маш үр ашиггүй ашиглах болно. Хүсэлтүүд зарим санамсаргүй машинууд дээр буух болно: энд кэш хийгдсэн байсан, харин дараагийнх нь байхгүй байна. Тэгээд энэ бүхэн ажиллавал маш муу болно. Кластерт цөөн тооны машинтай ч гэсэн.
Бид ямар нэгэн байдлаар ямар сервер ямар хүсэлт гаргахыг хоёрдмол утгагүй тодорхойлох хэрэгтэй.
Улиг болсон арга бий. Бид URL хаягаас хэшийг эсвэл URL-д байгаа sharding түлхүүрийнхээ хэшийг аваад серверийн тоогоор хуваана. Ажиллана? Вилл.
Тэдгээр. Бидэнд 2% хүсэлт байна, жишээлбэл, зарим "example_url"-ийн хувьд энэ нь үргэлж "XNUMX" индекстэй сервер дээр буух бөгөөд кэшийг аль болох сайн устгаж байх болно.
Гэхдээ ийм схемд дахин хуваахад асуудал гардаг. Дахин хуваалцах - Би серверийн тоог өөрчлөхийг хэлж байна.
Манай кэш кластер даахаа больсон тул өөр машин нэмэхээр шийдсэн гэж бодъё.
Нэмье.
Одоо бүх зүйл гуравт биш дөрөвт хуваагддаг болсон. Тиймээс, бидэнд байсан бараг бүх түлхүүрүүд, бараг бүх URL-ууд одоо бусад серверүүд дээр амьдардаг. Бүхэл бүтэн кэш хэсэгхэн зуур хүчингүй болсон. Бүх хүсэлт манай хадгалалтын кластер дээр унасан бөгөөд энэ нь муудаж, үйлчилгээ доголдож, хэрэглэгчид сэтгэл хангалуун бус байв. Би үүнийг хийхийг хүсэхгүй байна.
Энэ сонголт бидэнд бас тохирохгүй.
Тэр. Бид юу хийх ёстой вэ? Бид ямар нэгэн байдлаар кэшийг үр ашигтай ашиглах, ижил хүсэлтийг нэг сервер дээр дахин дахин илгээх ёстой, гэхдээ дахин хуваахад тэсвэртэй байх ёстой. Мөн ийм шийдэл байдаг, энэ нь тийм ч төвөгтэй биш юм. Үүнийг тууштай хэш гэж нэрлэдэг.
Энэ юу шиг харагдаж байна вэ?
Бид sharding түлхүүрээс зарим функцийг авч, түүний бүх утгыг тойрог дээр тараана. Тэдгээр. 0 цэг дээр түүний хамгийн бага ба хамгийн их утгууд нийлдэг. Дараа нь бид бүх серверээ нэг тойрог дээр ойролцоогоор дараах байдлаар байрлуулна.
Сервер бүр нэг цэгээр тодорхойлогддог бөгөөд цагийн зүүний дагуу түүн рүү явдаг салбар нь энэ хостоор үйлчилдэг. Бидэнд хүсэлт ирэхэд бид жишээлбэл, А хүсэлт - энэ нь тэнд хэштэй - сервер 2. Хүсэлт B - сервер 3. гэх мэтээр үйлчилдэг болохыг шууд хардаг.
Дахин хуваах үед энэ нөхцөлд юу тохиолддог вэ?
Бид өмнөх шигээ кэшийг бүхэлд нь хүчингүй болгож, бүх түлхүүрүүдийг шилжүүлэхгүй, харин салбар бүрийг богино зайд шилжүүлдэг бөгөөд ингэснээр бидний нэмэхийг хүсч буй зургаа дахь сервер нь сул зайд багтах бөгөөд бид тэнд нэмнэ.
Мэдээжийн хэрэг, ийм нөхцөлд түлхүүрүүд нь бас хөдөлдөг. Гэхдээ тэд өмнөхөөсөө хамаагүй сул дорой хөдөлж байна. Бидний эхний хоёр түлхүүр сервер дээрээ үлдсэн бөгөөд кэш сервер нь зөвхөн сүүлчийн түлхүүрээр өөрчлөгдсөнийг бид харж байна. Энэ нь маш үр дүнтэй ажилладаг бөгөөд хэрэв та шинэ хостуудыг аажмаар нэмбэл энд нэг их асуудал гарахгүй. Та бага багаар нэмж, нэмээд кэш дахин дүүрэх хүртэл хүлээнэ үү, бүх зүйл сайн ажилладаг.
Цорын ганц асуулт бол татгалзах явдал юм. Ямар нэг машин эвдэрсэн гэж бодъё.
Хэрэв жишээлбэл, машин дахин ачаалагдсан бол бид ямар нэгэн байдлаар хүсэлт гаргах шаардлагатай бол энэ газрын зургийг сэргээх, кэшийн зарим хэсгийг хүчингүй болгох гэх мэтийг үнэхээр хүсэхгүй байна. Бид зүгээр л сайт бүрт нэг нөөц зургийн кэш хадгалдаг бөгөөд энэ нь одоогоор ажиллахгүй байгаа аливаа машиныг орлуулах үүрэг гүйцэтгэдэг. Хэрэв гэнэт манай серверүүдийн аль нэг нь ажиллахгүй бол ачаалал тэнд очно. Мэдээжийн хэрэг, бидэнд кэш байхгүй, жишээлбэл. хүйтэн байна, гэхдээ ядаж хэрэглэгчийн хүсэлтийг боловсруулж байна. Хэрэв энэ нь богино хугацааны интервал юм бол бид үүнийг бүрэн тайван мэдрэх болно. Хадгалахад илүү их ачаалал байна. Хэрэв энэ интервал урт байвал бид энэ серверийг газрын зургаас устгах, эсвэл өөр серверээр солих шийдвэр гаргаж болно.
Энэ нь кэшийн системийн тухай юм. Үр дүнг харцгаая.
Энд ямар ч төвөгтэй зүйл байхгүй юм шиг санагдаж байна. Гэхдээ кэшийг удирдах энэ арга нь бидэнд 98% орчим заль мэхийг өгсөн. Тэдгээр. Секундэд эдгээр 80 мянган хүсэлтээс ердөө 1600 нь хадгалалтанд хүрдэг бөгөөд энэ нь бүрэн хэвийн ачаалал бөгөөд тэд үүнийг тайвнаар тэсвэрлэдэг, бидэнд үргэлж нөөц бий.
Бид эдгээр серверүүдийг гурван DC-д байрлуулж, Прага, Майами, Хонг Конг гэсэн гурван цэгийг хүлээн авлаа.
Тэр. Эдгээр нь манай зорилтот зах зээл бүр дээр бага эсвэл бага хэмжээгээр байрладаг.
Сайхан урамшууллын хувьд бид энэ кэш проксиг авсан бөгөөд CPU нь үнэхээр идэвхгүй байдаг, учир нь энэ нь контентоор үйлчлэхэд тийм ч шаардлагагүй юм. Тэнд NGINX+ Lua ашиглан бид маш их ашиг тустай логикийг хэрэгжүүлсэн.
Жишээлбэл, бид webp эсвэл дэвшилтэт jpeg (эдгээр нь үр дүнтэй орчин үеийн форматууд) дээр туршилт хийж, энэ нь замын хөдөлгөөнд хэрхэн нөлөөлж байгааг харах, зарим шийдвэр гаргах, зарим улс оронд үүнийг идэвхжүүлэх гэх мэт; Динамик хэмжээг өөрчлөх эсвэл зураг тайрах боломжтой.
Жишээлбэл, танд зураг харуулдаг гар утасны програм байгаа бөгөөд гар утасны програм нь үйлчлүүлэгчийн CPU-ийг их хэмжээний зураг авахыг хүсч, дараа нь тодорхой хэмжээгээр өөрчлөхийг хүсэхгүй байгаа тохиолдолд ашиглахад тохиромжтой. үзэмж. Бид зүгээр л UPort нөхцөлт URL-д зарим параметрүүдийг динамикаар зааж өгөх боломжтой бөгөөд зургийн кэш нь зургийн хэмжээг өөрөө өөрчлөх болно. Дүрмээр бол энэ нь дискэн дээр байгаа хэмжээсийг хүссэн хэмжээтэй аль болох ойртуулж, тодорхой координатаар буулгах болно.
Дашрамд хэлэхэд, бид өндөр ачаалалтай систем хөгжүүлэгчдийн хурлын сүүлийн таван жилийн видео бичлэгийг олон нийтэд нээлттэй болгосон. . Үзэх, сурах, хуваалцах, бүртгүүлэх .
Мөн бид тэнд маш олон бүтээгдэхүүний логикийг нэмж болно. Жишээлбэл, бид URL параметрүүдийг ашиглан өөр өөр усан тэмдэг нэмж, зургийг бүдгэрүүлэх, бүдгэрүүлэх, пикселжүүлэх боломжтой. Энэ бол бид хүний зургийг харуулахыг хүсч байгаа боловч түүний царайг харуулахыг хүсэхгүй байгаа, энэ нь сайн ажилладаг, бүгдийг энд хэрэгжүүлдэг.
Бид юу авсан бэ? Бид гурван оноотой, сайн трик хурдтай, тэр үед эдгээр машинууд дээр ажиллахгүй CPU байхгүй. Тэр одоо өмнөхөөсөө илүү чухал болсон нь мэдээж. Бид өөрсдөдөө илүү хүчирхэг машин өгөх хэрэгтэй, гэхдээ энэ нь үнэ цэнэтэй юм.
Энэ нь гэрэл зургуудыг буцааж өгөхтэй холбоотой юм. Энд бүх зүйл маш тодорхой бөгөөд тодорхой байна. Би Америкийг нээгээгүй гэж бодож байна, бараг бүх CDN ийм байдлаар ажилладаг.
Магадгүй, боловсронгуй сонсогчдод асуулт гарч ирж магадгүй юм: яагаад бүгдийг CDN болгож болохгүй гэж? Энэ нь бараг ижил байх болно; орчин үеийн бүх CDN үүнийг хийж чадна. Мөн хэд хэдэн шалтгаан бий.
Эхнийх нь гэрэл зураг юм.
Энэ бол манай дэд бүтцийн гол цэгүүдийн нэг бөгөөд үүнд аль болох хяналт тавих шаардлагатай байна. Хэрэв энэ нь гуравдагч талын худалдагчийн ямар нэгэн шийдэл бөгөөд танд ямар ч эрх мэдэл байхгүй бол танд том өгөгдлийн багц болон маш их урсгалтай үед түүнтэй амьдрахад хэцүү байх болно. хэрэглэгчийн хүсэлт.
Би танд нэг жишээ хэлье. Одоо бид дэд бүтцээрээ, жишээ нь, ямар нэг асуудал, газар доорх тогшсон тохиолдолд машин руу очиж, тэндээ эмх замбараагүй байх боломжтой. Бид зөвхөн шаардлагатай хэмжүүрүүдийн цуглуулгыг нэмж, ямар нэгэн байдлаар туршилт хийж, энэ нь графикт хэрхэн нөлөөлж байгааг харах боломжтой. Одоо энэ кэш кластер дээр маш олон статистик мэдээлэл цуглуулж байна. Мөн бид үүнийг үе үе харж, зарим гажигийг судлахад удаан хугацаа зарцуулдаг. Хэрэв энэ нь CDN талд байсан бол үүнийг хянахад илүү хэцүү байх болно. Эсвэл, жишээ нь, ямар нэгэн осол гарвал бид юу болсныг мэддэг, түүнтэй хэрхэн амьдрах, яаж даван туулахаа мэддэг. Энэ бол анхны дүгнэлт юм.
Хоёрдахь дүгнэлт нь нэлээд түүхэн юм, учир нь систем нь удаан хугацааны туршид хөгжиж ирсэн бөгөөд янз бүрийн үе шатанд бизнесийн олон янзын шаардлага байсан бөгөөд тэдгээр нь CDN-ийн үзэл баримтлалд үргэлж нийцдэггүй.
Мөн өмнөхөөс гарах цэг нь
Учир нь зургийн кэш дээр бид маш олон тодорхой логиктой байдаг бөгөөд үүнийг хүсэлтийн дагуу үргэлж нэмж болохгүй. Ямар ч CDN таны хүсэлтээр танд зарим нэг захиалгат зүйлийг нэмэх магадлал багатай юм. Жишээлбэл, хэрэв та үйлчлүүлэгч ямар нэг зүйлийг өөрчлөхийг хүсэхгүй байгаа бол URL-уудыг шифрлэх. Та сервер дээрх URL-г өөрчилж, шифрлээд, динамик параметрүүдийг энд илгээхийг хүсч байна уу.
Үүнээс ямар дүгнэлт гарах вэ? Манай тохиолдолд CDN нь тийм ч сайн хувилбар биш юм.
Мөн таны хувьд, хэрэв танд бизнесийн тодорхой шаардлага байгаа бол миний үзүүлсэн зүйлийг өөрөө амархан хэрэгжүүлж чадна. Мөн энэ нь ижил төстэй ачааллын профайлтай төгс ажиллах болно.
Гэхдээ хэрэв танд ямар нэгэн ерөнхий шийдэл байгаа бөгөөд даалгавар нь тийм ч тодорхой биш бол та CDN-ийг аюулгүйгээр авч болно. Эсвэл цаг хугацаа, нөөц нь танд хяналтаас илүү чухал бол.
Орчин үеийн CDN-д миний одоо хэлсэн бараг бүх зүйл бий. Нэмэх эсвэл хасах зарим функцийг эс тооцвол.
Энэ бол зураг өгөх тухай юм.
Одоо бид өнгөрсөн түүхээ бага зэрэг урагшлуулж, хадгалалтын талаар ярилцъя.
2013 он өнгөрч байсан.
Кэш серверүүд нэмэгдсэн, гүйцэтгэлийн асуудал арилсан. Бүх зүйл сайхан байна. Өгөгдлийн багц нэмэгдэж байна. 2013 оны байдлаар бид хадгалах санд холбогдсон 80 орчим сервер, DC бүрт 40 орчим кэш сервертэй байсан. Энэ нь DC тус бүр дээр 560 терабайт өгөгдөл, өөрөөр хэлбэл. нийтдээ петабайт орчим.
Мэдээллийн багц нэмэгдэхийн хэрээр үйл ажиллагааны зардал ихээхэн нэмэгдэж эхлэв. Энэ юу гэсэн үг вэ?
Энэ зурсан диаграммд - SAN-тай, түүнтэй холбогдсон машинууд болон кэшүүдтэй - маш олон эвдэрсэн цэгүүд байдаг. Хэрэв бид өмнө нь серверүүдийн кэшийн бүтэлгүйтлийн асуудлыг шийдэж байсан бол бүх зүйл урьдчилан таамаглах боломжтой, ойлгомжтой байсан ч хадгалах тал дээр бүх зүйл илүү муу байсан.
Нэгдүгээрт, Хадгалах бүсийн сүлжээ (SAN) өөрөө бүтэлгүйтэж болзошгүй.
Хоёрдугаарт, энэ нь эцсийн машинуудтай оптикоор холбогддог. Оптик карт болон оч залгууртай холбоотой асуудал гарч болзошгүй.
Мэдээжийн хэрэг, эдгээр нь SAN-тай адил олон байдаггүй, гэхдээ эдгээр нь бас бүтэлгүйтлийн цэгүүд юм.
Дараа нь хадгалах төхөөрөмжтэй холбогдсон машин өөрөө юм. Энэ нь бас бүтэлгүйтэж болно.
Нийтдээ бидэнд бүтэлгүйтсэн гурван оноо байна.
Цаашилбал, эвдэрсэн цэгүүдээс гадна агуулахын засвар үйлчилгээ маш их байдаг.
Энэ бол нарийн төвөгтэй олон бүрэлдэхүүн хэсэгтэй систем бөгөөд системийн инженерүүд үүнтэй ажиллахад хэцүү байдаг.
Мөн сүүлчийн, хамгийн чухал цэг. Хэрэв эдгээр гурван цэгийн аль нэг нь бүтэлгүйтвэл файлын систем эвдэрч болзошгүй тул хэрэглэгчийн мэдээллийг алдах магадлал XNUMX-ээс ихгүй байна.
Манай файлын систем эвдэрсэн гэж бодъё. Нэгдүгээрт, түүнийг сэргээхэд удаан хугацаа шаардагддаг - их хэмжээний өгөгдөлтэй бол долоо хоног шаардагдана. Хоёрдугаарт, эцэст нь бид ямар нэгэн байдлаар хэрэглэгчийн зураг болгон нэгтгэх шаардлагатай олон тооны ойлгомжгүй файлуудтай байх магадлалтай. Мөн бид өгөгдлийг алдах эрсдэлтэй. Эрсдэл нэлээд өндөр байна. Ийм нөхцөл байдал олон удаа тохиолдох тусам энэ бүхэл бүтэн гинжин хэлхээнд илүү олон асуудал үүсэх тусам энэ эрсдэл өндөр болно.
Энэ талаар ямар нэг зүйл хийх хэрэгтэй байсан. Бид зөвхөн өгөгдлийг нөөцлөх хэрэгтэй гэж шийдсэн. Энэ нь үнэндээ ойлгомжтой бөгөөд сайн шийдэл юм. Бид юу хийсэн бэ?
Манай сервер өмнө нь хадгалах санд холбогдсон үед иймэрхүү харагдаж байсан. Энэ бол нэг үндсэн хэсэг бөгөөд энэ нь зүгээр л оптикоор дамжуулан алсын зайнаас хадгалах төхөөрөмжийг төлөөлдөг блок төхөөрөмж юм.
Бид дөнгөж сая хоёр дахь хэсгийг нэмлээ.
Бид түүний хажууд хоёр дахь хадгалах сан байрлуулж (аз болоход энэ нь мөнгөний хувьд тийм ч үнэтэй биш) бөгөөд үүнийг нөөц хуваалт гэж нэрлэсэн. Энэ нь мөн шилэн кабелиар холбогдсон бөгөөд нэг машин дээр байрладаг. Гэхдээ бид тэдгээрийн хоорондох өгөгдлийг ямар нэгэн байдлаар синхрончлох хэрэгтэй.
Энд бид зүгээр л ойролцоох асинхрон дараалал үүсгэдэг.
Тэр тийм ч завгүй биш. Бидэнд хангалттай бүртгэл байхгүй гэдгийг бид мэднэ. Дараалал нь MySQL-д "та энэ зургийг нөөцлөх хэрэгтэй" гэх мэт мөрүүдийг бичсэн зүгээр л хүснэгт юм. Ямар нэгэн өөрчлөлт эсвэл байршуулалт хийснээр бид үндсэн хуваалтаас асинхрон эсвэл зүгээр л нэг төрлийн арын ажилтан ашиглан нөөцлөлт рүү хуулдаг.
Тиймээс бид үргэлж хоёр тууштай хэсэгтэй байдаг. Энэ системийн аль нэг хэсэг нь бүтэлгүйтсэн ч гэсэн бид үндсэн хуваалтыг үргэлж нөөцлөлтөөр солих боломжтой бөгөөд бүх зүйл үргэлжлүүлэн ажиллах болно.
Гэвч үүнээс болоод унших ачаалал их хэмжээгээр нэмэгддэг, учир нь... Үндсэн хэсгээс уншсан үйлчлүүлэгчдээс гадна, тэд эхлээд тэнд байгаа зургийг хардаг (энэ нь илүү сүүлийн үеийн), дараа нь олсонгүй бол нөөцөөс хайдаг (гэхдээ NGINX үүнийг л хийдэг), Манай систем нь үндсэн хуваалтаас уншдаг нэмэлт нөөц юм. Энэ нь саад тотгор байсан юм биш, гэхдээ би ачааллыг нэмэгдүүлэхийг хүсээгүй, яг үүнтэй адил.
Мөн бид жижиг SSD болох гурав дахь дискийг нэмээд буфер гэж нэрлэв.
Одоо яаж ажилладаг.
Хэрэглэгч буферт зургаа байршуулсны дараа дараалалд үйл явдал хаягдаж, үүнийг хоёр хэсэгт хуваах шаардлагатай болно. Үүнийг хуулж, зураг нь буфер дээр хэсэг хугацаанд (жишээлбэл, нэг өдөр) амьдардаг бөгөөд зөвхөн дараа нь тэндээс цэвэрлэгддэг. Энэ нь хэрэглэгчийн туршлагыг ихээхэн сайжруулдаг, учир нь хэрэглэгч зураг байршуулдаг, дүрмээр бол хүсэлтүүд тэр даруй дагаж эхэлдэг, эсвэл тэр өөрөө хуудсыг шинэчилж, шинэчилсэн байдаг. Гэхдээ энэ бүхэн байршуулалт хийдэг програмаас хамаарна.
Эсвэл, жишээлбэл, түүний өөрийгөө харуулж эхэлсэн бусад хүмүүс энэ зургийн дараа шууд хүсэлт илгээдэг. Энэ нь кэшэд хараахан ороогүй байгаа тул эхний хүсэлт маш хурдан ирдэг. Зургийн кэштэй үндсэндээ адилхан. Удаан хадгалах нь үүнд огт хамаагүй. Нэг өдрийн дараа үүнийг цэвэрлэхэд энэ нь бидний кэшийн давхаргад хадгалагдсан эсвэл хэнд ч хэрэггүй болсон байх магадлалтай. Тэдгээр. Ийм энгийн залилангийн ачаар энд хэрэглэгчийн туршлага маш сайн өссөн.
За, хамгийн чухал нь: бид өгөгдөл алдахаа больсон.
Бид зогссон гэж хэлье болзошгүй өгөгдлийг алдах, учир нь бид үүнийг үнэхээр алдаагүй. Гэхдээ аюул байсан. Энэ шийдэл нь мэдээж сайн гэдгийг бид харж байна, гэхдээ энэ нь асуудлыг бүрэн шийдэхийн оронд шинж тэмдгийг арилгахтай адил юм. Мөн зарим асуудал энд хэвээр байна.
Нэгдүгээрт, энэ нь бүх машин механизм ажиллаж байгаа физик хост хэлбэрийн бүтэлгүйтлийн цэг бөгөөд энэ нь арилаагүй байна.
Хоёрдугаарт, SAN-тай холбоотой асуудлууд, тэдгээрийн хүнд засвар үйлчилгээ гэх мэт асуудлууд байсаар байна. Энэ нь маш чухал хүчин зүйл биш байсан ч би ямар нэгэн байдлаар түүнгүйгээр амьдрахыг хичээхийг хүссэн.
Мөн бид гурав дахь хувилбарыг (үнэндээ хоёр дахь нь) - захиалгын хувилбарыг хийсэн. Ямар харагдаж байсан бэ?
Энэ бол ийм байсан -
Бидний гол асуудал бол энэ нь бие махбодийн хост юм.
Нэгдүгээрт, бид SAN-уудыг устгаж байна, учир нь бид туршилт хийхийг хүсч байна, бид зөвхөн дотоод хатуу дискийг туршиж үзэхийг хүсч байна.
Энэ бол аль хэдийн 2014-2015 он бөгөөд тэр үед нэг хост дахь диск болон тэдгээрийн багтаамжийн байдал хамаагүй дээрдсэн. Бид яагаад туршиж болохгүй гэж шийдсэн.
Тэгээд бид зүгээр л нөөц хуваалтаа аваад тусдаа машин руу биечлэн шилжүүлнэ.
Тиймээс бид энэ диаграммыг олж авна. Бидэнд ижил мэдээллийн багцыг хадгалдаг хоёр машин бий. Тэд бие биенээ бүрэн нөөцөлж, ижил MySQL дэх асинхрон дараалалаар дамжуулан сүлжээгээр өгөгдлийг синхрончлох болно.
Яагаад энэ сайн ажилладаг вэ гэвэл манайд цөөхөн бичлэг байгаа. Тэдгээр. Хэрэв бичих нь уншихтай харьцуулж болох юм бол бидэнд ямар нэгэн сүлжээний ачаалал, асуудал гарах байсан. Бичлэг бага, их уншдаг - энэ арга нь сайн ажилладаг, i.e. Бид энэ хоёр серверийн хооронд зураг хуулах нь ховор.
Хэрэв та бага зэрэг нарийвчлан авч үзвэл энэ нь хэрхэн ажилладаг вэ.
Байршуулах. Тэнцвэржүүлэгч нь санамсаргүй хостуудыг хосоор нь сонгоод түүнд байршуулдаг. Үүний зэрэгцээ тэрээр эрүүл мэндийн үзлэг хийж, машин унахгүй эсэхийг шалгадаг. Тэдгээр. Тэр зурагнуудаа зөвхөн шууд серверт байршуулдаг бөгөөд дараа нь асинхрон дараалалаар хөршдөө хуулж авдаг. Татаж авснаар бүх зүйл маш энгийн.
Даалгавар нь арай илүү хэцүү.
Луа энд бидэнд тусалсан, учир нь ванилийн NGINX дээр ийм логик гаргахад хэцүү байж болно. Бид эхлээд эхний серверт хүсэлт гаргаж, зураг байгаа эсэхийг шалгана, учир нь үүнийг хөршдөө байршуулах боломжтой боловч энд хараахан ирээгүй байна. Хэрэв зураг байгаа бол энэ нь сайн хэрэг. Бид үүнийг шууд үйлчлүүлэгчид өгч, магадгүй кэш хийх боломжтой.
Хэрэв байхгүй бол бид хөршдөө хүсэлт гаргаж, тэндээс хүлээж авах баталгаатай.
Тэр. Бид дахин хэлж чадна: гүйцэтгэлтэй холбоотой асуудал байж магадгүй, учир нь байнгын дугуй аялал байдаг - зургийг байршуулсан, энэ нь энд байхгүй, бид нэг хүсэлтийн оронд хоёр хүсэлт гаргаж байна, энэ нь удаан ажиллах ёстой.
Манай нөхцөлд энэ нь удаан ажилладаггүй.
Бид энэ систем дээр олон тооны хэмжүүр цуглуулдаг бөгөөд ийм механизмын нөхцөлт ухаалаг түвшин 95% орчим байдаг. Тэдгээр. Энэ нөөцлөлтийн хоцрогдол нь бага бөгөөд үүнээс болж бид бараг баталгаатай, зургийг байршуулсны дараа бид үүнийг эхний удаа авах бөгөөд хоёр удаа хаашаа ч явах шаардлагагүй болно.
Тэгэхээр бидэнд үнэхээр гайхалтай өөр юу байгаа вэ?
Өмнө нь бид үндсэн нөөц хуваалттай байсан бөгөөд бид тэдгээрийг дараалан уншдаг байсан. Тэдгээр. Бид үргэлж эхлээд үндсэн, дараа нь нөөцлөлт дээр хайдаг байсан. Энэ нь нэг алхам байсан.
Одоо бид хоёр машинаас унших аргыг нэгэн зэрэг ашигладаг. Бид Round Robin ашиглан хүсэлтийг түгээдэг. Тохиолдлын багахан хувьд бид хоёр хүсэлт гаргадаг. Гэхдээ ерөнхийдөө бид өмнөхөөсөө хоёр дахин их уншлагын нөөцтэй болсон. Мөн тухайн үед бидэнд байсан илгээгч машинууд болон шууд хадгалах машинуудын ачаалал эрс багассан.
Алдааг тэсвэрлэх чадварын хувьд. Үнэндээ бид үүний төлөө голлон тэмцсэн. Алдааг тэсвэрлэх чадвартай бол энд бүх зүйл сайхан болсон.
Нэг машин эвдэрч байна.
Асуудалгүй! Системийн инженер шөнө ч сэрэхгүй, өглөө болтол хүлээх болно, муу зүйл тохиолдохгүй.
Хэрэв энэ машин доголдсон ч дараалал нь эвдэрсэн, ямар ч асуудал гарахгүй, лог нь эхлээд амьд машин дээр хуримтлагдаж, дараа нь дараалалд, дараа нь машин дээр нэмэгдэх болно. хэсэг хугацааны дараа ашиглалтад орно.
Засвар үйлчилгээтэй ижил зүйл. Бид зүгээр л нэг машиныг унтрааж, бүх усан сангаас гараараа татаж аваад, урсгалыг хүлээж авахаа больж, бид ямар нэгэн засвар үйлчилгээ хийж, ямар нэг зүйлийг засварлаж, дараа нь үйлчилгээнд буцааж өгдөг бөгөөд энэ нөөц нь маш хурдан хийгддэг. Тэдгээр. өдөрт нэг машины зогсолт хэдхэн минутын дотор дуусдаг. Энэ үнэхээр маш бага юм. Алдааг тэсвэрлэх чадвартай тул энд бүх зүйл сайхан байна гэж би дахин хэлье.
Энэхүү цомхотголын схемээс ямар дүгнэлт хийж болох вэ?
Бид алдааг тэсвэрлэх чадвартай болсон.
Хэрэглэхэд хялбар. Машинууд нь орон нутгийн хатуу дисктэй тул түүнтэй ажилладаг инженерүүдэд энэ нь үйл ажиллагааны үүднээс илүү тохиромжтой.
Бид давхар уншлагын тэтгэмж авсан.
Энэ нь алдааг тэсвэрлэх чадвараас гадна маш сайн урамшуулал юм.
Гэхдээ бас асуудал бий. Одоо бид үүнтэй холбоотой зарим функцийг илүү төвөгтэй хөгжүүлж байна, учир нь систем эцэстээ 100% тогтвортой болсон.
"Бид одоо ямар сервер дээр ажиллаж байна вэ?", "Энд үнэхээр одоогийн зураг байгаа юу?" гэж байнга бодож байх ёстой. гэх мэт. Энэ нь мэдээжийн хэрэг бүх зүйл дууссан бөгөөд бизнесийн логик бичдэг програмистын хувьд энэ нь ил тод байдаг. Гэсэн хэдий ч энэ том нарийн төвөгтэй давхарга гарч ирэв. Гэхдээ бид үүнээс авсан сайн сайхны төлөө үүнийг тэвчихэд бэлэн байна.
Мөн энд дахин зөрчилдөөн гарч ирнэ.
Бүх зүйлийг дотоод хатуу диск дээр хадгалах нь муу гэж би эхэндээ хэлсэн. Тэгээд одоо би бидэнд таалагдсан гэж хэлж байна.
Тийм ээ, үнэхээр цаг хугацаа өнгөрөхөд нөхцөл байдал маш их өөрчлөгдсөн бөгөөд одоо энэ арга нь олон давуу талтай болсон. Нэгдүгээрт, бид илүү хялбар ажиллагаатай болно.
Хоёрдугаарт, энэ нь илүү бүтээмжтэй, учир нь бидэнд эдгээр автомат хянагч эсвэл дискний тавиуртай холболт байхгүй байна.
Тэнд асар их хэмжээний машин техник байдаг бөгөөд эдгээр нь машин дээр угсарч, дайралт хийх цөөн хэдэн диск юм.
Гэхдээ сул талууд бас бий.
Энэ нь одоогийн үнээр ч гэсэн SAN ашиглахаас ойролцоогоор 1,5 дахин үнэтэй юм. Тиймээс бид бүхэл бүтэн том кластераа орон нутгийн хатуу дисктэй машин болгон хувиргахгүй байхаар шийдсэн бөгөөд эрлийз шийдлийг үлдээхээр шийдсэн.
Манай машинуудын тал хувь нь хатуу дисктэй ажилладаг (тэн хагас нь биш - магадгүй 30 хувь). Үлдсэн хэсэг нь анхны захиалгын схемтэй байсан хуучин машинууд юм. Бид тэдгээрийг зүгээр л дахин холбосон, учир нь бидэнд шинэ өгөгдөл эсвэл өөр зүйл хэрэггүй байсан тул бэхэлгээг нэг физик хостоос хоёр руу шилжүүлсэн.
Мөн бид одоо уншлагын асар их нөөцтэй бөгөөд бид үүнийг өргөжүүлсэн. Хэрэв бид өмнө нь нэг санах ойг нэг машин дээр суурилуулсан бол одоо дөрөв, жишээ нь нэг хос дээр суурилуулсан. Мөн энэ нь сайн ажилладаг.
Юу амжуулсан, юуны төлөө тэмцсэн, амжилтанд хүрсэн эсэхээ товч тоймлон хүргэе.
Үр дүн
Бидэнд 33 сая хэрэглэгч бий.
Бидэнд Прага, Майами, Хонг Конг гэсэн гурван цэг бий.
Эдгээр нь NGINX-ийн энгийн машинууд, түүний access.log болон Python дэмонууд ажилладаг, энэ бүгдийг боловсруулж, кэшийг удирддаг хурдан локал диск (SSD) бүхий машинуудаас бүрдэх кэш давхаргыг агуулдаг.
Хэрэв та хүсэж байгаа бол, хэрэв та өөрийн төсөлд хамрагдаж байгаа бол, хэрэв зураг нь бидний хувьд чухал биш бол, эсвэл хөгжлийн хурд, нөөцийн өртөгтэй харьцуулах хяналт таны хувьд өөр чиглэлд байгаа бол та үүнийг аюулгүйгээр сольж болно. CDN-тэй бол орчин үеийн CDN-үүд сайн ажилладаг.
Дараа нь хадгалах давхарга ирдэг бөгөөд бид бие биенээ нөөцлөх хос машинуудын кластеруудтай бөгөөд файлууд өөрчлөгдөх бүртээ нэгээс нөгөөд синхроноор хуулдаг.
Түүнээс гадна эдгээр машинуудын зарим нь орон нутгийн хатуу дисктэй ажилладаг.
Эдгээр машинуудын зарим нь SAN-д холбогдсон байдаг.
Мөн нэг талаас ашиглахад илүү тохиромжтой, арай илүү бүтээмжтэй, нөгөө талаас байрлуулах нягтрал, нэг гигабайтын үнийн хувьд тохиромжтой.
Энэ бол бидний олж авсан архитектур, хэрхэн хөгжсөн тухай товч тойм юм.
Ахмадаас хэдэн зөвлөгөө, маш энгийн.
Нэгдүгээрт, хэрэв та өөрийн зургийн дэд бүтцийн бүх зүйлийг яаралтай сайжруулах шаардлагатай гэж гэнэт шийдсэн бол эхлээд хэмжилт хий, учир нь юу ч сайжруулах шаардлагагүй байж магадгүй юм.
Би танд нэг жишээ хэлье. Бид хавсралтаас зургийг чатаар илгээдэг машинуудын кластертай бөгөөд энэ схем нь 2009 оноос хойш ажиллаж байгаа бөгөөд үүнээс болж зовж шаналах хүн байхгүй. Бүгд сайн, бүх зүйлд дуртай.
Хэмжихийн тулд эхлээд олон тооны хэмжүүр өлгөж, тэдгээрийг хар, дараа нь юунд сэтгэл хангалуун бус байгаагаа, юуг сайжруулах шаардлагатайг шийдээрэй. Үүнийг хэмжихийн тулд бидэнд Pinba хэмээх гайхалтай хэрэгсэл бий.
Энэ нь NGINX-ээс хүсэлт, хариултын код, цаг хугацааны хуваарилалт тус бүрийн хувьд маш нарийвчилсан статистик мэдээллийг цуглуулах боломжийг олгодог. Энэ нь янз бүрийн аналитик системүүдтэй холбоотой бөгөөд дараа нь та бүгдийг сайхан харж болно.
Эхлээд хэмжиж, дараа нь сайжруулсан.
Цаашид. Бид кэш ашиглан унших, sharding ашиглан бичихийг оновчтой болгодог, гэхдээ энэ нь тодорхой цэг юм.
Цаашид. Хэрэв та одоо л системээ бүтээж эхэлж байгаа бол зургийг хувиршгүй файл болгон хийх нь илүү дээр юм. Учир нь та кэшийг хүчингүй болгох, логик нь зургийн зөв хувилбарыг хэрхэн олох гэх мэт асуудлуудыг бүхэлд нь алддаг.
Та зууг байршуулаад дараа нь эргүүлээд, физикийн хувьд өөр файл байсан гэж бодъё. Тэдгээр. Бодох шаардлагагүй: одоо би бага зэрэг зай хэмнэж, ижил файл руу бичиж, хувилбараа өөрчлөх болно. Энэ нь үргэлж сайн ажилладаггүй бөгөөд дараа нь маш их толгой өвдөхөд хүргэдэг.
Дараагийн цэг. Хэмжээг хурдан өөрчлөх тухай.
Өмнө нь хэрэглэгчид зураг байршуулах үед бид нэн даруй бүх тохиолдлуудад, өөр өөр үйлчлүүлэгчдэд зориулсан бүхэл бүтэн хэмжээг багасгаж, бүгд дискэн дээр байсан. Одоо бид үүнийг орхисон.
Бид жижиг, дунд, том гэсэн гурван үндсэн хэмжээг л үлдээсэн. Бид зүгээр л Uport дээр биднээс асуусан хэмжээнээс бусад бүх зүйлийг багасгадаг, бид зүгээр л багасгаж, хэрэглэгчдэд өгдөг.
Энд байгаа кэшийн давхаргын CPU нь хадгалах сан бүрт эдгээр хэмжээг байнга шинэчилж байснаас хамаагүй хямд байх болно. Бид шинээр нэмэхийг хүсч байна гэж бодъё, үүнд нэг сарын хугацаа шаардагдах болно - кластерийг устгахгүйгээр энэ бүгдийг цэгцтэй хийх скриптийг хаа сайгүй ажиллуул. Тэдгээр. Хэрэв танд одоо сонгох боломж байгаа бол аль болох цөөн тооны физик хэмжээг хийх нь дээр, гэхдээ дор хаяж нэг хуваарилалт, жишээ нь, гурав байх болно. Мөн бусад бүх зүйлийг бэлэн модулиудын тусламжтайгаар шууд өөрчлөх боломжтой. Энэ бүхэн одоо маш хялбар бөгөөд хүртээмжтэй болсон.
Мөн өсөн нэмэгдэж буй асинхрон нөөц нь сайн.
Бидний туршлагаас харахад энэ схем нь өөрчлөгдсөн файлуудыг хойшлуулсан хуулбарлахад маш сайн ажилладаг.
Сүүлийн цэг нь бас ойлгомжтой. Дэд бүтцэд чинь одоо тийм асуудал гараагүй мөртлөө эвдрэх зүйл байгаа бол арай ахихаараа тасрах нь гарцаагүй. Тиймээс энэ талаар урьдчилан бодож, үүнтэй холбоотой асуудал гарахгүй байх нь дээр. Үүнийг л хэлэхийг хүссэн юм.
Холбоо барих
»
»
Энэхүү илтгэл нь өндөр ачаалалтай систем хөгжүүлэгчдийн бага хурал дээр хэлсэн шилдэг илтгэлүүдийн нэг юм . HighLoad++ 2017 чуулган болоход сар хүрэхгүй хугацаа үлдлээ.
Бид үүнийг аль хэдийн бэлэн болгосон , хуваарь одоо идэвхтэй бүрдэж байна.
Энэ жил бид архитектур, масштабын сэдвийг үргэлжлүүлэн судалж байна.
- / Игорь Васильев
- / Дмитрий Егоров
- / Анатолий Пласковский
- / Роман Шеховцов, Алексей Громатчиков
- / Филип Делгадо
Бид мөн эдгээр материалын заримыг өндөр ачаалалтай системийг хөгжүүлэх онлайн сургалтандаа ашигладаг тусгайлан сонгосон захидал, нийтлэл, материал, видео бичлэгийн сүлжээ юм. Манай сурах бичигт 30 гаруй өвөрмөц материалууд орсон байгаа. Холбогоорой!
Эх сурвалж: www.habr.com