AWS Elasticsearch: produit fondamentalement défectueux

Traduction du Nick Price

Je travaille actuellement sur un grand projet de journalisation qui a été initialement implémenté à l'aide d'AWS Elasticsearch. Ayant travaillé avec les clusters dorsaux Elasticsearch à grande échelle pendant plusieurs années, je suis complètement submergé par la qualité de la mise en œuvre d'AWS et je ne comprends pas pourquoi ils ne l'ont pas corrigé ou du moins amélioré.

Résumé

Elasticsearch stocke les données dans divers index que vous créez explicitement ou qui peuvent être créés automatiquement après l'envoi des données. Les entrées de chaque index sont divisées en un certain nombre de fragments, qui sont ensuite équilibrés entre les nœuds de votre cluster (aussi uniformément que possible si le nombre de vos fragments n'est pas divisé également par le nombre de nœuds). Il existe deux principaux types de fragments dans ElasticSearch: les fragments de base et les fragments de réplique. Les fragments de réplique offrent une tolérance aux pannes en cas de défaillance d'un nœud, et les utilisateurs peuvent définir le nombre de fragments de réplique séparément pour chaque index.

Le travail de Elasticsearch standard

Elasticsearch - Il est élastique. Parfois, cela peut être assez difficile, mais, en général, vous pouvez ajouter des nœuds au cluster ou les supprimer. Et si dans le cas de la suppression d'un nœud, il existe un nombre approprié de répliques, Elasticsearch distribuera des fragments et équilibrera même la charge sur les nœuds du cluster. Cela fonctionne généralement.

L'exécution de requêtes coûteuses peut parfois entraîner la chute de nœuds et similaires, mais un grand nombre de paramètres permet de maintenir le travail. Avec un nombre suffisant de fragments de réplique, si le nœud tombe, cela n'affecte pas le travail dans son ensemble.

Standard Elasticsearch propose également un certain nombre de modules complémentaires, notamment le X-Pack, les fonctions d'audit, les listes de contrôle d'accès granulaires, la surveillance et les alertes. La plupart du X-Pack est récemment devenu gratuit, probablement en réponse à la nouvelle politique de licence Splunk.

Amazon Elasticsearch Work

Comme d'habitude, Amazon a pris le code open source pour une partie d'Elasticsearch, a créé un hard fork et a commencé à le vendre comme son propre service, introduisant progressivement ses propres versions de fonctions qui, depuis de nombreuses années, sont disponibles d'une manière ou d'une autre dans la version principale d'Elasticsearch.
Le produit Amazon manque de beaucoup de choses, telles que: RBAC et audit, ce qui est particulièrement problématique pour nous, car nous acceptons les journaux de différentes équipes et souhaitons les séparer les uns des autres. À l'heure actuelle, tout utilisateur ayant accès à Elasticsearch dispose de tous les droits d'accès et peut supprimer accidentellement les données de quelqu'un d'autre, changer la façon dont elles sont répliquées sur les nœuds et cesser complètement de recevoir des données en ajoutant le mauvais modèle d'indexation.

C'est frustrant, mais ce n'est pas le plus gros problème avec le service. Le rééquilibrage des fragments - le concept central d'Elasticsearch - ne fonctionne pas dans l'implémentation AWS, ce qui annule presque tout ce qui est bon dans Elasticsearch.

En règle générale, lorsque des données sont ajoutées aux nœuds, on peut remplir plus que les autres. Cela est attendu car il n'y a aucune garantie que les enregistrements chargés auront la même taille ou que le nombre de fragments sera toujours réparti uniformément sur tous les nœuds du cluster. Ce n'est pas critique, car Elasticsearch peut rééquilibrer les fragments entre les nœuds, et si un nœud est vraiment plein, les autres nœuds commenceront volontiers à recevoir des données au lieu d'être remplis.

Ce n'est pas pris en charge sur Amazon. Certains nœuds peuvent se remplir (beaucoup) plus rapidement que d'autres.

De plus, dans Amazon, si un nœud de votre cluster Elasticsearch n'a pas assez d'espace libre, le cluster entier cesse de recevoir des données , il s'arrête complètement. La solution d'Amazon consiste à laisser les utilisateurs passer par le cauchemar de changer périodiquement le nombre de fragments dans leurs modèles d'indexation, puis de réindexer les données précédemment créées dans de nouveaux index, supprimer les index précédents et, si nécessaire, inverser l'indexation des données dans la structure précédente. Ceci est complètement redondant et nécessite, en plus des coûts de calcul importants, qu'une copie non traitée des données téléchargées soit enregistrée avec l'enregistrement analysé, car une copie non traitée sera nécessaire pour la réindexation. Et, bien sûr, cela double la quantité de mémoire nécessaire pour un travail «normal» sur AWS.

«Oups! Je n'ai pas réindexé le cluster entier assez souvent, et le nœud était plein! Que faire? "

Vous avez deux options. Tout d'abord, supprimez autant de données que nécessaire pour ramener le cluster à la vie, puis commencez à réindexer avec l'espoir que rien ne s'effondrera. Avez-vous une sauvegarde de ce que vous souhaitez supprimer?

