Како AWS ги подготвува своите еластични услуги. Скалирачки сервери и база на податоци

Облаците се како магична кутија - прашувате што ви треба, а ресурсите едноставно се појавуваат од никаде. Виртуелни машини, бази на податоци, мрежа - сето ова ви припаѓа само вам. Има и други станари на облак, но во вашиот Универзум вие сте единствениот владетел. Сигурни сте дека секогаш ќе ги добивате потребните ресурси, никого не земате предвид и самостојно одредувате каква ќе биде мрежата. Како функционира оваа магија што го тера облакот еластично да распределува ресурси и целосно да ги изолира станарите едни од други?

Облакот AWS е мега-супер комплексен систем кој еволутивно се развива од 2006 година. Дел од овој развој се случи Василиј Пантјухин - Архитект на веб-услуги на Амазон. Како архитект, тој добива внатрешен поглед не само на крајниот резултат, туку и на предизвиците што AWS ги надминува. Колку е поголемо разбирањето за тоа како функционира системот, толку е поголема довербата. Затоа, Василиј ќе ги сподели тајните на облак услугите AWS. Подолу е дизајнот на физичките AWS сервери, еластичната приспособливост на базите на податоци, прилагодената база на податоци на Amazon и методите за зголемување на перформансите на виртуелните машини додека истовремено се намалува нивната цена. Познавањето на архитектонските пристапи на Амазон ќе ви помогне поефективно да ги користите AWS услугите и може да ви даде нови идеи за градење сопствени решенија.

За говорникот: Василиј Пантјухин (Кокошка) започна како администратор на Unix во компаниите .ru, работеше на голем хардвер Sun Microsystem 6 години и проповедаше свет фокусиран на податоци во EMC 11 години. Природно еволуираше во приватни облаци, а во 2017 година се пресели во јавни. Сега тој дава технички совети за да помогне во живеењето и развојот во облакот AWS.

Одрекување: сè подолу е лично мислење на Василиј и може да не се совпаѓа со позицијата на веб-услугите на Амазон. Видео снимање Извештајот на кој се базира написот е достапен на нашиот канал на YouTube.

Зошто зборувам за уредот Амазон?

Мојот прв автомобил имаше рачен менувач. Беше одлично поради чувството дека можам да го возам болидот и да имам целосна контрола над него. Ми се допадна и тоа што барем приближно го разбрав принципот на неговото функционирање. Нормално, ја замислив структурата на кутијата како прилично примитивна - нешто како менувач на велосипед.

Сè беше супер, освен една работа - заглавена во сообраќајниот метеж. Се чини дека седите и не правите ништо, но постојано менувате брзини, притискате на куплунгот, гасот, сопирачката - тоа навистина ве заморува. Проблемот со сообраќајниот метеж беше делумно решен кога семејството доби автоматско возило. Додека возев, имав време да размислам за нешто и да слушам аудиокнига.

Во мојот живот се појави уште една мистерија, бидејќи целосно престанав да разбирам како работи мојот автомобил. Модерен автомобил е сложен уред. Автомобилот се прилагодува истовремено на десетици различни параметри: притискање на гас, сопирачка, стил на возење, квалитет на патот. Веќе не разбирам како функционира.

Кога почнав да работам на облакот Амазон, тоа исто така ми беше мистерија. Само оваа мистерија е ред на големина поголема, бидејќи има еден возач во автомобилот, а во AWS има милиони од нив. Сите корисници истовремено управуваат, притискаат гас и сопираат. Неверојатно е што одат каде сакаат - за мене е чудо! Системот автоматски се прилагодува, скалира и еластично се прилагодува на секој корисник така што му се чини дека е сам во овој универзум.

Магијата малку исчезна кога подоцна дојдов да работам како архитект во Амазон. Видов со какви проблеми се соочуваме, како ги решаваме и како развиваме услуги. Со зголеменото разбирање за тоа како функционира системот, се појавува поголема доверба во услугата. Затоа, сакам да споделам слика од она што е под капакот на облакот AWS.

За што да зборуваме

Избрав разновиден пристап - избрав 4 интересни услуги за кои вреди да се зборува.

