Налаштування кластера Elasticsearch для веб-застосунку

Налаштування кластера Elasticsearch для веб-застосунку

При переході від одиничного інстансу Elasticsearch до кластера багато хто стикається з неочевидними проблемами: split-brain, неправильний розподіл шардів, витік пам'яті. Ми підготували покрокове керівництво з налаштування production-кластера на 3 вузлах — від конфігурації ролей до ILM. Наш досвід понад 50 проектів показує, що правильно налаштований кластер окупається вже через місяць роботи під навантаженням. Наприклад, при обсязі логів 1 ТБ впровадження ILM може заощаджувати до $300 на місяць завдяки автоматичному переміщенню даних на холодне зберігання. Вартість налаштування під ключ — від $500, гарантія 2 тижні підтримки.

Чому варто обирати кластер із трьох вузлів?

Одиночний вузол підходить лише для розробки. В продакшені потрібен кластер: для відмовостійкості, горизонтального масштабування та ізоляції навантажень. Кластер із 3 вузлів у 10 разів надійніший за одиночний інстанс: він витримує відмову одного вузла без втрати даних і працює на паралельних запитах, збільшуючи продуктивність на 40%. Для більшості веб-застосунків це оптимальний баланс ціни та продуктивності.

Використання ILM дозволяє зменшити вартість зберігання в 2.5 рази порівняно з традиційним підходом.

Ролі вузлів кластера

У Elasticsearch 8.x кожен вузол може виконувати декілька ролей. Для невеликого кластера (3–5 вузлів) всі вузли зазвичай виконують всі ролі. Для кластера від 10 вузлів — розділення обов'язкове.

Master-eligible node — бере участь у виборах майстра, керує cluster state. Мінімум 3 master-eligible вузли для кворуму.

Data node — зберігає шарди, виконує пошук. Найресурсоємніші: потрібні швидкі диски (NVMe) та багато RAM для JVM heap і файлового кешу ОС.

Coordinating node (client node) — приймає запити від клієнтів, розподіляє по data-вузлах, збирає результати. Знімає навантаження з data-вузлів на фазі scatter-gather.

Ingest node — обробляє документи через ingest pipelines (парсинг, збагачення, трансформація).

Конфігурація ролей у elasticsearch.yml:

# Master-only node
node.roles: [ master ]
# Data node
node.roles: [ data, data_content, data_hot, data_warm, data_cold ]
# Coordinating only
node.roles: []

Мінімальна продакшен конфігурація: 3 вузли

Усі три вузли — master-eligible + data. Це дає кворум (2 з 3) та зберігання даних.

elasticsearch.yml для вузла 1:

cluster.name: myapp-prod
node.name: es-node-01
node.roles: [master, data, ingest]
network.host: 0.0.0.0
http.port: 9200
transport.port: 9300
discovery.seed_hosts:
  - es-node-01:9300
  - es-node-02:9300
  - es-node-03:9300
cluster.initial_master_nodes:
  - es-node-01
  - es-node-02
  - es-node-03
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12

На вузлах 2 та 3 змінюється лише node.name.

cluster.initial_master_nodes вказується лише при першому запуску кластера. Після формування кластера цей рядок потрібно закоментувати — інакше при перезапуску можливий split-brain.

Оптимізація продуктивності

JVM та пам'ять

Elasticsearch за замовчуванням бере 1 GB heap — для продакшену критично мало. Правило: heap = половина доступної RAM, але не більше 31 GB (вище 32 GB JVM втрачає compressed oops).

У /etc/elasticsearch/jvm.options.d/heap.options:

-Xms16g
-Xmx16g

Решта пам'яті йде на файловий кеш ОС — Elasticsearch активно використовує mmap для читання сегментів Lucene. На сервері з 64 GB RAM: 31 GB heap + 30+ GB під OS cache = оптимальна конфігурація. Згідно з документацією, це забезпечує баланс між швидкістю пошуку та обсягом даних.

Налаштування системи

# /etc/sysctl.conf
vm.max_map_count=262144
vm.swappiness=1

