Что такое вертикальное масштабирование?

Что такое вертикальное масштабирование?

Вертикальное масштабирование (Vertical Scaling, Scale Up) — это увеличение мощности одного сервера путём добавления ресурсов: больше оперативной памяти (RAM), мощнее процессор (CPU), быстрее диск (SSD). Это противоположно горизонтальному масштабированию, которое предполагает добавление новых серверов.

Вертикальное vs горизонтальное масштабирование

ВЕРТИКАЛЬНОЕ МАСШТАБИРОВАНИЕ (Scale Up)

Старый сервер:        Новый сервер:
┌─────────────────┐   ┌─────────────────────┐
│ 8 GB RAM        │   │ 64 GB RAM           │
│ 4 CPU cores     │   │ 16 CPU cores        │
│ 500 GB SSD      │   │ 2 TB SSD            │
└─────────────────┘   └─────────────────────┘

ХОРИЗОНТАЛЬНОЕ МАСШТАБИРОВАНИЕ (Scale Out)

┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│ Server 1    │  │ Server 2    │  │ Server 3    │
│ 8 GB RAM    │  │ 8 GB RAM    │  │ 8 GB RAM    │
│ 4 CPU cores │  │ 4 CPU cores │  │ 4 CPU cores │
└─────────────┘  └─────────────┘  └─────────────┘
         ↓               ↓                ↓
              Load Balancer

Преимущества вертикального масштабирования

# 1. ПРОСТОТА РЕАЛИЗАЦИИ
# Не нужно менять код приложения
# Не нужна синхронизация между серверами

# Пример: приложение работает с БД
from django.db import connections

def get_database_pool():
    # Просто используем одно соединение
    db = connections['default']
    return db.connection

# При вертикальном масштабировании
# код не меняется, растёт мощность сервера

# 2. МЕНЬШЕ СЛОЖНОСТИ
# Нет нужды в Load Balancer
# Нет проблем с синхронизацией кеша
# Нет race conditions между серверами

class UserCache:
    _cache = {}  # Local cache
    
    @classmethod
    def get(cls, user_id):
        return cls._cache.get(user_id)
    
    @classmethod
    def set(cls, user_id, data):
        cls._cache[user_id] = data

# На одном сервере - всё просто
# На нескольких - нужен Redis

Недостатки вертикального масштабирования

# 1. ОГРАНИЧИВАЕТСЯ ТЕХНИЧЕСКИ
# Есть максимальный размер одного сервера
# AWS: max 768 GB RAM, Intel: max ~200+ cores на одном чипе

# 2. ДОРОГО
# Стоимость растёт экспоненциально

def calculate_cost(ram_gb, cpu_cores, monthly_rate=0.10):
    """
    Примерный расчёт стоимости облачного сервера
    """
    # Цена не линейна: 16 GB не в 2 раза дешевле 32 GB
    # Обычно цена растёт экспоненциально
    
    base_cost = 50  # Базовая стоимость
    ram_cost = ram_gb * monthly_rate * 2  # Дороже на большие объёмы
    cpu_cost = cpu_cores * monthly_rate * 3
    
    return base_cost + ram_cost + cpu_cost

print(f"8GB, 4 cores: ${calculate_cost(8, 4)}")  # ~$52
print(f"128GB, 32 cores: ${calculate_cost(128, 32)}")  # ~$450 (не 8x дороже)

# 3. DOWNTIME РИСК
# Нужно перезагрузить сервер для смены оборудования
# Приложение будет недоступно

import time
from datetime import datetime

def upgrade_server():
    """
    Процесс обновления сервера
    """
    print(f"[{datetime.now()}] Starting upgrade...")
    print("1. Завершить текущие соединения")
    time.sleep(2)
    
    print("2. Сохранить состояние")
    time.sleep(1)
    
    print("3. СЕРВЕР НЕДОСТУПЕН (физическая замена железа)")
    time.sleep(5)  # Этот период = DOWNTIME
    
    print("4. Сервер перезагружается")
    time.sleep(3)
    
    print("5. Приложение восстанавливает соединения")
    print(f"[{datetime.now()}] Upgrade complete!")

Горизонтальное масштабирование (без downtime)

# Горизонтальное масштабирование может быть без downtime
# через Blue-Green deployment

from enum import Enum
from typing import List

class Environment(Enum):
    BLUE = "blue"    # Старые серверы
    GREEN = "green"  # Новые серверы

