Serwer cloud dla Elasticsearch w Europie: hosting wyszukiwania EU
Elasticsearch jest podstawa wyszukiwania pelnotekstowego, analizy logów i stosów obserwowalnosci w nowoczesnych aplikacjach. Dla firm przetwarzajacych dane europejskich użytkowników, miejsce przechowywania indeksu wyszukiwania ma bezposrednie konsekwencje dla zgodności z RODO i czasów odpowiedzi na zapytania.
Dlaczego rezydencja danych w UE ma znaczenie dla Elasticsearch
Indeksy Elasticsearch często zawieraja treści generowane przez użytkowników, logi behawioralne i dane dokumentów powiazane z indywidualnymi tozsamosciami - wszystko to sa dane osobowe pod RODO. Hosting na serwerze UE prowadzonym przez europejska firme oznacza, ze Twój indeks wyszukiwania nigdy nie opuszcza jurysdykcji UE.
Bliskosc sieciowa jest również wazna dla wyszukiwania. Klaster Elasticsearch w Europie Środkowej odpowiada na zapytania aplikacji berlinskiej w 2-5 ms. Ten sam klaster w centrum danych w USA dodaje 80-120 ms na zapytanie.
Minimalne specyfikacje dla Elasticsearch
- Mały (dev/logowanie, do 50 GB indeksu) - 4 vCPU, 16 GB RAM, 200 GB NVMe SSD
- Średni (produkcyjne wyszukiwanie, 50-500 GB) - 8 vCPU, 32 GB RAM, 1 TB NVMe SSD
- Duży (analityka, indeks multi-TB) - 16+ vCPU, 64 GB RAM, 2+ TB NVMe SSD
Rekomendowana konfiguracja DCXV
Serwery cloud DCXV zapewniaja przechowywanie NVMe ze stałym IOPS:
- 8 vCPU, 32 GB RAM, 1 TB NVMe - węzeł produkcyjnego klastra wyszukiwania
- 16 vCPU, 64 GB RAM, 2 TB NVMe - analityka logów lub stos obserwowalnosci
Skontaktuj sie z sales@dcxv.com w celu konfiguracji klastra.
Komendy szybkiej konfiguracji
# Instalacja Elasticsearch 8.x na 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
# Rozmiar sterty JVM - 50% RAM
-Xms16g
-Xmx16g
# Wylaczenie swapa
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
Cztery liczby, które decydują, czy to się utrzyma
RAM i dysk to łatwa część. To są ustawienia, które kładą klaster, a trzy z czterech są na tyle nieoczywiste, że więcej sprzętu je pogarsza, a nie poprawia:
| Ustawienie | Zasada | Dlaczego | Jak wygląda awaria |
|---|---|---|---|
| Rozmiar heap | Połowa RAM i nigdy powyżej 31 GB | Powyżej ~32 GB JVM traci skompresowane wskaźniki obiektów | Heap 64 GB adresuje mniej niż heap 31 GB |
| Shardy na węzeł | Mniej niż 20 na GB heap | Każdy shard kosztuje heap, pytany czy nie | Wolny stan klastra, potem węzły wypadające |
| Rozmiar sharda | 10-50 GB każdy | Mniejsze marnują narzut, większe nie równoważą się | Odzyskiwanie po restarcie trwa godziny |
| Swap | Wyłączony, pamięć zablokowana | Heap JVM w swapie zatrzymuje odśmiecanie | Losowe kilkusekundowe pauzy bez rzeczywistego obciążenia |
Najczęściej ludzie potykają się o liczbę shardów, bo odruch przy wolnym klastrze to dodać węzły i podzielić indeksy jeszcze drobniej. To wydaje jeszcze więcej heap na księgowanie i pogarsza problem. Najpierw policz swoje shardy: indeks na dzień przez rok to 365 shardów tam, gdzie miesięczny dałby 12.
Oczekiwana wydajność
Na wezle 8 vCPU / 32 GB RAM / NVMe z Elasticsearch 8.x:
- Przepustowosc indeksowania (API bulk) - 15 000-30 000 docs/s
- Zapytania na sekunde - 500-1 500 QPS
- Opoznienie P99 (cieple zapytanie) - poniżej 10 ms
To oczekiwania dla sprzętu tej klasy, a nie pomiary z naszego laboratorium. Traktuj je jako punkt wyjścia do doboru rozmiaru i zmierz własne obciążenie: realne liczby zależą od twoich danych, zapytań i tuningu znacznie bardziej niż od dostawcy.
Podsumowanie
Elasticsearch na serwerze cloud UE utrzymuje Twój indeks wyszukiwania pod jurysdykcja UE, zapewniając wyszukiwanie z malym opoznieniem i duzym throughputem.
