Multi-tenancy, коли один екземпляр або кілька екземплярів однієї або кількох програм працюють в одному спільному середовищі інфраструктури, не є новою концепцією. Це спростило як апаратне забезпечення, так і навички та ресурси, необхідні для керування середовищами, повідомляє DevOps.
Із розвитком програмного забезпечення як послуги (SaaS) у сучасних приватних і публічних хмарних середовищах мультитенантний доступ (multi-tenant) став звичайною та важливою функцією. Це дозволяє хмарним компаніям масштабуватися, а клієнтам – заощаджувати кошти, фактично об’єднуючи ресурси. Оскільки все більше застосунків потребують все більше і більше даних, multi-tenant тепер є основною функцією на рівні бази даних.
Але коли у вас є багато різних програм, які працюють в одній інфраструктурі та мають доступ до однієї бази даних, як запобігти впливу однієї програми на продуктивність даних іншої? І як ви визначаєте з базової інфраструктури бази даних, які орендарі отримають яку інфраструктуру та з яким рівнем продуктивності?
Ось погляд на рушійні сили, що стоять за сьогоднішніми потребами в даних у реальному часі, і на те, як вони впливають на керування архітектурою multi-tenant-даних.
SLA є основою мультитенантного керування даними
Усі хочуть швидшої продуктивності та більш стійких систем. Ми нетерплячі, тому надійна продуктивність у реальному часі забезпечує значні конкурентні переваги для бізнесу. Проте кожен орендар не вимагає однакового рівня продуктивності.
Угоди про рівень послуг (SLA) остаточно регулюють ресурси, що надаються орендарю. В одному випадку (наприклад, для біржової торгівлі) реальний час може знадобитися вимірювати в субмілісекундах, а в інших – у субсекундах (наприклад, під час переказу коштів Zelle). Саме тут розробники, архітектори й оператори співпрацюють із бізнесом, щоб зрозуміти його фактичні потреби та створити систему, яка може забезпечити SLA, використовуючи мінімально можливу кількість ресурсів.
Змішане робоче навантаження та проблема «шумного сусіда»
Щойно робочі навантаження розподіляються, одна програма може швидко захоплювати та використовувати ресурси таким чином, щоб впливати на інші програми. Програми, які часто називають «шумним сусідом», можуть значно перешкоджати виконанню SLA в режимі реального часу, коли мультитенантні програми спільно використовують інфраструктуру. Наприклад, один вузол у кластері бази даних стає сильно завантаженим, що впливає на продуктивність інших вузлів, а це призводить до пропуску SLA.
Як правило, кілька віртуальних машин (VМ) розміщені на одній фізичній машині або вузлі, але спільно використовують системні ресурси (тобто процесор, мережу, сховище тощо) з іншими VМ. Програми можуть надмірно використовувати ці спільні ресурси, впливаючи на інші програми, а іноді навіть на саму базу даних.
Таке надмірне використання рівня інфраструктури (у цьому випадку спільне використання обчислювальної техніки, сховища, мережевих черг тощо) призводить до низької продуктивності бази даних і наскрізної системи. Це як підключити 100-амперний прилад до 50-амперного ланцюга. Всі автоматичні вимикачі спрацьовують, і вся система повністю зупиняється.
Стратегії щодо максимізації продуктивності для мультитенантності баз даних
Налаштування та керування самою базою даних (а не лише інфраструктурою) з урахуванням мультитенантності може максимізувати продуктивність і дати змогу уникнути таких проблем, як «шумний сусід». Ізоляція баз даних у вашій мультитенантній архітектурі може допомогти звести до мінімуму проблеми, не пов’язані з базами даних, які можуть бути основною причиною низької продуктивності та пропуску SLA.
Почніть із вибору баз даних, які дозволяють програмам ізолювати доступ до даних на основі наборів (або таблиць, кажучи реляційною мовою), які можуть мати обмеження на зберігання. У поєднанні з обмеженнями швидкості транзакцій для кожного користувача можна гарантувати застосункам квоту ресурсів виконання. Використовуючи конфігурації квот на програму для таких елементів, як сховище і TPS (транзакцій за секунду), база даних може оцінити загальну доступну ємність у системі та переконатися, що достатньо ресурсів зарезервовано та доступно для забезпечення виконання SLA.
Зауважте, що несподівані події, які спричиняють перебалансування даних у розподіленій базі даних, наприклад збої вузлів і мережі, потребують додаткових ресурсів. Система бази даних відніме цей обсяг ресурсів із того, що доступно для програм, щоб система не перевантажувалася під час збоїв.
Підприємства також потребують дуже високої автоматизації та спостережливості, щоб швидко вирішувати негайні проблеми й мати необхідну видимість довгострокових тенденцій, які впливають на продуктивність і дотримання SLA. В іншому випадку до того моменту, коли людина помітить проблему, SLA вже може бути пропущено, і це вплине на бізнес.
Хороша спостережливість може допомогти вам зрозуміти, як використовуються дані, і створити цю автоматизацію. Оскільки все більше програм отримують доступ і використовують той самий набір даних різними способами, вам потрібні сучасні інструменти спостереження, інтегровані в базову базу даних (або сумісні з нею).
Добре розуміючи, як ваші застосунки, багаті на дані, взаємодіють з іншими клієнтами в середовищах зі змішаним навантаженням, ви можете розпочати розгортання цих стратегій, щоб переконатися, що відповідаєте всім необхідним угодам про рівень обслуговування і зберегти всі ці дані в робочому стані для бізнесу.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодну публікацію!
