Еуропадағы Elasticsearch үшін бұлт сервері: ЕО ішінде іздеу хостингі
Elasticsearch - қазіргі қосымшалардағы толық мәтінді іздеудің, журнал аналитикасының және бақылау стектерінің негізі. Еуропалық пайдаланушылардың деректерімен жұмыс істейтін компаниялар үшін осы іздеу индексінің қайда тұратыны және инфрақұрылымды кім басқаратыны GDPR-ға сәйкестікке және сұраныстардың жауап беру уақытына тікелей әсер етеді.
Бұл нұсқаулық Elasticsearch-ке қандай жабдық қажет, JVM үйіндісі мен шардтарды қалай баптау керек және ЕО бұлт серверінде іздеудің қандай өткізу қабілетін күту керегін баяндайды.
Деректердің ЕО ішінде сақталуы Elasticsearch үшін неге маңызды
Elasticsearch индекстері әдетте пайдаланушылар жасаған мазмұнды, мінез-құлық журналдарын және нақты тұлғаларға байланған құжаттарды сақтайды - бұның бәрі GDPR бойынша дербес деректер. ЕО компаниясындағы ЕО серверінде орналастыру іздеу индексіңіз ЕО юрисдикциясынан ешқашан шықпайтынын білдіреді, ал сақталу орны талаптары қосымша заңдық құралдарсыз орындалады.
Іздеу үшін желі жақындығы да маңызды. Орталық Еуропадағы Elasticsearch кластері берлиндік қосымшаға 2-5 мс ішінде жауап береді. АҚШ дата-орталығындағы сол кластер сұранысқа 80-120 мс қосады, ал бұл автотолықтыру мен жүрдек іздеудің еуропалық пайдаланушыға сылбыр көрінуіне жетеді.
Elasticsearch үшін серверге қойылатын ең аз талаптар
Elasticsearch жад пен CPU-ға талапшыл. JVM үйіндісін қолжетімді RAM-ның 50% етіп қою керек, ал қалған 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 бұлт серверлері IOPS-ы тұрақты NVMe қорына негізделген сақтауды береді, бұл Elasticsearch сегменттерінің біріктірілуін кестеде ұстайды. Ұсынылатын конфигурациялар:
- 8 vCPU, 32 ГБ RAM, 1 ТБ NVMe - мазмұн немесе электрондық сауда платформасына продакшен іздеу кластерінің түйіні
- 16 vCPU, 64 ГБ RAM, 2 ТБ NVMe - журнал аналитикасы немесе бақылау стегі (ELK және OpenSearch-пен үйлесімді)
Продакшен кластер үшін DCXV жеке желісінде 3 түйін орналастырыңыз. Бұл шардтардың артықтығын береді және тоқтап қалмай кезекпен қайта жіберуге мүмкіндік береді. Кластер топологиясын және жеке желі конфигурациясын талқылау үшін sales@dcxv.com адресіне жазыңыз.
Жылдам орнатуға арналған командалар
# Ubuntu 22.04-ке Elasticsearch 8.x орнату
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
# 32 ГБ RAM түйініне elasticsearch.yml-дың негізгі параметрлері
# /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 үйіндісінің өлшемі - RAM-ның 50% қойыңыз, 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 үйіндісі қоқыс жинауды тоқтатып қояды | Нақты жүктеме жоқта бірнеше секундтық кездейсоқ үзілістер |
Адамдарды нақ шард саны шатастырады, себебі кластер баяулағанда бірінші түрткі - түйін қосып, индекстерді әрі бөлу. Сонда есеп жүргізуге үйіндіден көбірек кетеді және мәселе ауырлайды. Алдымен қанша шардыңыз бар екенін санаңыз: жыл ішінде күн сайынғы индекс - айлық индекс 12 берер жерде 365 шард.
Күтілетін өнімділік көрсеткіштері
Elasticsearch 8.x және 16 ГБ JVM үйіндісі бар 8 vCPU / 32 ГБ RAM / NVMe түйінінде:
- Индекстеу өткізу қабілеті (bulk API, 1000-дық партиялар) - секундына 15 000-30 000 құжат
- Секундына іздеу сұранысы (қарапайым терм сұранысы) - 500-1 500
- Секундына іздеу сұранысы (күрделі агрегация) - 50-200
- P99 сұраныс кешігуі (кештен жылытылған сұраныс) - 10 мс-тен аз
- Сегменттерді біріктіру өткізу қабілеті - NVMe-де секундына 200-500 МБ
Шард саны - баптаудың ең күшті тұтқасы. Шардтарды 20-50 ГБ шамасында ұстаңыз. Шағын шард тым көп болса, үстеме шығын босқа кетеді; ірі шард тым аз болса, параллельдік шектеледі.
Бұл осы кластағы жабдыққа күтілетін шамалар, өз зертханамыздағы өлшемдер емес. Оларды есептеудің бастау нүктесі деп санап, өз жүктемеңізді өлшеңіз: нақты цифрлар провайдерден гөрі сіздің деректеріңізге, сұраныстарыңызға және баптауыңызға әлдеқайда күштірек байланысты.
Түйін
ЕО бұлт серверіндегі Elasticsearch іздеу индексі мен пайдаланушы деректерін ЕО юрисдикциясында ұстайды және сонымен бірге қосымшаңызға керек кешігуі төмен, өткізу қабілеті жоғары іздеуді береді. JVM үйіндісін RAM-ның 50% етіп қойыңыз, своп-ты өшіріңіз және продакшендегі төзімділік үшін 3 түйіндік кластер орналастырыңыз. DCXV бұлт серверлері Elasticsearch кластеріңізге керек NVMe қорын және деректерді ЕО ішінде сақтауды береді.
