AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау

Бұлттар сиқырлы қорапқа ұқсайды - сіз не қажет екенін сұрайсыз, ал ресурстар күтпеген жерден пайда болады. Виртуалды машиналар, дерекқорлар, желі - мұның бәрі сізге ғана тиесілі. Басқа бұлтты жалға берушілер бар, бірақ сіздің Әлеміңізде сіз жалғыз билеушісіз. Сіз әрқашан қажетті ресурстарды алатыныңызға сенімдісіз, сіз ешкімді есепке алмайсыз және желінің қандай болатынын өзіңіз анықтайсыз. Бұлт ресурстарды серпімді түрде бөлетін және жалға алушыларды бір-бірінен толығымен оқшаулайтын бұл сиқыр қалай жұмыс істейді?

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау

AWS бұлты - 2006 жылдан бері эволюциялық жолмен дамып келе жатқан мега-супер күрделі жүйе. Бұл дамудың бір бөлігі орын алды Василий Пантюхин - Amazon Web Services сәулетшісі. Сәулетші ретінде ол соңғы нәтижеге ғана емес, сонымен қатар AWS жеңетін қиындықтарға да ішкі көзқараспен қарайды. Жүйенің қалай жұмыс істейтінін түсіну неғұрлым көп болса, соғұрлым сенім артады. Сондықтан Василий AWS бұлттық қызметтерінің құпияларымен бөліседі. Төменде физикалық AWS серверлерінің дизайны, дерекқордың икемді масштабталуы, пайдаланушы Amazon дерекқоры және олардың бағасын бір уақытта төмендете отырып, виртуалды машиналар өнімділігін арттыру әдістері берілген. Amazon архитектуралық тәсілдерін білу AWS қызметтерін тиімдірек пайдалануға көмектеседі және өзіңіздің шешімдеріңізді құруға арналған жаңа идеяларды бере алады.

Баяндамашы туралы: Василий Пантюхин (Хен) .ru компанияларында Unix әкімшісі ретінде бастады, үлкен Sun Microsystem аппараттық құралында 6 жыл жұмыс істеді және 11 жыл бойы EMC-те деректерге негізделген әлемді уағыздады. Ол табиғи түрде жеке бұлттарға айналды, ал 2017 жылы жалпыға ортақ бұлттарға көшті. Енді ол AWS бұлтында өмір сүруге және дамытуға көмектесу үшін техникалық кеңес береді.

Жауапкершіліктен бас тарту: төмендегілердің барлығы Василийдің жеке пікірі және Amazon Web Services ұстанымымен сәйкес келмеуі мүмкін. Бейне жазу Мақала негізге алынған репортаж біздің YouTube арнамызда қолжетімді.

Неліктен мен Amazon құрылғысы туралы айтып отырмын?

Менің бірінші көлігім механикалық беріліс қорабы болды. Мен көлікті басқара аламын және оны толығымен басқара аламын деген сезім өте жақсы болды. Маған оның жұмыс істеу принципін кем дегенде шамамен түсінгенім ұнады. Әрине, мен қораптың құрылымын өте қарапайым деп елестеттім - велосипедтегі беріліс қорабы сияқты.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау

Барлығы тамаша болды, тек бір нәрседен басқа - кептелісте тұрып қалды. Сіз отырған сияқтысыз және ештеңе істемейсіз, бірақ сіз үнемі берілістерді ауыстырып, ілінісу, газ, тежегішті басып отырасыз - бұл сізді шынымен шаршатады. Отбасы автоматты көлікке ие болған соң кептеліс мәселесі жартылай шешілді. Көлік жүргізіп келе жатып, бірдеңе ойлап, аудиокітап тыңдауға уақыт таптым.

Менің өмірімде тағы бір жұмбақ пайда болды, өйткені мен көлігімнің қалай жұмыс істейтінін түсінуді мүлдем тоқтаттым. Заманауи автокөлік - күрделі құрылғы. Автокөлік бір уақытта ондаған түрлі параметрлерге бейімделеді: газды басу, тежеу, жүргізу стилі, жол сапасы. Мен енді оның қалай жұмыс істейтінін түсінбеймін.

