AWS Elasticsearch: фундаментально дефектный продукт
Перевод статьи Nick Price
В настоящее время я работаю над большим проектом логирования, который изначально был реализован с использованием AWS Elasticsearch. Поработав с крупномасштабными магистральными кластерами Elasticsearch в течение нескольких лет, я совершенно повержен качеством реализации AWS и не могу понять, почему они не исправили или хотя бы улучшили ее.
Краткое изложение
Elasticsearch хранит данные в различных индексах, которые вы создаете в явной форме или которые могут быть созданы автоматически, после отправки данных. Записи в каждом индексе разбиты на определенное количество шардов, которые затем балансируются между узлами в вашем кластере (настолько равномерно, насколько это возможно, если количество ваших шардов не делится поровну на количество узлов). В ElasticSearch существует два основных типа шардов: основные шарды и шарды реплики. Шарды реплик обеспечивают отказоустойчивость в случае сбоя узла, а пользователи могут задавать количество шардов реплик отдельно для каждого индекса.
Работа стандартного Elasticsearch
Elasticsearch — он эластичный. Иногда он может быть довольно привередливым, но, в целом, вы можете добавлять узлы в кластер или удалять их. И если в случае удаления узла имеется подходящее количество реплик, Elasticsearch будет распределять шарды и даже балансировать нагрузку на узлы в кластере. Как правило, это работает.
Выполнение дорогих запросов иногда может привести к падению узлов и тому подобному, но большое количество настроек помогает поддерживать работу. При достаточном количестве шардов реплик, если узел падает, это не сказывается на работе в целом.
Стандартный Elasticsearch также имеет ряд доступных дополнений, включая X-Pack, функции аудита, детализированного ACL, мониторинга и оповещения. Большая часть X-Pack недавно стала бесплатной, вероятно, в ответ на новую политику лицензии Splunk.
Работа Amazon Elasticsearch
Как обычно, Amazon взял открытый исходный код части Elasticsearch, сделал хард-форк и начал продавать его в качестве собственного сервиса, постепенно внедряя свои собственные версии функций, которые многие годы были так или иначе доступны в основной версии Elasticsearch.
В продукте от Amazon отсутствуют многие вещи, такие как: RBAC и аудит, что для нас особенно проблематично, поскольку мы принимаем логи от разных команд и хотели бы отделять их друг от друга. В настоящий момент любой пользователь, имеющий доступ к Elasticsearch, обладает всеми правами доступа и может случайно удалить чужие данные, изменить способ их репликации на узлах и полностью прекратить прием данных, добавив неверный шаблон индексации.
Это расстраивает, но это не самая большая проблема с сервисом. Перебалансировка шардов — центральный концепт Elasticsearch, не работает в реализации AWS, что сводит на нет почти все хорошее в Elasticsearch.
Обычно, когда данные добавляются в узлы, один может наполниться больше, чем другие. Это ожидаемо, поскольку нет никаких гарантий, что загружаемые записи будут иметь одинаковый размер или что количество шардов всегда будет равномерно распределено по всем узлам кластера. Это не критично, потому что Elasticsearch может перебалансировать шарды между узлами, и если один узел действительно заполнится, то другие узлы с радостью начнут принимать данные вместо заполненного.
Это не поддерживается на Amazon. Некоторые узлы могут заполняться (намного) быстрее других.
Более того, в Amazon, если одному узлу в вашем кластере Elasticsearch не хватает свободного места, весь кластер прекращает прием данных, происходит полная остановка. Решение Amazon заключается в том, чтобы пользователи проходили через кошмар периодического изменения количества шардов в своих шаблонах индексации, а затем реиндексации ранее созданных данных в новые индексы, удаления предыдущих индексов, а при необходимости, и обратной индексации данных в прежнюю структуру. Это совершенно излишне, и требует, помимо больших вычислительных затрат, чтобы необработанная копия загруженных данных сохранялась вместе с проанализированной записью, потому что необработанная копия потребуется для повторной индексации. И, конечно, это удваивает объем памяти, необходимый для «нормальной» работы на AWS.
«Упс! Я не переиндексировал весь кластер достаточно часто, и узел заполнился! Что делать?»
У вас есть два варианта действий. Во-первых, удалите столько данных, сколько необходимо для возвращения кластера к жизни, а затем начните переиндексацию с надеждой, что ничего не развалится. У вас же есть бекап того, что вы хотите удалить?
Второй вариант — добавить больше узлов в кластер или изменить размеры существующих на больший размер инстансов.
Но, подождите, как добавлять узлы или вносить изменения, если нельзя перебалансировать шарды?
Решение Amazon — это сине-зеленое развертывание. Они раскручивают целый новый кластер, копируют все содержимое предыдущего кластера в новый, а затем переключаются и уничтожают старый кластер.
Подобные задания по изменению размера могут занимать дни, для больших кластеров, как вы можете себе представить, дублирование нескольких триллионов записей может занять какое-то время. Это также создает безумную нагрузку на существующий кластер (вероятно, уже превышающий емкость) и может фактически вызвать сбой кластера. Я выполнил несколько подобных операций на более чем 30 кластерах в AWS и только один раз я наблюдал успешное завершение в автоматическом режиме.
Итак, вы попытались изменить размер своего кластера, и задание не выполнилось. Что теперь?
Взаимодействие с Amazon
Ваше задание по изменению размера кластера оборвалось (для сервиса, который вы, вероятно, выбрали, чтобы не иметь дело с подобной статьей), поэтому вы открываете тикет в техподдержку AWS с наивысшим приоритетом. Конечно, они будут жаловаться на количество или размер вашего шарда и будут любезно добавлять ссылку на «best practices», которые вы прочитали уже 500 раз. И затем вы ждете, пока это исправят. И ждете. И ждете. В последний раз, когда я пытался изменить размер кластера, и он заблокировался, что привело к серьезным сбоям в работе, потребовалось СЕМЬ ДНЕЙ, чтобы вернуть все в онлайн. Они восстановили сам кластер за пару дней, но, когда все остановилось, очевидно, что узлы, на которых работает Kibana, потеряли связь с основным кластером. Служба поддержки AWS потратила еще четыре дня, пытаясь что-то исправить, параллельно интересуясь, работает ли Кибана. Они даже не знали, исправили ли они проблему, и мне пришлось проверять, восстановили ли они связь между их собственными системами. С тех пор я перестал делать что-либо, кроме удаления данных, если узел заполняется.
Расходы нашей организации на AWS огромны. Это дает нам возможность периодически встречаться с их экспертами в различных областях, обсуждать стратегии реализации и разбираться с множеством технических вопросов. Мы договорились о встрече с представителем Elasticsearch, во время которой я провел большую часть встречи, объясняя основы Elasticsearch и описывая… причуды… их продукта. Эксперт был в полном шоке, что все рушится, когда узел заполняется. Если отправленный эксперт не знает основ работы своего продукта, неудивительно, что команде поддержки требуется семь дней, чтобы возобновить работу производственного кластера.
Мысли напоследок
В проекте логирования, в который я погрузился, есть доля архитектурных ошибок и слабых дизайнерских решений, над которыми мы сейчас работаем. И я, конечно, ожидал, что AWS Elasticsearch будет отличаться от исходного продукта. Однако в AWS Elasticsearch отключено или отсутствует так много фундаментальных функций, что это усугубляет практически все проблемы, с которыми мы сталкиваемся.
Для легкого использования и небольших кластеров AWS Elasticsearch работает достаточно хорошо, но для кластеров петабайтных размеров, это был бесконечный кошмар.
Мне крайне любопытно, почему реализация Elasticsearch в Amazon не умеет балансировать шарды; это довольно фундаментальная функциональность Elasticsearch. Даже несмотря на ограничения по сравнению с основным Elasticsearch, он, безусловно, был бы приемлемым продуктом для больших кластеров, если бы просто работал должным образом. Я не могу понять, почему Amazon предлагает что-то настолько сломанное, и почему не исправили ситуацию более чем за два года.
Как полагают другие, и это представляется разумным, подобное поведение является признаком реализации AWS, спроектированной как гигантский мультитенантный кластер, пытающийся обеспечить изоляцию, чтобы сделать его похожим на автономный кластер для конечных пользователей. Даже с такими опциями, как зашифрованные данные в покое и зашифрованная передача данных, это кажется правдоподобным. Или, возможно, их инструменты и конфигурации просто являются наследством намного более ранней архитектуры.
И, как заметил мой друг, довольно забавно, что они все еще называют его «Эластичным», когда вы не можете добавлять или удалять узлы из ваших кластеров, не раскручивая новый и не перенося все ваши данные.
Сноска: когда я писал этот текст, то обнаружил пост двухгодичной давности со многими аналогичными претензиями: read.acloud.guru/things-you-should-know-before-using-awss -elasticsearch-сервис-7cd70c9afb4f
