Как масштабировать Elasticsearch

Масштабирование Elasticsearch требует балансировки шарда, производительности запросов и настройки памяти для оптимальной эффективности в приложениях с высоким трафиком, в реальном времени.

Благодаря развитию современных приложений, служащих растущим потребностям в обработке и поиске данных в реальном времени, масштабируемость тоже. Одним из таких распределенных поисковых и аналитических двигателей с открытым исходным кодом является Elasticsearch, который очень эффективен для обработки данных в больших наборах и высокоскоростных запросах. Тем не менее, процесс эффективного масштабирования Elasticsearch может быть детальным, поскольку нужно правильное понимание архитектуры, стоящей за ней, и компромиссов производительности.

В то время как распределенная природа Elasticsearch позволяет ему масштабировать горизонтально, это также вводит больше сложностей в том, как данные распространяются и обслуживаются. Одной из теоретических проблем, связанных с масштабированием Elasticsearch, является его по своей сути распределенный характер. В большинстве практических сценариев чтение на автономном узле всегда превзойдет чтения в ловковом кластере. Это связано с тем, что в кластере Sharded владение данными распространяется по нескольким узлам. Это означает, что каждому запросу может придется выстрелить несколько запросов на разные узлы, агрегировать результаты обратно в координирующий узел и вернуть результат. Эти дополнительные сетевые накладные расходы легко приведут к увеличению задержки по сравнению с единой архитектурой, где доступ к данным прост.

В этом отношении кластеры Sharded имеют основополагающее значение для масштабирования Elasticsearch для больших наборов данных, с высоким трафиком и индексацией в реальном времени. Знание прекрасного баланса между распространением данных по узлам и низким содержанием задержки запроса является ключом к достижению оптимальной производительности. Кроме того, статья охватывает теоретические аспекты масштабируемости Elasticsearch, практические стратегии оптимизации производительности кластера и уроки, извлеченные из реальных опытов развертывания.

В SWOO, наше живое потоковое и игровое приложение, Elasticsearch была основой всего поиска всего, и это сработало просто по мере роста нашего пользователя. В тот момент, когда количество параллельных пользователей превышало 150 000, страница поиска начала время от времени терпеть неудачу, и было совершенно ясно, что в кластере Elasticsearch было какое -то узкое место. Вскоре это стало неприемлемым для живой игровой среды и заставило нас сделать серию оптимизаций, которые, наконец, стабилизировали как наш поисковый, так и домашнюю страницу.

Понимание архитектуры Elasticsearch для масштабируемости

Elasticsearch Nangy поддерживает распределенную архитектуру, что делает систему очень масштабируемой, но в то же время более сложной по сравнению с традиционными единичными решениями. Elasticsearch делит данные на индексы, причем каждый индекс, в свою очередь, разделен на осколки. Shard является основной единицей хранения и индексации данных в Elasticsearch, поскольку система распределяет и параллелизирует операции поиска по нескольким узлам кластера.

Типичный кластер будет содержать ряд узлов данных, размещающих подмножество данных, которые выполняют поисковые запросы. По умолчанию Elasticsearch может автоматически распространять данные по узлам, поэтому каждый узел выполняет только часть загрузки запроса. Таким образом, Elasticsearch масштабирует горизонтально: он обрабатывает все больше и больше данных и обслуживает все больше и больше запросов, просто добавляя в него узлы.

Этот компромисс в масштабируемости с производительностью запроса, конечно, является одной из самых важных вещей, которые следует учитывать при разработке кластеров Elasticsearch, особенно тех приложений, требующих высокой пропускной способности записи в сочетании с низкой задержкой чтения. Такая проблема действительно запрашивает тщательную конфигурацию кластера, а также сочетание методов оптимизации.

Итак, по сути, в нашем кластере Elasticsearch было несколько узлов данных для случая Swoo и три выделенных мастер -узла. Каждый узел работал на 8-ядерном процессоре с 16 ГБ оперативной памяти, в основном нацеленном на индексацию в реальном времени и мгновенный поиск игровых событий. Поскольку мы работаем в высокой параллелистике, нам нужно посвятить действительно существенную сетевую полосу пропускания, чтобы обеспечить минимальную задержку между узлами.

Планирование стратегии масштабирования

Другими словами, масштабирование Elasticsearch эффективно требует анализа нынешних показателей эффективности, создания узких мест и четких целей в отношении масштабируемости. Например, было бы здорово контролировать задержку запроса, пропускную способность и здоровье кластера, чтобы понять ограничения вашего кластера. Вы сможете создать дорожную карту для оптимизации, выявив горячие осколки, шипы в процессоре и проблемы с памятью.

Другим важным действием, которое требует внимания с помощью масштабирования Elasticsearch, является планирование потенциала. Оценка использования диска, шаблона трафика и требования к удержанию для данных обеспечит правильный размер вашего кластера. Вообще говоря, горизонтальное масштабирование (добавление узлов в кластер), как правило, является лучшим подходом к увеличению данных и объеме трафика. В этом случае, однако, вертикальное увеличение масштабирования ресурсов отдельных узлов-май будет эффективным.

