Як обрати хмарного провайдера для реляційної бази даних — порівнюємо Azure та AWS

Привіт. Мене звати Костя Макаренко. Я Data Engineer у компанії SMART business. Понад 10 років працюю у сфері інформаційних технологій, зокрема з базами даних.

Останні роки в моїй роботі акцент поступово змінюється з on-prem баз даних на їхні хмарні проєкції. З кожним роком пропозиція хмарних баз даних збільшується, і стає дедалі важче серед них орієнтуватися.

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

Наразі більше ніж 50% ринку хмарних обчислень припадає на Azure та AWS, відповідно ці провайдери є лідерами світового ринку і пропонують найширший діапазон типів і варіацій реляційних баз даних.

В цій статті я надам загальне бачення пропозицій від двох провайдерів, спробую визначити точки перетину та основні відмінності в сервісах.

Загальний огляд реляційних баз даних Azure та AWS

Нижче є загальна таблиця, базуючись на ній, ми бачимо, які СУБД представлені в хмарі як сервісі (SaaS).

Представлення реляційних баз даних в хмарах

СУБД в AWS представлені в рамках єдиного сервісу RDS

Насправді під час створення екземпляра бази даних в RDS (relational data service) ви будете зустрічати особливості конкретних СУБД, а не загального сервісу RDS.

Тобто якщо ви розгортаєте MS SQL Server, вам необхідно обрати тип ліцензування — Enterprise, Standard, Express чи Web edition, обрати версію (2012-2019), диски та потужності віртуальної машини, на якій буде розгорнуто екземпляр, та сконфігурувати інфраструктуру. Якщо робота буде з іншими видами СУБД, то, відповідно, все конфігурується під конкретну СУБД з усіма її особливостями.

Таким чином, RDS здебільшого повторює і реалізує повноцінні СУБД, і під час вибору та налаштування користувачі керуються знаннями про наземні повноцінні реалізації.

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

СУБД в Azure виділені в окремі сервіси

Cервіси в Azure переважно надають змогу сконцентруватись на розробці додатків та рішень «з нуля», можуть використовуватись під різні типи навантажень з можливістю змінювати технічні характеристики залежно від інтенсивності навантажень, типу або умов. Такі зміни технічних характеристик можуть відбуватись на вимогу, автоматично або за регламентом, і ці можливості описують рівень масштабованості сервісів.

Вища здатність до масштабованості зумовлена тим, що керування інфраструктурою в більшості сервісів СУБД повністю виноситься на рівень відповідальності Microsoft, а на рівні користувача залишається тільки управління даними та додатком.

RDS також відноситься до PaaS, але, оскільки забезпечує повну сумісність з наземними екземплярами, потребує глибшого розуміння спеціаліста саме особливостей наземних повноцінних інстансів.

Хмарні сервіси СУБД в Azure мають свої підходи, підтримують повну сумісність коду, але не забезпечують повну сумісність з повноцінною версією СУБД, проєкцією якої вони є.

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

Умовно кажучи, функціонал MS SQL Server в хмарі може бути розділений на окремі послуги, які мають власні принципи ціноутворення.

Для багатьох сценаріїв «повний комплект» є дійсно надлишковим, і часто достатньо буде тільки використання функціонала бази даних, а не всіх супутніх сервісів одразу, за доступність яких клієнт так чи інакше сплачує платежі, які покриває ліцензія повноцінного інстансу.

Приклад: Гранулярність — невичерпна кількість можливих сервісів та факторів ціноутворення

Крім того, Azure має ширшу лінійку пропозицій варіантів баз даних, що належать до типів СУБД MS SQL server. Насправді це не дивно, оскільки Azure — це Microsoft, і SQL server — це також Microsoft.

Компанія намагається розширювати свою лінійку пропозицій, аби задовольнити різних користувачів з дуже різними робочими завданнями — від цілковитих новачків, які хочуть спробувати попрацювати з базами даних і зрозуміти, як це — встановити БД без зайвого клопоту, до досвідчених розробників чи адміністраторів баз даних, які обирають та досить тонко конфігурують БД під промислові навантаження.

При цьому все одно багато адміністративних питань будуть залишатися на стороні Microsoft.

