Как да оцелее SQL-базата през 21-ви век: облаци, Kubernetes и PostgreSQL multimaster

Здравейте, хабровци. Днес започва учебният курс на първата група. «PostgreSQL». В тази връзка, искаме да ви разкажем как премина откритият уебинар по този курс.

В още един открит урок поговорихме за предизвикателствата, с които се сблъскаха SQL базите данни в ерата на облаците и Kubernetes. И настрана, разгледахме как SQL базите данни се адаптират и мутират под влиянието на тези предизвикателства.

Уебинарът беше воден от Валерий Безруков, Google Cloud Practice Delivery Manager в EPAM Systems.

Когато дърветата бяха малки...

За начало нека си припомним как се извършваше изборът на СУБД в края на миналия век. Всъщност, това не е трудно, тъй като изборът на СУБД тогава започваше и завършваше Oracle.

в края на 90-те — началото на 2000-те, действителният избор не беше особено широк, ако говорим за промишлено мащабируеми бази данни. Да, имаше IBM DB2, Sybase и още няколко бази данни, които се появяваха и изчезваха, но общо взето, те не бяха толкова забележими на фона на Oracle. В съответствие с това, уменията на инженери от онова време бяха така или иначе свързани с единствения избор, който съществуваше.

Oracle DBA трябваше да умее:

• да инсталира Oracle Server от дистрибутива;
• да конфигурира Oracle Server:

• init.ora;
• listener.ora;

— да създава:

• таблични пространства;
• схеми;
• потребители;

— да извършва резервно копиране и възстановяване;
— да извършва мониторинг;
— да се бори с неоптимални запитвания.

В същото време, от Oracle DBA не се изискваше особено:

• да умее да избира оптимална СУБД или друга технология за съхранение и обработка на данни;
• да осигурява висока наличност и хоризонтална мащабируемост (това не винаги беше задача на DBA);
• да познава добре предметната област, инфраструктурата, приложната архитектура, операционните системи;
• да извършва зареждане и извеждане на данни, миграция на данни между различни СУБД.

Общо взето, ако говорим за избора в онези времена, той наподобява избора в съветския магазин в края на 80-те:

Нашето време

Оттогава, разбира се, дърветата пораснаха, светът се промени и стана така:

Промени се и пазарът на СУБД, което се вижда ясно от последния доклад на компания Gartner:

И тук не може да не се отбележи, че облаците заеха своята ниша, чиято популярност нараства. Ако прочетем същия доклад на компания Gartner, ще видим следните изводи:

1. Много клиенти са на път да прехвърлят приложенията си в облака.
2. Новите технологии първоначално се появяват в облака и не е сигурно, че ще се преместят изобщо в необлачна инфраструктура.
3. Станала е обичайна моделът на ценообразуване на принципа pay-as-you-go. Всички искат да плащат само за това, което използват, и това вече не е просто тенденция, а констатация на факта.

Какво сега?

Днес всички ние сме в облака. А въпросите, които възникват у нас, са въпроси на избор. А той е огромен, дори когато говорим само за избора на технологии за СУБД в On-premises формат. А имаме и управляеми услуги и SaaS. Така изборът става все по-сложен с всяка изминала година.

Наред с въпросите на избора, действат и ограничителни фактори:

• цената. Много технологии все още изискват заплащане;
• умения. Ако говорим за свободен софтуер, възниква въпросът за уменията, тъй като безплатният софтуер изисква от хората, които го инсталират и експлоатират, достатъчна компетентност;
• функционалност. Не всички услуги, които са достъпни в облака и са изградени, да речем, дори на базата на Postgres, притежават същите функции като Postgres On-premises. Това е съществен фактор, който трябва да знаете и разбирате. Освен това, този фактор придобива по-голямо значение от знанието за някакви скрити възможности на отделна СУБД.

Какво очакват сега от DA/DE:

• добро разбиране на предметната област и приложната архитектура;
• възможността да избирате подходящата технология на СУБД в зависимост от поставената задача;
• възможността да подбирате оптималния метод на реализация на избраната технология в контекста на наличните ограничения;
• възможността да осъществявате пренос и миграция на данни;
• възможността да реализирате и експлоатирате избраните решения.

Следният пример на база GCP демонстрира как се осъществява изборът на определена технология за работа с данни в зависимост от тяхната структура:

Обърнете внимание, че в схемата липсва PostgreSQL, а всичко е, защото той е скрит под терминологията Cloud SQL. А когато попаднем в Cloud SQL, отново трябва да направим избор:

Трябва да се отбележи, че този избор не винаги е ясен, затова разработчиците на приложения често разчитат на интуицията си.

Общо:

1. Колкото по-далеч, толкова по-актуален става въпросът за избора. И дори когато погледнем само на GCP, управляеми услуги и SaaS, споменаването на РСУБД се появява едва на 4-та стъпка (и там Spanner е близо). Плюс това, изборът на PostgreSQL се появява на 5-та стъпка, а до него още MySQL и SQL Server, тоест много хора, но трябва да изберем.
2. Не трябва да забравяме и за ограниченията пред соблазните. В повечето случаи всички искат Spanner, но той е скъп. В крайна сметка типичната заявка изглежда приблизително така: «Моля, направете ни Spanner, но на цената на Cloud SQL, вие сте професионалисти!»

