Услуги по настройке веб-серверов и прокси

Как настроить веб-сервер Nginx для высокой нагрузки?

Мы предоставляем услуги по настройке веб-серверов и прокси: Nginx, HAProxy, Traefik, Envoy, Istio, Linkerd — под ключ. Наш опыт — более 7 лет в DevOps и 50+ проектов по этой теме.

Недавний кейс: Nginx отдаёт статику за 2 ms, а первый байт от upstream приходит за 800 ms — но медиана upstream_response_time в Grafana показывает 1.2 секунды. Проблема не в Nginx. Проблема в том, что upstream keepalive не настроен. Каждый запрос к бэкенду поднимает новое TCP-соединение. При 500 rps это 500 handshake'ов в секунду. Типичная экономия от правильного keepalive — до 30% времени ответа и снижение нагрузки на CPU, что при 500 rps может сэкономить до $200 в месяц на инстансах.

Как избежать ошибок при настройке Nginx под нагрузкой?

worker_processes auto и worker_connections 1024 — настройки по умолчанию, которые не трогают годами. На сервере с 8 ядрами и 10 Gbps сетью это потолок в ~8000 одновременных соединений. При spike-нагрузке файловые дескрипторы заканчиваются раньше, чем CPU.

Критические параметры для production:

worker_processes auto; worker_rlimit_nofile 65535; events { worker_connections 16384; use epoll; multi_accept on; } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; keepalive_requests 1000; upstream backend { server 10.0.1.10:8080; server 10.0.1.11:8080; keepalive 64; # пул keepalive-соединений к upstream keepalive_requests 100; keepalive_timeout 60s; } server { location /api/ { proxy_pass http://backend; proxy_http_version 1.1; # обязательно для keepalive proxy_set_header Connection ""; # убираем "close" из заголовка proxy_connect_timeout 5s; proxy_read_timeout 60s; proxy_send_timeout 60s; } } } 

Без пары proxy_http_version 1.1 + proxy_set_header Connection "" keepalive к upstream не работает — Nginx всё равно закрывает соединение после каждого запроса. Wikipedia подтверждает это.

worker_rlimit_nofile должен совпадать с системным ulimit -n. Если в /etc/security/limits.conf стоит nginx soft nofile 1024 — все настройки в конфиге бесполезны.

Nginx как TLS termination с OCSP stapling

TLS handshake при OCSP validation занимает 50–200 ms на каждое новое соединение. OCSP Stapling кеширует статус сертификата на стороне сервера, сокращая задержку. Рекомендация Mozilla SSL Configuration Generator:

ssl_certificate /etc/ssl/certs/example.com.crt; ssl_certificate_key /etc/ssl/private/example.com.key; ssl_trusted_certificate /etc/ssl/certs/ca-bundle.crt; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:50m; ssl_session_timeout 1d; ssl_session_tickets off; ssl_stapling on; ssl_stapling_verify on; resolver 1.1.1.1 8.8.8.8 valid=300s; resolver_timeout 5s; 

ssl_session_tickets off — форвардная секретность. Session tickets позволяют возобновлять сессии без нового handshake, но при компрометации ticket key компрометируются все сессии.

Когда HAProxy выгоднее Nginx?

HAProxy специализируется на балансировке L4 и L7, мониторинге состояния бэкендов и fine‑grained traffic control. Для TCP load balancing (базы данных, очереди) HAProxy удобнее.

Конкретный кейс: балансировка PostgreSQL с разделением read/write трафика по разным портам:

frontend postgres_write bind *:5432 mode tcp default_backend pg_primary frontend postgres_read bind *:5433 mode tcp default_backend pg_replicas backend pg_primary mode tcp option tcp-check server pg1 10.0.1.1:5432 check port 8008 inter 2s # Patroni REST API healthcheck server pg2 10.0.1.2:5432 check port 8008 inter 2s backup backend pg_replicas mode tcp balance leastconn option tcp-check server pg2 10.0.1.2:5432 check port 8008 inter 2s server pg3 10.0.1.3:5432 check port 8008 inter 2s 

Patroni поднимает REST API на порту 8008, возвращает HTTP 200 для primary и 503 для replica. HAProxy проверяет этот endpoint — после failover write‑трафик автоматически перенаправляется на новый primary.

Traefik: динамическая конфигурация для Kubernetes

Traefik — cloud‑native reverse proxy с автодискавери из K8s API, Consul, Docker. Не нужно перезагружать при добавлении новых сервисов — конфигурация подтягивается динамически.

Middleware для rate limiting и circuit breaker:

apiVersion: traefik.containo.us/v1alpha1 kind: Middleware metadata: name: rate-limit spec: rateLimit: average: 100 burst: 50 period: 1s sourceCriterion: ipStrategy: depth: 2 # X-Forwarded-For второй с конца (за load balancer) apiVersion: traefik.containo.us/v1alpha1 kind: Middleware metadata: name: circuit-breaker spec: circuitBreaker: expression: ResponseCodeRatio(500, 600, 0, 600) > 0.25 checkPeriod: 10s fallbackDuration: 30s recoveryDuration: 10s 

Circuit breaker срабатывает, когда >25% ответов — 5xx за последние 10 секунд. Защита от каскадных отказов: вместо накопления очереди Traefik возвращает 503.

Почему Istio может быть избыточным?

Istio — самый функциональный и самый тяжёлый service mesh. Envoy sidecar инжектируется в каждый Pod через MutatingAdmissionWebhook. Control plane (istiod) управляет конфигурацией Envoy через xDS API: EDS, CDS, RDS, LDS.

На практике это даёт: mTLS между всеми сервисами автоматически, circuit breaking на уровне каждого upstream, distributed tracing через автоматическую инъекцию B3/W3C headers, traffic shifting для canary deployments.

Canary deployment через VirtualService:

apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: api-service spec: http: - match: - headers: x-canary: exact: "true" route: - destination: host: api-service subset: v2 weight: 100 - route: - destination: host: api-service subset: v1 weight: 95 - destination: host: api-service subset: v2 weight: 5 

5% трафика идёт на v2 для всех пользователей. Хедер x-canary: true для тестировщиков — они всегда попадают на v2.

Реальная проблема Istio — overhead: каждый sidecar потребляет ~50‑100 MB RAM и добавляет 1‑5 ms latency на hop. На кластере с 200 подами это 10‑20 GB дополнительного RAM. Дополнительные расходы на облачные инстансы могут составлять $500‑2000 в месяц. Istio Ambient Mesh (ztunnel + waypoint proxy) решает это переносом proxy на уровень ноды, но на текущий момент — пока beta‑качества.

Linkerd как альтернатива

Linkerd написан на Rust (data plane proxy linkerd2-proxy), потребляет в 10 раз меньше ресурсов, чем Envoy. Нет Lua extensions, WebAssembly plugins — зато стабильно работает. Если нужен mTLS + basic traffic splitting + golden metrics (success rate, latency, RPS) без сложных routing rules — Linkerd проще в операционке.

Envoy как standalone

Envoy без Istio — отличный edge proxy или sidecar для конкретного сервиса. Его xDS API поддерживается Control Plane от Contour, Gloo Edge, Ambassador. Для тех, кто хочет L7 функциональность Istio без полного service mesh — Contour (Envoy‑based Ingress Controller) хорошая точка входа.

Что входит в работу по настройке веб-серверов и прокси

Сравнение подходов: когда что выбирать

Как мы настраиваем веб-сервер: пошаговый процесс

1. Аудит текущей конфигурации — собираем логи, метрики, конфиги. Выявляем узкие места (keepalive, буферы, TLS).
2. Проектирование оптимальной архитектуры — выбираем инструмент под задачу: Nginx для статики, HAProxy для TCP, Traefik для K8s.
3. Реализация — применяем IaC (Ansible, Terraform), настраиваем параметры ядра, worker, upstream, TLS.
4. Тестирование под нагрузкой — используем wrk2, vegeta, k6. Проверяем p99 latency, error rate.
5. Деплой и documentation — передаём runbook, обучаем команду. Предоставляем 2 недели поддержки.

Этапы работы и сроки

Стоимость рассчитывается индивидуально после аудита инфраструктуры. Закажите консультацию — оценим проект и предложим оптимальное решение. Свяжитесь с нами, чтобы обсудить ваш сценарий.

Наш опыт и подход

Мы занимаемся DevOps и настройкой инфраструктуры более 7 лет. За плечами 50+ проектов — от стартапов до enterprise с сотнями Pod. Используем best practices: GitOps, Infrastructure as Code, автоматическое тестирование конфигураций. Работаем под ключ — от аудита до передачи готовой системы. Получите консультацию — расскажем, как решить вашу задачу.