La deuxième option consiste à ajouter plus de nœuds au cluster ou à redimensionner les nœuds existants à une taille d'instance plus grande.

Mais attendez, comment ajouter des nœuds ou apporter des modifications si les fragments ne peuvent pas être rééquilibrés?

La solution d'Amazon est un déploiement bleu-vert. Ils font tourner un tout nouveau cluster, copient tout le contenu du cluster précédent dans un nouveau, puis basculent et détruisent l'ancien cluster.

De telles tâches de redimensionnement peuvent prendre des jours, pour les grands clusters, comme vous pouvez l'imaginer, la duplication de plusieurs billions d'enregistrements peut prendre un certain temps. Cela crée également une charge folle sur le cluster existant (dépassant probablement déjà la capacité) et peut en fait entraîner l'échec du cluster. J'ai effectué plusieurs opérations similaires sur plus de 30 clusters dans AWS et une seule fois j'ai observé une réussite en mode automatique.

Vous avez donc essayé de redimensionner votre cluster et la tâche ne s'est pas terminée. Et maintenant

Interactions avec Amazon

Votre tâche de redimensionnement du cluster a été interrompue (pour le service que vous avez probablement choisi de ne pas traiter avec un tel article), vous ouvrez donc le ticket au support technique AWS avec la priorité la plus élevée. Bien sûr, ils se plaindront de la quantité ou de la taille de votre fragment et ajouteront gentiment un lien vers les "meilleures pratiques" que vous avez déjà lues 500 fois. Et puis vous attendez qu'il soit corrigé. Et attends. Et attends. La dernière fois que j'ai essayé de redimensionner le cluster, et il a été bloqué, ce qui a entraîné de graves dysfonctionnements, il a fallu SEPT JOURS pour tout renvoyer en ligne. Ils ont restauré le cluster lui-même en quelques jours, mais quand tout s'est arrêté, il est évident que les nœuds sur lesquels Kibana s'exécute ont perdu le contact avec le cluster principal. Le support AWS a passé encore quatre jours à essayer de réparer quelque chose tout en se demandant si Kibana fonctionnait. Ils ne savaient même pas s'ils avaient résolu le problème, et j'ai dû vérifier s'ils avaient rétabli la communication entre leurs propres systèmes. Depuis lors, j'ai cessé de faire autre chose que de supprimer des données si le nœud est plein.

Les coûts de notre organisation sur AWS sont énormes. Cela nous donne l'occasion de rencontrer périodiquement leurs experts dans divers domaines, de discuter des stratégies de mise en œuvre et de traiter une variété de problèmes techniques. Nous avons pris rendez-vous avec un représentant d'Elasticsearch, au cours duquel j'ai passé la majeure partie de la réunion à expliquer les bases d'Elasticsearch et à décrire ... les caprices ... de leur produit. L'expert était complètement choqué que tout s'effondre lorsque le nœud est plein. Si l'expert envoyé ne connaît pas les bases de son produit, il n'est pas surprenant que l'équipe de support ait besoin de sept jours pour reprendre le cluster de production.

Enfin des pensées

Dans le projet d'exploitation forestière, dans lequel j'ai plongé, il y a une part d'erreurs architecturales et de faibles décisions de conception sur lesquelles nous travaillons actuellement. Et bien sûr, je m'attendais à ce qu'AWS Elasticsearch soit différent du produit d'origine. Cependant, dans AWS Elasticsearch, de nombreuses fonctions fondamentales sont désactivées ou manquantes, ce qui aggrave presque tous les problèmes que nous rencontrons.

Pour une utilisation facile et de petits clusters, AWS Elasticsearch fonctionne plutôt bien, mais pour les clusters de taille pétaoctet, c'était un cauchemar sans fin.

Je suis très curieux de savoir pourquoi l'implémentation d'Amazon Elasticsearch ne peut pas équilibrer les fragments; il s'agit d'une fonctionnalité Elasticsearch assez fondamentale. Même avec des limitations par rapport à Elasticsearch principal, ce serait certainement un produit acceptable pour les grands clusters s'il fonctionnait correctement. Je ne peux pas comprendre pourquoi Amazon propose quelque chose d'aussi cassé, et pourquoi ils n'ont pas corrigé la situation depuis plus de deux ans.

Comme d'autres l'ont suggéré, et cela semble raisonnable, ce comportement est un signe de l'implémentation d'AWS, conçue comme un cluster multi-locataire géant, essayant de fournir l'isolement pour le faire ressembler à un cluster autonome pour les utilisateurs finaux. Même avec des options telles que les données chiffrées au repos et le transfert de données chiffrées, cela semble plausible. Ou peut-être que leurs outils et configurations sont simplement l'héritage d'une architecture beaucoup plus ancienne.

Et, comme mon ami l'a fait remarquer, il est assez drôle qu'ils l'appellent toujours «Flexible» lorsque vous ne pouvez pas ajouter ou supprimer des nœuds de vos clusters sans en créer un nouveau et transférer toutes vos données.

Note de bas de page: lorsque j'ai écrit ce texte, j'ai trouvé un article il y a deux ans avec de nombreuses allégations similaires: read.acloud.guru/things-you-should-know-before-using-awss-elasticsearch-service-7cd70c9afb4f