Оптимизација на серверот. Ефемерни облаци со физичко отелотворување: физички центри за податоци каде што има физички сервери кои брмчат, загреваат и трепкаат со светла.

Функции без сервер (Lambda) е веројатно најскалабилната услуга во облакот.

Скалирање на базата на податоци. Ќе ви кажам за тоа како ги градиме нашите сопствени скалабилни бази на податоци.

Мрежно скалирање. Последниот дел во кој ќе го отворам уредот на нашата мрежа. Ова е прекрасна работа - секој корисник на облак верува дека е сам во облакот и воопшто не ги гледа другите станари.

Забелешка. Оваа статија ќе разговара за оптимизација на серверот и скалирање на базата на податоци. Ќе го разгледаме мрежното скалирање во следната статија. Каде се функциите без сервер? За нив беше објавен посебен транскрипт “Мал, но паметен. Микровиртуал за отпакување Firecracker" Зборува за неколку различни методи на скалирање и детално го разгледува решението Firecracker - симбиоза на најдобрите квалитети на виртуелна машина и контејнери.

Сервери

Облакот е ефемерен. Но, оваа минливост сè уште има физичко олицетворение - сервери. Првично, нивната архитектура беше класична. Стандарден x86 чипсет, мрежни картички, Linux, Xen хипервизор на кој се извршуваа виртуелните машини.

Во 2012 година, оваа архитектура доста добро се справи со своите задачи. Xen е одличен хипервизор, но има еден голем недостаток. Доста му е високи трошоци за емулација на уредот. Како што стануваат достапни нови, побрзи мрежни картички или SSD-дискови, овие трошоци стануваат превисоки. Како да се справите со овој проблем? Решивме да работиме на два фронта одеднаш - оптимизирајте ги и хардверот и хипервизорот. Задачата е многу сериозна.

Оптимизирање на хардвер и хипервизор

Да се ​​направи сè одеднаш и да се направи добро, нема да успее. Што е „добро“ исто така беше нејасно на почетокот.

Решивме да преземеме еволутивен пристап - менуваме еден важен елемент на архитектурата и го фрламе во производство.

Нагазиме на секое гребло, слушаме поплаки и предлози. Потоа менуваме друга компонента. Така, во мали чекори, радикално ја менуваме целата архитектура врз основа на повратни информации од корисниците и поддршката.

Трансформацијата започна во 2013 година со најкомплексното нешто - мрежата. ВО С3 на пример, специјална картичка за мрежен забрзувач беше додадена на стандардната мрежна картичка. Тој беше поврзан буквално со краток кабел за враќање на јамката на предниот панел. Не е убаво, но не се гледа во облакот. Но, директната интеракција со хардверот фундаментално го подобри нервозата и пропусната моќ на мрежата.

Следно, решивме да го подобриме пристапот до блокираното складирање податоци EBS - Elastic Block Storage. Тоа е комбинација од мрежа и складирање. Тешкотијата е што додека картичките на Network Accelerator постоеја на пазарот, немаше опција едноставно да се купи хардвер за Storage Accelerator. Така се свртевме кон стартап Лаборатории Анапурна, кој разви специјални ASIC чипови за нас. Тие дозволија далечинските томови на EBS да се монтираат како уреди NVMe.

Во примери C4 решивме два проблема. Првата е дека имплементиравме основа за иднината на ветувачката, но нова во тоа време, технологијата NVMe. Второ, значително го растоваривме централниот процесор со префрлање на обработката на барањата до EBS на нова картичка. Се покажа добро, па сега Annapurna Labs е дел од Amazon.

До ноември 2017 година, сфативме дека е време да го смениме самиот хипервизор.

Новиот хипервизор беше развиен врз основа на модифицирани модули на кернелот на KVM.

Тоа овозможи фундаментално да се намалат трошоците за емулација на уреди и да се работи директно со нови ASIC. Инстанци С5 беа првите виртуелни машини со нов хипервизор кој работи под хаубата. Го именувавме Нитро.

Еволуција на примери на временската линија.

Сите нови типови виртуелни машини што се појавија од ноември 2017 година работат на овој хипервизор. Случаите на Bare Metal немаат хипервизор, но тие се нарекуваат и Нитро, бидејќи користат специјализирани Нитро картички.

