Облачный сервер для Elasticsearch в Европе: хостинг поиска в ЕС

Облачный сервер для Elasticsearch в Европе: хостинг поиска в ЕС

Elasticsearch - основа полнотекстового поиска, аналитики журналов и стеков наблюдаемости в современных приложениях. Для компаний, работающих с данными европейских пользователей, где живёт этот поисковый индекс и кто управляет инфраструктурой, напрямую влияет на соответствие GDPR и время отклика запросов.

Это руководство описывает, какое оборудование нужно Elasticsearch, как настроить кучу JVM и шарды и какой пропускной способности поиска ждать на облачном сервере в ЕС.

Почему место хранения данных в ЕС важно для Elasticsearch

Индексы Elasticsearch обычно содержат содержимое, созданное пользователями, журналы поведения и документы, привязанные к конкретным личностям, - всё это персональные данные по GDPR. Хостинг на сервере в ЕС у компании из ЕС означает, что ваш поисковый индекс никогда не покидает юрисдикцию ЕС, а требования к месту хранения выполняются без дополнительных юридических инструментов.

Сетевая близость для поиска тоже важна. Кластер Elasticsearch в Центральной Европе отвечает берлинскому приложению за 2-5 мс. Тот же кластер в дата-центре США добавляет 80-120 мс на запрос, а этого достаточно, чтобы автодополнение и поиск на ходу казались европейским пользователям вялыми.

Минимальные требования к серверу для Elasticsearch

Elasticsearch требователен к памяти и CPU. Кучу JVM следует задать в 50% доступной RAM, а другие 50% должны остаться ОС под файловый кеш (Lucene читает файлы сегментов через страничный кеш ОС):

• Небольшой (разработка и журналы, индекс менее 50 ГБ) - 4 vCPU, 16 ГБ RAM, 200 ГБ NVMe SSD
• Средний (продакшен-поиск, индекс 50-500 ГБ) - 8 vCPU, 32 ГБ RAM, 1 ТБ NVMe SSD
• Крупный (аналитика, индекс в несколько ТБ или интенсивный приём) - 16 и более vCPU, 64 ГБ RAM, 2 ТБ и более NVMe SSD

Хранилище NVMe особенно важно для Elasticsearch, потому что слияние сегментов - это фоновые операции с интенсивным вводом-выводом. Медленный диск заставляет слияния отставать во время всплесков приёма, из-за чего задержка поиска подскакивает.

Рекомендуемая конфигурация DCXV

Облачные серверы DCXV дают хранилище на NVMe со стабильным IOPS, что держит слияние сегментов Elasticsearch в графике. Рекомендуемые конфигурации:

• 8 vCPU, 32 ГБ RAM, 1 ТБ NVMe - узел продакшен-кластера поиска для контентной платформы или электронной торговли
• 16 vCPU, 64 ГБ RAM, 2 ТБ NVMe - аналитика журналов или стек наблюдаемости (совместимый с ELK и OpenSearch)

Для продакшен-кластера разверните 3 узла в приватной сети DCXV. Это даёт избыточность шардов и позволяет делать поочерёдные перезапуски без простоя. Напишите на sales@dcxv.com, чтобы обсудить топологию кластера и конфигурацию приватной сети.

Команды для быстрой установки

# Установка Elasticsearch 8.x на Ubuntu 22.04
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list

sudo apt update && sudo apt install -y elasticsearch

# Запуск и включение службы
sudo systemctl start elasticsearch
sudo systemctl enable elasticsearch

# Ключевые параметры elasticsearch.yml для узла с 32 ГБ RAM
# Правьте /etc/elasticsearch/elasticsearch.yml

cluster.name: my-eu-cluster
node.name: node-1
network.host: 10.0.0.5         # приватный адрес этого сервера
http.port: 9200
discovery.seed_hosts: ["10.0.0.5", "10.0.0.6", "10.0.0.7"]
cluster.initial_master_nodes: ["node-1", "node-2", "node-3"]

# Пути
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

# Размер кучи JVM - задайте 50% RAM, никогда не превышайте 31 ГБ
# Правьте /etc/elasticsearch/jvm.options.d/heap.options
-Xms16g
-Xmx16g

