Serveur cloud pour Elasticsearch en Europe: hébergement recherche EU
Elasticsearch est l'épine dorsale de la recherche plein texte, de l'analyse de logs et des stacks d'observabilite dans les applications modernes. Pour les entreprises traitant des données sur des utilisateurs européens, l'endroit ou vit cet index de recherche a des implications directes pour la conformité RGPD et les temps de réponse aux requêtes.
Pourquoi la résidence des données en UE est importante pour Elasticsearch
Les index Elasticsearch contiennent souvent du contenu génère par les utilisateurs, des logs comportementaux et des données de documents lies a des identites individuelles - toutes des données personnelles sous le RGPD. L'hébergement sur un serveur EU exploite par une entreprise européenne signifie que votre index de recherche ne quitte jamais la juridiction européenne.
La proximite réseau est egalement importante pour la recherche. Un cluster Elasticsearch en Europe centrale répond aux requêtes d'une application berlinoise en 2-5 ms. Le même cluster dans un centre de données americain ajoute 80-120 ms par requete.
Specifications minimales pour Elasticsearch
- Petit (dev/logging, moins de 50 Go d'index) - 4 vCPU, 16 Go RAM, 200 Go NVMe SSD
- Moyen (recherche de production, 50-500 Go) - 8 vCPU, 32 Go RAM, 1 To NVMe SSD
- Grand (analytique, index multi-To) - 16+ vCPU, 64 Go RAM, 2+ To NVMe SSD
Configuration DCXV recommandée
Les serveurs cloud DCXV fournissent un stockage NVMe avec des IOPS constants:
- 8 vCPU, 32 Go RAM, 1 To NVMe - noeud de cluster de recherche de production
- 16 vCPU, 64 Go RAM, 2 To NVMe - analytique de logs ou stack d'observabilite
Contactez sales@dcxv.com pour la configuration du cluster.
Commandes de configuration rapide
# Installer Elasticsearch 8.x sur 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
# Taille du heap JVM - 50% de la RAM
-Xms16g
-Xmx16g
# Désactiver le swap
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
Les quatre chiffres qui décident si cela tient debout
La RAM et le disque sont la partie facile. Voici les réglages qui mettent un cluster à terre, et trois des quatre sont assez contre-intuitifs pour que plus de matériel les aggrave:
| Réglage | La règle | Pourquoi | À quoi ressemble l'échec |
|---|---|---|---|
| Taille du heap | La moitié de la RAM, et jamais au-delà de 31 Go | Au-delà de ~32 Go la JVM perd les pointeurs compressés | Un heap de 64 Go adresse moins qu'un heap de 31 Go |
| Shards par noeud | Moins de 20 par Go de heap | Chaque shard coûte du heap, interrogé ou non | État du cluster lent, puis des noeuds qui décrochent |
| Taille de shard | 10-50 Go chacun | Plus petits, l'overhead domine; plus grands, pas de rééquilibrage | La reprise après un redémarrage prend des heures |
| Swap | Désactivé, mémoire verrouillée | Un heap JVM envoyé en swap bloque le ramasse-miettes | Des pauses aléatoires de plusieurs secondes sans charge réelle |
Ce qui piège, c'est le nombre de shards, parce que le réflexe devant un cluster lent est d'ajouter des noeuds et de découper davantage les index. Cela dépense encore plus de heap en comptabilité et aggrave le problème. Comptez d'abord vos shards: un index par jour pendant un an fait 365 shards là où un index mensuel en aurait eu 12.
Performances attendues
Sur un noeud 8 vCPU / 32 Go RAM / NVMe avec Elasticsearch 8.x:
- Débit d'indexation (API bulk) - 15 000-30 000 docs/s
- Requêtes par seconde - 500-1 500 QPS
- Latence P99 (requete chaude) - moins de 10 ms
Ce sont des attentes pour du matériel de cette classe, pas des mesures issues de notre propre laboratoire. Prenez-les comme point de départ pour le dimensionnement et mesurez votre charge : les chiffres réels dépendent de vos données, de vos requêtes et de votre tuning bien plus que du fournisseur.
Conclusion
Elasticsearch sur un serveur cloud EU maintient votre index de recherche sous juridiction européenne tout en offrant une recherche a faible latence et haut débit.
