Исторически се е случило така, че ИТ индустрията по всякакъв повод се разделя на два условни лагера: тези, които са „за“ и тези, които са „против“. Темата на споровете може да бъде абсолютно произволна. Коя операционна система е по-добра: Win или Linux? На смартфон Android или iOS? Да се съхраняват всичко в облака или да се качват на студени RAID хранилища и да се слагат дисковете в сейф? Имат ли право разработчиците на PHP да се наричат програмисти? Тези спорове носят, понякога, изцяло екзистенциален характер и нямат под себе си друга основа освен спортния интерес.
Случи се така, че с появата на контейнери и всичките тези любими на нас технологии с Docker и условния k8s започнаха споровете „за“ и „против“ използването на новите възможности в различни сфери на бекенда. (За достоверност ще уточним, че въпреки че най-често в този контекст се споменава Kubernetes като оркестратор, изборът на точно този инструмент не е от съществено значение. Вместо него може да се постави всеки друг, който смятате за най-удобен и познат.)
И, би изглеждало, че това е прост спор между две страни на един медал. Такъв също толкова безсмислен и безпощаден, колкото вечното противостоене Win срещу Linux, в който адекватни хора съществуват някъде по средата. Обаче в случая на контейнеризацията не всичко е толкова просто. Обикновено в такива спорове няма прави и грешни страни, но при въпроса дали да се „прилагат“ или „не прилагат“ контейнери за съхранение на БД всичко се обръща с главата надолу. Защото в определен смисъл и поддръжниците, и противниците на този подход са прави.
Светлата страна
Краткото описание на аргументацията на Светлата страна може да бъде сведено до една фраза: “Алло, 2к19 за прозореца!” Звучи като популизъм, безспорно, но ако се потопите в ситуацията по-дълбоко, ще видите, че има свои предимства. Точно тях ще разгледаме сега.
Да кажем, че имате голям уеб проект. Той може да е бил изграждан в началото на базата на микросервисен подход или да е стигнал до него еволюционно — всъщност, това не е толкова важно. Разделили сте проекта на отделни микросервизи, настроили сте оркестрация, натоварване, мащабиране. И сега с чиста съвест се наслаждавате на мохито в хамака по време на хабра-ефекта, вместо да вдигате падналите сървъри. Но във всяко действие трябва да бъдете последователни. Много често единствено самото приложение — кода — се контейнеризира. А какво имаме освен кода?
Правилно, данните. Сърцето на всеки проект — неговите данни: това може да бъде типичната СУБД — MySQL, Postgre, MongoDB, както и хранилища, използвани за търсене (ElasticSearch), key-value хранилища за кеширане — например, redis и т.н. Сега няма да говорим за кривите варианти на реализация на бекенда, когато БД пада заради лошо написани заявки, а вместо това ще обсъдим как да осигурим отказоустойчивост на самата БД под клиентското натоварване. Нали, когато контейнеризираме приложението си и му позволим да мащабира свободно, за да обработи всяко количество входящи заявки, това закономерно увеличава и натоварването на базата данни.
Всъщност, каналът за достъп до базата данни и сървърът, на който тя работи, стават ключов момент в нашия прекрасен контейнеризиран бекенд. Основната цел на контейнерната виртуализация — мобилност и гъвкавост на структурата, позволяваща да организираме разпределението на пикова натовареност по цялата налична инфраструктура максимално ефективно. Тоест, ако не контейнеризираме и не разпространим по кластера всички елементи на системата — допускаме много сериозна грешка.
Много по-логично е да клъстеризираме не само самото приложение, но и услугите, отговарящи за съхранение на данни. При клъстеризация и внедряване на независими и разпределящи натоварването помежду си уеб-сървъри в k8s вече решаваме проблема със синхронизацията на данните — например, коментарите под постовете, ако вземем за пример някоя медия или блог платформа. Във всеки случай създаваме вътре в клъстера, дори да е виртуално, представяне на БД като ExternalService. Въпросът е, че самата БД все още не е клъстеризирана — разположените в куба уеб-сървъри взимат информация за промените от нашата статична боевата база, която работи отделно.
Чувствате ли подводен камък? Използваме k8s или Swarm, за да разпределим натоварването и да избегнем срив на основния на уеб-сервера, но не правим това за БД. Но ако БД падне, то в цялата ни клъстеризирана инфраструктура няма смисъл — каква полза имаме от празни уеб страници, които показват грешка за достъп до базата данни?
Поради това клъстеризацията трябва да включва не само уеб-сървъри, както обикновено се прави, но и инфраструктурата на базата данни. Само по този начин можем да осигурим напълно функционална и независима структура в една система. Дори ако половината от нашия бекенд се „срине“ под натоварване — останалата част ще оцелее, а системата за синхронизация на БД в рамките на клъстера и възможността за безкрайно мащабиране и разгръщане на нови клъстери ще помогне бързо да достигнем необходимите мощности — стига да имаме сергии в дата центъра.
Освен това разпределената в клъстери модел на БД позволява да се пренесе самата БД до там, където е необходима; ако говорим за глобален сервиз, то би било доста нелогично да разгръщаме уеб-клъстера някъде в района на Сан-Франциско и в същото време да предаваме пакети до базата данни в Подмосковието и обратно.
Също така контейнеризацията на БД позволява изграждането на всички елементи на системата на едно ниво на абстракция. Това, от своя страна, прави възможно управлението на самата система директно от кода, от разработчиците, без активно ангажиране на администратори. На разработчиците им хрумна, че се нуждаят от отделна СУБД за нов подпроект — лесно! написаха yaml файл, заредиха в клъстера и готово.
Ами, разбира се, вътрешната експлоатация се опростява многократно. Кажете, колко пъти сте мигали в моментите, когато нов член на екипа се е опитвал да пробие в работната БД? Която всъщност е само една и в момента е активна? Разбира се, всички тук сме възрастни хора и някъде имаме свеж бекап, а още по-далеч — зад рафта с краставиците на баба и старите ски — има още един бекап, може би дори на студено хранилище, защото веднъж офисът ви вече горя. Но все пак, всяко въвеждане на нов член на екипа, който има достъп до продуктивната инфраструктура и, разбира се, до продуктивната база данни — е като ведро валидол за всички около вас. А кой знае, може ли новакът да е кривоследен? Страшно е, признайте.
Контейнеризацията и по същество разпределената физическа топология на БД-то на вашия проект помага да се избегнат подобни валидолни моменти. Не доверявате на новака? Окей! Ще му вдигнем собствен клъстер за работа и ще го откопчим от останалите клъстери на БД — синхронизация само по ръчно избутване и синхронно завъртане на два ключа (единият на тимлида, другият на администратора). И всички са щастливи.
А сега е време да се преобуем в противници на кластеризацията на БД.
Тъмната страна
Разсъждавайки защо не трябва да контейнеризираме базата данни и да продължаваме да я въртим на един централен сървър, няма да се спускаме до риториката на ортодоксите и твърдения от сорта на „дядовците въртяха БД на желязо, и ние ще правим същото!“ Вместо това да опитаме да измислим ситуация, в която контейнеризацията действително би донесла осезаеми дивиденти.
Съгласете се, проектите, на които реално им трябва база в контейнер, могат да се преброят на пръстите на една ръка на не най-добрия фрезерист. В повечето случаи, дори самото използване на k8s или Docker Swarm е излишно — често тези инструменти се използват заради общата хайповост на технологиите и установките на „всевишните“ в лицето на бенчмаркърите да натъкмят всичко в облаците и контейнерите. Ами, защото в момента е модерно и всички така правят.
Минимум в половината случаи използването на Kubernetes или просто Docker в проекта е излишно. Въпросът е, че не всички екипи или аутсорсинг компании, наети да обслужват инфраструктурата на клиента, осъзнават това. Още по-лошо — когато контейнерите се налагат, защото те струват на клиента определена сума пари.
Въобще, съществува мнение, че Docker/K8s мафията просто подчинява клиентите, които оставят тези инфраструктурни въпроси на аутсорс. Защото, за да работите с клъстери, са нужни инженери, които са способни да го правят и разбират архитектурата на внедреното решение. Вече описвахме нашия случай с изданието Republic — там обучихме екипа на клиента да работи в реалностите на Kubernetes и всички бяха доволни. И това беше съвсем приемливо. Често обаче „внедрителите“ на K8s взимат инфраструктурата на клиента за заложник — защото сега само те разбират как всичко работи, а на страна на клиента няма специалисти.
А сега си представете, че по такъв начин предаваме не само уебсървърната част на аутсорс, но също и обслужването на БД. Казахме, че БД е сърцето, а загубата на сърце е фатална за всяко живо същество. В общи линии, перспективите не са особено добри. Вместо хайп формат на Kubernetes, много проекти просто трябва да не пестят за нормален тарифен план на AWS, който да реши всички проблеми с натоварването на сайта/проекта им. Но AWS вече не е на мода, а показността е по-скъпа от парите — за съжаление, и в ИТ-средата също.
Окей. Възможно е кластеризацията на проекта наистина да е необходима, но ако с приложенията, без състояние, всичко е ясно, как тогава да организираме достойно осигуряване на мрежовата свързаност на кластеризираната база данни?
Ако говорим за безшевно инженерно решение, каквото представлява преминаването на k8s, нашата основна болка е репликацията на данни в кластеризирана база данни. Някои СУБД от самото начало доста лоялно се отнасят към разпределението на данни между своите отделни инстанции. Много други обаче не са толкова приветливи. Често основният аргумент при избора на СУБД за нашия проект не е способността на репликация с минимални ресурсни и инженерни разходи. Особено ако проектът първоначално не е бил планиран като микросервисен, а просто е еволюирал в тази посока.
Не мисля, че е нужно да говорим за скоростта на работа на мрежовите дискове — те са бавни. Т.е. реална възможност, в случай на нужда, да преместим инстанция на СУБД на място с повече, например, процесорна мощ или свободна оперативна памет, нямаме. Много бързо ще се сблъскаме с производителността на виртуализираната дискова подсистема. Съответно, СУБД трябва да бъде прикрепена към своя собствен набор от машини, които са в непосредствена близост. Или пък трябва да измислим начин за бърза синхронизация на данни с предполагаеми резерви.
Поверете на темата за виртуалните файлови системи: Docker Volumes, за съжаление, не са безпроблемни. В общи линии, в такава работа като дългосрочно надеждно съхранение на данни, е желателно да се използват максимално прости технически схеми. Добавянето на нов слой абстракция от файловата система на контейнера към файловата система на родителския хост — вече само по себе си е риск. Но когато в работата на системата за контейнеризация възникнат затруднения с транслацията на данни между тези слоеве, тогава положението е наистина лошо. В момента повечето известни проблеми, с които се сблъсква прогресивното човечество, изглежда са отстранени. Но сами разбирате, колкото по-сложен е механизмът, толкова по-лесно се счупва.
В светлината на всички тези "приключения" е много по-изгодно и по-лесно да се поддържа база данни на едно място. Ако ви е необходима контейнеризация на приложението, нека то да се изпълнява само по себе си, а чрез разпределителен шлюз да получава едновременно свързване с базата данни, която ще се чете и записва само веднъж и на едно място. Този подход намалява вероятността за грешки и несинхронизиране до минимални стойности.
Къде водим? Към това, че контейнеризацията на базата данни е уместна там, където има реална необходимост. Не може да налеете база на фулл-апп и да я изпълнявате така, все едно имате два десетки микросервиза — така не работи. И това трябва да се разбира ясно.
Вместо изхода
Ако очаквате ясен извод "да се виртуализира или не базата данни", то ще ви разочарова: такъв тук няма. Защото при създаването на всяко инфраструктурно решение повинно да се ръководите не от модата и прогреса, а в първостепенен ред от здравия разум.
Съществуват проекти, за които принципите и инструментите, водещи до Kubernetes, пасват идеално, и в такива проекти настъпва мир, поне в бекенд областта. А има проекти, на които не им трябва контейнеризация, а нормална сървърна инфраструктура, защото принципно не могат да се променят на микросервисна клъстерна модел, иначе ще паднат.
Източник: habr.com