Во текот на следните две години, бројот на типови на примероци на Nitro надмина неколку десетици: A1, C5, M5, T3 и други.

Видови на примери.

Како работат модерните Нитро машини

Тие имаат три главни компоненти: Нитро хипервизор (дискутирано погоре), безбедносниот чип и Нитро картичките.

Безбедносен чип интегриран директно во матичната плоча. Контролира многу важни функции, како што е контролата на вчитувањето на оперативниот систем домаќин.

Нитро картички - Има четири типа од нив. Сите тие се развиени од Annapurna Labs и се базираат на вообичаени ASIC. Некои од нивните фирмвери се исто така вообичаени.

Четири типа нитро картички.

Една од картичките е дизајнирана да работи мрежаVPC. Ова е она што е видливо во виртуелните машини како мрежна картичка ENA - Еластичен мрежен адаптер. Исто така, го опфаќа сообраќајот кога го пренесува преку физичка мрежа (ќе зборуваме за ова во вториот дел од статијата), го контролира заштитен ѕид на безбедносните групи и е одговорен за рутирање и други мрежни работи.

Избраните картички работат со блок складирање EBS и дискови кои се вградени во серверот. Тие се појавуваат на гостинската виртуелна машина како NVMe адаптери. Тие се исто така одговорни за шифрирање на податоците и следење на дискот.

Системот на Nitro картички, хипервизор и безбедносен чип е интегриран во SDN мрежа или Софтвер дефинирана мрежа. Одговорен за управување со оваа мрежа (Контролен авион) контролна картичка.

Се разбира, продолжуваме да развиваме нови ASIC. На пример, на крајот на 2018 година го објавија чипот Inferentia, кој ви овозможува поефикасно да работите со задачите за машинско учење.

Чип за процесор за машинско учење Inferentia.

Скалабилна база на податоци

Традиционалната база на податоци има слоевит структура. За значително поедноставување, се разликуваат следните нивоа.

• SQL — на тоа работат диспечерите на клиентите и барањата.
• Одредби трансакции - овде се е јасно, КИСЕЛИНА и сето тоа.
• кеширање, што е обезбедено од тампон базени.
• Сеча — обезбедува работа со логови за повторување. Во MySQL тие се нарекуваат Bin Logs, во PosgreSQL - Write Ahead Logs (WAL).
• Складирање – директно снимање на диск.

Структура на повеќеслојна база на податоци.

Постојат различни начини за скалирање на базите на податоци: споделување, архитектура на споделено ништо, споделени дискови.

Сепак, сите овие методи ја одржуваат истата структура на монолитна база на податоци. Ова значително го ограничува скалирањето. За да го решиме овој проблем, развивме сопствена база на податоци − Амазон Аурора. Компатибилен е со MySQL и PostgreSQL.

Амазон Аурора

Главната архитектонска идеја е да се одделат нивоата на складирање и логирање од главната база на податоци.

Гледајќи напред, ќе кажам дека исто така го направивме независно нивото на кеширање. Архитектурата престанува да биде монолит и добиваме дополнителни степени на слобода при скалирање на поединечни блокови.

Нивоата на евиденција и складирање се одвоени од базата на податоци.

Традиционален DBMS запишува податоци во систем за складирање во форма на блокови. Во Amazon Aurora, создадовме паметна меморија што може да зборува јазик повторно логови. Внатре, складиштето ги претвора логовите во блокови на податоци, го следи нивниот интегритет и автоматски прави резервни копии.

Овој пристап ви овозможува да спроведете такви интересни работи како клонирање. Работи фундаментално побрзо и поекономично поради фактот што не бара создавање целосна копија од сите податоци.

Слојот за складирање е имплементиран како дистрибуиран систем. Се состои од многу голем број физички сервери. Секој дневник за повторување се обработува и се зачувува истовремено шест јазли. Ова обезбедува заштита на податоците и балансирање на оптоварување.

Скалирањето на читањето може да се постигне со користење на соодветни реплики. Дистрибуираното складирање ја елиминира потребата за синхронизација помеѓу примерот на главната база на податоци, преку кој пишуваме податоци, и преостанатите реплики. Ажурираните податоци гарантирано ќе бидат достапни за сите реплики.