class BlueGreenDeployment:
    def __init__(self):
        self.active_env = Environment.BLUE
        self.blue_servers = ["server1", "server2"]
        self.green_servers = []
    
    def add_new_servers(self, count: int):
        """
        Добавить новые серверы в GREEN окружение
        """
        for i in range(count):
            self.green_servers.append(f"new_server_{i}")
        print(f"Added {count} new servers to GREEN")
    
    def switch_traffic(self):
        """
        Переключить трафик на GREEN (без downtime)
        """
        print(f"Switching traffic from {self.active_env.value} to GREEN...")
        self.active_env = Environment.GREEN
        print(f"All traffic now goes to {len(self.green_servers)} new servers")
        # Старые серверы (BLUE) можно выключить
        self.blue_servers.clear()

# Использование
deployment = BlueGreenDeployment()
deployment.add_new_servers(3)  # Добавляем новые серверы
deployment.switch_traffic()     # Переключаем трафик БЕЗ downtime

Когда использовать вертикальное масштабирование?

# КОГДА ИСПОЛЬЗОВАТЬ VERTICAL SCALING:
# 1. Приложение не требует высокой доступности
# 2. Короткие периоды maintenance допустимы
# 3. Стоимость менее критична
# 4. Большая часть нагрузки идёт на одну БД

class SingleDBApplication:
    """
    Пример: приложение с одной БД
    """
    def __init__(self):
        self.db_host = "postgres.example.com"  # Одна БД!
        self.connections = 100
    
    def handle_request(self):
        # Все запросы идут в ОДНУ БД
        # Увеличение мощности сервера БД = увеличение throughput
        return self.db_host

Когда использовать горизонтальное масштабирование?

# КОГДА ИСПОЛЬЗОВАТЬ HORIZONTAL SCALING:
# 1. Высокая доступность критична (99.9% uptime)
# 2. Нужна защита от сбоев
# 3. Стоимость оптимизирована
# 4. Приложение stateless

from typing import List
from dataclasses import dataclass

@dataclass
class HealthCheck:
    server_id: str
    cpu_usage: float
    memory_usage: float
    response_time: float

class HorizontallyScaledApp:
    """
    Пример: приложение с несколькими серверами
    """
    def __init__(self):
        self.servers: List[str] = []
        self.load_balancer = "nginx"
    
    def add_server(self, server_id: str):
        self.servers.append(server_id)
        print(f"Added server: {server_id}")
    
    def remove_server(self, server_id: str):
        # БЕЗ downtime! Load balancer переключает трафик
        self.servers.remove(server_id)
        print(f"Removed server: {server_id} (gracefully)")
    
    def auto_scale(self, health_checks: List[HealthCheck]):
        """
        Автоматическое масштабирование на основе метрик
        """
        avg_cpu = sum(h.cpu_usage for h in health_checks) / len(health_checks)
        
        if avg_cpu > 80:
            print(f"High CPU usage: {avg_cpu}% - adding server")
            self.add_server(f"server_{len(self.servers) + 1}")
        elif avg_cpu < 20 and len(self.servers) > 1:
            print(f"Low CPU usage: {avg_cpu}% - removing server")
            self.remove_server(self.servers[-1])

Пример: вертикальное масштабирование Django приложения

# settings.py
# На слабом сервере (8 GB RAM, 4 cores)
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'mydb',
        'CONN_MAX_AGE': 300,
        'OPTIONS': {
            'connect_timeout': 10,
        }
    }
}

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
        # Локальный кеш достаточно на одном сервере
    }
}

ALLOWED_HOSTS = ['myapp.com']

# Когда масштабируем вертикально (256 GB RAM, 128 cores)
# - Увеличиваем thread pool для БД connections
DATABASES['default']['CONN_MAX_AGE'] = 3600

# - Можем позволить больше кеша в памяти
CACHES['default']['OPTIONS'] = {'MAX_ENTRIES': 100000}

Сравнение: Вертикальное vs Горизонтальное

Вывод

Вертикальное масштабирование — это:

• Увеличение мощности одного сервера (RAM, CPU, SSD)
• Простое в реализации, не требует изменения кода
• Дорогое и имеет технические пределы
• Подходит для small-medium applications с maintenance-friendly SLA
• Противоположно горизонтальному масштабированию (добавление серверов)
• На практике часто комбинируют оба подхода