Какво да правим?

Без да претендираме за последна инстанция, да кажем следното:

Трябва да променим подхода към обучението:

• да обучаваме както по-рано DBA, няма смисъл;
• знанията за един продукт вече не са достатъчни;
• а да знаеш десетки на ниво един — невъзможно.

Необходимо е да знаем не само и не толкова продукта, а:

• use case на приложението;
• различни методи за разгръщане;
• предимствата и недостатъците на всеки от методите;
• аналогични и алтернативни продукти, за да направим осъзнат и оптимален избор, а не винаги в полза на познатия продукт.

А също така трябва да умеем да мигрираме данни и да разбираме основните принципи на интеграция с ETL.

Реален случай

В недалечното минало ми се наложи да създам бекенд за мобилно приложение. Към момента на започване на работата по него, бекендът вече беше разработен и готов за внедряване, а екипът разработчици прекара около две години в този проект. При това бяха поставени следните задачи:

• да изградим CI/CD;
• да направим преглед на архитектурата;
• да пуснем всичко в експлоатация.

Самото приложение беше микросервисно, а кодът на Python/Django беше разработен от нулата и веднага в GCP. Що се отнася до целевата аудитория, се предполага, че ще има два региона — САЩ и ЕС, а трафикът се разпределя чрез глобален балансер на натоварването. Всички работни натоварвания и изчислителни натоварвания работеха в Google Kubernetes Engine.

Що се отнася до данните, имаше 3 структури:

• Cloud Storage;
• Datastore;
• Cloud SQL (PostgreSQL).

Може да възникне въпрос, защо беше избран Cloud SQL? Честно казано, такъв въпрос в последните години оставя някаква неловка пауза — появява се усещането, че хората започнаха да се срамуват от релационни бази, но все пак продължават да ги използват активно ;-).

Относно нашия случай, Cloud SQL беше избран по следните причини:

1. Както беше споменато, приложението се разработваше с помощта на Django, а в него има модел за представяне на постоянни данни от SQL базата в обекти Python (Django ORM).
2. Самият фреймворк поддържа достатъчно ограничен списък от СУБД:

• PostgreSQL;
• MariaDB;
• MySQL;
• Oracle;
• SQLite.

Съответно, PostgreSQL беше избран от този списък по-скоро интуитивно (наистина ли да изберем Oracle?).

Какво липсваше:

• приложението беше разширено само в 2 региона, а в плановете се появи 3-ти (Азия);
• БД се намираше в северноамериканския регион (Айова);
• от страна на клиента имаше опасения относно възможните закъснения в достъпа от Европа и Азия и прекъсвания в обслужването в случай на престой на СУБД.

Въпреки че самият Django може да работи с няколко БД паралелно и да ги разделя на четене и писане, записите в приложението не бяха много (над 90 % — четене). И като цяло, ако можеше да се направи read-реплика на основната база в Европа и Азия, това щеше да бъде компромисно решение. А какво е толкова сложно тук?

А сложността се състоеше в това, че клиентът не искаше да се откаже от използването на управлявани услуги и Cloud SQL. А възможностите на Cloud SQL в момента са ограничени. Cloud SQL поддържа Висока наличност (HA) и Read Replica (RR), но същата RR се поддържа само в един регион. Създавайки БД в американския регион, не може да се направи read-реплика в европейския регион с помощта на Cloud SQL, въпреки че самият PostgreSQL не пречи на това. Кореспонденцията с служителите на Google не доведе до нищо и завърши с обещания в стил „знаем за проблема и работим по него, някога въпросът ще бъде решен.“

Ако изброим възможностите на Cloud SQL тезисно, то това би изглеждало приблизително така:

1. Висока наличност (HA):

• в рамките на един регион;
• чрез дискова репликация;
• не се използват механизми на PostgreSQL;
• възможно е автоматично и ръчно управление — failover/failback;
• при превключване СУБД не е налична в продължение на няколко минути.

2. Read Replica (RR):

• в рамките на един регион;
• горещо резервиране;
• стрийминг репликация на PostgreSQL.

Също така, както е обичайно, при избора на технология винаги се сблъскваш с някакви ограничения:

• клиентът не искаше да създава нови обекти и да използва IaaS, освен чрез GKE;
• клиентът не искаше да разгръща self service PostgreSQL/MySQL;
• а така или иначе, Google Spanner би бил подходящ, ако не беше цената му, но с него Django ORM не може да работи, а така е добър продукт.

Предвид ситуацията, клиентът зададе въпрос на засыпка: „Можете ли да направите нещо подобно, така че да е като Google Spanner, но да работи и с Django ORM?“

Опция за решение № 0

Първото, което ми хрумна:

