3 виміри масштабування систем: чому автомасштабування — це лише частина картини

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Мене звати Віталій Жгута, і я cтарший cистемний архітектор в EPAM Україна. Хочу поділитися з вами власними спостереженнями щодо підходів до масштабування систем.

Проводячи технічні співбесіди на позиції DevOps-інженерів та System Architects, я помітив: коли ми переходимо до питань про масштабування системи, у більшості випадків розмова одразу зводиться до інфраструктури.

«Налаштуємо Auto Scaling Group», «Додамо ще подів у Kubernetes», «Піднімемо більший інстанс бази даних».

Кандидати можуть годинами захоплено розповідати про метрики горизонтального автомасштабування (HPA), конфігурації Terraform та стратегії розгортання без збереження стану (stateless). Але майже ніколи розмова не зачіпає фундаментальних вимірів масштабування: роботи зі станом, жорстких компромісів розподілених систем та бізнес-вимог. Ми почали плутати просте нарощування інфраструктурних ресурсів зі справжнім архітектурним масштабуванням.

Навіщо ми взагалі масштабуємо системи?

Перш ніж говорити про те, як масштабувати, варто згадати, чому ми це робимо. Все починається не з метрик використання процесора, а з бізнесу. Точніше — з SLA (Service Level Agreement), угоди про рівень послуг між нами та нашими клієнтами.

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

• Доступність (Availability) — частка часу, коли система готова обробляти запити (ті самі «дев’ятки»).
• Надійність (Reliability) — здатність системи виконувати свої функції без збоїв протягом заданого проміжку часу.
• Цілісність даних (Data Integrity) — гарантія того, що дані не будуть втрачені або спотворені.
• Продуктивність (Performance / Latency) — швидкість відгуку системи на дії користувача. Навіть доступна система стає «неробочою» для клієнта, якщо сторінка вантажиться 10 секунд.
• Масштабованість (Scalability) — здатність системи зберігати продуктивність при зростанні навантаження (без деградації сервісу).
• Безпека (Security) — захист даних та інфраструктури від несанкціонованого доступу, що також часто прописується в Enterprise-контрактах.

Коли кількість користувачів зростає, підтримувати ці вимоги (особливо масштабованість та доступність) в межах одного сервера стає фізично неможливо. Щоб виконати умови SLA під навантаженням, ми змушені розподіляти систему на кілька вузлів.

CAP-теорема: фундаментальні обмеження

Щойно ми переходимо від одного сервера до розподіленої системи (мережі серверів), масштабування перестає бути просто «додаванням заліза». У гру вступають фундаментальні закони обчислювальної техніки. Найвідоміший із них — CAP-теорема. Вона стверджує, що в будь-якій розподіленій системі неможливо одночасно гарантувати більше двох із трьох властивостей:

1. Узгодженість (Consistency) — кожен клієнт бачить однакові, найновіші дані (або отримує помилку).
2. Доступність (Availability) — успішний запит завжди отримує відповідь (без гарантії, що дані найновіші, наприклад, система може віддати застарілий кеш).
3. Стійкість до розділення (Partition tolerance) — система продовжує працювати навіть у разі втрати зв’язку між її вузлами.

Ключовий момент, який часто втрачається: у реальному світі мережі завжди можуть розірватися або працювати із затримками. Тому Partition tolerance — це не опція, а даність. Оскільки уникнути проблем із мережею неможливо, інженерам завжди доводиться робити важкий вибір: коли вузли втрачають зв’язок один з одним, ми маємо зупинити систему, щоб не віддати старі дані (обрати Consistency), або продовжувати відповідати на запити, ризикуючи віддати неактуальну інформацію (обрати Availability)?

Саме цей вибір, зумовлений нашим SLA (що для бізнесу важливіше саме зараз: гарантувати точність даних чи залишатися доступним для користувачів?), диктує всю подальшу архітектуру. І ось тут ми підходимо до головного питання: якими інструментами ми можемо досягти цих цілей?

Три осі масштабування: AKF Scale Cube

