Привіт, хабрівчани. Сьогодні стартують заняття у першій групі курсу . У зв'язку з цим хочемо розповісти вам про те, як проходив відкритий вебінар за цим курсом.
В поговорили про те, з якими викликами зіткнулися 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 repplication.
До того ж, як це заведено, при виборі технології завжди стикаєшся з якими-небудь обмеженнями:
- замовник не хотів плодити сутності та використовувати 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.
Тарган DB
За описом річ абсолютно бомбічна і є open source-проект, написаний на Go. Основний учасник Cockroach Labs (заснована вихідцями з Google). Ця реляційна СУБД спочатку створена бути розподіленою (з горизонтальним масштабуванням «з коробки») та стійкою до відмови. Її автори з компанії позначили мету «поєднати багатство функціональності SQL з горизонтальною доступністю, звичною для NoSQL-рішень».
З приємного бонусу - підтримка постгресного протоколу підключення.
Pgpool
Це надбудова над PostgreSQL, насправді, нова сутність, яка приймає він всі з'єднання і обробляє їх. Має свій лоад балансер та парсер, ліцензується за ліцензією BSD. Надає широкі можливості, але виглядає дещо лякаюче, тому що наявність нової сутності могла стати джерелом додаткових пригод.
Патрони
Це останнє, на що впав погляд, і, як виявилося, не дарма. Patroni — опенсорсна утиліта, яка, по суті, є демоном на Python, що дозволяє автоматично обслуговувати кластери PostgreSQL з різними типами реплікації та автоматичним перемиканням ролей. Штука виявилася дуже цікавою, оскільки вона добре інтегрується з кубером і не несе жодних нових сутностей.
Що в результаті обрали
Вибір давався непросто:
- Тарган DB - Вогонь, але стрімко;
- MySQL Galera - теж непогано, багато де використовують, але MySQL;
- Pgpool — багато зайвих сутностей, так інтеграція з хмарою і K8s;
- Патрони - Чудова інтеграція з K8s, немає зайвих сутностей, добре інтегрується з GCP LB.
Таким чином, вибір ліг на Patroni.
Висновки
Настав час підбити короткі підсумки. Так, світ ІТ-інфраструктури значно змінився, і це тільки початок. І якщо раніше хмари були лише іншим типом інфраструктури, то тепер все інакше. Мало того, інновації в хмарах з'являються постійно, з'являтимуться і, можливо, вони з'являтимуться лише в хмарах і лише потім, силами стартапів, переноситимуться в On-premises.
Що стосується SQL, то SQL житиме. Це означає, що PostgreSQL і MySQL треба знати та працювати з ними треба вміти, але ще важливіше вміти їх правильно застосовувати.
Джерело: habr.com