• да останем в рамките на CloudSQL;
• вградена репликация между регионите няма да има в никакъв вид;
• да опитаме да прикрепим реплика към съществуващ Cloud SQL от PostgreSQL;
• някъде и по някакъв начин да стартираме инстанс на PostgreSQL, но поне вторичния да не го пипаме.

За съжаление, се оказа, че не може да се направи така, тъй като нямаме достъп до хоста (той наистина е в друг проект) — pg_hba и т.н., и нямаме достъп и под суперпотребител.

Вариант на решение № 1

След поредните размисли и с оглед на предишните обстоятелства мисълта се промени малко:

• все така се опитваме да останем в рамките на CloudSQL, но преминаваме към MySQL, тъй като Cloud SQL за MySQL има външен master, който:

— е прокси за външен MySQL;
— изглежда като инстанс на MySQL;
— е създаден за миграция на данни от други облаци или On-premises.

Тъй като настройката на репликацията на MySQL не изисква достъп до хоста, всичко работеше в основни линии, но много нестабилно и неудобно. А когато продължихме, стана още по-страшно, тъй като цялата структура я развивахме с terraform, а изведнъж се оказа, че външният master не се поддържа от terraform. Да, Google има CLI, но по някаква причина и тук всичко работеше през път — понякога се създаваше, понякога не. Може би, защото CLI е било създадено за миграция на данни отвън, а не за реплики.

Всъщност, на това стана ясно, че Cloud SQL изобщо не подхожда. Както се казва, направихме всичко, което можехме.

Вариант на решение № 2

Тъй като не успяхме да останем в рамките на Cloud SQL, се опитахме да формулираме изискванията към компромисно решение. Изискванията се оказаха следните:

• работа в Kubernetes, максимално използване на ресурсите и възможностите на Kubernetes (DCS, …) и GCP (LB, …);
• отсъствие на излишък от куп ненужни в облака неща като HA proxy;
• възможност за стартиране на основния регион HA PostgreSQL или MySQL; в останалите региони — HA от основния регион плюс негово копие (за надеждност);
• мулти master (не ни се искаше да се свързваме с него, но това нямаше да е особено принципно)

.
В резултат на тези изисквания на хоризонта най-накрая се появиха подходящи варианти на СУБД и обвивкиMySQL Galera;:

• CockroachDB;
• инструменти на PostgreSQL
• — pgpool-II;

:
— Patroni.
MySQL Galera

Технологията MySQL Galera е разработена от компанията Codership и представлява плъгин за InnoDB. Особености:

мулти master;

• синхронна репликация;
• четене от всякакъв възел;
• писане на всеки възел;
• вграден механизъм HA;
• има Helm chart от Bitnami.
• CockroachDB

CockroachDB

Според описанието, нещото е напълно впечатляващо и представлява open source проект, написан на Go. Основният участник е Cockroach Labs (основана от бивши служители на Google). Тази релационна СУБД е създадена да бъде разпределена (с хоризонтално мащабиране „извън кутията“) и устойчива на откази. Авторите от компанията са поставили целта да „съчетаят богатството на функционалността на SQL с хоризонталната достъпност, присъща за решенията NoSQL.

От приятните бонуси — поддръжка на PostgreSQL протокола за свързване.

Pgpool

Това е надстройка над PostgreSQL, всъщност нова същност, която поема всички свързвания и ги обработва. Има свой баланс по натоварването и парсер, лицензирана е по BSD лиценз. Предоставя широки възможности, но изглежда малко плашещо, тъй като наличието на нова същност може да стане източник на някои допълнителни приключения.

Patroni

Това е последното, на което се спря погледът, и не напразно. Patroni — опенсорсна утилита, която всъщност представлява демон на Python, позволяваща автоматично управление на PostgreSQL клъстери с различни типове репликация и автоматично превключване на роли. Необходимият инструмент се оказа много интересен, тъй като се интегрира добре с Kubernetes и не носи нови същности.

Какво в крайна сметка избрахме

Изборът не беше лесен:

1. CockroachDB — впечатляващ, но стряскащ;
2. Технологията MySQL Galera е разработена от компанията Codership и представлява плъгин за InnoDB. Особености: — също добро, употребяван на много места, но MySQL;
3. Pgpool — много излишни същности, интеграцията с облака и K8s не е добра;
4. Patroni — страхотна интеграция с K8s, няма излишни същности, добре се интегрира с GCP LB.

Така че, изборът падна на Patroni.

Изводи

Време е да обобщим. Да, светът на ИТ инфраструктурата се е променил съществено, и това е само началото. Ако преди облаците бяха просто един друг тип инфраструктура, сега всичко е различно. Още повече, иновации в облаците се появяват постоянно, ще се появяват и, възможно е, да се появяват единствено в облаците и само след това, с помощта на стартъпи, да бъдат пренесени на On-premises.

Що се отнася до SQL, SQL ще продължи да съществува. Това означава, че трябва да познавате PostgreSQL и MySQL и да умеете да работите с тях, но още по-важно е да умеете да ги прилагате правилно.

Източник: habr.com