Щоб розібратися, як саме ми приймаємо ці архітектурні рішення, зручно використовувати ментальну модель, відому як AKF Scale Cube. Давайте спробуємо поглянути на неї через класичну задачу з проєктування систем: сервіс коротких посилань на кшталт Bitly. Я свідомо беру банальний і знайомий усім приклад, щоб ми не відволікалися на складну бізнес-логіку, а сфокусувалися виключно на осях масштабування.

Функціонально все просто:

• Користувач надсилає довгий URL.
• Система генерує короткий ідентифікатор (ID).
• Під час переходу за коротким посиланням відбувається перенаправлення.
• Додатково — збирається аналітика.

Коли наша система опрацьовує 10–20 тисяч запитів на секунду (RPS), усе доволі тривіально.

Архітектура:

• API без збереження стану (Stateless)
• Балансувальник навантаження
• Кілька екземплярів застосунку
• Одна реляційна база даних
• Кеш (наприклад, Redis) для популярних посилань

Вісь X: Клонування (Горизонтальне масштабування)

Коли зростає трафік, ми просто йдемо в конфігурацію і змінюємо кількість реплік із 3 на 30, або налаштовуємо автомасштабування. Це працює, доки вузьким місцем є процесор (CPU), оперативна пам’ять (RAM) чи мережа на рівні застосунку.

Збільшуючи кількість екземплярів застосунку за балансувальником, ми застосовуємо горизонтальне масштабування (рух по осі X). Це наше перше рішення для підтримки Доступності та Продуктивності з нашого SLA. Якщо один вузол падає — трафік йде на інші. Якщо користувачів стає більше — ми просто додаємо вузли, і затримка (latency) залишається низькою.

Цей підхід дає швидкий ефект і вимагає мінімальних змін у коді. Це найдешевший спосіб виграти час. Але згодом, коли клонів стає занадто багато, система впирається в нове обмеження — усі екземпляри застосунку починають жорстко конкурувати за ресурси єдиної бази даних (запис нових посилань, оновлення лічильників, транзакції). Масштабування самої бази (наприклад, створення read-реплік) рятує лише тимчасово.

Вісь Y: Функціональна декомпозиція

Коли навантаження збільшується до сотень тисяч запитів на секунду і додається важка аналітика, моноліт з єдиною базою більше не виживає. Щоб виконати SLA, система логічно розділяється на незалежні домени:

• Сервіс перенаправлень (Redirect Service) — максимально легкий, оптимізований тільки для читання.
• Сервіс створення посилань (Shortening Service) — важчий компонент, який відповідає за генерацію та перевірку нових ID.
• Сервіс аналітики (Analytics Service) — оброблення подій переходів (через асинхронний конвеєр або чергу).

Тепер ми ізолюємо різні типи навантаження (великий обсяг запису від великого обсягу читання) і можемо масштабувати ці компоненти незалежно по осі X. З погляду SLA ми захищаємо масштабованість та надійність. Наприклад, якщо сервіс аналітики «впаде» або почне гальмувати, базовий функціонал перенаправлень (Redirect Service) продовжить працювати швидко і без збоїв.

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

Вісь Z: Сегментування даних (sharding)

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

З’являється потреба у:

• Сегментуванні (sharding) за хешем ідентифікатора (hash(short_id)).
• Регіональному розподілі (Європа / США / Азія).
• Ізоляції «гарячих» корпоративних клієнтів (Enterprise) на окремих кластерах.
• Окремому сховищі даних (Data Warehouse) для аналітики.

Щоб опрацювати запит, система повинна: визначити, у якому саме сегменті (shard) лежать потрібні дані; маршрутизувати запит до правильного кластера; врахувати різні профілі затримок клієнтів у різних регіонах (вимога продуктивності/latency з SLA). З’являються абсолютно нові інженерні виклики: перебалансування даних, складна аналітика між сегментами, забезпечення узгодженості та відновлення після збоїв на рівні окремих сегментів.

Це вже рух по осі Z. Він докорінно змінює модель даних, і саме тут ми зіштовхуємося з CAP-теоремою у повному обсязі. Наприклад, під час регіонального сегментування (sharding) виникає проблема глобальної унікальності ID. Якщо між дата-центрами в США та Європі зникає зв’язок (Partition), ми маємо обрати:

