Үүл бол шидэт хайрцаг шиг - та юу хэрэгтэйг асууж, нөөцүүд нь гэнэт гарч ирдэг. Виртуал машин, мэдээллийн сан, сүлжээ - энэ бүхэн зөвхөн танд хамаарна. Бусад үүл түрээслэгчид байдаг, гэхдээ таны Орчлонд та цорын ганц захирагч юм. Та шаардлагатай нөөцийг үргэлж хүлээн авах болно гэдэгт итгэлтэй байна, та хэнийг ч анхааралдаа авахгүй бөгөөд сүлжээ ямар байхыг бие даан тодорхойлдог. Үүл нь нөөцийг уян хатан байдлаар хуваарилж, түрээслэгчдийг бие биенээсээ бүрэн тусгаарладаг энэ ид шид хэрхэн ажилладаг вэ?
AWS үүл нь 2006 оноос хойш хувьслын замаар хөгжиж ирсэн мега супер цогц систем юм. Энэ хөгжлийн нэг хэсэг болсон Василий Пантюхин - Amazon Web Services Architect. Архитекторын хувьд тэрээр зөвхөн эцсийн үр дүнг төдийгүй AWS-ийн даван туулж буй сорилтуудыг дотроос нь харж чаддаг. Систем хэрхэн ажилладаг талаар ойлголт их байх тусам итгэл нэмэгдэнэ. Тиймээс Василий AWS үүлэн үйлчилгээний нууцыг хуваалцах болно. Физик AWS серверүүдийн дизайн, уян хатан мэдээллийн сангийн өргөтгөл, Amazon-ын захиалгат мэдээллийн сан, виртуал машинуудын гүйцэтгэлийг нэмэгдүүлэхийн зэрэгцээ үнийг нь бууруулах аргуудыг доор харуулав. Амазоны архитектурын арга барилын талаархи мэдлэг нь AWS үйлчилгээг илүү үр дүнтэй ашиглахад тусалж, өөрийн шийдлийг бий болгох шинэ санааг өгөх болно.
Илтгэгчийн тухай: Василий Пантюхин () .ru компаниудад Unix админаар ажиллаж эхэлсэн бөгөөд Sun Microsystem-ийн томоохон техник хангамж дээр 6 жил ажиллаж, EMC-д 11 жилийн турш өгөгдөл төвтэй ертөнцийг номлосон. Энэ нь байгалиасаа хувийн үүл болж хувирч, 2017 онд нийтийн үүл рүү шилжсэн. Одоо тэрээр AWS үүлэнд амьдрах, хөгжүүлэхэд туслах техникийн зөвлөгөө өгдөг.
Анхааруулга: доорх бүх зүйл бол Василийгийн хувийн бодол бөгөөд Amazon Web Services-ийн байр суурьтай давхцахгүй байж магадгүй юм. Нийтлэлд үндэслэсэн сурвалжлагыг манай YouTube сувагт үзэх боломжтой.
Би яагаад Amazon төхөөрөмжийн тухай ярьж байна вэ?
Миний анхны машин механик хурдны хайрцагтай байсан. Би машинаа жолоодож, түүнийг бүрэн удирдаж чадна гэсэн мэдрэмжтэй байсан учраас үнэхээр сайхан байсан. Наад зах нь түүний үйл ажиллагааны зарчмыг бараг ойлгосон нь надад таалагдсан. Мэдээжийн хэрэг, би хайрцгийн бүтэц нь унадаг дугуйн хурдны хайрцаг шиг энгийн зүйл гэж төсөөлж байсан.
Замын түгжрэлд гацсан ганц зүйлээс бусад бүх зүйл сайхан байсан. Та суугаад юу ч хийхгүй байгаа юм шиг санагдаж байна, гэхдээ та араагаа байнга сольж, шүүрч авах, бензин, тоормос дарах нь таныг үнэхээр ядраадаг. Айл автомат машинтай болсноор замын түгжрэл хэсэгчлэн шийдэгдсэн. Жолоо барьж байхдаа ямар нэг зүйлийн талаар бодож, аудио ном сонсох завтай байсан.
Миний амьдралд өөр нэг нууц гарч ирэв, учир нь би машин хэрхэн ажилладагийг бүрэн ойлгохоо больсон. Орчин үеийн машин бол нарийн төвөгтэй төхөөрөмж юм. Машин нь олон арван янз бүрийн параметрүүдэд нэгэн зэрэг дасан зохицдог: хийн дарах, тоормос, жолоодлогын хэв маяг, замын чанар. Энэ нь яаж ажилладагийг би ойлгохгүй байна.
Би Амазон үүл дээр ажиллаж эхлэхэд энэ нь бас миний хувьд нууцлаг байсан. Зөвхөн энэ нууц нь илүү том захиалга юм, учир нь машинд нэг жолооч байдаг бөгөөд AWS-д сая сая байдаг. Бүх хэрэглэгчид нэгэн зэрэг жолоодож, хий, тоормосыг дарна. Тэд хүссэн газраа очдог нь гайхалтай - энэ бол миний хувьд гайхамшиг юм! Систем нь хэрэглэгч бүрд автоматаар дасан зохицож, хэмжиж, уян хатан байдлаар тохируулдаг бөгөөд ингэснээр тэр хүн энэ ертөнцөд ганцаараа байгаа юм шиг санагддаг.
Дараа нь намайг Amazon-д архитектороор ажиллахаар ирэхэд ид шид бага зэрэг арилсан. Бидэнд ямар асуудал тулгардаг, тэдгээрийг хэрхэн шийдэж, үйлчилгээгээ хэрхэн хөгжүүлж байгааг харлаа. Систем хэрхэн ажилладаг талаар илүү их ойлголттой болох тусам үйлчилгээнд итгэх итгэл нэмэгддэг. Тиймээс би AWS үүлний бүрээсний доор байгаа зургийг хуваалцахыг хүсч байна.
Бид юу ярих вэ
Би төрөлжсөн аргыг сонгосон - Би ярихад үнэ цэнэтэй 4 сонирхолтой үйлчилгээг сонгосон.
Серверийн оновчлол. Физик дүрслэл бүхий түр зуурын үүл: дуугарч, халж, гэрлээр анивчдаг физик серверүүд байдаг физик мэдээллийн төвүүд.
Сервергүй функцууд (Lambda) нь үүлэн дэх хамгийн өргөтгөх боломжтой үйлчилгээ юм.
Өгөгдлийн сангийн масштаб. Бид өөрсдийн өргөтгөх боломжтой мэдээллийн санг хэрхэн бий болгодог талаар би танд хэлэх болно.
Сүлжээний масштаб. Миний сүлжээний төхөөрөмжийг нээх сүүлчийн хэсэг. Энэ бол гайхалтай зүйл - үүлэн хэрэглэгч бүр үүлэн дотор ганцаараа байгаа гэдэгт итгэдэг бөгөөд бусад түрээслэгчдийг огт хардаггүй.
Анхаарна уу. Энэ нийтлэлд серверийн оновчлол болон мэдээллийн сангийн масштабын талаар хэлэлцэх болно. Бид дараагийн өгүүллээр сүлжээний масштабыг авч үзэх болно. Сервергүй функцүүд хаана байна? Тэдний тухай тусдаа хуулбар хэвлэгдсэн "" Энэ нь хэд хэдэн янз бүрийн масштабын аргуудын талаар ярьж, Firecracker шийдлийг нарийвчлан авч үздэг - виртуал машин ба савны хамгийн сайн чанаруудын симбиоз.
Серверүүд
Үүл нь түр зуурынх. Гэхдээ энэ түр зуурын байдал нь серверүүд гэсэн биет биелэлтэй хэвээр байна. Эхэндээ тэдний архитектур сонгодог байв. Стандарт x86 чипсет, сүлжээний карт, Линукс, виртуал машинууд дээр ажилладаг Xen гипервизор.
2012 онд энэ архитектур нь даалгавраа нэлээд сайн даван туулсан. Xen бол гайхалтай гипервизор боловч нэг том сул талтай. Түүнд хангалттай төхөөрөмжийн эмуляцийн өндөр зардал. Шинэ, илүү хурдан сүлжээний картууд эсвэл SSD хөтчүүд гарах тусам энэ нэмэлт зардал хэт өндөр болно. Энэ асуудлыг хэрхэн шийдвэрлэх вэ? Бид нэгэн зэрэг хоёр фронт дээр ажиллахаар шийдсэн - техник хангамж болон гипервизорыг хоёуланг нь оновчтой болгох. Даалгавар нь маш ноцтой юм.
Техник хангамж болон гипервизорыг оновчтой болгох
Бүгдийг нэг дор хийгээд сайн хийх нь бүтэхгүй. "Сайн" гэж юу вэ гэдэг нь эхэндээ тодорхойгүй байсан.
Бид хувьслын арга барилаар шийдсэн - бид архитектурын нэг чухал элементийг өөрчилж, үйлдвэрлэлд оруулав.
Бид тармуур болгон дээр гишгэж, гомдол, саналыг сонсдог. Дараа нь бид өөр бүрэлдэхүүн хэсгийг өөрчилнө. Тиймээс бид хэрэглэгчдийн санал хүсэлт, дэмжлэг дээр үндэслэн архитектурыг бүхэлд нь бага багаар эрс өөрчилдөг.
Өөрчлөлт нь 2013 онд хамгийн төвөгтэй зүйл болох сүлжээнээс эхэлсэн. IN С3 Жишээ нь, тусгай сүлжээний хурдасгуур картыг стандарт сүлжээний картанд нэмсэн. Энэ нь урд талын самбар дээрх богино холболтын кабелиар шууд утгаараа холбогдсон. Энэ нь хөөрхөн биш ч үүлэнд харагдахгүй байна. Гэхдээ техник хангамжтай шууд харьцах нь чичиргээ болон сүлжээний дамжуулах чадварыг үндсээр нь сайжруулсан.
Дараа нь бид EBS - Elastic Block Storage мэдээллийн санг блоклох хандалтыг сайжруулахаар шийдсэн. Энэ нь сүлжээ болон хадгалалтын хослол юм. Хэцүү тал нь Network Accelerator картууд зах зээл дээр байсан ч зүгээр л Storage Accelerator техник хангамж худалдаж авах боломж байгаагүй. Тиймээс бид стартап руу хандсан Аннапурна лаборатори, хэн бидэнд зориулж тусгай ASIC чип боловсруулсан. Тэд алсын зайн EBS хэмжээг NVMe төхөөрөмж болгон холбохыг зөвшөөрсөн.
Тохиолдолд C4 Бид хоёр асуудлыг шийдсэн. Эхнийх нь бид ирээдүйтэй, гэхдээ тэр үед шинэ NVMe технологийн ирээдүйн суурийг хэрэгжүүлсэн явдал юм. Хоёрдугаарт, бид EBS-ийн хүсэлтийн боловсруулалтыг шинэ карт руу шилжүүлснээр төв процессорыг ихээхэн буулгасан. Энэ нь сайн болсон тул одоо Annapurna Labs нь Амазоны нэг хэсэг болжээ.
2017 оны XNUMX-р сар гэхэд бид гипервизорыг өөрөө өөрчлөх цаг болсныг ойлгосон.
Шинэ гипервизорыг өөрчилсөн KVM цөмийн модулиуд дээр үндэслэн боловсруулсан.
Энэ нь төхөөрөмжийн эмуляцийн нэмэлт зардлыг үндсээр нь бууруулж, шинэ ASIC-тай шууд ажиллах боломжтой болсон. Тохиолдлууд С5 нь шинэ гипервизортой анхны виртуал машинууд байсан. Бид түүнийг нэрлэсэн Nitro.
Хугацаа дээрх тохиолдлуудын хувьсал.
2017 оны XNUMX-р сараас хойш гарч ирсэн бүх шинэ төрлийн виртуал машинууд энэ гипервизор дээр ажилладаг. Нүцгэн металлын жишээнүүдэд гипервизор байдаггүй, гэхдээ тусгай Nitro карт ашигладаг тул тэдгээрийг Nitro гэж нэрлэдэг.
Дараагийн хоёр жилийн хугацаанд Nitro инстанцийн төрлүүдийн тоо хэд хэдэн арваас давсан: A1, C5, M5, T3 болон бусад.
Инстанцийн төрлүүд.
Орчин үеийн Nitro машинууд хэрхэн ажилладаг
Эдгээр нь гурван үндсэн бүрэлдэхүүн хэсэгтэй: Nitro hypervisor (дээр дурдсан), хамгаалалтын чип, Nitro картууд.
Хамгаалалтын чип эх хавтанд шууд холбогдсон. Энэ нь хост үйлдлийн системийн ачааллыг хянах зэрэг олон чухал функцийг хянадаг.
Нитро картууд -Тэдгээрийн дөрвөн төрөл байдаг. Эдгээрийг бүгдийг нь Annapurna Labs боловсруулсан бөгөөд нийтлэг ASIC дээр суурилдаг. Тэдний зарим програм хангамж нь бас түгээмэл байдаг.
Дөрвөн төрлийн Nitro картууд.
Картуудын нэг нь ажиллахад зориулагдсан сүлжээVPC. Энэ нь виртуал машинд сүлжээний карт хэлбэрээр харагддаг ENA - уян хатан сүлжээний адаптер. Энэ нь мөн физик сүлжээгээр дамжуулж байх үед траффикийг багтаасан (бид энэ тухай өгүүллийн хоёрдугаар хэсэгт ярих болно), Аюулгүй байдлын бүлгийн галт ханыг удирдаж, чиглүүлэлт болон бусад сүлжээг хариуцдаг.
Сонгосон картууд нь блок санах ойтой ажилладаг EBS болон серверт суулгасан дискүүд. Тэд зочдод виртуал машин шиг харагддаг NVMe адаптерууд. Тэд мөн өгөгдлийг шифрлэх, дискний хяналтыг хариуцдаг.
Nitro картын систем, гипервизор, хамгаалалтын чип нь SDN сүлжээнд нэгдсэн эсвэл Програм хангамжаар тодорхойлсон сүлжээ. Энэ сүлжээг удирдах үүрэгтэй (Хяналтын онгоц) хянагч карт.
Мэдээжийн хэрэг, бид шинэ ASIC-уудыг үргэлжлүүлэн хөгжүүлсээр байна. Жишээлбэл, 2018 оны сүүлээр тэд Inferentia чипийг гаргасан бөгөөд энэ нь машин сургалтын даалгавруудтай илүү үр дүнтэй ажиллах боломжийг олгодог.
Inferentia машин сургалтын процессорын чип.
Өргөтгөх боломжтой мэдээллийн сан
Уламжлалт мэдээллийн сан нь давхаргат бүтэцтэй байдаг. Маш хялбарчлахын тулд дараах түвшнийг ялгаж үздэг.
- SQL — Үйлчлүүлэгч болон хүсэлтийн диспетчерүүд үүн дээр ажилладаг.
- заалтууд гүйлгээ - энд бүх зүйл тодорхой байна, ACID болон бусад.
- кэш хийх, үүнийг буфер усан сангуудаар хангадаг.
- Мод бэлтгэх — дахин хийх бүртгэлтэй ажиллах боломжийг олгодог. MySQL-д тэдгээрийг Bin Logs, PosgreSQL-д - Write Ahead Logs (WAL) гэж нэрлэдэг.
- Хадгалалт - диск рүү шууд бичлэг хийх.
Өгөгдлийн сангийн давхаргат бүтэц.
Мэдээллийн санг масштаблах янз бүрийн арга байдаг: sharding, Shared Nothing архитектур, хуваалцсан диск.
Гэсэн хэдий ч эдгээр бүх аргууд нь нэг цул мэдээллийн сангийн бүтцийг хадгалдаг. Энэ нь масштабыг мэдэгдэхүйц хязгаарладаг. Энэ асуудлыг шийдэхийн тулд бид өөрсдийн мэдээллийн санг боловсруулсан - Амазон Аврора. Энэ нь MySQL болон PostgreSQL-тэй нийцдэг.
Амазон Аврора
Архитектурын гол санаа нь үндсэн мэдээллийн сангаас хадгалах, бүртгэлийн түвшинг тусгаарлах явдал юм.
Цаашид бид кэшийн түвшинг бие даасан болгосон гэж би хэлэх болно. Архитектур нь цул байхаа больж, бид тусдаа блокуудыг масштаблахдаа нэмэлт эрх чөлөөг олж авдаг.
Бүртгэл болон хадгалалтын түвшин нь мэдээллийн сангаас тусдаа байдаг.
Уламжлалт DBMS нь өгөгдлийг хадгалах системд блок хэлбэрээр бичдэг. Амазон Аврора дээр бид хэлээр ярьдаг ухаалаг хадгалах санг бий болгосон redo-logs. Дотор нь хадгалах сан нь бүртгэлийг өгөгдлийн блок болгон хувиргаж, тэдгээрийн бүрэн бүтэн байдлыг хянаж, автоматаар нөөцлөнө.
Энэ арга нь танд сонирхолтой зүйлсийг хэрэгжүүлэх боломжийг олгодог клончлох. Энэ нь бүх өгөгдлийн бүрэн хуулбарыг үүсгэх шаардлагагүй тул үндсэндээ илүү хурдан бөгөөд илүү хэмнэлттэй ажилладаг.
Хадгалах давхарга нь тархсан систем хэлбэрээр хэрэгждэг. Энэ нь маш олон тооны физик серверүүдээс бүрддэг. Дахин хийх бүртгэл бүрийг нэгэн зэрэг боловсруулж хадгалдаг зургаан зангилаа. Энэ нь өгөгдлийг хамгаалах, ачааллыг тэнцвэржүүлэх боломжийг олгодог.
Унших масштабыг тохирох хуулбарыг ашиглан хийж болно. Түгээмэл санах ой нь бидний өгөгдөл бичих үндсэн мэдээллийн сан болон үлдсэн хуулбаруудын хооронд синхрончлол хийх шаардлагагүй болно. Хамгийн сүүлийн үеийн өгөгдөл нь бүх хуулбарт бэлэн байх баталгаатай.
Ганц асуудал бол уншсан хуулбар дээр хуучин өгөгдлийг кэш хийх явдал юм. Гэхдээ энэ асуудал шийдэгдэж байна бүх дахин хийх бүртгэлийг шилжүүлэх дотоод сүлжээгээр хуулбарлах. Хэрэв бүртгэл нь кэшэд байгаа бол түүнийг буруу гэж тэмдэглэж, дарж бичсэн байна. Хэрэв энэ нь кэшэд байхгүй бол үүнийг зүгээр л устгана.
Бид хадгалах санг цэгцэлсэн.
DBMS давхаргыг хэрхэн томруулах вэ
Энд хэвтээ масштаблах нь илүү хэцүү байдаг. Тиймээс зодуулсан замаар явцгаая сонгодог босоо масштаб.
Бидэнд DBMS-тэй мастер зангилаагаар холбогддог програм байгаа гэж бодъё.
Босоо масштабтай байх үед бид илүү олон процессор, санах ойтой байх шинэ зангилаа хуваарилдаг.
Дараа нь бид програмыг хуучин мастер зангилаанаас шинэ рүү шилжүүлнэ. Асуудал үүсдэг.
- Энэ нь аппликешны ихээхэн сул зогсолтыг шаардах болно.
- Шинэ мастер зангилаа нь хүйтэн кэштэй байх болно. Өгөгдлийн сангийн гүйцэтгэл нь кэшийг халаасны дараа л хамгийн их байх болно.
Нөхцөл байдлыг хэрхэн сайжруулах вэ? Програм болон мастер зангилааны хооронд прокси тохируулна уу.
Энэ нь бидэнд юу өгөх вэ? Одоо бүх програмуудыг гараар шинэ зангилаа руу дахин чиглүүлэх шаардлагагүй. Шилжүүлэгчийг прокси дор хийх боломжтой бөгөөд үндсэндээ илүү хурдан байдаг.
Асуудал шийдэгдсэн бололтой. Гэхдээ үгүй, бид кэшийг дулаацуулах шаардлагаас болж зовж шаналж байна. Үүнээс гадна шинэ асуудал гарч ирэв - одоо прокси нь бүтэлгүйтлийн боломжит цэг юм.
Amazon Aurora сервергүй эцсийн шийдэл
Бид эдгээр асуудлыг хэрхэн шийдсэн бэ?
Прокси үлдээсэн. Энэ бол тусдаа жишээ биш, харин программууд мэдээллийн санд холбогддог проксигийн бүхэл бүтэн тархсан флот юм. Алдаа гарсан тохиолдолд аль ч зангилааг бараг тэр даруй сольж болно.
Төрөл бүрийн хэмжээтэй дулаан зангилааны санг нэмсэн. Тиймээс, хэрэв том эсвэл жижиг хэмжээтэй шинэ зангилаа хуваарилах шаардлагатай бол тэр даруй бэлэн болно. Үүнийг ачаалахыг хүлээх шаардлагагүй.
Бүхэл бүтэн масштабын процессыг тусгай хяналтын системээр хянадаг. Хяналт нь одоогийн мастер зангилааны төлөвийг байнга хянаж байдаг. Хэрэв энэ нь жишээлбэл, процессорын ачаалал эгзэгтэй утгад хүрсэн бол шинэ зангилаа хуваарилах шаардлагатай байгаа талаар дулааны санд мэдэгдэнэ.
Түгээмэл прокси, дулаан тохиолдлууд болон мониторинг.
Шаардлагатай хүч чадал бүхий зангилаа байдаг. Буферийн сангууд түүн рүү хуулж, систем шилжихийн тулд аюулгүй мөчийг хүлээж эхэлдэг.
Ихэвчлэн солих мөч маш хурдан ирдэг. Дараа нь прокси болон хуучин мастер зангилааны хоорондох холбоог түр зогсоож, бүх сешнүүдийг шинэ зангилаа руу шилжүүлнэ.
Өгөгдлийн сангийн анкеттай ажиллах.
Графикаас харахад түдгэлзүүлэлт үнэхээр богино байна. Цэнхэр график нь ачааллыг, улаан алхмууд нь масштаблах мөчүүдийг харуулдаг. Цэнхэр график дахь богино хугацааны уналт нь яг ийм богино хугацааны саатал юм.
Дашрамд хэлэхэд, Amazon Aurora танд мөнгөө бүрэн хэмнэж, мэдээллийн санг ашиглаагүй үед, жишээлбэл, амралтын өдрүүдээр унтраах боломжийг олгодог. Ачаалал зогссоны дараа DB нь хүчийг аажмаар бууруулж, хэсэг хугацаанд унтардаг. Ачаалал буцаж ирэхэд дахин жигд өсөх болно.
Амазоны төхөөрөмжийн тухай түүхийн дараагийн хэсэгт бид сүлжээний масштабын талаар ярих болно. Бүртгүүлэх Мөн нийтлэлийг алдахгүйн тулд бидэнтэй хамт байгаарай.
дээр Василий Пантюхин илтгэл тавина "" Амазоны хөгжүүлэгчид тархсан системийн дизайны ямар загваруудыг ашигладаг вэ, үйлчилгээний доголдлын шалтгаан юу вэ, Cell-based архитектур гэж юу вэ, Тогтмол ажил, Shuffle Sharding - энэ нь сонирхолтой байх болно. Чуулган болоход сар хүрэхгүй хугацаа үлдлээ. . Аравдугаар сарын 24-ний эцсийн үнийн өсөлт.
Эх сурвалж: www.habr.com