Наши прогнозы показали рост активных пользователей примерно на 10-15% месяца за месяц, причем каждый пользователь генерирует значительный объем данных о событиях в ходе использования игры. Основываясь на этих прогнозах, мы ожидали, что наш кластер поддержит здоровый рост в одновременных запросах наряду с увеличением объема индексированного документа. Таким образом, мы проанализировали, будет ли масштабирование горизонтально, добавив больше узлов данных или масштабируя вертикально путем модернизации наших текущих узлов для этого увеличения.

Методы основного масштабирования

Оптимизация Elasticsearch будет включать в себя ряд стратегий, каждая из которых нацелена на различные аспекты системы. Среди них наиболее эффективные методы включают оптимизацию приема данных, управление осколками и оптимизацию использования памяти.

Основными областями фокуса будут проглатывание данных. Elasticsearch Nangy поддерживает объемную индексацию, что означает, что вы можете отправить действительно большие партии документов в одном запросе. Это уменьшает накладные расходы и, как правило, ускоряет процесс индексации. Во-вторых, точная настройка интервала обновления может иметь все значение при быстрое употребление данных. Вы переопределяете интервал обновления по умолчанию на одну секунду на более высокое значение, скажем, на десять секунд, потому что это уменьшит стресс слишком частых обновлений на вашем кластере, и ваши записи будут быстрее.

Другие ключевые причины, которые составляют функцию масштабируемости Elasticsearch, включают управление Shard . В то время как Elasticsearch может масштабироваться горизонтально через шардинг, неуместный размер Shard фактически приводит к ухудшению производительности. Количество осколков слишком высоких или слишком низких результатов в ухудшенной скорости индексации и/или производительности запроса. Хитрость заключается в балансе для оптимальной производительности в Elasticsearch.

Конечно, управление памятью является еще одним очень важным фактором в масштабировании Elasticsearch. Вы определенно уменьшаете потребление ресурсов и улучшаете производительность ваших запросов, оптимизируя размер кучи JVM, настройку кеша данных полевых данных и включив кэш запросов. Правильное использование памяти и правильных настроек кэширования может предотвратить ошибки вне памяти и минимизировать накладные расходы сбора мусора.

Хорошее количество штамма Elasticsearch было связано с непрерывным приемом игровых данных в реальном времени. Мы оптимизировали трубопроводы приема, путем прохождения документов через объемный API. В периоды определенной пиковой нагрузки мы могли бы дополнительно увеличить размеры партий и увеличить период обновления для надлежащего компромисса между индексацией почти в реальном времени и общей стабильностью кластера.

Расширенные масштабирующие решения

Когда масштаб становится огромным, Elasticsearch требует более продвинутых методов, чтобы быть эффективными. Среди них выделяется оптимизация запросов.

ILM или управление жизненным циклом ILM или индекса-еще одна удивительная функция для точной настройки Elasticsearch в качестве возраста вашего набора данных. Вы сможете перемещать более старые данные на более медленное, более дешевое хранилище, сохраняя при этом наиболее актуальное на более быстрое и более доступное хранилище, масштабируя архитектуру, оказавшуюся горячей, холодной. Он сохраняет кластерные характеристики великолепной по мере роста кластера.

Последние темы обсуждения, касающиеся масштабируемости Elasticsearch, являются оборудованием. По мере роста вашего кластера вы захотите убедиться, что аппаратное обеспечение должным образом предоставляется для увеличения нагрузки. Это означало бы, что узлы имеют соответствующий процессор, память и диск ввода/вывода для эффективной работы. DIS или NVME -диски значительно улучшат производительность, особенно для индексации и поисковых операций, которые требуют высокой скорости доступа к данным.

Одним из тяжелых уроков было то, что присвоение только количества осколков по умолчанию для новых индексов доставит нам неприятности с горячими пятнами. Мы также нашли сладкое место, где ни один осколок действительно не был перегружен основной частью обновлений в реальном времени, поступающих с нашей игровой платформы с помощью индексов с тяжелыми записями, перераспределенными по нескольким небольшим осколкам, соответствующим образом регулируя реплики.

Теоретические идеи и компромиссы оптимизации

В дополнение к практической оптимизации выше, есть несколько интересных теоретических соображений для масштабирования Elasticsearch. Одно ключевое понимание включает в себя масштабируемость и компромиссы эффективности запросов в распределенной системе. В частности, отмечается, что, хотя кластеры осколков горизонтально масштабируемы, они увеличивают накладные расходы, потому что результаты нескольких узлов должны быть объединены. Это в отличие от одного узла, где данные находятся на локальной машине, и запросы могут быть выполнены без необходимости «разговаривать» с другими узлами. Понимание этого компромисса важно, если кто-то разрабатывает кластер Elasticsearch, который должен сбалансировать производительность с масштабируемостью.

