Кто отвечал за настройку системы при высокой нагрузке

Кто отвечал за настройку системы при высокой нагрузке

В крупной компании как IKEA, настройка системы при высокой нагрузке — это ответственность нескольких команд, каждая с чётко определёнными зонами ответственности. Моя роль как Senior Backend Engineer была архитектурной оптимизацией и балансировкой нагрузки на уровне приложения.

Структура ответственности

1. DevOps/SRE команда (Site Reliability Engineering)

Отвечала за:

• Масштабирование инфраструктуры (горизонтальное и вертикальное)
• Настройка балансировщиков нагрузки (Load Balancers)
• Мониторинг и алерты
• Автоматическое масштабирование (Auto-scaling)
• Управление Kubernetes кластерами

# DevOps настраивал автоскейлинг
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: backend-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: backend-api
  minReplicas: 5
  maxReplicas: 100
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

2. Database Team

Отвечала за:

• Оптимизацию SQL запросов
• Добавление индексов
• Кеширование на уровне БД
• Шардирование и реплицирование
• Настройка параметров PostgreSQL/MySQL

-- Database Team проводила профилирование
EXPLAIN ANALYZE
SELECT p.*, s.stock_count
FROM products p
JOIN stocks s ON p.id = s.product_id
WHERE p.category_id = $1
ORDER BY p.popularity DESC
LIMIT 100;

-- И добавляла оптимальные индексы
CREATE INDEX idx_products_category_popularity 
ON products(category_id, popularity DESC)
INCLUDE (id, name, price);

3. Backend Team (моя ответственность)

Отвечала за:

• Оптимизацию кода приложения
• Правильное использование потоков (Threading, Thread Pool)
• Настройка кешей (Redis, In-memory)
• Асинхронная обработка (Message Queues, Event Sourcing)
• Connection pooling к БД
• Отключение/оптимизация логирования при пиковой нагрузке

Мой вклад: Оптимизация приложения

1. Настройка JVM параметров

# startup.sh в production
java -server \
  -Xms4g -Xmx4g \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -XX:+ParallelRefProcEnabled \
  -XX:+AlwaysPreTouch \
  -XX:+UnlockDiagnosticVMOptions \
  -XX:G1SummarizeRSetStatsPeriod=1 \
  -Dspring.profiles.active=production \
  -jar backend.jar

Эти параметры критичны при высокой нагрузке:

• UseG1GC — современный сборщик мусора для низких пауз
• MaxGCPauseMillis=200 — максимум 200ms пауза GC (недопустимо останавливать обработку)
• AlwaysPreTouch — предварительно выделяем всю память (избегаем задержек в runtime)

2. Connection Pool настройка

@Configuration
public class DatabaseConfig {
    
    @Bean
    public DataSource dataSource() {
        HikariConfig config = new HikariConfig();
        config.setJdbcUrl("jdbc:postgresql://db.internal:5432/ikea");
        config.setUsername("ikea_app");
        config.setPassword(System.getenv("DB_PASSWORD"));
        
        // При высокой нагрузке это критично
        config.setMaximumPoolSize(50);        // Макс 50 connection
        config.setMinimumIdle(20);           // Минимум 20 в пуле
        config.setConnectionTimeout(10000);  // 10 сек на получение connection
        config.setIdleTimeout(600000);       // 10 минут на неиспользованный
        config.setMaxLifetime(1800000);      // 30 минут max lifetime
        config.setLeakDetectionThreshold(60000); // Алерт если connection лежит 60 сек
        
        return new HikariDataSource(config);
    }
}

3. Redis кеширование для товаров (самый критичный запрос)

@Service
public class ProductService {
    
    private final RedisTemplate<String, Product> redisTemplate;
    private final ProductRepository repository;
    
    @Cacheable(value = "products", key = "#categoryId")
    public List<Product> getProductsByCategory(Long categoryId) {
        // При высокой нагрузке это вызывается 1000 раз/сек
        // Без кеша — 1000 запросов в БД
        // С кешем в Redis — достаём из памяти (1ms вместо 50ms)
        return repository.findByCategory(categoryId);
    }
    
