Вибір ІТ-інфраструктури вже давно не зводиться до простого питання, який сервер орендувати. У бізнесу є хмарні платформи, віртуальні та виділені сервери, власне обладнання, керовані сервіси. Нарешті, все це можна комбінувати.
Універсального варіанту тут немає і бути не може, оскільки для кожного бізнесу існують свої вимоги до інформаційних систем. Наприклад, інтернет-магазину з різкими добовими коливаннями відвідуваності потрібна одна архітектура, а великій корпоративній системі з передбачуваним навантаженням — зовсім інша.
Тому підходити до вибору інфраструктури слід, починаючи з розуміння завдань бізнесу.
Спочатку вимоги, потім характеристики
Найбільш безглуздою помилкою буде відразу починати рахувати процесорні ядра та гігабайти пам’яті, оскільки без розуміння проєкту ці цифри мало що означають.
Спочатку варто визначити такі найважливіші параметри, як характер навантаження, допустимий час простою, темпи зростання даних та вимоги конкретних додатків. Причому два проекти з, здавалося б, однаковим споживанням ресурсів насправді можуть вимагати зовсім різного підходу до архітектури, адже корпоративний сайт здатний кілька хвилин прожити без відвідувачів майже без наслідків, а ось для системи, через яку співробітники оформлюють замовлення або працюють зі складом, такий самий простой уже перетворюється на проблему, причому цілком відчутну, фінансову.
Також не варто забувати, що існує сезонність або сплески активності, пов’язані з рекламними кампаніями та загалом маркетинговою стратегією компанії. Так, звичайний інтернет-магазин під час рекламної кампанії може отримати навантаження, яке в кілька разів перевищує звичайне, тоді як внутрішня бухгалтерська система роками працює приблизно в одному режимі, адже кількість бухгалтерів змінюється рідко.
На основі цієї первинної інформації вже можна обирати технологію.
Хмара — коли навантаження постійно змінюється
Головна перевага хмарної інфраструктури — це можливість швидко, буквально «на льоту», змінювати конфігурацію. Бізнес отримує доступ до обчислювальних ресурсів провайдера, які підключає за потреби або відключає, коли сплеск активності минув.
Це зручно для сервісів та проєктів, що активно зростають і мають помітні стрибки навантаження, які ще не вийшли на плато будь-якого стандартного навантаження. Разом із самими хмарними віртуальними машинами можна використовувати балансувальники, об’єктні сховища, керовані бази даних та інші хмарні компоненти, що надаються великими хмарними провайдерами.
Але будь-яка гнучкість поступово ускладнює архітектуру. З’являються окремі мережі, правила доступу, сховища та політики резервування. Витрати теж стає складніше прогнозувати, оскільки, здавалося б, підсумковий рахунок залежить від фактичного споживання ресурсів і використовуваних сервісів, але ось будь-який додатковий сервіс також починає вимагати оплати. І в підсумку, наприкінці місяця, ви можете отримати рахунок, який суттєво відрізнятиметься від ваших очікувань.
Виходячи з усього сказаного, перенесення звичайного корпоративного сайту в складну хмару саме по собі не дає практично жодних переваг. Можливості платформи мають сенс лише тоді, коли проект дійсно широко їх використовує.
Віртуальний сервер — коли потрібна проста інфраструктура
Для невеликих і середніх проєктів часто вистачає лише однієї віртуальної машини з власною операційною системою та адміністративним доступом для організації всього бізнес-процесу.
На такому сервері можна розмістити сайт, CRM, API, базу даних або внутрішній додаток. Витрати при цьому абсолютно прогнозовані й незмінні, а сама архітектура залишається зрозумілою.
Наприклад, компанії потрібен WordPress-сайт, невелика база даних PostgreSQL та якийсь внутрішній сервіс. Купувати під таке навантаження ресурси цілої фізичної машини — надмірно. А ось VPS-сервер із відповідною кількістю процесорних ядер, оперативної пам’яті та швидким накопичувачем обійдеться набагато дешевше й залишить запас і можливості для майбутнього зростання.
Інша справа, що вертикальне масштабування має свої межі, і якщо ваш додаток продовжує активно зростати, то з часом доведеться все-таки розподілити його компоненти між кількома вузлами або перейти до іншої архітектури.
Виділений сервер — коли ресурси потрібні постійно
У фізичного виділеного сервера зовсім інший сценарій використання. Його процесор, пам’ять і накопичувачі повністю перебувають у розпорядженні одного клієнта.
Такий варіант підходить для постійного високого навантаження, великих баз даних, інтенсивної роботи з диском, віртуалізації або конфігурацій зі специфічними вимогами до обладнання.
Припустимо, база даних цілодобово активно використовує процесор і дискову підсистему. Її навантаження давно відоме і змінюється незначно. У такій ситуації окрема фізична машина може виявитися простішою та економічно вигіднішою, ніж велика конфігурація у публічній хмарі.
Але й тут є свої мінуси, оскільки зворотним боком є швидкість масштабування такої інфраструктури. Ресурси фізичного сервера неможливо збільшити кількома кліками, і іноді може знадобитися модернізація машини з її короткочасним вимкненням або підключення додаткового вузла.
Щоб ви могли наочніше уявити собі всі описані варіанти, ми звели їх у таку просту й наочну таблицю:
| Параметр | Хмара | Віртуальний сервер | Виділений сервер |
|---|---|---|---|
| Масштабування | Швидке | Обмежене ресурсами платформи | Вимагає додаткового обладнання |
| Передбачуваність витрат | Середня | Висока | Висока |
| Складність інфраструктури | Від низької до високої | Зазвичай низька | Середня |
| Доступ до фізичних ресурсів | Ні | Ні | Повний |
| Типове навантаження | Змінне | Невелике та середнє | Високе та стабільне |
Але не варто сприймати цю таблицю як жорстку рекомендацію, це скоріше орієнтир, адже, по суті, один і той самий проєкт іноді можна успішно розмістити на будь-якій із цих платформ.
То як же вибрати відповідну архітектуру
Ціна сервера сама по собі мало що говорить про вартість інфраструктури. До щомісячної оренди можуть додаватися резервні копії, ліцензії, додаткове сховище, моніторинг та робота адміністратора. Іноді з’являються платний трафік або окремі сервіси безпеки. У результаті недорога на перший погляд конфігурація через кілька місяців може виявитися зовсім не такою вже й дешевою.
Варто враховувати й вартість людського часу, адже складну систему потрібно налаштовувати, оновлювати, контролювати та відновлювати після збоїв. Якщо заради економії на оренді компанія отримує інфраструктуру, якою постійно займається дороговартісний DevOps-інженер, то різниця швидко нівелюється. Тому при порівнянні варіантів корисніше буде підрахувати загальні витрати на експлуатацію за рік або інший обраний період.
Надійність теж пов’язана з архітектурою, а не лише з обраною платформою. Один сервер залишається єдиною точкою відмови незалежно від його потужності та місця розміщення. Резервні копії, звісно, допомагають відновити дані, але на це знадобиться час. Реплікація на другий вузол скорочує час простою, однак збільшує вартість і складність системи.
Тут бізнесу корисно заздалегідь визначити допустимі наслідки аварії. Наприклад, якщо ваш сайт може бути недоступним протягом години, а дані легко відновити з нічної копії, то будувати складний відмовостійкий кластер навряд чи раціонально. А ось для сервісу, зупинка якого одразу блокує продажі або роботу співробітників, вимоги будуть набагато суворішими.
У міру зростання проєкту змінюється й сама архітектура. Спочатку сайт, база даних і внутрішній додаток цілком можуть працювати на одній машині, але пізніше база починає споживати більше пам’яті, додаток сильніше навантажує процесор, а резервні копії займають дедалі більше місця. У цей момент окремі компоненти можна розподілити між різними системами.
Причому не обов’язково використовувати для них однакову платформу. Додаток може працювати на віртуальному сервері, навантажена база даних — на фізичній машині, а резервні копії краще зберігати в об’єктному сховищі в хмарі. Тимчасові додаткові потужності під час пікових навантажень можна отримувати з хмари. Виходить гібридна схема, де для кожного завдання обирається відповідне середовище.
Але складність має з’являтися слідом за реальною потребою, оскільки поділ невеликого проєкту на безліч серверів збільшує кількість мережевих зв’язків, налаштувань і компонентів, за якими потрібно стежити. А в результаті архітектура стає дорожчою в обслуговуванні ще до того, як бізнес отримує від неї помітну користь.
Тому розумною відправною точкою буде вибір найпростішої конфігурації, яка справляється з поточним навантаженням і залишає зрозумілий шлях для зростання. Під час вибору варто перевірити лише кілька сценаріїв: що станеться у разі відмови сервера, скільки часу займе відновлення, куди можна перенести окремий компонент і що доведеться змінювати, якщо через рік навантаження збільшиться вдвічі.
Такі питання зазвичай дають набагато більше корисної інформації, ніж порівняння процесорів і кількості гігабайтів пам’яті. Хороша архітектура має вирішувати сьогоднішнє завдання і при цьому не заганяти бізнес у технічний тупик.
Підсумовуючи, можна сказати, що хороша та правильно побудована ІТ-інфраструктура відповідає реальним вимогам бізнесу й не створює ані зайвої технічної складності, ані зайвих витрат.