# Настройка на уровне ОС для Elasticsearch
# Отключите своп (критично для производительности JVM)
sudo swapoff -a
echo 'vm.swappiness=1' | sudo tee -a /etc/sysctl.conf

# Поднимите пределы файловых дескрипторов и mmap
echo 'elasticsearch soft nofile 65535' | sudo tee -a /etc/security/limits.conf
echo 'elasticsearch hard nofile 65535' | sudo tee -a /etc/security/limits.conf
echo 'vm.max_map_count=262144' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

sudo systemctl restart elasticsearch

# Проверка здоровья кластера и создание индекса
curl -X GET "http://10.0.0.5:9200/_cluster/health?pretty"

# Создание индекса с явными параметрами шардов и реплик
curl -X PUT "http://10.0.0.5:9200/my-index" -H 'Content-Type: application/json' -d'
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1,
    "refresh_interval": "30s"
  }
}'

# Индексация документа
curl -X POST "http://10.0.0.5:9200/my-index/_doc" -H 'Content-Type: application/json' -d'
{
  "title": "EU cloud server guide",
  "content": "Elasticsearch running on DCXV infrastructure"
}'

# Выполнение поискового запроса
curl -X GET "http://10.0.0.5:9200/my-index/_search?q=cloud&pretty"

Четыре числа, от которых зависит, останется ли кластер на ногах

RAM и диск - лёгкая часть. Ниже те параметры, которые роняют кластер, и три из четырёх достаточно неочевидны, чтобы добавление оборудования делало их хуже, а не лучше:

Параметр	Правило	Почему	Как выглядит поломка
Размер кучи	Половина RAM и никогда выше 31 ГБ	Выше примерно 32 ГБ JVM теряет сжатые указатели на объекты	Куча 64 ГБ адресует меньше, чем куча 31 ГБ
Шардов на узел	Менее 20 на каждый ГБ кучи	Каждый шард стоит кучи, запрашивают его или нет	Медленное состояние кластера, затем узлы выпадают
Размер шарда	По 10-50 ГБ	Меньше - расход на накладные, больше - невозможно перебалансировать	Восстановление после перезапуска идёт часами
Своп	Выключен, память заблокирована	Ушедшая в своп куча JVM останавливает сборку мусора	Случайные паузы на несколько секунд без реальной нагрузки

Людей ловит именно число шардов, потому что первый порыв при медленном кластере - добавить узлы и разбить индексы дальше. Так на учёт уходит больше кучи, и проблема усугубляется. Сначала посчитайте, сколько шардов у вас есть: индекс на каждый день за год - это 365 шардов там, где месячный индекс дал бы 12.

Ожидаемые показатели производительности

На узле 8 vCPU / 32 ГБ RAM / NVMe с Elasticsearch 8.x и кучей JVM 16 ГБ:

• Пропускная способность индексации (bulk API, партии по 1000) - 15 000-30 000 документов в секунду
• Поисковых запросов в секунду (простой терм-запрос) - 500-1 500
• Поисковых запросов в секунду (сложная агрегация) - 50-200
• Задержка запроса P99 (прогретый запрос из кеша) - менее 10 мс
• Пропускная способность слияния сегментов - 200-500 МБ/с на NVMe

Число шардов - самый мощный рычаг настройки. Держите шарды по 20-50 ГБ. Слишком много мелких шардов тратят накладные расходы, слишком мало крупных ограничивают параллелизм.

Это ожидания для оборудования такого класса, а не измерения из нашей лаборатории. Считайте их отправной точкой для расчёта и измеряйте собственную нагрузку: реальные цифры зависят от ваших данных, ваших запросов и вашей настройки гораздо сильнее, чем от провайдера.

Итог

Elasticsearch на облачном сервере в ЕС держит поисковый индекс и данные пользователей в юрисдикции ЕС и при этом даёт поиск с низкой задержкой и высокой пропускной способностью, который нужен вашему приложению. Задайте кучу JVM в 50% RAM, отключите своп и разверните кластер из 3 узлов для устойчивости в продакшене. Облачные серверы DCXV дают хранилище NVMe и хранение данных в ЕС, которые нужны вашему кластеру Elasticsearch.