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