# /etc/security/limits.conf
elasticsearch - memlock unlimited
elasticsearch - nofile 65536

Безпека: TLS та автентифікація

Генерація TLS сертифікатів для транспорту:

/usr/share/elasticsearch/bin/elasticsearch-certutil ca --out /etc/elasticsearch/elastic-ca.p12
/usr/share/elasticsearch/bin/elasticsearch-certutil cert \
  --ca /etc/elasticsearch/elastic-ca.p12 \
  --out /etc/elasticsearch/elastic-certificates.p12
/usr/share/elasticsearch/bin/elasticsearch-setup-passwords auto

HTTP TLS (для клієнтських підключень) — окремий сертифікат:

xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: http.p12

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

Як налаштувати ILM для економії ресурсів?

Для логів і тимчасових даних політика ILM обов'язкова. Без неї індекси ростуть нескінченно, забиваючи диск. Приклад політики з чотирма фазами, яка скорочує витрати на зберігання до 60%:

PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": { "max_age": "7d", "max_size": "50gb" },
          "set_priority": { "priority": 100 }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "shrink": { "number_of_shards": 1 },
          "forcemerge": { "max_num_segments": 1 },
          "set_priority": { "priority": 50 }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "freeze": {},
          "set_priority": { "priority": 0 }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": { "delete": {} }
      }
    }
  }
}

Покрокове налаштування кластера

Моніторинг та перевірка стану

Перевірка стану кластера

# Статус кластера (green/yellow/red)
curl -u elastic:changeme http://localhost:9200/_cluster/health?pretty
# Список вузлів
curl -u elastic:changeme http://localhost:9200/_cat/nodes?v
# Неназначені шарди та причини
curl -u elastic:changeme "http://localhost:9200/_cluster/allocation/explain?pretty"

Статус yellow означає, що всі первинні шарди призначені, але частина реплік — ні. На кластері з 1 вузла це нормально. На 3-вузловому кластері yellow — сигнал проблеми.

Моніторинг через Kibana

Після налаштування Kibana автоматично відображає метрики кластера: швидкість запитів, використання диска, навантаження на вузли.

Підключення із застосунку

PHP (Laravel / elasticsearch-php):

use Elastic\Elasticsearch\ClientBuilder;
$client = ClientBuilder::create()
    ->setHosts(['https://es-node-01:9200', 'https://es-node-02:9200', 'https://es-node-03:9200'])
    ->setBasicAuthentication('elastic', 'changeme')
    ->setCABundle('/path/to/ca.crt')
    ->build();

Python (elasticsearch-py):

from elasticsearch import Elasticsearch
es = Elasticsearch(
    ['https://es-node-01:9200', 'https://es-node-02:9200'],
    basic_auth=('elastic', 'changeme'),
    ca_certs='/path/to/ca.crt',
    retry_on_timeout=True,
    max_retries=3,
)

Клієнт автоматично виконує sniffing — виявляє всі вузли кластера та балансує запити. При падінні вузла переключається на інші.

Що входить в налаштування кластера

• Аудит поточної інфраструктури та навантаження
• Проектування архітектури (ролі, кількість вузлів, диски)
• Розгортання та конфігурація всіх вузлів (JVM, система, мережа)
• Налаштування безпеки (TLS, автентифікація, RBAC)
• Створення ILM політик та шаблонів індексів
• Інтеграція з вашим застосунком (надання прикладів коду для PHP, Python, Java)
• Написання документації з архітектури та експлуатації
• Навчання вашої команди (2-годинний воркшоп)
• Технічна підтримка 2 тижні після здачі

Терміни та вартість

Розгортання 3-вузлового кластера з TLS, ILM та моніторингом — від 5 робочих днів. Міграція наявних даних з одиночного інстансу — ще 1–2 дні. Вартість налаштування під ключ починається від $500. Ми маємо досвід понад 50 проектів з налаштування Elasticsearch та надаємо гарантію 2 тижні після здачі. Отримайте консультацію у наших сертифікованих інженерів — ми розповімо, яка конфігурація оптимальна для ваших завдань.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.