Мен Amazon бұлтында жұмыс істей бастағанда, бұл мен үшін де жұмбақ болды. Тек осы жұмбақ үлкен мәнге ие, өйткені көлікте бір жүргізуші бар, ал AWS-де олардың миллиондағаны бар. Барлық пайдаланушылар бір уақытта рульді басқарады, газды басады және тежейді. Олардың қалаған жеріне баруы ғажап – бұл мен үшін керемет! Жүйе әрбір пайдаланушыға автоматты түрде бейімделеді, масштабтайды және серпімді түрде реттеледі, сонда ол осы Ғаламда жалғыз қалғандай көрінеді.

Мен кейінірек Amazon-да сәулетші болып жұмыс істеуге келгенімде, сиқыр аздап жойылды. Мен қандай мәселелерге тап болғанымызды, оларды қалай шешетінімізді және қызметтерді қалай дамытатынымызды көрдім. Жүйе қалай жұмыс істейтінін түсіну артқан сайын, қызметке деген сенімділік артады. Сондықтан мен AWS бұлтының астындағы нәрсенің суретін бөліскім келеді.

Не туралы сөйлесеміз

Мен әртараптандырылған тәсілді таңдадым - мен айтуға тұрарлық 4 қызықты қызметті таңдадым.

Серверді оңтайландыру. Физикалық көрінісі бар эфемерлік бұлттар: ызылдаған, қызатын және шамдармен жыпылықтайтын физикалық серверлер бар физикалық деректер орталықтары.

Серверсіз функциялар (Lambda) бұлттағы ең ауқымды қызмет болуы мүмкін.

Мәліметтер базасын масштабтау. Мен өзіміздің масштабталатын дерекқорларымызды қалай жасайтынымыз туралы айтып беремін.

Желіні масштабтау. Мен желіміздің құрылғысын ашатын соңғы бөлім. Бұл керемет нәрсе - бұлттың әрбір пайдаланушысы бұлтта жалғыз екеніне сенеді және басқа жалға алушыларды мүлде көрмейді.

Ескерту. Бұл мақалада серверді оңтайландыру және дерекқорды масштабтау талқыланады. Желіні масштабтауды келесі мақалада қарастырамыз. Серверсіз функциялар қайда? Олар туралы жеке стенограмма жарияланды «Кішкентай, бірақ ақылды. Firecracker микровиртуалды қорабын ашу" Ол бірнеше масштабтау әдістері туралы айтады және Firecracker шешімін егжей-тегжейлі талқылайды - виртуалды машина мен контейнерлердің ең жақсы қасиеттерінің симбиозы.

Серверлер

Бұлт эфемерлі. Бірақ бұл эфемералдылықтың әлі де физикалық көрінісі бар - серверлер. Бастапқыда олардың архитектурасы классикалық болды. Стандартты x86 чипсет, желілік карталар, Linux, виртуалды машиналар іске қосылған Xen гипервизоры.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау

2012 жылы бұл архитектура өз міндеттерін өте жақсы орындады. Xen - керемет гипервизор, бірақ оның бір маңызды кемшілігі бар. Оған жетеді құрылғыны эмуляциялауға арналған жоғары шығындар. Жаңа, жылдамырақ желі карталары немесе SSD дискілері қолжетімді болған сайын, бұл үстеме шығын тым жоғары болады. Бұл мәселемен қалай күресуге болады? Біз бірден екі майданда жұмыс істеуді шештік - аппараттық құралды да, гипервизорды да оңтайландыру. Тапсырма өте ауыр.

Аппараттық құралдар мен гипервизорды оңтайландыру

Барлығын бірден жасап, оны жақсы орындау нәтиже бермейді. Бастапқыда «жақсы» дегеннің не екені белгісіз еді.

Біз эволюциялық тәсілді қабылдауды шештік – біз сәулеттің бір маңызды элементін өзгертіп, оны өндіріске енгіземіз.

Біз әр рейканы басып, шағымдар мен ұсыныстарды тыңдаймыз. Содан кейін біз басқа компонентті өзгертеміз. Осылайша, шағын қадамдармен біз пайдаланушылардың пікірлері мен қолдауына негізделген бүкіл архитектураны түбегейлі өзгертеміз.

