Logo Zéphyrnet

Intelligence de données générative

Big Data

Créez une extension rentable pour votre cluster Elasticsearch avec Amazon OpenSearch Service

Republié par Platon
Republié par Platon

Date :

Vues: 1044

Au cours de l'année écoulée, nous avons vu des clients exécutant des clusters Elasticsearch autogérés sur AWS qui manquaient de capacité de calcul et de stockage en raison de la non-élasticité de leurs clusters. Ils ont adopté Amazon OpenSearch Service (successeur d'Amazon Elasticsearch Service) de bénéficier d'une meilleure flexibilité pour leurs logs et de durées de conservation améliorées.

Dans cet article, nous expliquons comment créer une extension rentable pour votre cluster Elasticsearch avec Amazon OpenSearch Service afin de prolonger la durée de conservation de vos données.

En mai 2021, nous avons publié le billet de blog Présentation du stockage à froid pour Amazon OpenSearch Service, qui explique comment réduire votre coût global. Le stockage à froid sépare les coûts de calcul et de stockage lorsque vous détachez les index du domaine. Vous bénéficiez d'un meilleur rapport stockage/calcul global. Le stockage à froid peut réduire vos coûts de conservation des données jusqu'à 90 % par Go par rapport au stockage des mêmes données dans le niveau Hot. Vous pouvez automatiser la gestion du cycle de vie de vos données et déplacer vos données entre les trois niveaux (Hot, UltraWarm et Cold) grâce à Index State Management.

Les équipes des services professionnels AWS ont travaillé avec un client pour ajouter un domaine OpenSearch Service comme deuxième cible pour leurs journaux. Ce client n'a pu conserver ses index que pendant 8 jours sur son cluster Elasticsearch autogéré existant. En raison d'exigences légales et de sécurité, ils devaient conserver les données jusqu'à 6 mois. La solution consistait à utiliser un cluster Elasticsearch (exécutant la version 7.10) sur Amazon OpenSearch Service en tant qu'extension de leur cluster Elasticsearch existant. Cela a donné à leurs équipes d'application internes un tableau de bord Kibana supplémentaire pour visualiser leurs indices pendant plus de 8 jours. Cette extension utilise le niveau UltraWarm pour fournir un accès chaleureux à leurs données. Ensuite, ils déplacent les données vers le niveau de stockage froid lorsqu'ils ne l'utilisent pas activement pour supprimer les ressources de calcul et pour des raisons de rentabilité.

La création de cette solution en tant qu'extension de leur cluster autogéré existant leur a donné 172 jours supplémentaires d'accès à leurs journaux (21.5 fois la durée de conservation des données) pour un coût supplémentaire de 15 %.

Démystifier la gestion de l'état des index

Gestion de l'état de l'index (ISM) vous permet de créer une stratégie pour automatiser la gestion des index au sein de différents niveaux dans un domaine OpenSearch Service.

Depuis février 2022, trois niveaux sont disponibles dans Amazon OpenSearch Service : Hot, UltraWarm et Cold.

Le niveau Hot par défaut est destiné à l'écriture active et à l'analyse à faible latence. UltraChaud est pour les données en lecture seule jusqu'à trois pétaoctets à un dixième du coût du niveau Chaud, et Du froid est pour un archivage à long terme illimité. Bien que le stockage à chaud soit utilisé pour l'indexation et offre l'accès le plus rapide, UltraWarm complète le niveau de stockage à chaud en fournissant un stockage moins coûteux pour les données plus anciennes et moins fréquemment consultées. Cela se fait tout en conservant la même expérience d'analyse interactive. Plutôt que le stockage attaché, les nœuds UltraWarm utilisent Service de stockage simple Amazon (Amazon S3) et une solution de mise en cache sophistiquée pour améliorer les performances.

ISM vous aide d'un point de vue économique, lorsque vous n'avez pas besoin d'accéder à vos données après une certaine période, mais que vous devez quand même les conserver en raison d'exigences légales, par exemple, pour automatiser la transition de vos données au sein de ces niveaux. Ces opérations sont basées sur l'âge de l'index, la taille et d'autres conditions.