Наголошую, що майже все те, що вміє робити RDS з базами даних SQL server, буде вміти і Azure, але додатково він пропонуватиме ще більше гібридних версій під різних користувачів і під різні кейси.

Може здатися, що вже в цьому буде певна надмірність та виникатимуть складнощі під час вибору типу, але це ми розберемо в наступній статті. Все ж таки в RDS більше технічних, а не бізнесових деталей.

Пропоную докладніше розглянути пропозиції Azure та AWS.

Що пропонує Microsoft у рамках Azure SQL

Моделі розгортання в Azure SQL

Що пропонує AWS

Реляційна база даних — це віртуальна машина з встановленим MS SQL Server. Між SQL Server on Azure Virtual Machines — повний мепінг, тобто приймаємо, що це тотожні сервіси (IaaS).

Далі AWS пропонує згадуваний RDS з МS SQL Server (SaaS).

Тут ви не будете керувати віртуальною машиною, але будете її обирати з-поміж багатьох типів. Необхідно розбиратися не тільки в простих та головних показниках ефективності бази даних, а саме IOPS, memory, CPU — потрібно буде розуміти характеристики віртуальних машин. Так, звісно, існує документація, але ця історія буде складнішою для чистих розробників чи аналітиків, а не профільних адмінів.

Знову ж таки, Azure також надає можливість тонко підходити до питання.

Azure має managed instance, тип Azure SQL, що найбільше відповідає RDS, де також обирається віртуальна машина. Потрібно розуміти її особливості та конфігураційні деталі, але додатково Azure SQL single database, що дійсно працює як послуга, найбільше очищена від інфраструктурних питань та є «чистим» database engine.

Узагальнюючи:

При цьому забезпечується стандарт T-SQL для всіх версій.

Для прикладу, варіанти вибору параметрів віртуальної машини (ec2) для RDS.

Позицій — сотні. Кожен інстанс має свої додаткові характеристики. Окремо обираються диски, які не корелюють з частиною інстансів.

Додатково — конфігурація самої RDS.

Частина параметрів, які конфігуруються: Allocated storage, Architecture settings, Auto minor version upgrade, Availability zone, AWS KMS key, Backup replication, Backup retention period, Backup target, Backup window, Character set, Collation, Copy tags to snapshots, Database authentication, Database management type, Database port, DB engine version, DB instance class, DB instance identifier, DB parameter group, DB subnet group, Deletion protection, Encryption, Enhanced Monitoring, Engine type, Initial database name, License, Log exports, Maintenance window, Master password, Master username, Microsoft SQL Server Windows Authentication, Multi-AZ deployment, National character set (NCHAR), Network type, Option group, Performance Insights, Provisioned IOPS, Public access, Storage autoscaling, Storage type, Time zone, Virtual Private Cloud (VPC), VPC security group (firewall).

Для деяких параметрів існують свої вкладені параметри.

На противагу — варіанти для створення Azure SQL

Azure SQL має дві загальні моделі розгортання, які класифікуються більш компактно (їх детально опишу в наступних статтях про хмарні бази).

Перша модель

Друга модель:

Тобто вибір сервісу уніфікований до типів навантаження з поступовим, за необхідності, масштабуванням.

Якщо Vcore — 1, 2, 4, 8, 16, 32 і так далі. Якщо DTU — 20, 50, 100, 200, 500, 1000 і так далі.

Звісно, існує багато деталей у виборі типу Azure SQL, велика частина яких має бізнес-контекст. Чітке розуміння бізнес-потреб є дуже важливим, адже технічні деталі інтегровані в бізнес-визначення для полегшення розуміння того, яку БД вам необхідно обрати, якщо ви не адміністратор БД, а розробник чи власник стартапу.

Це тема окремої статті, але цікаво звернути увагу на ціноутворення та вартість Azure SQL в порівнянні з аналогами за продуктивністю від інших хмарних провайдерів. Різниця в ціні на середніх та дорогих планах може перевищувати 100%, але треба розуміти, як балансувати функціональність.

Питання порівняння ціноутворення в залежності від продуктивності та функціональності планую розкрити у наступних статтях.