Трансформация 2013 жылы ең күрделі нәрсе – желіден басталды. IN СХNUMX жағдайларда стандартты желі картасына арнайы Network Accelerator картасы қосылды. Ол алдыңғы панельдегі қысқа кері кабель арқылы тікелей қосылды. Бұл әдемі емес, бірақ бұлтта көрінбейді. Бірақ аппараттық құралдармен тікелей әрекеттесу діріл мен желі өткізу қабілетін түбегейлі жақсартты.

Әрі қарай біз EBS деректерін блоктау мүмкіндігін жақсартуды шештік - Elastic Block Storage. Бұл желі мен сақтаудың қосындысы. Қиындық мынада: Network Accelerator карталары нарықта болған кезде, жай ғана Storage Accelerator аппараттық құралдарын сатып алу мүмкіндігі болмады. Сондықтан біз стартапқа бет бұрдық Аннапурна зертханалары, біз үшін арнайы ASIC чиптерін жасаған. Олар қашықтағы EBS көлемдерін NVMe құрылғылары ретінде орнатуға мүмкіндік берді.

Жағдайларда C4 екі мәселені шештік. Біріншісі, біз болашағы зор, бірақ сол кездегі жаңа NVMe технологиясының негізін енгіздік. Екіншіден, біз EBS-ке сұраныстарды өңдеуді жаңа картаға көшіру арқылы орталық процессорды айтарлықтай түсірдік. Бұл жақсы болды, сондықтан қазір Annapurna Labs Amazon құрамына кіреді.

2017 жылдың қарашасына қарай біз гипервизордың өзін өзгерту уақыты келгенін түсіндік.

Жаңа гипервизор модификацияланған KVM ядросының модульдері негізінде әзірленді.

Бұл құрылғы эмуляциясының үстеме шығындарын түбегейлі азайтуға және жаңа ASIC-пен тікелей жұмыс істеуге мүмкіндік берді. Даналар СХNUMX қалпақ астында жұмыс істейтін жаңа гипервизоры бар алғашқы виртуалды машиналар болды. Біз оның атын қойдық нитро.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтауУақыт шкаласында даналардың эволюциясы.

2017 жылдың қарашасынан бастап пайда болған виртуалды машиналардың барлық жаңа түрлері осы гипервизорда жұмыс істейді. Жалаң металл даналарында гипервизор жоқ, бірақ олар Nitro деп те аталады, өйткені олар арнайы Nitro карталарын пайдаланады.

Келесі екі жылда Nitro даналарының түрлерінің саны бірнеше ондаған асты: A1, C5, M5, T3 және т.б.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау
Дана түрлері.

Қазіргі Nitro машиналары қалай жұмыс істейді

Олардың үш негізгі құрамдас бөлігі бар: Nitro гипервизоры (жоғарыда талқыланды), қауіпсіздік чипі және Nitro карталары.

Қауіпсіздік чипі тікелей аналық платаға біріктірілген. Ол негізгі операциялық жүйенің жүктелуін басқару сияқты көптеген маңызды функцияларды басқарады.

Нитро карталары – Олардың төрт түрі бар. Олардың барлығын Annapurna Labs әзірлеген және жалпы ASIC негізінде жасалған. Олардың кейбір микробағдарламалары да кең таралған.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау
Nitro карталарының төрт түрі.

Карточкалардың бірі жұмыс істеуге арналған желіVPC. Бұл виртуалды машиналарда желілік карта ретінде көрінетін нәрсе ENA - серпімді желі адаптері. Ол сондай-ақ оны физикалық желі арқылы жіберу кезінде трафикті инкапсуляциялайды (бұл туралы мақаланың екінші бөлігінде айтатын боламыз), Қауіпсіздік топтары брандмауэрін басқарады және маршруттау және басқа желілік заттарға жауап береді.

Таңдалған карталар блоктық сақтаумен жұмыс істейді EBS және серверге орнатылған дискілер. Олар қонаққа виртуалды машина ретінде көрінеді NVMe адаптерлері. Сондай-ақ олар деректерді шифрлау және дискіні бақылау үшін жауап береді.

Nitro карталарының жүйесі, гипервизор және қауіпсіздік чипі SDN желісіне біріктірілген немесе Бағдарламалық құрал анықталған желі. Осы желіні басқаруға жауапты (басқару жоспары) контроллер картасы.

