Данное руководство по устранению неисправностей основано на личном опыте нашего эксперта по OpenSearch, столкнувшегося с всплеском поискового трафика, и посвящено тому, как правильная конфигурация первичных шардов и реплик может помочь OpenSearch справиться с подобными ситуациями. Если вы хотите получить базовое представление о шардах и репликах, прочтите это.
Иногда сервис получает огромное количество поискового трафика одновременно, возможно, в связи с каким-то событием (например, распродажей "черной пятницы" на сайте электронной коммерции) или в результате DDoS-атаки. Ожидается, что при наличии легитимного трафика поисковая система и сервисы будут работать в рамках SLA. Существует несколько обстоятельств, при которых внезапный всплеск легитимного поискового трафика (поиск и индексация) может происходить спорадически.
Когда вы запускаете кластер с производственной OpenSearch, он обычно интегрирован с некоторыми средствами мониторинга инфраструктуры, средствами анализа журналов, трафика и т.д., чтобы помочь в отладке производственных проблем. Несмотря на то что в приведенном ниже примере были использованы эти традиционные средства, команде потребовалось значительное время, чтобы найти первопричину проблемы.
Описание сбоя
В системе на одном кластере ОС (многопользовательский кластер ОС) размещалось несколько служебных индексов. Кластер ОС, на котором размещался поисковый индекс, до инцидента был мало загружен, а такие показатели кластера, как использование процессора и памяти, за предыдущие 15 дней составляли менее 40%. Инцидент начался с того, что сервисная служба получила информацию о значительном увеличении трафика (~5 раз) на одном поисковом функционале. Во время этого события пользователи начали испытывать замедление поиска, а на кластере появились предупреждения о высокой загрузке процессора. Это также повлияло на производительность других индексов, размещенных на том же кластере.
Руководство по устранению неисправностей повышенной задержки поиска
- Проверьте метрики инфраструктуры - высокую загрузку процессора, памяти, дисков, сети и кучи. Частая и длительная сборка мусора (GC) на узлах данных ОС является симптомом, и необходимо выявить его причину.
- Перед проверкой медленных журналов рекомендуется проверить статистику по автоматическим выключателям ОС - предполагаемое использование памяти, а также сколько раз и когда срабатывали выключатели. Оба эти параметра дают верный признак того, что поиск связан с нагрузкой, и могут помочь сузить круг поиска только до медленных журналов поиска. Количество журналов медленного поиска в индексе OpenSearch обычно значительно увеличивается при снижении времени отклика OpenSearch, как показано на приведенном ниже изображении из примера - ось Y на изображении представляет собой количество медленных запросов, занявших более 100 мс, а ось X - временной интервал.
- Проверку дорогостоящих запросов можно начать с интервала более 100 мс и увеличить этот интервал до 10 секунд или более в зависимости от задач. Идея состоит в том, чтобы выяснить, какие поисковые запросы работают хуже всего. Используйте API "горячих потоков" ОС, он помогает быстро определить, какие типы операций в запросах ОС потребляют больше всего процессора. К известным дорогостоящим запросам относятся тяжелые агрегаты и регекс-запросы.
- Если многие медленные запросы представляют собой базовые поисковые запросы (простые запросы с булевым совпадением без агрегирования), то возьмите эти примеры запросов и запустите их непосредственно на менее загруженных средах, например на стенде или в непиковое время на производственном кластере. Таким образом, можно проверить время отклика.
- Одна из причин того, что базовые и исторически быстрые поисковые запросы приходят в медленные журналы, заключается в том, что когда кластер выполняет тяжелые поисковые запросы и эти запросы потребляют большую часть ресурсов, то все остальные поисковые запросы в это время начинают выполняться медленно и выглядят как медленный поиск. Поэтому, чтобы ускорить поиск неисправностей, рекомендуется проверить временной диапазон начала проблемы и попытаться найти первые медленные поиски. Таким образом, вы избежите ложных срабатываний.
- Другой быстрый способ поиска тяжелых поисковых запросов - проверить, какие поисковые запросы раньше выполнялись быстро, и отбросить их. Если запрос выполняется периодически и обычно выполняется быстро, значит, это, скорее всего, не тот тяжелый поиск, который вы ищете, и он попадает в медленные журналы из-за эффекта пульсации от реальных тяжелых поисковых запросов. Очень важно понимать журналы медленных запросов для выявления и устранения проблем с производительностью OSv.
Данные о перебоях в работе
Конфигурация индекса ОС
- 5 основных шардов и 2 шарда-реплики.
- Общее количество документов ~500K, общий размер индекса ~2GB.
Конфигурация кластера ОС
- 6 узлов данных.
- 3 основных узла.
- На кластере размещено более 15 индексов с 5 шардами и 2 репликами для каждого индекса.
Анализ корневой причины сбоя в примере
С помощью приведенного выше руководства команда обнаружила, что эти запросы ОС выполняются на всех шардах, и ситуация оказалась хуже, чем предполагалось. Общий запрос ОС занимал не только ~2 секунды, как указано в журнале медленных запросов одного шарда, но и более 10 секунд в совокупности (включая все шарды) для одного запроса. Обратите внимание, что эти запросы выполнялись из строки поиска на сайте. Желательный SLA для этих запросов был в пределах 100 мс, а они обычно выполняются в пределах 50 мс, поэтому предел, настроенный для медленных запросов, составляет 50 мс в приложении, и его можно изменить, как описано в документации OpenSearch.
В этом индексе было всего 500 тыс. документов, а размер индекса составлял 2 ГБ, что вполне могло уместиться в 1 шард. Для запроса каждого шарда в ОС создается отдельный поток, а для поисковых запросов существует отдельный пул потоков фиксированного размера. Учитывая, что в кластере ОС было 6 узлов данных, а индекс ОС имел 5 первичных шардов, для получения результатов ОС должна была запросить все шарды, что требовало 5 потоков для каждого поискового запроса, что привело к исчерпанию поисковых потоков. Это приводило к замиранию потоков в состоянии ожидания и замедляло выполнение поисковых запросов.
Действия по устранению неисправностей в случае сбоя
Простое уменьшение количества первичных шардов для проблемного индекса с 5 до 1 помогло решить проблему, и после этого индекс работал достаточно стабильно даже во время пикового трафика. Как и во многих других случаях развертывания OpenSearch, в данном случае команда работала на старой версии ОС и использовала настройки OpenSearch по умолчанию. Как правило, лучше использовать отдельные шарды, если это возможно.
Важные советы и рекомендации по работе со всплесками поискового трафика
- Хотя OpenSearch имеет разумные значения по умолчанию для многих параметров при обычном развертывании, вам, вероятно, потребуется их настройка, если вы используете его для создания высокопроизводительных и масштабируемых систем.
- Рекомендуется поддерживать оптимальные размеры шардов. Оптимальный размер шарда для чтения должен находиться в пределах 30-50 Гбайт. В случае наличия большого количества небольших шардов, доступных только для чтения, рекомендуется объединить их в один шард с помощью API переиндексации.
- Жонглирование многими системами (мониторинг инфры, анализ журналов и различные панели мониторинга) требует значительных усилий во время таких перебоев, и если вы не являетесь экспертом в области ОС, вам может быть сложно самостоятельно устранить эти неполадки.
- Ознакомьтесь с нашим руководством по перераспределению ресурсов.
- Описанный выше случай - еще один пример того, как простая настройка параметров может привести к большим проблемам. Проверить, оптимизированы ли настройки OS.
ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
Как определить задержку поиска?
В OpenSearch предусмотрена возможность создания лог-вывода всех поисковых запросов, выполнение которых занимает больше определенного времени. Такой вывод называется "медленным журналом".
Каковы краткие рекомендации по уменьшению задержки поиска в OpenSearch?
- Оптимизация запросов
- Избегать использования скриптов
- Избегайте запросов, содержащих подстановочные знаки
- Использовать таймаут при поиске
- Избегайте сложных агрегатов, если они не нужны.
- Замораживайте неиспользуемые индексы
- Увеличить интервал обновления
- Увеличить размер кэша запросов узла
- Оптимизация шардов и реплик
- Увеличить аппаратные ресурсы