De plus, l'ordre de transition doit être respecté de Hot à UltraWarm à Cold, et de Cold à UltraWarm à Hot - vous ne pouvez pas changer cet ordre.

Vue d'ensemble de la solution

Notre solution vous permet de prolonger la durée de conservation de vos données. Nous vous montrons comment ajouter un deuxième domaine Cold OpenSearch Service à votre déploiement Hot autogéré existant. Vous utilisez des instantanés Elasticsearch pour déplacer des données du cluster Hot vers le domaine Cold. Vous utilisez des politiques ISM appliquées à ces index, avec différentes durées de conservation avant leur suppression, de 14 à 180 jours.

En plus de cela, vous ajoutez 9 alarmes recommandées pour Amazon OpenSearch Service in Amazon Cloud Watch par l'intermédiaire d'un AWS CloudFormation modèle pour améliorer votre capacité à surveiller votre pile. Ces alarmes recommandées vous avertissent, par le biais d'un Service de notification simple d'Amazon (Amazon SNS), sur les métriques clés que vous devez surveiller, comme ClusterStatus, FreeStorageSpace, CPUUtilizationet JVMMemoryPressure.

Le schéma suivant illustre l'architecture de la solution :

Le diagramme contient les composants suivants dans notre solution pour étendre votre cluster Elasticsearch autogéré avec Amazon OpenSearch Service (disponible sur GitHub):

  1. Référentiel d'instantanés
    1. Vous dirigez un AWS Lambda fonction une seule fois pour enregistrer votre compartiment S3 (snapshots-bucket dans le diagramme) en tant que référentiel d'instantanés pour votre domaine OpenSearch Service.
  2. Politiques ISM
    1. Vous exécutez une fois une fonction Lambda pour créer six stratégies ISM qui automatisent la migration de vos index du niveau Hot vers UltraWarm et d'UltraWarm vers le stockage Cold, dès qu'ils sont restaurés dans le domaine, avec des périodes de rétention différentes (14, 21 , 35, 60, 90 et 180 jours avant la suppression).
  3. Migration d'index
    1. Vous utilisez un Amazon Event Bridge règle pour déclencher automatiquement, une fois par jour, une fonction Lambda (RestoreIndices dans le schéma).
    2. Cette fonction analyse les derniers instantanés qui ont été poussés par le cluster Elasticsearch.
    3. Lorsque la fonction trouve un nouvel index qui n'existe pas encore dans le domaine OpenSearch Service, elle lance une opération de restauration et attache une politique ISM (créée à l'étape 2.1).
  4. Cache UltraWarm gratuit
    1. Vous utilisez une règle EventBridge pour déclencher automatiquement – ​​une fois par jour – une fonction AWS Lambda (MoveToCold dans le schéma).
    2. Cette fonction vérifie les index qui ont été accédés à chaud et les ramène au niveau froid afin de libérer les caches des nœuds UltraWarm.
  5. Alertes
    1. Vous utilisez CloudWatch pour créer 9 alarmes basées sur Amazon OpenSearch Service Clou
      dWatch métriques.
    2. CloudWatch redirige les alarmes vers une rubrique SNS.
    3. Vous recevez des notifications de la rubrique SNS, qui envoie des e-mails dès qu'une alarme est déclenchée.

Pré-requis

