Неяк так гістарычна склалася, што IT-індустрыя з любой нагоды разбіваецца на два ўмоўныя лагеры: якія «за» і якія «супраць». Прычым прадмет спрэчак можа быць абсалютна адвольным. Якая АС лепш: Win ці Linux? На смартфоне Android ці iOS? Захоўваць усе ў аблоках або заліваць на халодныя RAID-сховішчы і класці шрубы ў сейф? Ці маюць PHP-шнікі права звацца праграмістамі? Гэтыя спрэчкі носяць, часам, выключна экзістэнцыйны характар і не маюць пад сабой ніякай іншай, акрамя спартовай цікавасці, базы.
Так ужо атрымалася, што са з'яўленнем кантэйнераў і ўсёй гэтай каханай намі кухні з докерам і ўмоўным k8s пачаліся і спрэчкі "за" і "супраць" выкарыстанні новых магчымасцяў у розных сферах бэкэнда. (Загадзя абмовімся, што хоць часцей за ўсё ў дадзеным разважанні ў якасці аркестратара будзе паказвацца Kubernetes, прынцыповага значэння выбар менавіта гэтай прылады не мае. Замест яго можна падставіць любы іншы, які вам здаецца найболей зручным і звыклым.)
І, здавалася б, была б гэта простая спрэчка паміж двума бакамі аднаго медаля. Такі ж бессэнсоўны і бязлітасны, як адвечнае супрацьстаянне Win vs Linux, у якім адэкватныя людзі суцэль сабе існуюць дзесьці пасярэдзіне. Вось толькі ў выпадку кантэйнерызацыі не ўсё так проста. Звычайна ў такіх спрэчках не бывае правага боку, але ў выпадку "ужываць" ці "не ўжываць" кантэйнеры для захоўвання БД усё становіцца з ног на галаву. Таму што ў пэўным сэнсе маюць рацыю і прыхільнікі і супернікі падобнага падыходу.
Светлы Бок
Коратка апісаць аргументацыю Светлага Боку можна адной фразай: "Алё, 2к19 за акном!" Гучыць як папулізм, безумоўна, але калі ўнікаць у сітуацыю дэталёва, тамака ёсць свае плюсы. Іх зараз і разбярэм.
Выкажам здагадку, у вас ёсць буйны вэб-праект. Ён мог першапачаткова будавацца на аснове мікрасэрвіснага падыходу, альбо ж у нейкі момант прыйшоў да яго эвалюцыйным шляхам – гэта не вельмі важна, насамрэч. Вы раскідалі наш праект па асобных мікрасэрвісах, настроілі аркестрацыю, балансаванне нагрузкі, маштабаванне. І зараз з чыстым сумленнем папіваеце мохіта ў гамаку падчас хабра-эфектаў замест таго, каб паднімаць упаўшыя сервера. Але ва ўсіх дзеяньнях трэба быць пасьлядоўным. Вельмі часта кантэйнерызуецца толькі непасрэдна само дадатак - код. А што яшчэ ў нас ёсць апроч кода?
Правільна, дадзеныя. Сэрца любога праекта – яго дадзеныя: гэта можа быць як тыповая СКБД – MySQL, Postgre, MongoDB, так і сховішчы, якія выкарыстоўваюцца для пошуку (ElasticSearch), key-value сховішчы для кэшавання – напрыклад, redis, і т. д. Цяпер мы не будзем казаць аб крывых варыянтах рэалізацыі бэкэнда, калі БД падае з-за дрэнна напісаных запытаў, а замест гэтага пагаворым аб забеспячэнні адмоваўстойлівасці гэтай самай БД пад кліенцкай нагрузкай. Бо калі мы кантэйнерызуем наша дадатак і дазваляем яму свабодна маштабавацца для апрацоўкі любога колькасць уваходных запытаў, гэта заканамерна павялічвае і нагрузку на базу дадзеных.
Фактычна, канал звароту да базы дадзеных і сервер, на якім яна круціцца, становяцца іголкавым вушкам у нашым выдатным кантэйнерызаваным бэкэндзе. Пры гэтым асноўны матыў кантэйнернай віртуалізацыі - рухомасць і пластычнасць структуры, якія дазваляюць арганізаваць размеркаванне пікавай нагрузкі па ўсёй даступнай нам інфраструктуры максімальна эфектыўна. Гэта значыць, калі мы не кантэйнерызуем і не раскочваем па кластары ўсе наяўныя элементы сістэмы - мы дапускаем вельмі сур'ёзную памылку.
Нашмат лагічней кластарызаваць не толькі само прыкладанне, але і сэрвісы, якія адказваюць за захоўванне дадзеных. Пры кластарызацыі і разгортванні незалежна якія працуюць і размяркоўвалых паміж сабой нагрузку вэб-сервераў у k8s мы ўжо вырашаем праблему сінхранізацыі дадзеных - тых жа каментароў да пастоў, калі прыводзіць у прыклад нейкі СМІ або блогаплатформу. У нас у любым выпадку заводзіцца ўнутрыкластарнае, хай нават віртуальнае, паданне БД як ExternalService. Пытанне ў тым, што сама БД пакуль не кластарызаваная - разгорнутыя ў кубіку вэб-серверы забіраюць інфармацыю аб зменах з нашай статычнай баявой базы, якая круціцца асобна.
Адчуваеце падвох? Мы выкарыстоўваем k8s ці Swarm для таго, каб размеркаваць нагрузку і пазбегнуць падзення асноўнага вэб-сервера, але мы не робім гэтага для БД. Але ж калі зваліцца БД, то ва ўсёй нашай кластарызаванай інфраструктуры няма сэнсу – толку нам ад пустых вэб-старонак, якія вяртаюць памылку доступу да базы дадзеных?
Менавіта таму кластарызаваць трэба не толькі вэб-серверы, як гэта звычайна і робіцца, але і інфраструктуру базы даных. Толькі такім чынам мы можам забяспечыць паўнавартасна працуючую ў адной запрэжцы, але пры гэтым незалежную сябар ад сябра структуру. Пры гэтым нават калі ў нас «зваляецца» палова з нашага бэкэнду пад нагрузкай – астатняя выжыве, і сістэма сінхранізацыі БД паміж сабой у межах кластара і магчымасць бясконцага маштабавання і разгортвання новых кластараў дапаможа хутка выйсці на неабходныя магутнасці – былі б стойкі ў дата-цэнтры. .
Акрамя таго, размеркаваная ў кластарах мадэль БД дазваляе выносіць гэтую самую БД туды, дзе яна неабходна; калі мы гаворым аб глабальным сэрвісе, то даволі нелагічна круціць вэб-кластар дзесьці ў раёне Сан-Францыска і пры гэтым ганяць пакеты пры звароце да базы дадзеных у Падмаскоўе і назад.
Таксама кантэйнерызацыі БД дазваляе выбудаваць усе элементы сістэмы на адным узроўні абстракцыі. Што, у сваю чаргу, робіць магчымым кіраванне гэтай самай сістэмай прама з кода, распрацоўшчыкамі, без актыўнага прыцягнення адмінаў. Падумалася распрацоўшчыкам, што патрэбна асобная СКБД для новага падпраекта - лёгка! напісалі yaml-файл, загрузілі ў кластар і гатова.
Ну і само сабой, унутраная эксплуатацыя спрашчаецца ў разы. Скажыце, колькі разоў вы зажмурыліся ў моманты, калі новы чалец каманды соваў рукі ў баявую БД па працы? Якая ў вас, па факце, адна і вось прама зараз круціцца? Вядома, усе мы тут людзі дарослыя, і ў нас дзесьці ёсць свежанькі бэкап, а яшчэ далей - за паліцай з бабулінымі агуркамі і старымі лыжамі - яшчэ адзін бэкап, магчыма нават на халодным сховішчы, таму што аднойчы ўжо ваш офіс гарэў. Але ўсё роўна, кожнае ўвядзенне новага члена каманды, які мае доступ да баявой інфраструктуры і, вядома ж, да баявой базы дадзеных - гэта вядро валідолу для ўсіх навакольных. Ну хто яго, навічка, ведае, можа ён касарукі? Страшна, пагадзіцеся.
Кантэйнерызацыя і, па сутнасці, размеркаваная фізічная тапалогія БД вашага праекта дапамагае падобных валідольных момантаў пазбегнуць. Не давяраеце пачаткоўцу? Окей! Паднімем яму ўласны кластар для працы і адключым ад астатніх кластараў БД - сінхранізацыя толькі па ручным пушу і сінхроннаму павароту двух ключоў (адзін тымліду, другі адміну). І ўсё шчаслівыя.
А зараз надышоў час пераабуцца ў супернікаў кластарызацыі БД.
Цёмны бок
Разважаючы, чаму ж не варта кантэйнерызаваць базу дадзеных і працягваць круціць яе на адным цэнтральным серверы, не будзем апускацца да рыторыкі артадоксаў і сцвярджэнняў выгляду "дзяды круцілі БД на жалезе, і мы будзем!" Замест гэтага давайце паспрабуем прыдумаць сітуацыю, у якой кантэйнерызацыя сапраўды прыносіла б адчувальныя дывідэнды.
Пагадзіцеся, праектаў, якім рэальна патрэбна база ў кантэйнеры, можна пералічыць па пальцах адной рукі не самага лепшага фрэзероўшчыка. У большасці сваёй, нават само выкарыстанне k8s або Docker Swarm бывае залішне – даволі часта да гэтых прылад звяртаюцца з-за агульнай хайпавасці тэхналогій і ўсталёвак «усявышніх» у асобе гендыраў загнаць усё ў аблокі і кантэйнеры. Ну, таму што зараз гэта модна і ўсё так робяць.
Мінімум у палове выпадкаў выкарыстанне кубернетысу ці проста докера на праекце залішне. Пытанне ў тым, што не ўсе каманды ці аўтсорс-кампаніі, нанятыя абслугоўваць інфраструктуру кліента, разумеюць гэта. Горш - калі кантэйнеры навязваюцца, таму што гэта ўстае ў пэўную колькасць манет кліенту.
Наогул, існуе меркаванне, што докер/кубік-мафія тупа падмінае пад сябе кліентаў, якія аддаюць гэтыя інфраструктурныя пытанні на аўтсорс. Бо для таго, каб працаваць з кластарамі, патрэбны інжынеры, якія здольныя на гэта і разумеюць увогуле архітэктуру ўкаранёнага рашэння. Мы неяк ужо апісвалі наш кейс з выданнем Republic - там мы навучылі каманду кліента працаваць у рэаліях кубернетысу, і ўсе засталіся задаволеныя. І гэта было прыстойна. Часцяком жа «ўкараняльнікі» k8s бяруць інфраструктуру кліента ў закладнікі - бо зараз толькі яны разумеюць, як там усё працуе, на баку кліента спецыялістаў няма.
А зараз уявіце, што такім чынам мы аддаём не толькі вэб-серверную частку на водкуп аўтсорсу, але яшчэ і абслугоўванне БД. Мы казалі, што БД - гэта сэрца, а страта сэрца фатальная для любога жывога арганізма. Карацей, далягляды не самыя лепшыя. Так што замест хайпавага кубернетысу многім праектам варта было б проста не скардзіцца на нармальны тарыф на AWS, які вырашыць усе праблемы з нагрузкай на іх сайт/праект. Але AWS ужо не модна, а панты даражэй грошай – нажаль, і ў IT-асяроддзі таксама.
Окей. Магчыма, кластарызацыя праекту рэальна патрэбна, але калі з са stateless-прыкладаннямі ўсё зразумела, то як тады арганізаваць годнае забеспячэнне сеткавай складнасці кластарызаванай базы дадзеных?
Калі мы кажам аб бясшвоўным інжынерным рашэнні, якім і ўяўляецца пераход на k8s, то галоўны наш галаўны боль - гэта рэплікацыя дадзеных у кластэрызаванай БД. Нейкія СКБД першапачаткова даволі лаяльна ставяцца да размеркавання дадзеных паміж асобнымі сваімі асобнікамі. Многія ж іншыя не такія ветлівыя. І даволі часта асноўным аргументам у выбары СКБД для нашага праекта становіцца зусім не здольнасць рэпліцыравацца з мінімальнымі рэсурснымі і інжынернымі выдаткамі. Асабліва калі праект першапачаткова не планаваўся як мікрасэрвісны, а проста эвалюцыянаваў у гэты бок.
Думаем, аб хуткасці працы сеткавых дыскаў расказваць не трэба - яны павольныя. Г.зн. рэальнай магчымасці, у выпадку чаго, перападняць асобнік СКБД дзесьці, дзе больш, да прыкладу, працэсарных магутнасцяў ці вольнай аператыўнай памяці, у нас усё роўна няма. Мы вельмі хутка ўпрэмся ў прадукцыйнасць віртуалізаванай дыскавай падсістэмы. Адпаведна, СКБД павінна быць прыбіта да свайго ўласнага персанальнага набору машын, якія знаходзяцца ў непасрэднай блізкасці. Або ж трэба неяк асобна акастыльваць досыць хуткую сінхранізацыю дадзеных на меркаваныя рэзервы.
У працяг тэмы віртуальных ФС: Docker Volumes, нажаль, не беспраблемныя. У цэлым, у такой справе як доўгатэрміновае надзейнае захоўванне дадзеных хацелася б абыходзіцца максімальна простымі тэхнічна схемамі. І даданне новага пласта абстракцыі з ФС кантэйнера ў ФС бацькоўскага хаста - ужо само па сабе рызыка. Але калі яшчэ і ў працы сістэмы забеспячэння кантэйнерызацыі ўзнікаюць складанасці з трансляваннем дадзеных паміж гэтымі пластамі, тады ўжо зусім бяда. На дадзены момант большая частка вядомых прагрэсіўнаму чалавецтву праблем быццам бы выкаранена. Але самі разумееце, чым складанейшы механізм, тым прасцей ён ламаецца.
У святле ўсіх гэтых «прыгод» нашмат выгодней і прасцей трымаць БД у адным месцы, і нават калі вам запатрабавалася кантэйнерызацыя прыкладання - няхай яно круціцца само па сабе і праз размеркавальны шлюз атрымлівае адначасовую сувязь з БД, якая будзе чытацца і пісацца толькі адзін раз і у адным месцы. Такі падыход зніжае верагоднасць памылак і рассінхранізацый да мінімальных значэнняў.
Да чаго мы вядзем? Да таго, што кантэйнерызацыя БД дарэчная тамака, дзе ў ёй ёсць рэальная неабходнасць. Нельга запіхнуць базу фул-аппа і круціць яе так, быццам бы ў вас два дзясяткі мікрасэрвісаў – гэта так не працуе. І гэта трэба дакладна разумець.
замест вываду
Калі вы чакаеце выразнай высновы «віртуалізаваць ці не БД», то засмуцім: яго тут не будзе. Бо пры стварэнні любога інфраструктурнага рашэння трэба кіравацца не модай і прагрэсам, а ў першую чаргу, разумным сэнсам.
Існуюць праекты, на якія прынцыпы і інструменты, якія ідуць з кубернетысам, кладуцца ідэальна, і ў такіх праектах надыходзіць свет хаця б у бэкэнд-вобласці. А ёсць праекты, якім патрэбна не кантэйнерызацыя, а нармальная серверная інфраструктура, таму што яны прынцыпова не могуць перамаштабавацца пад мікрасэрвісную кластарную мадэль, бо ўпадуць.
Крыніца: habr.com