    public void invalidateCache(Long categoryId) {
        redisTemplate.delete("products::" + categoryId);
    }
}

4. Асинхронная обработка тяжёлых операций

@Service
public class OrderProcessingService {
    
    private final RabbitTemplate rabbitTemplate;
    
    public OrderResponse createOrder(OrderRequest request) {
        // Синхронно: быстрая реакция
        Order order = new Order(request);
        orderRepository.save(order);
        
        // Асинхронно: отправляем в очередь
        // Не блокируем пользователя на тяжёлые операции
        rabbitTemplate.convertAndSend("email.queue", 
            new EmailEvent(order.getId(), "confirmation"));
        
        rabbitTemplate.convertAndSend("analytics.queue",
            new AnalyticsEvent(order));
        
        return new OrderResponse(order.getId(), "Created");
    }
}

5. Отключение дорогих операций при пиковой нагрузке

@RestController
public class ProductController {
    
    @GetMapping("/products/{id}")
    public ProductResponse getProduct(@PathVariable Long id) {
        Product product = productService.getById(id);
        
        // При нормальной нагрузке: логируем всё
        if (loadMonitor.getCpuUsage() < 70) {
            logger.info("Fetched product {}", id);
            analyticsService.trackProductView(id); // Дорого
        }
        
        // При высокой нагрузке: минимум логирования
        return ProductResponse.from(product);
    }
}

6. Thread Pool оптимизация

@Configuration
public class ThreadPoolConfig {
    
    // Основной пул для обработки HTTP запросов
    // Tomcat (Jetty) автоматически управляет, но можно настроить
    
    @Bean(name = "asyncExecutor")
    public Executor asyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(100);      // 100 потоков
        executor.setMaxPoolSize(500);       // До 500 при пиках
        executor.setQueueCapacity(10000);   // Очередь на 10k задач
        executor.setThreadNamePrefix("async-");
        executor.initialize();
        return executor;
    }
    
    // Пул для блокирующих операций
    @Bean(name = "blockingExecutor")
    public Executor blockingExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(50);
        executor.setMaxPoolSize(200);
        executor.setQueueCapacity(5000);
        executor.initialize();
        return executor;
    }
}

7. Мониторинг и метрики

@Component
public class LoadMonitor {
    
    private final MeterRegistry meterRegistry;
    private final ApplicationContext context;
    
    @Scheduled(fixedDelay = 5000)
    public void recordMetrics() {
        ThreadMXBean threadBean = ManagementFactory.getThreadMXBean();
        
        // Отслеживаем потоки
        meterRegistry.gauge("jvm.threads.live", 
            threadBean.getThreadCount());
        
        // Отслеживаем memory
        MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean();
        meterRegistry.gauge("jvm.memory.used", 
            memoryBean.getHeapMemoryUsage().getUsed());
        
        // Отслеживаем GC паузы
        // Если pause > 500ms при пиковой нагрузке — проблема!
    }
}

Координация во время Black Friday (Пиковая нагрузка)

В день распродаж нагрузка в 10+ раз выше нормы. Я координировал с DevOps и Database командами:

1. За неделю до: 
   - Прогнозируем нагрузку
   - Проверяем оптимизации кода
   - DevOps: предварительно масштабирует инфраструктуру
   - Database: создаёт indices и оптимизирует queries

2. За день до:
   - Load testing: 100k concurrent users
   - Выявляем bottlenecks
   - Я оптимизирую критичные endpoints

3. В день распродажи:
   - Я в режиме on-call
   - Мониторю CPU/Memory/Response Time
   - Динамически отключаю неважные features
   - DevOps масштабирует по необходимости

Итоговая ответственность

Без скоординированной работы всех команд невозможно обработать пиковые нагрузки. Моя роль как Backend-инженера была обеспечивать, чтобы приложение было максимально эффективно на той инфраструктуре, которую даёт DevOps команда.