Effectuez les étapes préalables suivantes :

  1. Déployez un cluster Elasticsearch autogéré (exécuté sur site ou dans AWS) qui envoie périodiquement des instantanés vers un compartiment S3 (idéalement une fois par jour).
  2. Déployez un domaine de service OpenSearch (exécutant la version OpenSearch 1.1) et activez les options UltraWarm et Cold.
  3. Déployer un le serveur proxy (NGINX sur le diagramme d'architecture) dans un sous-réseau public qui permet d'accéder aux tableaux de bord de vos domaines OpenSearch Service, hébergés dans un VPC.
  4. Pour automatiser plusieurs mécanismes dans cette solution, créez un Gestion des identités et des accès AWS (IAM) rôle pour nos différentes fonctions Lambda. Utilisez la stratégie IAM suivante :
{ "Version": "2012-10-17", "Statement": [ { "Action": "logs:CreateLogGroup", "Resource": "arn:aws:logs:us-east-1:123456789012:log-group:*", "Effect": "Allow" }, { "Action": [ "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/*:*", "Effect": "Allow" }, { "Action": "iam:PassRole", "Resource": "arn:aws:iam::123456789012:role/snapshotsRole", "Effect": "Allow" }, { "Action": [ "es:ESHttpPut", "es:ESHttpGet", "es:ESHttpPost" ], "Resource": "arn:aws:es:us-east-1:123456789012:domain/my-test-domain/*", "Effect": "Allow" } ]
}

Cette stratégie permet à nos fonctions Lambda d'envoyer des requêtes PUT, GET et POST à ​​notre domaine OpenSearch Service, d'enregistrer leurs journaux dans CloudWatch Logs et de transmettre un rôle IAM utilisé pour accéder au compartiment S3 qui stocke les instantanés.

  1. De plus, modifiez la relation d'approbation à assumer par Lambda : 
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ]
}

Vous utilisez ce rôle IAM pour les fonctions Lambda que vous créez.

Vous devez également configurer le plug-in de sécurité d'OpenSearch pour attribuer des autorisations pour le trafic que Lambda envoie à OpenSearch.

  1. Connectez-vous au tableau de bord Kibana de votre domaine Cold et dans le Sécurité section, choisissez Rôles.

Vous trouverez ici les rôles Kibana existants et prédéfinis.

  1. Sélectionnez le all_access rôle et choisir Utilisateurs mappés.
  2. Selectionnez Gérer la cartographie pour modifier les utilisateurs mappés.
  3. Entrez l'ARN du rôle IAM que vous venez de créer en tant que nouveau rôle backend sur ce rôle Kibana.

Dans les sections suivantes, nous vous expliquons les étapes de configuration de chaque composant dans l'architecture de la solution.

Référentiel d'instantanés

