Elasticsearch - это мощная, но хрупкая часть инфраструктуры с множеством вещей, которые могут привести к нестабильности сервиса AWS.

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

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

AWS Elasticsearch не предлагает ничего из этого. Нет даже API-интерфейсов, предназначенных только для чтения, таких как / _cluster / pending_tasks API, что было бы действительно удобно, учитывая, что количество задач в нашей очереди ожидающих задач неуклонно увеличивалось до более чем 60 тысяч.

Это проклятое сообщение преследует меня с тех пор, как несколько месяцев назад мне навязали Elasticsearch, размещенный на AWS:

{
  "Message":"Your request: '/_cluster/pending_tasks' is not allowed."
}

Спасибо, AWS. Спасибо….

Без доступа к журналам, без доступа к административным API, без метрик на уровне узла (все, что вы получаете, это агрегированные метрики на уровне кластера) или даже чертовых журналов запросов, в принципе невозможно устранить неполадки в собственном кластере Elasticsearch. Это оставляет вам один вариант, когда что-то пойдет не так: связаться со службой поддержки AWS.

В 9 случаях из 10 AWS просто пожалуется, что у вас слишком много шардов.

Горько забавно, что они упрекают вас за это, потому что по умолчанию любой созданный вами индекс будет содержать 5 осколков и 1 реплику. Любой ветеран ES скажет себе: черт возьми, я просто обновлю настройки кластера и уменьшу значение по умолчанию до 1 осколка! Неа.

{
  "Message": "Your request: '/_cluster/settings' is not allowed for verb: GET"
}

Ну, блин (хотя можно обойтись с помощью шаблонов индексов).

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

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

Добавление записи в список IP-адресов, которые имеют доступ к кластеру, приведет к увеличению размера кластера вдвое и переносу всех вонючих осколков.

Фактически, даже добавление единственного узла данных к кластеру приводит к его увеличению вдвое и перемещению всех данных.

Не верите мне? Вот фактический график количества наших узлов, поскольку мы имели дело со вчерашней проблемой:

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

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

Я часто задаюсь вопросом, сколько неоправданной сложности таится в промежуточном программном обеспечении AWS Elasticsearch. Моя теория заключается в том, что их кластеры ES являются мультитенантными. Почему еще конечная точка ожидающих задач может быть заблокирована? Иначе почему бы им не дать вам доступ к журналам ES? Иначе зачем им использовать так много полезных административных API за «запрещенным» Cerberus?

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

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

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

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

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

Спасибо за внимание! Если вам нравится то, что вы читаете, удерживайте расположенную ниже кнопку хлопка, чтобы другие могли это найти. Вы можете подписаться на меня в Twitter.