Рома Новіков «Зараз всім треба бути трошки DevOps-ом»

Technical Director, Рома Новіков 3,5 років працює у компанії Percona. Зараз виконує роль Product Owner для проєкту «Monitoring and Management» – системи моніторингу для open-source баз даних. Рома поділився досвідом на Data Talks #5: «Database Management: Cloud vs On-premise. Proprietary vs Open-source» від SQL.ua Data Academy. Переглянути повний запис вебінару можна тут.

Proprietary vs. Open-source

Якщо компанія хоче мігрувати з proprietary на open-source, то їм завжди потрібно пояснювати плюси і мінуси. Треба дивитися на фічі. Поняття «open-source» зараз і 10 років тому – це дві великі різниці.

З трійки великих open-source, PostgreSQL – єдина, яка ще має залишки відкритих систем, community-driven. Інші називаються «open-source» тому, що фали доступні, але ти не завжди можеш використати їх в будь-якому кейсі.

Останні 5 років іде дуже сильна міграція всередині опен-сорса – між тим, що було дійсно open-source, до того, що називається «маркетингово-комерційний-available…».

Зараз набагато більше треба розуміти: факт того, що ти маєш файли продукту в себе на комп’ютері, ще не означає, що це дійсно повний open-source. Це треба розуміти навіть, коли іде вибір бази під якийсь проєкт.

Вибір буде дуже залежати від типу навантаження, типу даних. Що стосується «багів», то у відкритих системах, з одного боку, більше очей, а з іншого – менше очей дивляться всередину коду. Інколи це плюс, інколи – мінус. Потрібно завжди дивитися на конкретну базу і конкретні випадки.

Ми (у Percona – ред.) проводили дослідження, яке показало, що у 92% людей в інфраструктурі є більше, ніж одна база даних. Сьогодні переважна більшість компаній мають декілька різних баз – під кожен сервіс, задачу.

Я не думаю, що в найближчому часі ми прийдемо до того, що буде одна база даних, яка буде справлятися з будь-яким навантаженням сама ідеально. Цей «мультисвіт» залишиться і буде ще дуже довго.

Читайте професійну біографію Роми Новікова тут.

Cloud vs. On-premise. Гібридні системи?

Це більш складне питання. Якщо з open-source та пропріетарними БД все досить полярно, то тут головна перевага он-преміс – security і вартість підтримки. Принаймні, уявна.

Cloud – це швидкість. Швидкість – це отримання ресурсів. Коли тобі треба сервіс зараз, то чекати два тижні, поки замовлять сервер, привезуть його, потім підключать, налаштують, потім скажуть, що нам треба перебілдити, «тому що у нас тут не те ядро»…

Зараз між он-преміс і клаудом посередині є гібридна система. Ми бачимо, дуже великий різкий зсув в бік гібридного клауда, кубернетіса, які фактично нівелюють різницю між тим, чи є «залізо» – наше власне чи від Amazon, чи ми не знаємо, від кого, але воно якось з’являється.

Роль DBA теж змінюється, і вже делелопер може починати рахувати себе DBA, тому що він знає, де натиснути кнопку «зробити мені базу».

Питання зараз більше не в моноклаудах, а в мега-клаудах між різними зонами, між провайдерами. Щоб працювало надійно і стабільно, щоб не було вендорлокінгу* на рівні віртуальному або фізичному – це один із викликів, який буде у нас в найближчому часі.

* Vendor lock–in – прив’язка до постачальника або суттєва залежність від його рішень, коли виникають бар’єри для зміни постачальника, – ред.

Базуючись на нашому досвіді, сьогодні вже є інструменти, які можуть сказати, наприклад: якщо у Вас вже працює база в cloud, та Ви не робили якихось оновлень, то її роботу на певний відсоток можна покращити.

У Database, які працюють від клаудних провайдерів, дуже рідко в кого є питання, чи ефективно Ви використовуєте базу, тому що клауди всеодно продають Вам залізо. І якщо Вам дають базу, то клауд хотів би, щоб Ви використовували його більше. Ми (Percona – ред.) робимо акцент – як використати базу більш ефективно, або як зробити, щоб треба було менше ресурсів. В клауді компанії набагато легше «отримати гроші одразу», тому що не треба додаткових інстансів.

Про тренди. Куди клієнти мігрують свої бази?

З одного боку, це кубернетіс-кластери, з іншого – Database as a Service. Якщо дивитися на кубернетіс, то дуже багато компаній, і ми в тому числі, зараз почали робити операторів, які б розгортали базу і виконували інші задачі. Клієнту треба лише мати цей кластер кубернетіса, і далі – оператор за тебе все робить.

В одному з досліджень ми використовували такий термін – «scale via credit card», тобто, як часто люди збільшують свою інфраструктуру просто за рахунок докуповування ресурсів.

Виявилося, що у 50% випадків компаніям доводиться скейлитися, просто докупаючи ресурси. Від того, що БД буде працювати на якомусь віртуальному сервері, вона не буде магічно починати працювати ідеально, в залежності від навантаження. Вона не виправить неоптимально написаний SQL-запит… Все одно, розуміння того, як працює база, що там всередині відбувається, буде потрібно. Зараз всім треба бути трошки девопсом (DevOps, ред.).

Говорячи про Database as a Service, треба розуміти різницю. Деякі DBaaS можуть привести компанію до вендорлокінгу. Коли при спробі мігрувати виявиться, що бази, наче, схожі, але міграція назад може і не відбутися. Вибираючи DBaaS треба розуміти плюси та мінуси.

Питання фізичних серверів або більшого контролю, ніж дає клауд, постає, коли ми стикаємося з дуже специфічним навантаженням, яке дуже залежить від файлової системи, від того, як БД працює з тим, де фактично зберігається. В таких випадках, зазвичай, cloud-провайдери, якщо це DBaaS, мало що дають Вам зробити. Коли вже треба «лізти» в Linux налаштування, тоді для таких кейсів, DBaaS на власній інфраструктурі може бути компромісом.