Pour migrer vos journaux du cluster Hot vers le domaine Cold, vous enregistrez votre compartiment S3 qui stocke les journaux sous forme d'instantanés (à partir du cluster Elasticsearch) en tant que référentiel d'instantanés pour votre domaine OpenSearch Service.

  1. Créez un rôle IAM (pour ce post, nous utilisons SnapshotsRole pour le nom du rôle) pour accorder des autorisations au domaine Cold pour accéder à votre compartiment S3 qui stocke les instantanés de votre cluster Elasticsearch. Utilisez la stratégie IAM suivante pour ce rôle : 
    { "Version": "2012-10-17", "Statement": [{ "Action": [ "s3:ListBucket" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::s3-bucket-name" ] }, { "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::s3-bucket-name/*" ] } ]
}

  2. Modifiez la relation d'approbation à utiliser depuis Amazon OpenSearch Service : 
    { "Version": "2012-10-17", "Statement": [{ "Sid": "", "Effect": "Allow", "Principal": { "Service": "es.amazonaws.com" }, "Action": "sts:AssumeRole" }] }

  3. Créez la fonction Lambda chargée d'enregistrer ce compartiment S3 en tant que référentiel d'instantanés.

Sur le GitHub référentiel, vous pouvez trouver les fichiers nécessaires à la construction de cette pièce. Voir le lambda-functions/register-snapshots-repository.py Fichier Python pour créer la fonction Lambda.

  1. Selectionnez Teste sur la console Lambda pour exécuter la fonction.

Vous ne l'exécutez qu'une seule fois. Il enregistre le compartiment S3 en tant que nouveau référentiel d'instantanés pour votre domaine OpenSearch Service.

  1. Vérifiez le référentiel d'instantanés en accédant au tableau de bord Kibana du domaine Cold sur le Outils de développement tab et en exécutant la commande suivante : 
    GET _snapshots/myelasticsearch-snapshots-repository (replace with your repository name)

Vous pouvez également réaliser cette étape à partir d'un Cloud de calcul élastique Amazon (Amazon EC2) (au lieu d'une fonction Lambda) car elle ne doit être exécutée qu'une seule fois, avec un rôle IAM de profil d'instance attaché à l'instance EC2.

Stratégies de gestion de l'état de l'index

Vous utilisez Index State Management pour automatiser la transition de vos index entre les niveaux de stockage dans Amazon OpenSearch Service. Pour utiliser ISM, vous créez politiques (petits documents JSON qui définissent un automate d'état) et attachez ces politiques aux index de votre domaine. Les politiques ISM spécifient les états avec actes et transitions qui vous permettent de déplacer et de supprimer des index. Vous pouvez utiliser le functions/create-indexstatemanagement-policy.py Code Lambda pour créer six stratégies ISM qui automatisent la transition au sein des niveaux et suppriment vos index Cold après 14, 21, 35, 60, 90 et 180 jours. Vous utilisez le rôle IAM que vous avez créé précédemment et exécutez cette fonction une fois pour créer les stratégies dans votre domaine.

Accédez à Kibana dans votre domaine OpenSearch Service et choisissez Gestion d'index. D' Politiques de gestion de l'État , vérifiez que vous pouvez voir vos politiques ISM.

Migration d'index

Pour migrer vos données du cluster Hot vers le domaine Cold, vous utilisez le functions/restore-indices.py code pour créer une fonction Lambda (RestoreIndices) Et le cfn-templates/event-bridge-lambda-function.yaml Modèle CloudFormation pour créer son déclencheur, qui est une règle EventBridge (programmée une fois par jour à 12hXNUMX). Vos index sont migrés vers le domaine Cold grâce à la fonction Lambda qui analyse les index dans votre référentiel d'instantanés et lance des opérations de restauration pour chaque nouvel index qui n'existe pas dans le domaine Cold. Dès que l'index est restauré dans le domaine, la fonction Lambda lui attache une stratégie ISM, basée sur son modèle d'index pour déterminer sa période de rétention.

Le code Python recherche un nom d'application structuré en exactement trois lettres (par exemple, aws). Si vos journaux ont un modèle d'index différent, vous devez mettre à jour les lignes de code pertinentes (trigramme = index [5:8]).

Cache UltraWarm gratuit

Pour libérer le cache de vos nœuds UltraWarm du domaine Cold, vous utilisez le functions/move-to-Cold.py code pour créer une fonction Lambda (MoveToCold) Et le cfn-templates/event-bridge-lambda-function.yaml Modèle CloudFormation pour créer son déclencheur, qui est une règle EventBridge (modifiez son horaire pour éviter de fonctionner en parallèle avec la règle précédente). Vos index qui se trouvent dans le niveau UltraWarm pour un accès à chaud sont déplacés vers le stockage froid pour libérer le cache des nœuds afin de préparer la prochaine migration d'index et pour plus de rentabilité.

Alertes

Pour être alerté par e-mail lorsque le domaine Cold requiert votre attention, vous utilisez le cfn-templates/alarms.yaml Modèle CloudFormation pour créer une rubrique SNS qui reçoit des notifications lorsque l'une des 9 alarmes CloudWatch a été déclenchée, sur la base des métriques Amazon OpenSearch Service. Ces alarmes proviennent du alarmes CloudWatch recommandées pour Amazon OpenSearch Service.

Conclusion

Dans cet article, nous avons abordé une solution permettant d'activer un domaine OpenSearch en tant qu'extension de votre cluster Elasticsearch autogéré existant, afin de prolonger la période de conservation des journaux d'applications sans serveur et de manière rentable.

Si vous souhaitez approfondir les fonctionnalités d'Amazon OpenSearch Service et d'AWS Analytics en général, vous pouvez obtenir de l'aide et participer à des discussions sur notre forums.

À propos des auteurs

Alexandre Levret est consultant en services professionnels au sein d'Amazon Web Services (AWS) dédié au secteur public en Europe. Il vise à construire, innover et inspirer ses multiples clients qui font face à des défis que le cloud computing peut les aider à résoudre.

spot_img

Dernières informations

spot_img

Copyright @ 2024 Platon Technologies Inc.

Discutez avec nous

Salut! Comment puis-je t'aider?