Хабрахабр

AWS Elasticsearch: фундаментально дефектный продукт

Перевод статьи Nick Price

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

Краткое изложение

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

Работа стандартного Elasticsearch

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

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

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

Работа Amazon Elasticsearch

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

Перебалансировка шардов — центральный концепт Elasticsearch, не работает в реализации AWS, что сводит на нет почти все хорошее в Elasticsearch. Это расстраивает, но это не самая большая проблема с сервисом.

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

Некоторые узлы могут заполняться (намного) быстрее других. Это не поддерживается на Amazon.

Решение Amazon заключается в том, чтобы пользователи проходили через кошмар периодического изменения количества шардов в своих шаблонах индексации, а затем реиндексации ранее созданных данных в новые индексы, удаления предыдущих индексов, а при необходимости, и обратной индексации данных в прежнюю структуру. Более того, в Amazon, если одному узлу в вашем кластере Elasticsearch не хватает свободного места, весь кластер прекращает прием данных, происходит полная остановка. И, конечно, это удваивает объем памяти, необходимый для «нормальной» работы на AWS. Это совершенно излишне, и требует, помимо больших вычислительных затрат, чтобы необработанная копия загруженных данных сохранялась вместе с проанализированной записью, потому что необработанная копия потребуется для повторной индексации.

Я не переиндексировал весь кластер достаточно часто, и узел заполнился! «Упс! Что делать?»

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

Второй вариант — добавить больше узлов в кластер или изменить размеры существующих на больший размер инстансов.

Но, подождите, как добавлять узлы или вносить изменения, если нельзя перебалансировать шарды?

Они раскручивают целый новый кластер, копируют все содержимое предыдущего кластера в новый, а затем переключаются и уничтожают старый кластер. Решение Amazon – это сине-зеленое развертывание.

Это также создает безумную нагрузку на существующий кластер (вероятно, уже превышающий емкость) и может фактически вызвать сбой кластера. Подобные задания по изменению размера могут занимать дни, для больших кластеров, как вы можете себе представить, дублирование нескольких триллионов записей может занять какое-то время. Я выполнил несколько подобных операций на более чем 30 кластерах в AWS и только один раз я наблюдал успешное завершение в автоматическом режиме.

Что теперь? Итак, вы попытались изменить размер своего кластера, и задание не выполнилось.

Взаимодействие с Amazon

Ваше задание по изменению размера кластера оборвалось (для сервиса, который вы, вероятно, выбрали, чтобы не иметь дело с подобной статьей), поэтому вы открываете тикет в техподдержку AWS с наивысшим приоритетом. Конечно, они будут жаловаться на количество или размер вашего шарда и будут любезно добавлять ссылку на «best practices», которые вы прочитали уже 500 раз. И затем вы ждете, пока это исправят. И ждете. И ждете. В последний раз, когда я пытался изменить размер кластера, и он заблокировался, что привело к серьезным сбоям в работе, потребовалось СЕМЬ ДНЕЙ, чтобы вернуть все в онлайн. Они восстановили сам кластер за пару дней, но, когда все остановилось, очевидно, что узлы, на которых работает Kibana, потеряли связь с основным кластером. Служба поддержки AWS потратила еще четыре дня, пытаясь что-то исправить, параллельно интересуясь, работает ли Кибана. Они даже не знали, исправили ли они проблему, и мне пришлось проверять, восстановили ли они связь между их собственными системами. С тех пор я перестал делать что-либо, кроме удаления данных, если узел заполняется.

Это дает нам возможность периодически встречаться с их экспертами в различных областях, обсуждать стратегии реализации и разбираться с множеством технических вопросов. Расходы нашей организации на AWS огромны. Эксперт был в полном шоке, что все рушится, когда узел заполняется. Мы договорились о встрече с представителем Elasticsearch, во время которой я провел большую часть встречи, объясняя основы Elasticsearch и описывая… причуды… их продукта. Если отправленный эксперт не знает основ работы своего продукта, неудивительно, что команде поддержки требуется семь дней, чтобы возобновить работу производственного кластера.

Мысли напоследок

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

Для легкого использования и небольших кластеров AWS Elasticsearch работает достаточно хорошо, но для кластеров петабайтных размеров, это был бесконечный кошмар.

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

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

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

Сноска: когда я писал этот текст, то обнаружил пост двухгодичной давности со многими аналогичными претензиями: read.acloud.guru/things-you-should-know-before-using-awss -elasticsearch-сервис-7cd70c9afb4f

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»