Прывітанне, хабраўчане. Сёння стартуюць заняткі ў першай групе курса . У сувязі з гэтым, жадаем распавесці вам пра тое, як праходзіў адкрыты вэбінар па дадзеным курсе.
В пагаварылі аб тым, з якімі выклікамі сутыкнуліся SQL-базы ў эру аблокаў і Kubernetes. А заадно разгледзелі, як базы дадзеных SQL прыстасоўваюцца і мутуюць пад уздзеяннем гэтых выклікаў.
Вебінар правёў , Google Cloud Practice Delivery Manager у EPAM Systems.
Калі дрэвы былі маленькімі…
Для пачатку давайце ўспомнім, як пачынаўся выбар СКБД у канцы мінулага стагоддзі. Зрэшты, гэта не складзе працы, бо выбар СКБД у тыя часы пачынаўся і заканчваўся Аракул.
У канцы 90-х - пачатку нулявых, асаблівага выбару, па сутнасці, не было, калі казаць пра прамысловыя маштабуюцца БД. Так, існавалі IBM DB2, Sybase і яшчэ нейкія базы дадзеных, якія з'яўляліся і знікалі, але ўвогуле і цэлым яны былі не так прыкметныя на фоне Oracle. Адпаведна, навыкі інжынераў тых часоў былі так ці інакш завязаны на той адзіны выбар, які існаваў.
Oracle DBA павінен быў умець:
- усталёўваць Oracle Server з дыстрыбутыва;
- наладжваць Oracle Server:
- init.ora;
- listener.ora;
- ствараць:
- таблічныя прасторы;
- схемы;
- карыстальнікаў;
- выконваць рэзервовае капіраванне і аднаўленне;
- ажыццяўляць маніторынг;
- змагацца з неаптымальнымі запытамі.
Пры гэтым ад Oracle DBA асоба не патрабавалася:
- умець выбіраць аптымальную СКБД ці іншую тэхналогію захоўвання і апрацоўкі дадзеных;
- забяспечваць высокую даступнасць і гарызантальную маштабаванасць (гэта не заўсёды было пытанне DBA);
- добра ведаць прадметную вобласць, інфраструктуру, прыкладную архітэктуру, АС;
- выконваць загрузку і выгрузку дадзеных, міграцыю дадзеных паміж рознымі СКБД.
Увогуле, калі казаць аб выбары ў тыя часы, то ён нагадвае выбар у савецкай краме ў канцы 80-х:
Наш час
З таго часу, зразумела, дрэвы падраслі, свет змяніўся, і стала неяк так:
Змяніўся і рынак СКБД, што добра відаць па свежым дакладзе кампаніі Gartner:
І тут нельга не адзначыць, што сваю нішу занялі аблокі, папулярнасць якіх расце. Калі пачытаць тую ж справаздачу кампаніі Gartner, мы ўбачым наступныя высновы:
- Многія заказчыкі знаходзяцца на шляху пераводу прыкладанняў у воблака.
- Новыя тэхналогіі спачатку з'яўляюцца ў воблаку і не факт, што яны ўвогуле калі-небудзь пераедуць у нявоблачную інфраструктуру.
- Стала звыклай мадэль коштаўтварэння па прынцыпе pay-as-you-go. Усё жадаюць плаціць толькі за тое, чым карыстаюцца, і гэта нават ужо не трэнд, а проста канстатаванне факту.
Што цяпер?
Сёння ўсе мы ў воблаку. А тыя пытанні, якія ў нас узнікаюць, — гэта пытанні выбару. А ён вялізны, нават калі казаць толькі пра выбар тэхналогій СКБД у фармаце On-premises. А яшчэ ў нас есць managed services і SaaS. Такім чынам, выбар з кожным годам толькі ўскладняецца.
Нараўне з пытаннямі выбару, дзейнічаюць і абмежавальныя фактары:
- кошт. Многія тэхналогіі па-ранейшаму каштуюць грошай;
- навыкі. Калі мы кажам аб вольным ПЗ, тое ўзнікае пытанне навыкаў, бо бясплатны софт патрабуе ад людзей, якія яго разгортваюць і эксплуатуюць, дастатковай кампетэнтнасці;
- функцыянал. Не ўсе сэрвісы, якія даступныя ў воблаку і пабудаваны, скажам, нават на базе таго ж Postgres, валодаюць тымі ж фічамі, што і Postgres On-premises. Гэта істотны фактар, які трэба ведаць і разумець. Мала таго, гэты фактар набывае важнейшае значэнне, чым веданне нейкіх утоеных магчымасцяў асобна ўзятай СКБД.
Што чакаюць зараз ад DA/DE:
- добрага разумення прадметнай вобласці і прыкладной архітэктуры;
- ўменні правільна выбіраць прыдатную тэхналогію СКБД з улікам пастаўленай задачы;
- ўменні падбіраць аптымальны метад рэалізацыі абранай тэхналогіі ў кантэксце наяўных абмежаванняў;
- ўменні выконваць перанос і міграцыю даных;
- ўменні рэалізоўваць і эксплуатаваць выбраныя рашэнні.
Наступны прыклад на базе GCP дэманструе, як уладкованы выбар той ці іншай тэхналогіі працы з дадзенымі ў залежнасці ад іх структуры:
Звярніце ўвагу, што ў схеме адсутнічае PostgreSQL, а ўсё таму, што ён хаваецца пад тэрміналогіяй Воблачны SQL. І калі мы пападаем у Cloud SQL, нам трэба зноў зрабіць выбар:
Варта заўважыць, што гэты выбар не заўсёды зразумелы, таму распрацоўшчыкі прыкладання часта кіруюцца інтуіцыяй.
Разам:
- Чым далей, тым больш актуальным становіцца пытанне выбару. І нават калі глядзець толькі на GCP, managed services і SaaS, то нейкая згадка РСУБД з'яўляецца толькі на 4-м кроку (а тамака Spanner побач). Плюс, выбар PostgreSQL з'яўляецца ўвогуле на 5-м кроку, а побач яшчэ MySQL і SQL Server, гэта значыць усяго шмат, а выбіраць трэба.
- Нельга забываць і пра абмежаванні на фоне спакус. У асноўным, усё жадаюць Spanner, але ён дарагі. У выніку тыпавы запыт выглядае прыкладна так: "Зрабіце нам, калі ласка, Spanner але за кошт Cloud SQL, ну вы ж прафесіяналы!"
А што рабіць?
Не прэтэндуючы на ісціну ў апошняй інстанцыі, скажам наступнае:
Трэба мяняць падыход да навучання:
- вучыць, як вучылі раней DBA, няма сэнсу;
- веды аднаго прадукта цяпер ужо недастаткова;
- а ведаць дзясяткі на ўзроўні аднаго - немагчыма.
Трэба ведаць не толькі і не колькі прадукт, а:
- use case яго прымянення;
- розныя метады разгортвання;
- перавагі і недахопы кожнага з метадаў;
- аналагічныя і альтэрнатыўныя прадукты, каб рабіць усвядомлены і аптымальны выбар і не заўсёды ў карысць знаёмага прадукта.
А яшчэ трэба ўмець міграваць дадзеныя і разумець базавыя прынцыпы інтэграцыі з ETL.
Рэальны выпадак
У нядаўнім мінулым даводзілася рабіць бэкенд для мабільнага прыкладання. Да моманту пачатку працы над ім бэкэнд ужо быў распрацаваны і гатовы да ўкаранення, а каманда распрацоўшчыкаў выдаткавала на гэты праект каля двух гадоў. Пры гэтым былі пастаўлены наступныя задачы:
- пабудаваць CI/CD;
- зрабіць review архітэктуры;
- запусціць усё гэта ў эксплуатацыю.
Само прыкладанне было мікрасэрвісным, а код на Python/Django быў распрацаваны з нуля і адразу ў GCP. Што тычыцца мэтавай аўдыторыі, то меркавалася, што будзе два рэгіёны – US і EU, а трафік размяркоўваўся праз Global Load balancer. Усе Workloads і вылічальная нагрузка працавалі ў Google Kubernetes Engine.
Што да дадзеных, то былі 3 структуры:
- Cloud Storage;
- Datastore;
- Cloud SQL (PostgreSQL).
Можа ўзнікнуць пытанне, чаму быў абраны Cloud SQL? Гаворачы па праўдзе, такое пытанне ў апошнія гады выклікае нейкую няёмкую паўзу - узнікае адчуванне, што людзі сталі саромецца рэляцыйных баз, але тым не менш яны працягваюць іх актыўна выкарыстоўваць ;-).
Што да нашага выпадку, то Cloud SQL быў абраны па наступных прычынах:
- Як было згадана, прыкладанне распрацоўвалася з дапамогай Django, а ў ім ёсць мадэль адлюстравання пастаянных дадзеных з SQL-базы ў аб'екты Python (Django ORM).
- Сам фрэймворк падтрымліваў дастаткова канчатковы спіс СКБД:
- PostgreSQL;
- MariaDB;
- MySQL;
- Аракул;
- SQLite.
Адпаведна, PostgreSQL абралі з гэтага спісу хутчэй інтуітыўна (ну не Oracle жа выбіраць, на самай справе).
Чаго не хапала:
- прыкладанне было разгорнута толькі ў 2-х рэгіёнах, а ў планах з'явіўся 3. (Азія);
- БД знаходзілася ў паўночнаамерыканскім рэгіёне (Iowa);
- з боку заказчыка прысутнічалі асцярогі наконт магчымых затрымак з доступам з Еўропы і Азіі і перабояў у абслугоўванні у выпадку прастою СКБД.
Пры тым, што сам Django можа працаваць з некалькімі БД паралельна і дзяліць іх па чытанні і запісы, запісы ў дадатку было не так ужо і шмат (больш за 90% - чытанне). І ўвогуле, і ў цэлым, калі можна было зрабіць read-рэпліку асноўнай базы ў Еўропе і Азіі, гэта было б кампрамісным варыянтам рашэння. Ну, а што тут такога складанага?
А складанасць складалася ў тым, што замоўца не жадаў адмаўляцца ад выкарыстання managed services і Cloud SQL. А магчымасці Cloud SQL на дадзены момант часу абмежаваны. Cloud SQL падтрымлівае High availability (HA) і Read Replica (RR), але тая ж RR падтрымліваецца толькі ў адным рэгіёне. Стварыўшы БД у амерыканскім рэгіёне, зрабіць read-рэпліку ў еўрапейскім рэгіёне сродкамі Cloud SQL нельга, хоць сам постгрэс гэтага рабіць не мяшае. Перапіска з супрацоўнікамі Google ні да чаго не прывяла і скончылася абяцаннямі ў стылі "мы ведаем праблему і працуем над ёй, калі-небудзь пытанне будзе вырашана".
Калі пералічыць магчымасці Cloud SQL тэзісна, тое гэта будзе выглядаць прыблізна так:
1. High availability (HA):
- у рамках аднаго рэгіёна;
- з дапамогай дыскавай рэплікацыі;
- не выкарыстоўваюцца механізмы PostgreSQL;
- магчыма аўтаматычнае і ручное кіраванне - failover / failback;
- пры пераключэнні СКБД недаступная на працягу некалькіх хвілін.
2. Read Replica (RR):
- у рамках аднаго рэгіёна;
- hot standby;
- PostgreSQL streaming replication.
Да таго ж, як гэта прынята, пры выбары тэхналогіі заўсёды сутыкаешся з якімі-небудзь. абмежаваннямі:
- заказчык не хацеў пладзіць сутнасці і выкарыстоўваць IaaS, акрамя як праз GKE;
- замоўца не жадаў бы разгортваць self service PostgreSQL/MySQL;
- ну і наогул, Google Spanner суцэль бы падышоў, калі б не яго кошт, праўда, з ім Django ORM працаваць не можа, а так штука вось добрая.
Улічваючы сітуацыю, ад заказчыка паступіла пытанне на засыпанне: "А можаце што-небудзь падобнае зрабіць, каб было, як Google Spanner, але працавала яшчэ і з Django ORM?"
Варыянт рашэння №0
Першае, што прыйшло ў галаву:
- застацца ў рамках CloudSQL;
- убудаванай рэплікацыі паміж рэгіёнамі не будзе ні ў якім выглядзе;
- паспрабаваць прыкруціць рэпліку да існуючага Cloud SQL by PostgreSQL;
- дзесьці і неяк запусціць інстанс PostgreSQL, але хаця б master не чапаць.
Нажаль, апынулася, што так зрабіць нельга, т. к. няма доступу да хаста (ён наогул у іншым праекце) – pg_hba і гэтак далей, а яшчэ няма доступу пад superuser.
Варыянт рашэння №1
Пасля чарговых разважанняў і з улікам папярэдніх абставін ход думкі некалькі змяніўся:
- усё таксама спрабуем застацца ў рамках CloudSQL, але пераходзім на MySQL, т. к. у Cloud SQL by MySQL ёсць external master, які:
- з'яўляецца proxy для знешняга MySQL;
- выглядае як інстанс MySQL;
- Прыдуманы для міграцыі дадзеных з іншых аблокаў або On-premises.
Бо налада рэплікацыі MySQL не патрабуе доступу да хаста, у прынцыпе ўсё працавала, але вельмі нестабільна і няёмка. А калі пайшлі далей, стала і зусім страшна, бо мы ўсю структуру разгортвалі terraform'ам, а раптам аказалася, што external master не падтрымліваецца terraform'ам. Так, у Google ёсць CLI, але чамусьці і тут усё працавала праз раз - тое ствараецца, то не ствараецца. Магчыма, таму, што CLI прыдумлялі для міграцыі дадзеных звонку, а не для рэплік.
Уласна, на гэтым стала зразумела, што Cloud SQL не падыходзіць ад слова зусім. Як кажуць, мы зрабілі ўсё, што змаглі.
Варыянт рашэння №2
Бо застацца ў рамках Cloud SQL не атрымалася, паспрабавалі сфармуляваць патрабаванні да кампраміснага рашэння. Патрабаванні аказаліся наступныя:
- праца ў Kubernetes, максімальнае выкарыстанне рэсурсаў і магчымасцяў Kubernetes (DCS, …) і GCP (LB, …);
- адсутнасць баласта з кучы непатрэбных у воблаку рэчаў тыпу HA proxy;
- магчымасць запускаць у асноўным рэгіёне HA PostgreSQL ці MySQL; у астатніх рэгіёнах - HA з RR асноўнага рэгіёну плюс яе копію (для надзейнасці);
- multi master (звязвацца з ім не жадалася, але гэта было не вельмі прынцыпова)
.
У выніку гэтых патрабаванняў на гарызонце нарэшце з'явіліся падыходныя варыянты СКБД і абвязкі:
- MySQL Galera;
- CockroachDB;
- PostgreSQL tools
:
- pgpool-II;
- Patroni.
MySQL Galera
Тэхналогія MySQL Galera распрацавана кампаніяй Codership і ўяўляе сабой plugin for InnoDB. Асаблівасці:
- multi master;
- сінхронная рэплікацыя;
- чытанне з любога вузла;
- запіс на любы вузел;
- убудаваны механізм HA;
- ёсць Helm chart ад Bitnami.
ТараканДБ
Па апісанні рэч зусім бамбічная і ўяўляе сабой open source-праект, напісаны на Go. Асноўны ўдзельнік - Cockroach Labs (заснавана выхадцамі з Google). Гэтая рэляцыйная СКБД першапачаткова створана быць размеркаванай (з гарызантальным маштабаваннем "са скрынкі") і адмоваўстойлівай. Яе аўтары з кампаніі пазначылі мэту "сумясціць багацце функцыянальнасці SQL з гарызантальнай даступнасцю, звыклай для NoSQL-рашэнняў".
З прыемнага бонуса - падтрымка постгрэснага пратакола падлучэння.
Pgpool
Гэта надбудова над PostgreSQL, насамрэч, новая сутнасць, якая прымае на сябе ўсе злучэнні і апрацоўвае іх. Мае свой лоад балансар і парсер, ліцэнзуецца па ліцэнзіі BSD. Дае шырокія магчымасці, але выглядае некалькі пужала, т. к. наяўнасць новай сутнасці магло стаць крыніцай нейкіх дадатковых прыгод.
Patroni
Гэта апошняе, на што зваліўся погляд, і, як аказалася, не дарма. Patroni – апенсорсная ўтыліта, якая, па сутнасці, уяўляе сабой дэман на Python, які дазваляе аўтаматычна абслугоўваць кластары PostgreSQL з рознымі тыпамі рэплікацыі і аўтаматычным пераключэннем роляў. Штука аказалася вельмі цікавай, бо яна добра інтэгруецца з куберам і не нясе ніякіх новых сутнасцяў.
Што ў выніку выбралі
Выбар даваўся няпроста:
- ТараканДБ - агонь, але стрэмна;
- MySQL Galera - таксама нядрэнна, шмат дзе выкарыстоўваецца, але MySQL;
- Pgpool - шмат лішніх сутнасцяў, так сабе інтэграцыя з воблакам і K8s;
- Patroni - Выдатная інтэграцыя з K8s, няма лішніх сутнасцяў, добра інтэгруецца з GCP LB.
Такім чынам, выбар упаў на Patroni.
Высновы
Прыйшла пара падвесці кароткія вынікі. Так, свет ІТ-інфраструктуры істотна памяняўся, і гэта толькі пачатак. І калі раней аблокі былі толькі іншым тыпам інфраструктуры, то зараз усё інакш. Мала таго, інавацыі ў аблоках з'яўляюцца ўвесь час, з'яўляцца будуць і, магчыма, яны будуць з'яўляцца толькі ў аблоках і толькі потым, сіламі стартапаў, будуць пераносіцца ў On-premises.
Што да SQL, то SQL будзе жыць. Гэта значыць, што PostgreSQL і MySQL трэба ведаць і працаваць з імі трэба ўмець, але яшчэ важней умець іх правільна прымяняць.
Крыніца: habr.com