Әрине, біз жаңа ASIC әзірлеуді жалғастырамыз. Мысалы, 2018 жылдың соңында олар машиналық оқыту тапсырмаларымен тиімдірек жұмыс істеуге мүмкіндік беретін Inferentia чипін шығарды.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау
Inferentia Machine Learning процессорының чипі.

Масштабталатын деректер қоры

Дәстүрлі деректер базасы деңгейлі құрылымға ие. Үлкен жеңілдету үшін келесі деңгейлер бөлінеді.

  • SQL — онда клиент пен сұраныс диспетчерлері жұмыс істейді.
  • Ережелер транзакциялар - мұнда бәрі түсінікті, ACID және бәрі.
  • кэштеу, ол буферлік пулдармен қамтамасыз етіледі.
  • Тіркеу — қайталау журналдарымен жұмысты қамтамасыз етеді. MySQL-де олар Bin Logs деп аталады, PosgreSQL-де - Write Ahead Logs (WAL).
  • Сақтау – дискіге тікелей жазу.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау
Мәліметтер базасының деңгейлі құрылымы.

Дерекқорларды масштабтаудың әртүрлі жолдары бар: бөлу, Shared Nothing архитектурасы, ортақ дискілер.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау

Дегенмен, бұл әдістердің барлығы бірдей монолитті дерекқор құрылымын сақтайды. Бұл масштабтауды айтарлықтай шектейді. Бұл мәселені шешу үшін біз өзіміздің мәліметтер базасын әзірледік - Amazon Aurora. Ол MySQL және PostgreSQL-пен үйлесімді.

Amazon Aurora

Негізгі архитектуралық идея - сақтау және тіркеу деңгейлерін негізгі деректер базасынан бөлу.

Болашаққа қарап, мен кэштеу деңгейін де тәуелсіз еттік деп айтамын. Архитектура монолит болуды тоқтатады және біз жеке блоктарды масштабтауда қосымша еркіндік дәрежесіне ие боламыз.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау
Тіркеу және сақтау деңгейлері дерекқордан бөлек.

Дәстүрлі ДҚБЖ деректерді сақтау жүйесіне блоктар түрінде жазады. Amazon Aurora-да біз тілде сөйлей алатын смарт жад жасадық қайталау журналдары. Ішінде жад журналдарды деректер блоктарына айналдырады, олардың тұтастығын бақылайды және автоматты түрде сақтық көшірме жасайды.

Бұл тәсіл осындай қызықты нәрселерді жүзеге асыруға мүмкіндік береді клондау. Ол барлық деректердің толық көшірмесін жасауды қажет етпейтіндіктен, түбегейлі жылдамырақ және үнемді жұмыс істейді.

Сақтау қабаты бөлінген жүйе ретінде жүзеге асырылады. Ол физикалық серверлердің өте үлкен санынан тұрады. Әрбір қайталау журналы бір уақытта өңделеді және сақталады алты түйін. Бұл деректерді қорғауды және жүктемені теңестіруді қамтамасыз етеді.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау

Оқу масштабына сәйкес көшірмелерді пайдалану арқылы қол жеткізуге болады. Бөлінген жад деректерді жазатын негізгі дерекқор данасы мен қалған көшірмелер арасындағы синхрондау қажеттілігін жояды. Жаңартылған деректер барлық көшірмелер үшін қолжетімді болатынына кепілдік беріледі.

Жалғыз мәселе - оқылған көшірмелердегі ескі деректерді кэштеу. Бірақ бұл мәселе шешілуде барлық қайталау журналдарын тасымалдау ішкі желі арқылы көшірмелерге. Журнал кэште болса, ол қате деп белгіленеді және қайта жазылады. Егер ол кэште болмаса, ол жай ғана жойылады.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау

Біз қойманы реттедік.

ДҚБЖ деңгейлерін қалай масштабтауға болады

Мұнда көлденең масштабтау әлдеқайда қиын. Ендеше, соқпақпен жүрейік классикалық тік масштабтау.

Бізде ДҚБЖ-мен негізгі түйін арқылы байланысатын қолданба бар деп есептейік.

Тігінен масштабтау кезінде біз процессорлар мен жады көбірек болатын жаңа түйінді бөлеміз.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау

