Послуги з налаштування веб-серверів та проксі

Налаштування веб-сервера Nginx під високе навантаження

Нещодавній кейс: 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 може заощадити до $300‑500 на місяць на хмарних інстансах.

Ми надаємо послуги з налаштування веб-серверів та проксі: Nginx, HAProxy, Traefik, Envoy, Istio, Linkerd — під ключ. Наш досвід — понад 7 років у DevOps та 50+ проєктів із цієї теми. Використовуємо best practices: GitOps, Infrastructure as Code, автоматичне тестування конфігурацій. Працюємо під ключ — від аудиту до передачі готової системи.

Критичні параметри Nginx для production

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

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_requests 100; keepalive_timeout 60s; } server { location /api/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ""; 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, правильне налаштування keepalive зменшує навантаження на CPU до 30% при високих навантаженнях.

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 компрометуються всі сесії.

Коли варто використовувати Nginx, а коли — HAProxy?

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 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. Витрати на хмарні інстанси можуть становити $2000‑3000 на місяць. 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. Деплой та документація — передаємо runbook, навчаємо команду. Надаємо 2 тижні підтримки.

Етапи роботи та терміни

Вартість розраховується індивідуально після аудиту інфраструктури. Замовте аудит поточної конфігурації — отримайте звіт з рекомендаціями та оцінку вартості робіт. Також пропонуємо навчання команди: як вносити зміни та дебажити. Наша гарантія — сертифіковані інженери з 7+ роками досвіду, 5+ років на ринку. Понад 50 реалізованих проєктів — від стартапів до enterprise з сотнями Pod. Зв'яжіться з нами, щоб обговорити ваш сценарій — запропонуємо оптимальне рішення.

Типові помилки при налаштуванні веб-сервера Nginx

• Ігнорування worker_rlimit_nofile — при високих навантаженнях Nginx падає з помилкою “Too many open files”.
• Використання дефолтних cipher suites — вразливість до атак типу BEAST, POODLE.
• Відсутність health checks для upstream — трафік іде на мертвий бекенд.
• Не налаштований session cache для TLS — кожне нове з'єднання виконує повний handshake.

Бажаєте отримати детальний план оптимізації вашого веб-сервера? Замовте консультацію — ми проаналізуємо вашу конфігурацію.