Никита Кузнецов — про фізичну інфраструктуру, яка залишається під віртуальними машинами та хмарними сервісами.
Слово «хмара» настільки міцно увійшло до IT-лексикону, що поступово почало створювати хибне відчуття: ніби сучасному цифровому продукту фізичний комп’ютер уже майже не потрібен. Розробник відкриває панель провайдера, обирає процесор, пам’ять і диск, за кілька хвилин отримує віртуальну машину — і залізо наче зникає з рівняння.
Насправді воно нікуди не зникло. Застосунок, як і раніше, виконується на процесорах, дані записуються на накопичувачі, запити проходять через реальні мережеві пристрої, а обладнання стоїть у конкретних дата-центрах. Змінився передусім спосіб доступу до цих ресурсів. Замість купівлі та обслуговування власного сервера компанія орендує потрібну їй частину інфраструктури й отримує зручний програмний шар керування.
IT-інженер Никита Кузнецов вважає цю різницю принциповою. За його словами, проблеми починаються не тоді, коли бізнес використовує хмару чи віртуальні сервери, а коли зручна абстракція поступово підміняє розуміння того, що знаходиться під нею.
«Поки сервіс відкривається, нікого не хвилює, чия це шафа і скільки в ній полиць. Починає хвилювати, коли полиця ламається, а ключ від шафи виявляється в іншої людини».
Для розробника можливість не думати щодня про конкретний диск або фізичний сервер — величезна перевага. Для інженера, який відповідає за стійкість системи, повністю забути про них уже небезпечно. У момент аварії абстрактні поняття дуже швидко закінчуються: з’ясовується, де фізично знаходяться дані, які обмеження встановив провайдер, хто відповідає за інфраструктуру і що саме перестало працювати.
Віртуальний сервер не стає окремим комп’ютером
Никита Кузнецов пояснює, чому віртуальний сервер залишається частиною фізичної інфраструктури, навіть якщо для користувача виглядає окремою машиною.
З фізичним сервером усе відносно зрозуміло. Це конкретна машина з певним процесором, обсягом оперативної пам’яті, накопичувачами та мережевими інтерфейсами. Вона має межу продуктивності, займає місце у стійці, споживає електроенергію й може фізично вийти з ладу.
Віртуальна машина для користувача виглядає майже так само. У неї теж є процесорні ядра, пам’ять, диск, операційна система та мережева адреса. На неї можна встановити застосунок і поводитися з нею майже як з окремим сервером.
Але фізично окремою машиною вона від цього не стає.
Гіпервізор дає змогу розділити ресурси одного фізичного хоста між кількома віртуальними машинами. Для клієнта це зручно: йому не потрібно купувати цілий сервер, якщо потрібна лише частина його потужності. Провайдер, своєю чергою, може ефективніше розподіляти обчислювальні ресурси між більшою кількістю клієнтів.
Кузнецов пропонує сприймати віртуальний сервер не як зменшену копію фізичного комп’ютера, а як певний набір гарантованих або наданих ресурсів.
«Віртуальний сервер — це не маленький комп’ютер. Це договір: вам обіцяють шматок чужого комп’ютера і роблять вигляд, ніби цей шматок цілий».
У звичайній роботі ця різниця справді майже непомітна. Віртуальна машина завантажується, застосунок працює, диск доступний, пам’ять виділена. Саме тому команда швидко звикає сприймати її як повністю самостійний об’єкт.
Різниця стає помітною в нестандартній ситуації. Провайдер може переносити віртуальну машину між фізичними хостами, проводити технічні роботи, змінювати особливості платформи або запроваджувати обмеження на певні операції. На продуктивність можуть впливати й характеристики фізичної інфраструктури, яких користувач безпосередньо не бачить.
При цьому вихідний код застосунку може взагалі не змінитися.
Саме такі ситуації особливо неприємні під час діагностики: розробники шукають причину в останньому релізі, хоча змінився не застосунок, а середовище, у якому він працює.
Чому віртуальні машини непомітно розмножуються
Фізичне обладнання має природний обмежувач — його потрібно купити, привезти, встановити й підключити. Створення віртуальної машини займає хвилини.
Це одна з головних переваг хмарної інфраструктури й водночас джерело доволі типової проблеми.
Тестовий сервер створюють на кілька днів. Потім з’являється окрема машина для інтеграції. Далі комусь потрібна тимчасова копія production-середовища. Ще одну піднімають для експерименту, який планували завершити до п’ятниці. За кілька місяців частина цих ресурсів продовжує працювати просто тому, що ніхто не взяв на себе їх видалення.
З’являється інфраструктурний «зоопарк», де назви на кшталт test, test-new, stage-old або prod-copy вже мало кому щось пояснюють.
Тому Кузнецов звертає увагу не лише на технічний, а й на організаційний бік віртуалізації. Ресурс повинен мати зрозумілого власника, призначення та життєвий цикл. Якщо команда не може швидко визначити, навіщо існує конкретна віртуальна машина і що станеться після її вимкнення, проблема вже з’явилася — навіть якщо сервер поки працює справно.
Фізичний сервер складно забути хоча б тому, що він займає місце. Віртуальний здатен роками нагадувати про себе лише рядком у щомісячному рахунку.
Хмара — це не відсутність інфраструктури, а інший спосіб нею користуватися
Кузнецов не протиставляє хмарні рішення власному обладнанню. Хмара має очевидні переваги: ресурси можна отримувати значно швидше, масштабувати за потреби, розподіляти між регіонами й не будувати власний дата-центр для кожного нового проєкту.
Але зручність не скасовує залежності.
«Хмара не знаходиться в хмарі. Вона знаходиться в чужій будівлі, на чужих дисках, за чужими правилами й із вашою карткою на підписці».
Це формулювання навмисно спрощує будову хмарних платформ, але добре показує базовий принцип. Компанія орендує обчислювальні потужності й водночас приймає правила середовища, у якому ці потужності надаються.
У хмарного провайдера є квоти, тарифи, регіони доступності, правила обслуговування, API, система білінгу та власні технічні обмеження. Тому перенесення інфраструктури в хмару не означає зникнення інфраструктурних ризиків. Частина з них просто змінює форму.
З власним сервером команда думає про диски, живлення, мережу та резервне обладнання. У хмарі до цього додаються питання іншого рівня: що станеться в разі недоступності регіону, наскільки інфраструктура залежить від конкретних сервісів провайдера, чи можна відновити її в іншому місці, які ресурси оплачуються просто зараз і чи справді всі вони потрібні.
Особливо швидко ця проблема стає помітною у витратах. Хмарний ресурс легко створити саме тому, що його створення не відчувається як купівля обладнання. Але забутий диск, резервна копія, невикористовувана віртуальна машина або надлишкова конфігурація продовжують тарифікуватися.
«Хмара вигідна тим, хто рахує. Вона небезпечна для тих, хто плутає кнопку “створити” з тим, що система стала безсмертною».
Тому правильне питання до хмарної архітектури звучить не «наскільки швидко ми можемо підняти ще один сервер», а «чи розуміємо ми, які ресурси використовуємо, навіщо вони потрібні й що робитимемо, якщо звичний спосіб їх отримання стане недоступним».
Чому три сервери не обов’язково надійніші за один
Никита Кузнецов — про масштабування, балансування навантаження та проблеми, які виникають, коли кілька серверів мають працювати як єдина система.
Одна з найбільш оманливих ідей масштабування виглядає цілком логічно: якщо одному серверу важко, потрібно додати другий, а потім третій.
Іноді саме це й потрібно. Але збільшення кількості машин вирішує проблему лише тоді, коли сама система вміє працювати з кількома екземплярами.
«Масштаб без порядку гірший за тісноту. У тісноті хоча б зрозуміло, кого звинувачувати. У трьох машинах без господаря винні всі й ніхто».
Щойно серверів стає кілька, виникають нові питання. Куди спрямовувати вхідні запити? Як балансувальник визначає, що один з екземплярів перестав нормально відповідати? Де зберігається стан користувача? Чи можна надіслати наступний запит на іншу машину? Що відбувається з локальними файлами? Чи однакова версія застосунку розгорнута на всіх екземплярах?
Якщо ці питання не вирішені заздалегідь, додатковий сервер може не підвищити надійність, а створити нові варіанти відмови.
На одній машині може залишитися попередня версія застосунку, тоді як на двох інших уже працює нова. Один екземпляр продовжує вважатися справним для балансувальника, хоча фактично не здатен нормально обслуговувати користувачів. Файл записується локально на один сервер, а наступний запит потрапляє на інший і намагається знайти його там. Кеші розходяться. Фонові завдання запускаються одночасно на кількох машинах і починають виконувати одну й ту саму роботу кілька разів.
Ззовні користувач бачить лише нестабільний сервіс: одна сторінка відкрилася, наступна — ні, після оновлення все знову запрацювало.
Усередині системи проблема значно складніша — різні екземпляри перестали поводитися як єдине ціле.
Тому Кузнецов пропонує вимірювати масштабування не кількістю серверів, а здатністю архітектури узгоджено використовувати ці сервери. Нова машина має сенс лише тоді, коли заздалегідь зрозуміло, яку роботу вона отримує і як система поводитиметься в разі її появи або зникнення.
Один і той самий завислий сайт може означати зовсім різні аварії
Користувач практично завжди описує технічну проблему однаково: «сайт гальмує», «нічого не завантажується», «все лежить».
Але однаковий зовнішній симптом може мати зовсім різні причини. Саме тут, на думку Кузнецова, починається нормальна інженерна діагностика.
«Користувач бачить один індикатор завантаження. Інженер зобов’язаний бачити три різні могили. Інакше ви почнете докуповувати пам’ять там, де закінчився диск».
Уявімо три прості сценарії.
У першому закінчується місце на диску. Застосунок ще здатен відповідати на частину запитів, але вже не може нормально записувати нові дані. Причиною можуть стати розрослі логи, тимчасові файли, резервні копії або база даних, розмір якої ніхто вчасно не проконтролював.
У другому закінчується оперативна пам’ять. Система починає активніше використовувати swap, різко втрачає продуктивність або операційна система завершує процеси, яким більше неможливо виділити необхідний обсяг пам’яті.
У третьому процесор постійно працює під високим навантаженням. Сервер формально живий, пам’ять доступна, диск не заповнений, але запити обробляються надто повільно. Причиною може бути важкий звіт, невдалий алгоритм, сплеск трафіку або фонове завдання, що збіглося в часі з піковим навантаженням.
Для людини перед екраном результат справді майже однаковий: застосунок не працює нормально.
Для інженера це три різні аварії й три різні способи усунення проблеми.
Саме тому просте збільшення тарифу далеко не завжди вирішує проблему. Додаткова пам’ять не звільнить заповнений диск. Потужніший процесор не виправить неконтрольоване зростання логів. Новий сервер не усуне витік пам’яті, якщо та сама помилка автоматично переїде на нього разом із застосунком.
Спочатку необхідно зрозуміти характер відмови. Лише після цього має сенс збільшувати ресурси.
Зелений статус сервера ще нічого не гарантує
Никита Кузнецов про моніторинг інфраструктури: зелений статус машини ще не означає, що сервіс справді працює для користувача.
Панель моніторингу може показувати, що машина працює, хоча для користувача сервіс уже фактично недоступний.
Сервер увімкнений. Процес існує. Перевірочний endpoint відповідає. Формально все зелене.
При цьому база може відповідати настільки повільно, що нормальна робота неможлива. Диск може бути майже заповнений. Черга завдань — зростати швидше, ніж оброблятися. Окремий критичний користувацький сценарій — завершуватися помилкою.
Тому моніторинг інфраструктури не повинен обмежуватися питанням «сервер живий чи ні».
Потрібно бачити використання диска, пам’яті та процесора, затримки, помилки, мережеву активність, стан черг, доступність залежностей і, що особливо важливо, виконання реальних користувацьких операцій.
Якщо команда дізнається про проблему лише після скарги клієнта, моніторинг фактично зафіксував не початок аварії, а її наслідки.
Кузнецов формулює це простіше: перш ніж купувати дорожчий тариф, потрібно вміти назвати, який саме ресурс закінчився і чому.
Контейнер вирішує одну проблему, але не скасовує сервер
Никита Кузнецов — про контейнери та інфраструктуру, яка все одно залишається під програмним шаром.
З контейнерами сталася схожа історія, що й із хмарою. Зручна технологія поступово обросла очікуваннями, яких вона від початку не мала виконувати.
Проблема, яку контейнеризація справді допомагає вирішувати, добре відома практично кожному розробнику: «у мене працює».
Застосунок рідко складається лише з власного вихідного коду. Йому потрібні конкретні бібліотеки, системні залежності, змінні середовища, налаштування та певна структура файлів. На комп’ютері розробника все це вже є, тому програма запускається. На сервері середовище трохи відрізняється — і починаються проблеми.
Контейнер дає змогу упакувати застосунок разом із суттєвою частиною необхідних йому умов і відтворювати це середовище значно передбачуваніше.
«Контейнер не робить програму розумнішою. Він робить її переїзд меншою брехнею. Ви пакуєте не код. Ви пакуєте умови, у яких код погоджується жити».
Це справді серйозна перевага. Але контейнер не створює обчислювальні ресурси з повітря.
Під ним усе одно знаходиться операційна система. Ще нижче — віртуальна або фізична машина. На самому нижньому рівні залишаються процесор, оперативна пам’ять, накопичувач і мережа.
Якщо застосунок безконтрольно витрачає пам’ять, контейнер не виправить це автоматично. Якщо програма заповнює диск логами, упаковка не зробить диск нескінченним. Якщо обчислення повністю завантажують процесор, контейнеризація сама по собі не додасть продуктивності.
Ба більше, контейнерами теж потрібно керувати. Треба розуміти, які образи використовуються, де вони зберігаються, які версії запущені, які обмеження ресурсів установлені й що відбувається зі старими екземплярами після оновлення.
Контейнер робить середовище застосунку більш відтворюваним. Він не скасовує інфраструктуру, на якій це середовище існує.
Надійність починається з розуміння того, що знаходиться під інтерфейсом
Якщо прибрати термінологію, все виглядає доволі приземлено.
Фізичний сервер — конкретна машина. Віртуальний сервер — виділена програмним способом частина ресурсів фізичної інфраструктури. Хмара — модель отримання цих ресурсів у зовнішнього провайдера разом із його сервісами та правилами. Контейнер — спосіб упакувати застосунок і його середовище так, щоб зробити запуск передбачуванішим.
Жодна з цих технологій сама по собі не робить систему надійною.
Надійність з’являється тоді, коли команда розуміє межі кожного шару й уміє відповісти на незручні запитання: де знаходяться дані, які ресурси обмежені, хто відповідає за інфраструктуру, що станеться в разі відмови конкретного компонента, чи можна відновити сервіс і наскільки швидко стане відомо про проблему.
Саме тому Никита Кузнецов пропонує починати розмову про інфраструктуру не з назви хмарного провайдера, панелі керування чи модної технології.
«Інфраструктура починається не з панелі й не зі слова “хмара”. Вона починається з питання: що в нас справжнє, що орендоване і яка смерть буде першою».
У цьому формулюванні немає заклику повертати сервери з дата-центрів у власний підвал або відмовлятися від віртуалізації. Навпаки, сучасні інфраструктурні інструменти дають невеликій команді змогу робити те, для чого раніше були потрібні окремі приміщення, обладнання та фахівці.
Але що простішою стає кнопка «створити», то важливіше не плутати простоту інтерфейсу з простотою самої системи.
За віртуальною машиною залишається фізичний хост. За контейнером — операційна система та сервер. За хмарним регіоном — дата-центри. За красивою панеллю із зеленими індикаторами — кінцеві диски, пам’ять, процесори, мережеві з’єднання, квоти й домовленості.
Поки все працює, цей ланцюжок справді можна майже не помічати. Під час аварії він проявляється цілком.
