Аблокі падобныя да магічнай шкатулкі - задаеш, што табе трэба, і рэсурсы проста з'яўляюцца з ніадкуль. Віртуальныя машыны, базы дадзеных, сетка - усё гэта належыць толькі табе. Існуюць і іншыя тэнанты аблокі, але ў сваім Сусвеце ты аднаасобны кіраўнік. Ты ўпэўнены, што заўсёды атрымаеш патрэбныя рэсурсы, ні з кім не лічышся і самастойна вызначаеш, якой будзе сетка. Як уладкованая гэтая магія, якая прымушае воблака эластычна вылучаць рэсурсы і цалкам ізаляваць тэнанты сябар ад сябра?
Воблака AWS гэта мегасуперскладаная сістэма, якая эвалюцыйна развіваецца з 2006 года. Частка гэтага развіцця заспела Васіль Панцюхін - архітэктар Amazon Web Services. Як архітэктар ён бачыць знутры не толькі канчатковы вынік, але і складанасці, якія пераадольвае AWS. Чым больш разумення працы сістэмы, тым больш даверы. Таму Васіль падзеліцца сакрэтамі хмарных сэрвісаў AWS. Пад катам прылада фізічных сервераў AWS, эластычная маштабаванасць БД, кастамная база дадзеных Amazon і метады падвышэння прадукцыйнасці віртуальных машын з адначасовым памяншэннем іх кошту. Веданне архітэктурных падыходаў Amazon дапаможа больш эфектыўна выкарыстоўваць сэрвісы AWS і, магчыма, дасць новыя ідэі па пабудове ўласных рашэнняў.
Аб спікеры: Васіль Панцюхін () пачынаў Unix-адмінам в.ru-кампаніях, 6 гадоў займаўся вялікімі жалязякі Sun Microsystem, 11 гадоў прапаведаваў дата-цэнтрычнасць свету ў EMC. Натуральным шляхам эвалюцыянаваў у прыватныя аблокі, а ў 2017 падаўся ў публічныя. Цяпер тэхнічнымі парадамі дапамагае жыць і развівацца ў воблаку AWS.
Дысклеймер: усё, што ніжэй - гэта асабістае меркаванне Васіля, і яно можа не супадаць з пазіцыяй Amazon Web Services. даклада, на аснове якога створаны артыкул, даступна на нашым YouTube-канале.
Чаму я расказваю пра прыладу Amazon
Мая першая машына была з ручкай на механічнай КПП. Гэта было выдатна з-за адчування, што я магу кіраваць машынай і поўнасцю кантраляваць яе. Яшчэ мне падабалася, што я хаця б прыкладна разумею прынцып яе працы. Натуральна, я ўяўляў прыладу скрынкі досыць прымітыўна прыкладна як скрынку перадач на ровары.
Усё было выдатна, акрамя аднаго - стаянні ў корках. Накшталт сядзіш і нічога не робіш, але ўвесь час перамыкаеш перадачы, націскаеш на счапленне, газ, тормаз - ад гэтага рэальна стамляешся. Праблема пробак часткова вырашылася, калі ў сям'і з'явілася машына на аўтамаце. За рулём з'явіўся час аб нечым падумаць, паслухаць аўдыёкніжку.
Яшчэ ў маім жыцці з'явілася загадка, таму што я ўвогуле перастаў разумець, як працуе мая машына. Сучасны аўтамабіль - гэта складанае прылада. Машына адаптуецца адначасова да дзясяткаў розных параметраў: націск на газ, тормаз, стыль кіравання, якасць дарогі. Я ўжо не разумею, як гэта працуе.
Калі я пачаў займацца воблакам Amazon, для мяне гэта таксама было таямніцай. Толькі гэтая таямніца на парадак вышэйшая, таму што ў машыне адзін кіроўца, а ў AWS іх мільёны. Усе карыстачы адначасова руляць, націскаюць на газ і тормаз. Дзіўна, што яны едуць туды, куды хочуць - для мяне гэты цуд! Сістэма аўтаматычна адаптуецца, маштабуецца і эластычна падладжваецца пад кожнага карыстальніка так, што яму здаецца, што ён адзін у гэтым Сусвеце.
Магія крыху развеялася, калі пазней я прыйшоў працаваць архітэктарам у Amazon. Я ўбачыў, з якімі праблемамі мы сутыкаемся, як іх вырашаем, як развіваем сервісы. З ростам разумення працы сістэмы з'яўляецца больш даверы да сэрвісу. Таму я хачу падзяліцца карцінай таго, што пад капотам у аблокі AWS.
Пра што пагаворым
Я абраў дыверсіфікаваны падыход - адабраў 4 цікавых сэрвісу, пра якія варта пагаварыць.
Аптымізацыя сервераў. Эфемерныя аблокі з фізічным увасабленнем: фізічныя дата-цэнтры, дзе стаяць фізічныя серверы, якія гудуць, грэюцца і міргаюць лямпачкамі.
Серверлес-функцыі (Lambda) - мусіць, самы які маштабуецца сэрвіс у воблаку.
Маштабаванне базы дадзеных. Раскажу аб тым, як мы будуем свае ўласныя якія маштабуюцца БД.
Маштабаванне сеткі. Апошняя частка, у якой адкрыю прыладу нашай сеткі. Гэта цудоўная рэч - кожны карыстач аблокі лічыць, што ён у воблаку адзін і наогул не бачыць іншых тэнантаў.
Заўвага. У гэтым артыкуле гаворка пойдзе аб аптымізацыі сервераў і маштабаванні БД. Маштабаванне сеткі разгледзім у наступным артыкуле. Дзе ж серверлес-функцыі? Пра іх выйшла асобная расшыфроўка». У ёй расказана аб некалькіх розных спосабах маштабавання, і падрабязна разабрана рашэнне Firecracker – сімбіёз лепшых якасцяў віртуальнай машыны і кантэйнераў.
серверы
Воблака эфемерна. Але ў гэтай эфемернасці ўсё ж ёсць фізічнае ўвасабленне - серверы. Першапачаткова іх архітэктура была класічнай. Стандартны x86 чыпсэт, сеткавыя карты, Linux, гіпервізор Xen, на якім запускаліся віртуальныя машыны.
У 2012 годзе такая архітэктура цалкам спраўлялася са сваімі задачамі. Xen - выдатны гіпервізор, але з адным сур'ёзным недахопам. У яго дастаткова высокія накладныя выдаткі на эмуляцыю прылад. Пры з'яўленні новых хутчэйшых сеткавых карт або дыскаў SSD гэтыя накладныя выдаткі становяцца занадта высокімі. Як жа зладзіцца з гэтай праблемай? Вырашылі працаваць адразу на двух франтах. аптымізаваць і жалеза, і гіпервізор. Задача вельмі сур'ёзная.
Аптымізацыя жалеза і гіпервізара
Зрабіць усё адразу і добра не атрымаецца. Што такое "добра", першапачаткова таксама было незразумела.
Вырашылі ўжыць эвалюцыйны падыход – мяняем адзін важны элемент архітэктуры і кідаем яго ў прадакшн.
Надыходзім на ўсе граблі, выслухоўваем скаргі і прапановы. Потым змяняем іншую кампаненту. Так, невялікімі інкрыментамі, кардынальна мяняем усю архітэктуру на аснове зваротнай сувязі ад карыстальнікаў і падтрымкі.
Пераўтварэнні пачаліся ў 2013 г. з самага складанага - сеткі. У С3 інстансах да стандартнай сеткавай карце дадалі адмысловую карту Network Accelerator. Яна падключалася літаральна кароткім loopback кабелем на пярэдняй панэлі. Няпрыгожа, але ў воблаку не відаць. Затое прамое ўзаемадзеянне з жалезам прынцыпова палепшыла jitter і прапускную здольнасць сеткі.
Далей вырашылі заняцца паляпшэннем доступу да блокавага захоўвання дадзеных EBS – Elastic Block Storage. Гэта камбінацыя сеткі і сховішчы. Складанасць у тым, што калі на рынку існавалі карты Network Accelerator, то магчымасці проста набыць жалеза Storage Accelerator не было. Таму мы звярнуліся да стартапа Annapurna Labs, Які распрацаваў для нас спецыяльныя чыпы ASIC. Яны дазволілі падлучаць выдаленыя тамы EBS як прылады NVMe.
У інстансах C4 мы вырашылі дзве задачы. Першая – рэалізавалі задзел на будучыню перспектыўнай, але новай на той момант, тэхналогіі NVMe. Другая - значна разгрузілі цэнтральны працэсар пераносам апрацоўкі запытаў да EBS на новую карту. Атрымалася ўдала, таму цяпер Annapurna Labs - частка Amazon.
Да лістапада 2017 г. мы зразумелі, што прыйшоў час мяняць і сам гіпервізор.
Новы гіпервізор распрацавалі на аснове дапрацаваных модуляў ядра KVM.
Ён дазволіў прынцыпова паменшыць накладныя выдаткі на эмуляцыю прылад і працаваць напроста з новымі ASIC. Інстансы С5 былі першымі віртуалкамі, пад капотам якіх працуе новы гіпервізор. Мы назвалі яго Nitro.
Эвалюцыя інстансаў на часовай шкале.
Усе новыя тыпы віртуальных машын, якія з'явіліся з лістапада 2017 года, працуюць на гэтым гіпервізоры. У жалезных Bare Metal інстансаў няма гіпервізара, Але іх таксама называюць Nitro, бо яны выкарыстоўваюць спецыялізаваныя Nitro-карты.
За наступныя два гады колькасць тыпаў Nitro-інстансаў перавысіла пару дзясяткаў: A1, C5, M5, T3 і іншыя.
Тыпы інстансаў.
Як уладкованыя сучасныя Nitro-машыны
У іх ёсць тры асноўных кампанента: Nitro-гіпервізар (пра яго казалі вышэй), чып бяспекі і Nitro-карты.
Чып бяспекі інтэграваны прама ў матчыну плату. Ён кантралюе мноства важных функцый, напрыклад, кантроль загрузкі хаставой АС.
Nitro-карты - Іх існуе чатыры тыпу. Усе яны распрацаваны Annapurna Labs і грунтуюцца на агульных ASIC. Частка іх прашыўкі таксама агульная.
Чатыры тыпу Nitro-карт.
Адна з карт прызначана для працы з сеткайVPC. Менавіта яна бачная ў віртуалка як сеткавая карта ENA – Elastic Network Adaptor. Таксама яна інкапсулюе трафік пры перадачы яго праз фізічную сетку (пра гэта пагаворым у другой частцы артыкула), кантралюе файрвол Security Groups, адказвае за маршрутызацыю і іншыя сеткавыя рэчы.
Асобныя карты працуюць з блокавым захоўваннем EBS і дыскамі, якія ўбудаваны ў сервер. Гасцявы віртуалцы яны прадстаўляюцца як NVMe-адаптары. Таксама яны адказваюць за шыфраванне даных і маніторынг дыскаў.
Сістэма Nitro-карт, гіпервізара і чыпа бяспекі аб'яднана ў сетку SDN або Праграмна вызначаная сетка. За кіраванне гэтай сеткай (Control Plane) адказвае карта-кантролер.
Вядома, мы працягваем распрацоўку новых ASIC. Напрыклад, у канцы 2018 г. выпусцілі чып Inferentia, які дазваляе больш эфектыўна працаваць з задачамі машыннага навучання.
Чып Inferentia Machine Learning Processor.
Маштабуемая база дадзеных
Традыцыйная база дадзеных мае слаістай структуру. Калі моцна спрасціць, то выдзяляюцца наступныя ўзроўні.
- SQL - На ім працуюць дыспетчары кліентаў і запытаў.
- Забеспячэнні транзакцый - тут усё зразумела, ACID і ўсё такое.
- кэшаванне, якое забяспечваецца буфернымі пуламі.
- Лагіраванне - забяспечвае працу з redo-логамі. У MySQL яны называюцца Bin Logs, у PosgreSQL – Write Ahead Logs (WAL).
- захоўванне - непасрэдна запіс на дыск.
Слаістая структура базы даных.
Існуюць розныя спосабы маштабавання баз дадзеных: шардаванне, архітэктура Shared Nothing, падзяляныя дыскі.
Аднак усе гэтыя метады захоўваюць тую ж самую маналітную структуру базы дадзеных. Гэта прыкметна абмяжоўвае маштабаванне. Каб вырашыць гэтую праблему, мы распрацавалі сваю ўласную БД - Амазонка Аўрора. Яна сумяшчальная з MySQL і PostgreSQL.
Амазонка Аўрора
Асноўная архітэктурная ідэя - адшчапіць узроўні захоўвання і лагіравання ад асноўнай БД.
Забягаючы наперад скажу, што ўзровень кэшавання мы таксама зрабілі незалежным. Архітэктура перастае быць маналітам, і мы атрымліваем дадатковыя ступені свабоды ў маштабаванні асобных блокаў.
Узроўні лагіравання і захоўвання аддзелены ад базы дадзеных.
Традыцыйная СКБД запісвае дадзеныя на сістэму захоўвання ў выглядзе блокаў. У Amazon Aurora мы стварылі "разумнае" сховішча, якое можа размаўляць на мове redo-логаў. Усярэдзіне сябе сховішча ператварае логі ў блокі дадзеных, сочыць за іх цэласнасцю і аўтаматычна бэкапіт.
Гэты падыход дазваляе рэалізаваць такія цікавыя рэчы як кланаванне. Яно працуе прынцыпова хутчэй і эканамічней за кошт таго, што не патрабуе стварэння поўнай копіі ўсіх дадзеных.
Узровень захоўвання рэалізаваны ў выглядзе размеркаванай сістэмы. Яна складаецца з вельмі вялікай колькасці фізічных сервераў. Кожны redo-лог апрацоўваецца і захоўваецца адначасова шасцю вузламі. Гэта забяспечвае абарону даных і размеркаванне нагрузкі.
Маштабаванне на чытанне можна забяспечыць пры дапамозе адпаведных рэплік. Размеркаванае сховішча ўхіляе неабходнасць сінхранізацыі паміж галоўным інстансам БД, праз які мы запісваем дадзеныя, і астатнімі рэплікамі. Актуальныя дадзеныя гарантавана даступныя ўсім рэплікам.
Адзіная праблема - кэшаванне старых дадзеных на рэпліках чытання. Але гэтая задача вырашаецца перадачай усіх redo-логаў на рэплікі па ўнутранай сетцы. Калі лог у кэшы, то ён пазначаецца як некарэктны і перазапісваецца. Калі ў кэшы яго няма, то ён проста адкідаецца.
Са сховішчам разабраліся.
Як маштабаваць узроўні СКБД
Тут гарызантальнае маштабаванне зрабіць значна складаней. Таму пойдзем пракладзенай дарожкай класічнага вертыкальнага маштабавання.
Выкажам здагадку, што ў нас ёсць дадатак, якое мае зносіны з СКБД праз майстар-ноду.
Пры вертыкальным маштабаванні вылучаем новую ноду, у якой будзе больш працэсараў і памяці.
Далей перамыкаем дадатак са старой майстар-ноды на новую. Узнікаюць праблемы.
- Гэта запатрабуе прыкметнага даунтайма прыкладання.
- У новай майстар-ноды будзе халодны кэш. Прадукцыйнасць БД будзе максімальная толькі пасля прагрэву кэша.
Як палепшыць сітуацыю? Паставіць проксі паміж дадаткам і майстар-нодай.
Што нам гэта дасць? Цяпер усе прыкладанні не трэба ўручную перанакіроўваць на новую ноду. Пераключэнне можна зрабіць пад проксі і пры гэтым прынцыпова хутчэй.
Падаецца, што праблема вырашаная. Але не, мы ўсё яшчэ пакутуем ад неабходнасці выгравання кэша. Да таго ж, з'явілася новая праблема - зараз проксі гэта патэнцыйны пункт адмовы.
Выніковае рашэнне з Amazon Aurora serverless
Як мы вырашылі гэтыя праблемы?
Пакінулі проксі. Гэта не нейкі асобны інстанс, а цэлы размеркаваны флот проксі, праз які прыкладанні падлучаюцца да БД. Любую з нод у выпадку выхаду са строю можна замяніць практычна імгненна.
Дадалі пул цёплых нод рознага памеру. Таму пры неабходнасці вылучэння новай ноды большага ці меншага памеру яна адразу даступная. Ня трэба чакаць, калі яна загрузіцца.
Увесь працэс маштабавання кантралюецца спецыяльнай сістэмай маніторынгу. Маніторынг увесь час сочыць за станам бягучай майстар-ноды. Калі ён выяўляе, напрыклад, што нагрузка на працэсар дасягнула крытычнай велічыні, тое паведамляе пул цёплых інстансаў аб неабходнасці вылучэння новай ноды.
Размеркаваныя проксі, цёплыя інстансы і маніторынг.
Нода патрабаванай магутнасці даступная. На яе капіююцца буферныя пулы, і сістэма пачынае чакаць бяспечнага моманту для пераключэння.
Звычайна момант для пераключэння надыходзіць дастаткова хутка. Тады камунікацыя паміж проксі і старой майстар-нодай прыпыняецца, усе сесіі пераключаюцца на новую наду.
Праца з базай дадзеных аднаўляецца.
На графіцы відаць, што прыпыненне сапраўды вельмі кароткае. На сінім графіку нагрузка, а на чырвоных прыступках - моманты маштабавання. Кароткачасовыя правалы ў сінім графіку якраз і ёсць тая самая кароткая затрымка.
Дарэчы, Amazon Aurora дазваляе зусім зэканоміць і выключыць БД, калі яна не выкарыстоўваецца, напрыклад, на выходных. Пасля спынення нагрузкі БД паступова памяншае сваю магутнасць і на нейкі час адключаецца. Калі нагрузка вернецца, яна зноў плаўна паднімецца.
У наступнай частцы аповяду аб прыладзе Amazon пагаворым аб маштабаванні сеткі. Падпісвайцеся і сочыце за абнаўленнямі, каб не прапусціць артыкул.
На Васіль Панцюхін выступіць з дакладам «». Якія патэрны праектавання размеркаваных сістэм выкарыстоўваюць распрацоўшчыкі Amazon, якія бываюць прычыны адмоў сэрвісаў, што такое Cell-based architecture, Constant Work, Shuffle Sharding – будзе цікава. Да канферэнцыі менш за месяц — . 24 кастрычніка канчатковае павышэнне коштаў.
Крыніца: habr.com