Әрі қарай, біз қолданбаны ескі негізгі түйіннен жаңасына ауыстырамыз. Мәселелер туындайды.

  • Бұл қолданбаның айтарлықтай тоқтап қалуын талап етеді.
  • Жаңа негізгі түйінде суық кэш болады. Дерекқор өнімділігі тек кэш жылытылғаннан кейін ғана максималды болады.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау

Жағдайды қалай жақсартуға болады? Бағдарлама мен негізгі түйін арасында прокси орнатыңыз.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау

Бұл бізге не береді? Енді барлық қолданбаларды жаңа түйінге қолмен қайта бағыттаудың қажеті жоқ. Ауыстыруды прокси арқылы жасауға болады және негізінен жылдамырақ.

Мәселе шешілген сияқты. Бірақ жоқ, біз әлі де кэшті жылыту қажеттілігінен зардап шегеміз. Сонымен қатар, жаңа мәселе пайда болды - енді прокси ықтимал сәтсіздік нүктесі болып табылады.

Amazon Aurora серверсіз соңғы шешім

Біз бұл мәселелерді қалай шештік?

Прокси қалдырды. Бұл жеке дана емес, қолданбалар дерекқорға қосылатын прокси-серверлердің тұтас таратылған флоты. Сәтсіздік жағдайында түйіндердің кез келгенін бірден ауыстыруға болады.

Әртүрлі өлшемдегі жылы түйіндер пулы қосылды. Сондықтан, үлкенірек немесе кішірек өлшемдегі жаңа түйінді бөлу қажет болса, ол дереу қол жетімді. Оның жүктелуін күтудің қажеті жоқ.

Барлық масштабтау процесі арнайы бақылау жүйесімен бақыланады. Мониторинг ағымдағы негізгі түйіннің күйін үнемі бақылайды. Егер ол, мысалы, процессор жүктемесінің сыни мәнге жеткенін анықтаса, ол жаңа түйінді бөлу қажеттілігі туралы жылы даналардың пулын хабарлайды.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау
Таратылған проксилер, жылы инстанциялар және мониторинг.

Қажетті қуаты бар түйін бар. Оған буферлік пулдар көшіріледі және жүйе ауысу үшін қауіпсіз сәтті күте бастайды.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау

Әдетте ауысу сәті өте тез келеді. Содан кейін прокси мен ескі негізгі түйін арасындағы байланыс тоқтатылады, барлық сеанстар жаңа түйінге ауысады.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау

Мәліметтер қорымен жұмыс түйіндемесі.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау

График суспензияның өте қысқа екенін көрсетеді. Көк график жүктемені, ал қызыл қадамдар масштабтау сәттерін көрсетеді. Көк графиктегі қысқа мерзімді құлдыраулар дәл осы қысқа кешігу болып табылады.

AWS серпімді қызметтерін қалай дайындайды. Серверлер мен мәліметтер базасын масштабтау

Айтпақшы, Amazon Aurora ақшаны толығымен үнемдеуге және дерекқорды пайдаланбаған кезде, мысалы, демалыс күндерінде өшіруге мүмкіндік береді. Жүктемені тоқтатқаннан кейін МБ бірте-бірте қуатын азайтады және біраз уақытқа өшеді. Жүктеме қайтып келгенде, ол қайтадан біркелкі көтеріледі.

Amazon құрылғысы туралы әңгіменің келесі бөлімінде біз желіні масштабтау туралы айтатын боламыз. Жазылу пошта және мақаланы жіберіп алмау үшін хабардар болыңыз.

туралы Жоғары жүктеме++ Василий Пантюхин баяндама жасайды »Хьюстон, бізде проблема бар. Сәтсіздікке арналған жүйелерді жобалау, ішкі Amazon бұлттық қызметтерін әзірлеу үлгілері" Amazon әзірлеушілері таратылған жүйелер үшін қандай дизайн үлгілерін пайдаланады, қызмет ақауларының себептері қандай, ұяшыққа негізделген архитектура, тұрақты жұмыс, Shuffle Sharding деген не - бұл қызықты болады. Конференцияға бір айдан аз уақыт қалды - билеттеріңізді брондаңыз. 24 қазанда бағаның түпкілікті өсуі.

Ақпарат көзі: www.habr.com

пікір қалдыру