Оптимізація Elasticsearch: де ламається пошук під навантаженням
Кластер Elasticsearch рідко ламається одразу — він деградує поступово, і перший симптом помічає не інженер, а користувач: повільний пошук під навантаженням, коли видача приходить за секунди замість мілісекунд.
Причина найчастіше в розкладці даних — шарди й сегменти індексу розподіляються нерівномірно, один вузол тримає гарячий шард з основною часткою трафіку, решта простоюють, і додавання реплік картину не змінює.
Друге джерело — режим оновлення індексу.
Занадто частий refresh_interval тримає свіжі сегменти в пам'яті та витрачає ресурси на перезбирання, а не на пошук; merge не встигає за потоком записів, кількість сегментів на шард зростає, і кожен запит читає більше структур, ніж потрібно.
Поверх лягають важкі запити — агрегації по всьому індексу, пошук за підрядком, глибокий посторінковий обхід: окремо терпимо, в сумі вони з'їдають пам'ять і змінюють профіль віддачі.
Пік проявляється як деградація пошуку в пік: черга запитів зростає, затримки пошукових запитів множаться, частина звернень падає за таймаутом, а кластер витрачає час на узгодження стану між вузлами замість відповіді.
Ціна конкретна: користувач не знаходить товар чи документ і йде, а підтримка отримує потік звернень без виразної причини.
Оптимізація Elasticsearch — це не «покрутити параметри», а розбір конкретних місць відмови: розкладки шардів, політики оновлення та профілю запитів. Розбираємо, як це закривається.
Що дає оптимізація Elasticsearch: швидкість і стабільність
Час віддачі запиту в Elasticsearch визначається не потужністю вузлів, а розкладкою даних і частотою оновлення індексу.
Поки шарди розподілені по вузлах нерівномірно, а пошукові запити збирають усю видачу цілком, кожне зростання каталогу віддається подовженням відповіді — спочатку на частки секунди, далі на секунди, і це помічають уже користувачі.
Окремо про профіль навантаження: пік пошуку і пік запису майже ніколи не збігаються за характером.
Якщо інтервал оновлення індексу залишити на значенні за замовчуванням, кластер перезбирає сегменти на кожній порції нових даних — під піком це дає чергу запитів і періодичні перевищення часу очікування, які виглядають як випадкові відмови.
Оптимізація знімає саме цей клас відмов: кількість шардів приводиться до обсягу, який вузол перетравлює без перекосу, запис переводиться на рідше оновлення індексу, а важкі вибірки переписуються під те, що реально показує екран, замість «взяти все й відсортувати на боці застосунку». Швидкість пошуку зростає на тій самій конфігурації, а не за рахунок додавання заліза.
На виході — стабільність кластера й передбачувана робота під піком: час відповіді перестає залежати від добового ритму, а відмова «пошук недоступний у годину найбільшого навантаження» зникає зі статистики. Далі розбираємо, які параметри за це відповідають і як перевірити їх на вашому індексі.
Як розв'язують задачу: шардування, переіндексація, налаштування запитів
Шардування в Elasticsearch обирають один раз: кількість первинних шардів фіксується при створенні індексу, і змінити її без переіндексації не можна.
Тому спочатку рахують цільовий обсяг і профіль запитів, і лише потім чіпають розкладку — інакше шардів стає більше, а координація між ними дорожча.
Частина задач закривається без переіндексації: інтервал оновлення індексу, налаштування запитів і репліки змінюються на живому кластері. Нижче — варіанти, між якими реально обирають, та їхні обмеження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Переіндексація в новий індекс з іншою розкладкою шардів | Дані зросли, шарди перестали відповідати обсягу | Потрібне місце під другу копію, вікно синхронізації та план перемикання псевдоніма |
| Збільшення інтервалу оновлення індексу | Йде потоковий запис, затримка видимості нових документів прийнятна | Свіжі документи довше не потрапляють у пошук; не допомагає важким запитам |
| Налаштування пошукових запитів: фільтри замість повнотексту, обмеження полів у видачі | Багато широких запитів і агрегацій по всьому індексу | Потребує правок у застосунку; не лікує неправильну розкладку індексу |
| Додавання реплік | Потрібна відмовостійкість і розвантаження вузлів на читання | Множить обсяг зберігання та накладні витрати на запис; не прибирає перекіс шардів |
| Ручний розподіл шардів по вузлах | Є гарячі індекси та нерівномірне навантаження | Крихкий при заміні вузлів, потрібен регламент ребалансування |
Що беруть у комбінації
На практиці варіанти поєднують: розкладку змінюють один раз із запасом на зростання, а інтервал оновлення й запити правлять ітеративно. Кожну зміну перевіряємо на копії індексу та порівнюємо час відповіді до і після.
Етапи робіт: від аудиту кластера до передачі регламентів
Оптимізація Elasticsearch починається не з правки налаштувань, а з інвентаризації. Зміна кількості шардів або інтервалу оновлення індексу на живому кластері без заміру дає ефект, який складно відрізнити від збігу. Тому йдемо фіксованою послідовністю — від аудиту до регламентів у вашої команди.
- Аудит кластера. Знімаємо розмір індексів, розподіл шардів по вузлах, споживання пам'яті, черги та час відгуку. Фіксуємо базові метрики до будь-яких змін — інакше результат нема чим довести.
- Профілювання запитів. Розбираємо повільний лог і плани виконання, знаходимо запити з повним перебором документів та агрегації, які перераховують одні й ті самі дані.
- Схема індексів. Перезбираємо схеми полів і шаблони: кількість шардів і копій, розбиття за часом, правила життєвого циклу для старих даних.
- Налаштування режимів роботи. Підбираємо інтервал оновлення індексу під профіль навантаження: аналітиці частий перерахунок не потрібен, пошуку він критичний.
- Перевірка на бойовому трафіку. Проганяємо зміни на частині живого потоку та порівнюємо час відповіді, частку відмов і споживання ресурсів з базовими метриками.
- План відкату. Заздалегідь готуємо знімки стану, попередні шаблони та схеми полів, а також умову, за якої повертаємося до вихідної конфігурації.
- Передача регламентів. Віддаємо документацію по індексах, панелі моніторингу та оповіщення, навчаємо команду супроводжувати кластер самостійно.
Комплект передачі: схеми кластера, регламенти, панелі моніторингу
Передача кластера не закінчується тим, що пошук сьогодні відповідає швидко. Без описаної топології шардів, політик доступу та регламентів команда залишається з чорною скринькою: перша ж правка мапінгу чи зростання індексу повертає просідання.
Тому комплект передачі ми збираємо як робочу документацію, за якою експлуатацію можна вести без нас.
- Схема кластера: вузли та їхні ролі, розкладка шардів і реплік по індексах, запас за розміром шарда, порядок переіндексації при зростанні обсягу.
- Документація з налаштувань: значення refresh_interval, аналізатори, ліміти полів — із поясненням, чому обрано саме так і що зміниться при правці.
- Регламент супроводу: оновлення версії, злиття сегментів, вікна обслуговування, порядок дій при відмові вузла та втраті репліки.
- Права доступу до індексів: ролі застосунку, аналітики й адміністраторів, окремі облікові записи, режим лише читання для вітрин звітності.
- Панелі моніторингу: затримка пошуку та індексації, частка відмов, черга задач, стан шардів — з порогами для оповіщення чергового.
- Карта важких запитів: розбір звернень до та після оптимізації та список тих, що дешевше переписати, ніж масштабувати.
- Порядок оновлення та відкату: покрокова послідовність, перевірки після кожного кроку та точки повернення до попереднього стану кластера.
Кейс: пошук у каталозі перестав відвалюватися в пікові години
Що було вузьким місцем
Каталог на десятки тисяч позицій: на тестовому навантаженні пошук тримався впевнено, а в пікові вечірні години відгук просідав.
99-й процентиль виходив за кілька секунд, частина запитів закінчувалася помилкою за часом очікування, а кластер запускав ребалансування просто під навантаженням — відмова одного вузла тягла за собою сусідні. Закупівельники скаржилися, що підбір товару «зависає» саме тоді, коли йде основний виторг.
Що змінили і що це дало
Рознесли дані так, щоб пошук ішов паралельно: кількість основних шардів привели у відповідність до кількості вузлів, важкі фасетні вибірки винесли в окремий індекс.
refresh_interval підняли до 30 секунд там, де миттєва видимість не потрібна, — індексація перестала без кінця перезбирати сегменти. Глибоке посторінкове прокручування замінили курсорною навігацією: запити більше не читають весь індекс заради останніх сторінок видачі.
Метрики до і після: 99-й процентиль відгуку скоротився втричі, частка запитів, що впали за часом очікування, — з одиниць відсотків до нуля, відмов кластера в пік не було за весь період спостережень. Пропускна здатність індексації зросла приблизно вдвічі без заміни обладнання. Стек залишився на Elasticsearch — змінювали схему зберігання й профіль запитів, а не рушій.
Керівник напряму підтверджує: «Пошук перестав бути точкою ризику в пікові години, його більше не потрібно стерегти вручну».
Що робити, якщо переіндексація неможлива зараз
Переіндексація на живому кластері можлива без зупинки пошуку — зупинка потрібна там, де змінюється сенс поля і старі дані не можна прочитати по-новому.
Псевдонім індексу в Elasticsearch відокремлює ім'я, до якого звертаються застосунки, від фізичного індексу: нову версію збирають поруч, пошук відповідає на поточних даних, перемикання — зміна вказівника.
Робочі обхідні шляхи різняться за ціною та ризиком:
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Новий індекс поруч + перемикання псевдоніма | змінюється мапінг або аналізатор | потрібен запас диска й навантаження |
| Фонова переіндексація пакетами з обмеженням швидкості | правки точкові, кластер не перевантажений | довго, копія відстає |
| Подвійний запис в обидва індекси | індексація йде постійно | ускладнює код запису, потрібна звірка |
| Нічого не змінювати | правка не впливає на коректність видачі | борг накопичується, наступний прохід дорожчий |
Поступовий перевід трафіку — не «перемкнули й забули». Спочатку під псевдонім іде невелика частка запитів, видачі на новому й старому індексі порівнюють, розбіжності розбирають до переводу всього потоку. Відкат тут теж зміна вказівника, тому невдалий реліз не перетворюється на ручний розбір даних.
Відкладені правки накопичують борг непомітно: аналізатори розходяться з реальними формулюваннями запитів, шарди переростають розумний розмір, а наступна переіндексація потребує помітно більше ресурсів і гірше поєднується з плановим вікном. «Зробимо пізніше» виправдане лише там, де правка не впливає на коректність видачі.
Технічні сумніви: ризики, відкат, сумісність версій
Будь-яке втручання в працюючий пошуковий кластер починається зі зняття вихідного стану: знімок індексів, поточна карта шардів і реплік, фактичний інтервал оновлення, список повільних запитів за період спостереження.
Поки ці дані не зафіксовані, налаштувань не змінюємо — за ними будується план відкату й перевіряється, що після робіт кількість документів і видача контрольних вибірок збігаються з еталоном.
Цілісність даних тримається на порядку операцій: спочатку перебудовуємо шарди й репліки, дочікуємося повного відновлення копій, і лише потім чіпаємо інтервал оновлення індексу та формулювання запитів.
Кожен крок застосовуємо окремо, з контрольним заміром — видно, що дало ефект, і зрозуміло, який саме крок відкочувати при погіршенні.
Вікно робіт узгоджуємо заздалегідь і розтягуємо за етапами: частина налаштувань застосовується на живому кластері й оборотна однією командою, перебудову шардів виводимо в години мінімального навантаження.
Сумісність конфігурацій перевіряємо до робіт, а не в процесі — версія кластера, набір розширень і схеми індексів звіряються з планованими змінами на стенді з копією даних.
Як відкотитися, якщо після змін пошук працює гірше?
Відкат іде у зворотному порядку: повертаємо попередні значення налаштувань, потім розподіл шардів, за потреби піднімаємо індекс зі знімка.
Налаштування повертаються за хвилини, перебудова — за години, тому її призначаємо в узгоджене вікно й тримаємо попередню конфігурацію доступною до підтвердження результату.
Чи збережеться сумісність з поточною конфігурацією та клієнтським кодом?
Формат відповіді та схема полів залишаються попередніми, тому звернення з боку застосунку не переписуються. Якщо для оптимізації потрібно змінити тип або ім'я поля, додаємо псевдонім і перехідний період, упродовж якого працюють обидва варіанти.
Обговоримо вашу задачу: з чого почнемо
Щоб оцінка була предметною, а не «плюс-мінус», нам достатньо короткого технічного контексту: за ним видно, де вузьке місце — у топології кластера, у налаштуваннях індексації чи в самих запитах.
Нижче — що підготувати до обговорення; якщо частини даних немає, це теж робочий вхід, просто перший крок зміститься до діагностики.
- Топологія: кількість вузлів та їхні ролі, розміри індексів, кількість шардів і реплік, розподіл за гарячим і холодним зберіганням.
- Профіль навантаження: співвідношення пошуку й запису, добові обсяги, пікові вікна, вимоги до свіжості даних.
- Метрики за типовий період: затримки пошуку та індексації, черги на запис, відмови, швидкість зростання сховища.
- Поточні налаштування: refresh_interval, мапінги, політики життєвого циклу, шаблони індексів, ліміти на агрегації.
- Список важких запитів і агрегацій, на які скаржаться користувачі, — з прикладами викликів.
- Що вже пробували змінювати і до якого результату дійшли: це економить нам коло гіпотез.
Далі працюємо так. Перший крок з вашого боку — розмова про задачу та матеріали зі списку; з нашого — розбір конфігурації й запитів, гіпотези щодо вузьких місць і план робіт з етапами.
У плані фіксуємо, які метрики знімаємо до і після кожної зміни і в який момент відкочуємося, якщо стало гірше.
Наступний крок — узгодження обсягу: що закриваємо одразу, що окремою ітерацією після перевірки ефекту. Опишіть задачу у двох-трьох абзацах — повернемося з оцінкою та планом.
