Масштабирование Elasticsearch (2 серии деталей)
Каждый хочет, чтобы их кластер Elasticsearch индексировал и искал быстрее, но оптимизация оба в масштабе может быть сложной. В 2015 году Кластер Кенны провела 500 миллионов документов, и мы обработали миллион из них в день. В то время Elasticsearch была наименее стабильной частью нашей инфраструктуры и едва ли мог идти в ногу, поскольку наш размер данных вырос. Сегодня наш кластер имеет более 4 миллиардов документов, и мы с легкостью обрабатываем более 350 миллионов из них в день.
Создание кластера для удовлетворения всех наших индексаций и поиска требований было нелегко. Но с большим количеством настойчивости и несколькими «О, дерьмо!» Моменты, мы сделали это и узнали, черт возьми, многое многое на этом пути. В этом блоге двух частей я поделюсь методами, которые мы использовали в Кенне, чтобы привести нас туда, где мы находимся сегодня. Однако, прежде чем я погрузился во все веселье Elasticsearch, я сначала хочу рассказать вам немного о Кенне.
Кенна помогает компаниям Fortune 500 управлять риском кибербезопасности. Средняя компания имеет 60 тысяч активов. Актив — это в основном все с IP -адресом. Средняя компания также имеет 24 миллиона уязвимостей. Уязвимость — это то, как вы можете взломать актив. Со всеми этими данными для компаний может быть чрезвычайно трудно знать, на чем им нужно сосредоточиться, и сначала исправить. Вот куда входит Кенна. В Кенне мы берем все эти данные и проводим их через наши проприетарные алгоритмы. Эти алгоритмы затем сообщают нашим клиентам, какие уязвимости представляют самый большой риск для их инфраструктуры Поэтому они знают, что им нужно сначала исправить.
Первоначально мы храним все эти данные в MySQL, что является нашим источником истины. Оттуда мы индексируем данные актива и уязвимости в Elasticsearch:
Elasticsearch — это то, что позволяет нашим клиентам действительно нарезать и нарезать свои данные в любом случае, поэтому скорость поиска является главным приоритетом. В то же время данные постоянно меняются, поэтому индексация также чрезвычайно важна.
Давайте начнем с того, как мы смогли масштабировать нашу индексационную способность. Несмотря на наш бурный старт, мы получили одну вещь прямо с самого начала, и это устанавливало наш интервал обновления.
Во -первых, что такое обновление Elasticsearch? Elasticsearch Refresh-это когда Elasticsearch промывает буферы в памяти и передает данные, которые вы недавно проиндексировали в сегмент. При совершении сегмента, он в основном просто пишет его на диск. Когда вы первоначально индексируете данные, он хранится в буфере, как это:
Затем, когда происходит обновление, эти данные привержены сегменту и становятся доступными для поиска. Этот процесс показан ниже.
Интервал обновления Elasticsearch диктует, как часто Elasticsearch выполняет обновление. По умолчанию Elasticsearch использует Один второй интервал обновления Анкет Это означает, что он промывает эти буферы каждую секунду. Обновление индекса занимает значительные ресурсы, что отнимает от ресурсов, которые вы можете использовать для индексации. Один из самых простых способов ускорить индексацию — это увеличить интервал обновления. Увеличив его, вы уменьшите количество выполненных обновлений и, таким образом, освободите ресурсы для индексации. У нас есть наши на 30 секунд.
Наши обновления данных клиента обрабатываются фоновыми заданиями, поэтому ожидание дополнительных 30 секунд, чтобы данные были доступны для поиска, не имеет большого значения. Если 30 секунд слишком длинны для вашего варианта использования, попробуйте 10 или 20. Все, что больше, чем один, вы получите индексацию.
Как только у нас появился интервал обновления, это было плавное плавание — пока мы не получили нашего первого большого клиента. У этого клиента было 200 000 активов и более 100 миллионов уязвимостей. Получив их данные в MySQL, мы начали индексировать их в Elasticsearch, но это было медленно. Через пару дней индексации мы должны были сказать этому клиенту, что потребуется две недели, чтобы индексировать все их данные. ДВЕ НЕДЕЛИ! 😬 Очевидно, что это не сработает в долгосрочной перспективе. Решением было объемная обработка.
Вместо индексации документов индивидуально,
Мы сгруппировали их в одну партию и индексировали их все сразу, используя объемный запрос.
Мы обнаружили, что индексация 1000 документов в каждом объемном запросе дала нам самый большой повышение производительности. Размер, который вы хотите сделать, будут зависеть от размера вашего документа. Для получения советов по поиску оптимального размера партии, проверьте Предложения Elastic для объемной обработки Анкет
Один только объемная обработка привела нас в течение длительного года роста. Затем, в прошлом году, MySQL получил капитальный ремонт, и внезапно Elasticsearch не мог не отставать. В период пикового индексации CPU узел будет максимально максимальным, и мы начали получать группы 429 (to_many_requests) ошибок.
Да, это действительно снимок экрана наших узлов во время одного из наших индексационных наборок! Наш кластер не мог справиться с объемом данных, которые мы пытались втянуть в него, и начал отклонять запросы. После большого количества документов, чтения и гуглей, мы внезапно стали очень осведомленными о темах и роли, которую они играют в индексации. Это приводит меня к последнему совету, направляйте свои документы!
Когда вы индексируете набор документов, количество потоков, необходимых для выполнения запроса, зависит от того, сколько осколков, в которых принадлежат эти документы. Давайте посмотрим на две партии документов:
Для индексации каждой партии потребуется четыре потока, потому что каждый должен поговорить с четырьмя осколками. Простой способ уменьшить количество потоков, необходимых для каждого запроса, — это сгруппировать ваши документы с помощью Shard. Возвращаясь к нашему примеру, если вы сгруппируете документы Shard, вы можете сократить количество потоков, необходимых для выполнения запроса вдвое.
Кажется легко, верно? За исключением того, как вы узнаете, на каком Shard принадлежит документ? Ответ маршрутизация Анкет Когда Elasticsearch определяет, какой Shard будет размещать документ на него, использует эту формулу:
Значение маршрутизации по умолчанию в документ _id Или вы можете установить это самостоятельно. Если вы установите его самостоятельно, то вы можете использовать его, когда вы индексируете документы. Давайте снова посмотрим на этот пример. Поскольку наше значение маршрута соответствует Shard, в котором принадлежит документ, мы можем использовать его для группировки наших документов и сокращения количества потоков, необходимых для выполнения каждого запроса.
В Кенне у нас есть отношения родителей/ребенка между активами и уязвимостями. Это означает, что родитель, или Asset_id, используется для маршрутизации. Когда мы индексируем уязвимости, мы группируем их по Asset_id, чтобы уменьшить количество потоков, необходимых для выполнения каждого запроса.
Группирование документов по их маршрутам позволила нам значительно увеличить индексацию, сохраняя при этом кластер счастливым.
- Переключите интервал обновления
- Объемные процессовые документы
- Направить свои документы
Эти методы привели Кенну до такой степени, что мы можем обрабатывать более 350 миллионов документов в день, и у нас еще есть место для роста. Когда ваш кластер не маленький, и вы не обрабатываете много данных, эти небольшие корректировки легко пропустить. Однако, поскольку вы масштабируете, я гарантирую, что эти методы будут бесценными. Планируйте заранее и начните реализовывать эти стратегии индексации сейчас, чтобы вы могли избежать замедления в будущем.
Теперь скорость индексации — это только половина картинки. В Кенне поиск также является главным приоритетом для наших клиентов. Во второй части этого поста в блоге я погрузимся во все способы, которыми Кенна смогла ускорить свой поиск при масштабировании своего кластера.
Этот блог был первоначально опубликован elastic.co
Масштабирование Elasticsearch (2 серии деталей)
Оригинал: «https://dev.to/molly/scaling-elasticsearch-part-1-how-to-speed-up-indexing-2pel»