Еще одним более теоретическим аспектом масштабирования Elasticsearch является концепция местности данных. Вы можете запустить запросы только против локального узла, размещая соответствующие данные о осколках, используя preference=local Параметр запроса. Это сводит к минимуму связь между узлами и уменьшает задержку запроса. Это может снизить проблемы, которые возникают из -за репликации данных и балансировки нагрузки. Алгоритм выбора адаптивной копии Elasticsearch пытается оптимизировать выполнение запросов, выбрав лучший узел реплики в текущих условиях. Однако это не обязательно приносит наиболее эффективное выполнение запроса.

Первая волна неудач, которые мы испытали в нашей среде, связана с высоким давлением кучи JVM. Серверы Elasticsearch изначально работали с минимальными распределениями кучи, переживающими довольно частые циклы сбора мусора при высокой нагрузке запросов. Мы решили это, настраивая JVM, особенно выравнивая минимальный и максимальный размер кучи до 8 ГБ, что дало Elasticsearch достаточно места для обработки запросов, не перегружая кучу.

Общие ловушки и решения

Конечно, масштабирование Elasticsearch также не лишено проблем. Среди тех распространенных ошибок, которые человек хотел бы избежать,-это плохой размер осколков, отсутствие мониторинга, чрезмерное поправку на кэширование и не использование надлежащего управления жизненным циклом индекса. Они экономят довольно много времени и ресурсов, если они диагностируются на ранней стадии проактивной настройки конфигурации.

Одной из основных ловушек не было настройки настройки по умолчанию Elasticsearch, как в отношении распределения памяти, так и для управления осколками. По умолчанию работали нормально в условиях умеренного движения, но пристегнулись при пиковом трафике. Наше исправление было многослойным: это пересмотренное распределение кучи, репликация горячего индекса и краткосрочное кэширование для повторных запросов. В целом, он предотвращал повторные сбои во всем кластере и очень значительно сниженные тайм -ауты.

Руководство от разработчиков DST Global, по реализации Real-World

Масштабирование Elasticsearch будет включать в себя планирование, тестирование, развертывание и обслуживание после этого. Отсюда следует, что правильные практики, шаблоны конфигурации и тяжелое тестирование вашего кластера перед тем, как внедрить новые изменения в производстве, обеспечат беспрепятственное масштабирование в давний стабильный кластер.

- Точная настройка параметров JVM . Мы устанавливаем как XMS, так и XMX на 8 ГБ на каждом сервере Elasticsearch, что достигает баланса между доступной системной памятью и требованиями кучи.

- Оптимизация распределения осколков . Большие индексы были разделены на осколки меньшего размера, чтобы предотвратить горячие точки и масштабирование реплик для наиболее активных индексов. Это гарантировано, что трафик запроса был равномерно распределен по всему кластеру.

- Включить кэширование короткого TTL . Мы применили 1-секундное окно кэша на часто используемые статические запросы на домашней странице и заметили, что это значительно снижает нагрузку на Elasticsearch для повторяющихся запросов, не теряя отзывчивости в реальном времени.

- Мониторинг и итерация . Мы использовали Kibana, с некоторыми пользовательскими мониторными панелями для наблюдения за Health Health, производительности JVM и задержек запросов. Основываясь на этих показателях, тонкие настройки делались непрерывно.

Планы вперед или расширение технического стека

Кроме того, для роста мы хотели бы изучить управление жизненным циклом индекса с горячим планом, перемещая менее часто доступные данные к более дешевым узлам, сохраняя при этом аппаратное обеспечение высшего уровня для индексации и запросов в реальном времени. Мы изучаем передовые решения для мониторинга и обнаружение аномалий, управляемых искусственным интеллектом, чтобы убедиться, что шипы или замедление в необычных запросах находятся в результате воздействия на пользовательский опыт.

Заключение

Масштабирование Elasticsearch требует понимания архитектуры, тщательного планирования и создания лучших практик. Как бы то ни было, как elasticsearch масштабируется горизонтально через Sharding, это возникает с несколькими проблемами, которые необходимо контролировать для оптимальной производительности. Высокая масштабируемость и производительность кластера Elasticsearch могут быть обеспечены с помощью надлежащего приема данных, управления осколками, использования памяти и оптимизации запросов.

Принимая во внимание, что в нашем случае также требовалась миграция в Elasticsearch, без каких -либо сомнений, помимо чисто технических вопросов, важным вкладом был связан с пониманием теоретических трудностей, которые фактически скрыты в распределенных системах. Такая осторожная настройка по мнению разработчиков компании DST Global и творческие проблемы могут позволить большему растущему времени-мультицендорский отдельный кластер Elasticsearch-который должен получать миллионы запросов в день, улучшая показатели запроса при значительно уменьшенном времени отклика. Теоретические и практические элементы смешиваются вместе при масштабировании вашего развертывания Elasticsearch, чтобы обеспечить долгосрочный успех.