• Consistency (Узгодженість): заборонити створення нових посилань, доки зв’язок не відновиться (порушуємо доступність, але гарантуємо відсутність конфліктів).
• Availability (Доступність): дозволити створювати посилання локально. Ми виконуємо SLA щодо доступності, але змушені вводити регіональні префікси або складні алгоритми узгодження (eventual consistency), шукаючи баланс між вимогами щодо затримки та точністю.

Це вже не просто інфраструктурне масштабування. Це фундаментальна зміна самої топології системи.

Ціна масштабування: інфраструктура проти складності

Архітектура — це завжди про компроміси. Перехід від осі X до осей Y та Z — це не просто логічна інженерна еволюція продукту. Це фундаментальна зміна фокусу: від збільшення кількості серверів до стрімкого зростання інженерної складності, координації команд та операційного навантаження.

Рух по осі X (нарощування клонів) порівняно простий: він здебільшого вимагає лише додаткових обчислювальних ресурсів, які легко виділити або автоматизувати. Натомість рух по осях Y (мікросервіси) та Z (сегментування) привносить експоненційну складність. Це болючий рефакторинг моноліту чи бази даних, розв’язання фундаментальних проблем узгодженості (згадаймо CAP-теорему), складніший деплой та моніторинг. Зрештою, розподілена система може суттєво уповільнити час випуску нових функцій (time-to-market).

Саме тому бездумно впроваджувати мікросервіси або сегментування (sharding) лише тому, що «всі так роблять», — хибний шлях. Зріла високонавантажена система майже завжди використовує всі три осі одночасно, але робить це обґрунтовано: масштабуючи ту чи іншу площину лише еволюційно, коли вичерпано простіші варіанти, а підтримувати SLA іншими інструментами вже фізично неможливо.

Підсумки

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

Концепцію трьох осей, або AKF Scale Cube, Мартін Ебботт та Майкл Фішер запропонували ще у 2009 році. Відтоді з’явилися Kubernetes, безсерверні (serverless) платформи та потужні керовані бази даних. Інфраструктура стала значно зручнішою, але фундаментальні обмеження розподілених систем нікуди не зникли.

Саме тому автомасштабування не вирішує проблему конкуренції за дані; мікросервіси самі по собі не гарантують відсутності вузьких місць; а керовані хмарні сервіси не скасовують законів фізики, мережевих затримок та жорстких компромісів CAP-теореми.

Щоб приймати справді зрілі архітектурні рішення, варто спиратися на кілька базових принципів:

1. Починайте з бізнесу (SLA): Перш ніж масштабувати, зрозумійте, що саме болить. Ми рятуємо доступність? Нам не вистачає продуктивності (latency)? Чи система не може перетравити новий обсяг даних (масштабованість)?
2. Визнайте обмеження (CAP): Змиріться з тим, що мережа буде падати (partition tolerance). Визначте разом із бізнесом, чим ви пожертвуєте в цей момент: свіжістю даних (consistency) чи можливістю обслуговувати клієнтів (availability).
3. Застосовуйте AKF Scale Cube для вибору стратегії: Запитайте себе: ми зараз вперлися в обчислювальні ресурси (вісь X), у конкуренцію за спільну базу даних через монолітну логіку (вісь Y) чи в межі єдиного сховища на глобальному рівні (вісь Z)?
4. Не ускладнюйте передчасно: Для 80% проєктів грамотного руху по осі X вистачить на роки. Рухайтеся по осях Y та Z лише тоді, коли біль від їх впровадження менший за біль від неможливості виконати SLA поточними засобами.

Для більшості продуктів руху по осі X буде цілком достатньо протягом усього їхнього життєвого циклу. І це нормально. Але коли система починає рости, розуміння вимог SLA, обмежень CAP-теореми та інших вимірів масштабування дає змогу приймати інженерні рішення усвідомлено, а не реактивно.

Можливо, саме в цьому і полягає ключова різниця між інфраструктурним мисленням та архітектурним.