Elasticsearch 7.0 GA: мигрировали с 6.x, переписали запросы, убрали nginx-прокси

Elastic выкатили 7.0 GA в конце апреля. Мы прочитали release notes несколько месяцев назад, когда вышли беты, и в уме уже отметили: миграция с 6.x будет не бесплатной. Так и получилось - но итог скорее положительный, чем нет.

Контекст: что у нас живёт на ES

На проекте по аналитике поведения пользователей Elasticsearch выступает в роли поискового и аналитического слоя: raw-события из нескольких источников, индексы за скользящий период, несколько агрегирующих дашбордов в Kibana. Данные льются через Logstash, часть - напрямую через bulk API. Версия до миграции - 6.7, кластер из трёх data-нод и двух master-eligible-нод.

Главное изменение: mapping types исчезли

В ES 6.x каждый индекс мог содержать несколько mapping types - _doc, event, user и так далее. В 7.0 это убрали: один индекс - один тип, и этот тип называется _doc. Обращения к /{index}/{type}/{id} перестали работать как раньше.

У нас в коде было несколько мест, где запросы явно указывали тип. Конкретно - поиск с указанием type в URL и несколько мест в Logstash-конфигурации с document_type. Пришлось пройтись по всем точкам вхождения и переписать.

Что изменили:

• URL-запросы. Были запросы вида GET /events-2019.04/session/_search - переписали на GET /events-2019.04/_search. Тривиально, но надо найти все.
• Logstash output. Параметр document_type в elasticsearch output deprecated ещё в 6.x, но работал. В 7.0 его убрали. Заменили на index с явным именем индекса.
• Mapping templates. В index templates убрали обёртку с именем типа - маппинг теперь сразу под mappings, без {"session": {...}} вокруг.
• Multi-type запросы. Это самое болезненное место: несколько аналитических запросов использовали feature cross-type search - искали по нескольким типам в одном индексе. С удалением типов этот паттерн просто исчез. Переосмыслили схему индексов: то, что лежало в разных типах одного индекса, разбили по отдельным индексам. Больно один раз, зато схема стала понятнее.

Elastic честно предупреждал об этом с 6.0 - deprecation notice висел давно. Кто читал release notes заблаговременно, тот не удивился. Кто не читал - те несколько часов отладки обеспечены.

Движок кластеризации: ZenDiscovery заменили на Zen2

В 7.0 заменили механизм выбора мастера и управления кластером. Это внутренняя механика, напрямую в конфиге не заметна, но при миграции надо учесть: настройка discovery.zen.minimum_master_nodes больше не нужна и игнорируется. Вместо неё кластер сам выбирает кворум исходя из cluster.initial_master_nodes, который указывается только при первом запуске.

У нас в elasticsearch.yml висел старый discovery.zen.minimum_master_nodes: 2 - убрали, добавили cluster.initial_master_nodes при первом старте нового кластера. Ничего сложного, но если забыть убрать старую настройку и не добавить новую - кластер не стартует корректно.

Встроенная безопасность - это неожиданно приятно

До 7.0 базовая безопасность в Elasticsearch требовала лицензии X-Pack. TLS между нодами и simple аутентификация - платно. На большинстве проектов это обходили либо держа кластер в закрытой сети, либо ставя nginx-прокси перед HTTP API с базовой аутентификацией. Не идеально, но работало.

В 7.0 Elastic перелицензировал часть функций безопасности в базовую (бесплатную) лицензию. Теперь доступны:

• TLS между нодами кластера - без доплаты.
• Базовая аутентификация по паролю для HTTP API.
• Встроенные роли - read-only, kibana_user, и несколько стандартных.

Мы настроили TLS transport между нодами и включили аутентификацию на HTTP. Встроенная утилита elasticsearch-setup-passwords генерирует пароли для системных пользователей (elastic, kibana, logstash_system) за пару минут. Kibana получила свой пользователь kibana с ограниченными правами, Logstash - своего с правами на запись в индексы.

Nginx-прокси, который до этого висел перед ES HTTP и раздавал базовую аутентификацию, убрали. Одна движущаяся часть меньше. Сертификаты сгенерировали через elasticsearch-certutil, подписали внутренним CA - для внутреннего кластера этого достаточно.

Про новый движок координации запросов

В 7.0 появился адаптивный выбор replica shard для поиска - раньше это был round-robin, теперь координатор учитывает нагрузку и latency реплик при выборе. На нагруженном кластере это должно выравнивать нагрузку. У нас кластер не настолько нагруженный, чтобы разница была очевидна в цифрах, но направление правильное.

Порядок миграции

Делали rolling upgrade через 6.7. ES поддерживает миграцию с одной major-версии на следующую только через последний минор предыдущей. Порядок такой:

1. Обновить 6.x до 6.7 (если ещё не на последнем миноре).
2. В Kibana запустить Migration Assistant - он покажет индексы с несовместимыми маппингами.
3. Reindex старые индексы с несовместимыми настройками (у нас таких было два старых индекса с пятисимвольными field names из legacy-данных - в 7.0 минимальная длина field name не изменилась, но пара других устаревших настроек маппинга не поддерживается).
4. Rolling upgrade нод по одной: останавливаем, обновляем пакет, стартуем, ждём green кластера, переходим к следующей.

Весь процесс занял несколько часов с учётом reindex старых индексов. Downtime для чтения - ноль: кластер в rolling upgrade работает. Записи на время upgrade по каждой ноде на несколько секунд приостанавливались, это приемлемо.

Промежуточный итог

Mapping types - болезненная, но разовая история. Переписать запросы пришлось, но это технический долг, который в 6.x просто откладывался. Схема индексов стала чище.

Встроенная безопасность - это реально приятный сюрприз. Убрать nginx-прокси как костыль перед HTTP API и получить нормальную аутентификацию в базовой лицензии - именно то, чего не хватало. Для проектов по DWH и аналитике это снимает один из регулярных вопросов при выборе стека.