Единствениот проблем е кеширањето на старите податоци на читаните реплики. Но, овој проблем се решава префрлање на сите логови за повторување на реплики преку внатрешната мрежа. Ако дневникот е во кешот, тој е означен како неточен и препишан. Ако не е во кешот, едноставно се отфрла.

Го средивме складирањето.

Како да ги зголемите нивоата на DBMS

Овде, хоризонталното скалирање е многу потешко. Па, ајде да тргнеме по претепаниот пат класично вертикално скалирање.

Да претпоставиме дека имаме апликација која комуницира со DBMS преку главен јазол.

При вертикално скалирање, доделуваме нов јазол кој ќе има повеќе процесори и меморија.

Следно, ја префрламе апликацијата од стариот главен јазол на новиот. Се појавуваат проблеми.

• Ова ќе бара значителен прекин на апликацијата.
• Новиот главен јазол ќе има ладен кеш. Перформансите на базата на податоци ќе бидат максимални само откако кешот ќе се загрее.

Како да се подобри ситуацијата? Поставете прокси помеѓу апликацијата и главниот јазол.

Што ќе ни даде ова? Сега сите апликации не треба рачно да се пренасочуваат кон новиот јазол. Прекинувачот може да се направи под прокси и е фундаментално побрз.

Се чини дека проблемот е решен. Но, не, ние сè уште страдаме од потребата да се загрее кешот. Покрај тоа, се појави нов проблем - сега проксито е потенцијална точка на неуспех.

Конечно решение со Amazon Aurora без сервер

Како ги решивме овие проблеми?

Остави полномошник. Ова не е посебен пример, туку цела дистрибуирана флота на прокси преку кои апликациите се поврзуваат со базата на податоци. Во случај на неуспех, кој било од јазлите може да се замени речиси веднаш.

Додаден е базен на топли јазли со различни големини. Затоа, доколку е потребно да се распредели нов јазол со поголема или помала големина, тој е веднаш достапен. Нема потреба да чекате да се вчита.

Целиот процес на скалирање се контролира со посебен систем за следење. Мониторингот постојано ја следи состојбата на тековниот главен јазол. Ако открие, на пример, дека оптоварувањето на процесорот достигна критична вредност, го известува збирот на топли инстанци за потребата да се распредели нов јазол.

Дистрибуирани прокси, топли инстанци и мониторинг.

Достапен е јазол со потребната моќност. На него се копираат тампон базени и системот почнува да чека безбеден момент за да се префрли.

Обично моментот за префрлување доаѓа доста брзо. Потоа, комуникацијата помеѓу посредникот и стариот главен јазол е суспендирана, сите сесии се префрлаат на новиот јазол.

Работа со базата на податоци продолжува.

Графиконот покажува дека суспензијата е навистина многу кратка. Синиот графикон го прикажува оптоварувањето, а црвените чекори ги прикажуваат моментите на скалирање. Краткорочните падови на синиот график се токму тоа кратко доцнење.

Патем, Amazon Aurora ви овозможува целосно да заштедите пари и да ја исклучите базата на податоци кога не е во употреба, на пример, за време на викендите. По запирање на товарот, DB постепено ја намалува својата моќност и се исклучува некое време. Кога ќе се врати товарот, повторно ќе се крене непречено.

Во следниот дел од приказната за уредот Амазон, ќе зборуваме за мрежното скалирање. Претплатете се пошта и останете во тек за да не ја пропуштите статијата.

На HighLoad ++ Василиј Пантјухин ќе даде извештај “Хјустон, имаме проблем. Дизајн на системи за неуспех, развојни модели за внатрешни облак услуги на Amazon" Кои шеми на дизајн за дистрибуирани системи ги користат програмерите на Амазон, кои се причините за неуспесите на услугите, што е архитектура базирана на мобилен, Constant Work, Shuffle Sharding - ќе биде интересно. Помалку од еден месец до конференцијата - резервирајте ги вашите билети. Конечно зголемување на цената на 24 октомври.

Извор: www.habr.com