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

Alex Alex 31 жовтня 2019

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

Source: habr.com

Коментарі (0)

    Ще немає коментарів

Щоб залишити коментар необхідно авторизуватися.