Хмарний сервер для Elasticsearch в Європі: пошук в ЄС
Elasticsearch є основою повнотекстового пошуку, аналітики журналів та стеків спостереження в сучасних застосунках. Для бізнесу, що обробляє дані про європейських користувачів, де знаходиться цей пошуковий індекс - і хто контролює інфраструктуру - має пряме відношення до дотримання GDPR та часу відповіді на запити.
Чому резиденція даних в ЄС важлива для Elasticsearch
Індекси Elasticsearch зазвичай містять контент, створений користувачами, журнали поведінки та дані документів, повязані з особами - все це персональні дані відповідно до GDPR. Розміщення на сервері ЄС від компанії ЄС означає, що ваш пошуковий індекс ніколи не залишає юрисдикцію ЄС.
Мережева близькість також важлива для пошуку. Кластер Elasticsearch у Центральній Європі відповідає на запити від застосунку в Берліні за 2-5 мс. Той же кластер у центрі обробки даних США додає 80-120 мс на запит.
Мінімальні характеристики для Elasticsearch
- Малий (dev/журналювання, до 50 ГБ індексу) - 4 vCPU, 16 ГБ RAM, 200 ГБ NVMe SSD
- Середній (виробничий пошук, 50-500 ГБ) - 8 vCPU, 32 ГБ RAM, 1 ТБ NVMe SSD
- Великий (аналітика, мульти-ТБ індекс) - 16+ vCPU, 64 ГБ RAM, 2+ ТБ NVMe SSD
Купа JVM повинна бути встановлена на 50% доступної RAM, а ОС повинна зберігати інші 50% для кешу файлової системи.
Рекомендована конфігурація DCXV
Хмарні сервери DCXV забезпечують сховище NVMe зі стабільними IOPS, що дозволяє злиттям сегментів Elasticsearch відповідати графіку:
- 8 vCPU, 32 ГБ RAM, 1 ТБ NVMe - вузол виробничого пошукового кластера
- 16 vCPU, 64 ГБ RAM, 2 ТБ NVMe - стек аналітики журналів або спостереження
Для виробничого кластера розгорніть 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
# Налаштування купи JVM - 50% RAM (ніколи не перевищуйте 31 ГБ)
# /etc/elasticsearch/jvm.options.d/heap.options
-Xms16g
-Xmx16g
# Відключення свопу (критично для JVM)
sudo swapoff -a
echo 'vm.swappiness=1' | sudo tee -a /etc/sysctl.conf
echo 'vm.max_map_count=262144' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
Чотири числа, від яких залежить, чи все працюватиме
Оперативна пам'ять і диск - це проста частина. Ось параметри, через які кластер падає, і три з чотирьох настільки неочевидні, що більше обладнання робить їх гіршими, а не кращими:
| Параметр | Правило | Чому | Як виглядає проблема |
|---|---|---|---|
| Розмір heap | Половина RAM і ніколи понад 31 ГБ | Вище ~32 ГБ JVM втрачає стиснуті вказівники на об'єкти | Heap на 64 ГБ адресує менше, ніж на 31 ГБ |
| Шардів на вузол | Менше 20 на кожен ГБ heap | Кожен шард витрачає heap, навіть якщо до нього немає запитів | Повільний стан кластера, потім вузли випадають |
| Розмір шарда | 10-50 ГБ кожен | Менші марнують накладні витрати, більші не перебалансовуються | Відновлення після перезапуску триває години |
| Swap | Вимкнений, пам'ять заблокована | Heap JVM у swap зупиняє збирання сміття | Випадкові паузи на кілька секунд без реального навантаження |
Найчастіше спотикаються на кількості шардів, бо перший інстинкт після повільного кластера - додати вузли й розділити індекси ще дрібніше. Це витрачає ще більше heap на облік і робить гірше. Спершу порахуйте свої шарди: індекс на день протягом року - це 365 шардів там, де місячний індекс дав би 12.
Очікувані показники продуктивності
На вузлі 8 vCPU / 32 ГБ RAM / NVMe з Elasticsearch 8.x:
- Пропускна здатність індексування (bulk API) - 15 000-30 000 docs/s
- Запити за секунду (простий запит) - 500-1 500 QPS
- P99 затримка запиту (теплий кеш) - менше 10 мс
Це очікування для заліза цього класу, а не заміри в нашій лабораторії. Використовуйте їх як відправну точку для сайзингу і міряйте своє навантаження: реальні числа залежать від ваших даних, запитів і налаштувань значно більше, ніж від провайдера.
Висновок
Elasticsearch на хмарному сервері ЄС зберігає ваш пошуковий індекс під юрисдикцією ЄС, забезпечуючи пошук з малою затримкою. Встановіть купу JVM на 50% RAM та відключіть своп.
