Nous avons terminé 2022 sur une bonne note avec la sortie en avant-première de Amazon OpenSearch sans serveur chez re:Invent. Aujourd'hui, nous sommes heureux d'annoncer la disponibilité générale de Amazon OpenSearch sans serveur, l'option sans serveur pour Service Amazon OpenSearch cela facilite l'exécution des charges de travail de recherche et d'analyse sans même avoir à penser à la gestion de l'infrastructure. Dans cet article, nous partageons notre approche et notre architecture de haut niveau d'OpenSearch Serverless.

Contexte

Autogéré Opensearch et le service OpenSearch géré sont largement utilisés pour rechercher et analyser des pétaoctets de données. Les deux options vous donnent un contrôle total sur la configuration des ressources de calcul, de mémoire et de stockage dans les clusters, ce qui vous permet d'optimiser les coûts et les performances de leurs applications.

Cependant, vous pouvez souvent exécuter des applications qui peuvent être très variables, dont l'utilisation n'est pas toujours connue. Ces applications peuvent subir des pics soudains de données d'ingestion ou des demandes de requête irrégulières et imprévisibles. Pour maintenir des performances constantes, vous devez constamment régler et redimensionner les clusters ou surprovisionner pour les pics de demande, ce qui entraîne des coûts excessifs. De nombreux clients souhaitaient une expérience encore plus simple pour exécuter des charges de travail de recherche et d'analyse qui vous permettent de vous concentrer sur vos applications métier sans avoir à vous soucier de l'infrastructure backend et de la gestion des données.

De quoi plus simple moyenne? Cela signifie que vous ne voulez pas vous soucier de ces tâches :

• Choisir et provisionner des instances
• Gérer le shard ou la taille de l'index
• Index et gestion des données à des fins de dimensionnement et d'exploitation
• Surveillez ou ajustez les paramètres en continu pour répondre aux exigences de la charge de travail
• Planifier les pannes système et les dépassements de seuil de ressources
• Mises à jour de sécurité et mises à jour du logiciel de service

Nous avons traduit cette liste de contrôle en exigences et objectifs sous les thèmes de produits suivants :

• Simple et sécurisé
• Mise à l'échelle automatique, tolérance aux pannes et durabilité
• Rapport coût-efficacité
• Intégrations écosystémiques

Avant de nous plonger dans la manière dont OpenSearch Serverless répond à ces besoins, examinons les cas d'utilisation cibles d'OpenSearch Serverless, car leurs caractéristiques distinctives ont fortement influencé notre approche de conception et notre architecture.

Cibler les cas d'utilisation

Les cas d'utilisation cibles pour OpenSearch Serverless sont les mêmes que pour OpenSearch :

• Des séries chronologiques l'analyse (également connue sous le nom d'analyse de journaux) se concentre sur l'analyse de gros volumes de données semi-structurées générées par des machines en temps réel pour obtenir des informations sur les opérations, la sécurité et le comportement des utilisateurs
• Rechercher alimente les applications client dans leurs réseaux internes (recherche d'applications, systèmes de gestion de contenu, documents juridiques) et les applications accessibles sur Internet telles que la recherche de sites Web de commerce électronique et la recherche de contenu

Comprenons les différences entre les séries chronologiques typiques et les charges de travail de recherche (les exceptions peuvent varier) :

• Les charges de travail de séries chronologiques sont lourdes en écriture, tandis que les charges de travail de recherche sont lourdes en lecture
• Les charges de travail de recherche ont un corpus de données plus petit que les séries chronologiques
• Les charges de travail de recherche sont plus sensibles aux latences et nécessitent des temps de réponse plus rapides que les charges de travail de séries chronologiques
• Les requêtes pour les séries chronologiques sont exécutées sur des données récentes, tandis que les requêtes de recherche analysent l'ensemble du corpus

Ces caractéristiques ont fortement influencé notre approche de la gestion et de la gestion des partitions, des index et des données pour les charges de travail. Dans la section suivante, nous passons en revue les grands thèmes de la manière dont OpenSearch Serverless répond aux défis des clients tout en répondant efficacement à ces caractéristiques de charge de travail distinctives.

Simple et sécurisé

Pour démarrer avec OpenSearch Serverless, vous créez un collection. Collections sont un regroupement logique de données indexées qui fonctionnent ensemble pour prendre en charge une charge de travail, tandis que les ressources physiques sont automatiquement gérées dans le backend. Vous n'avez pas besoin de déclarer la quantité de calcul ou de stockage nécessaire, ni de surveiller le système pour vous assurer qu'il fonctionne bien. Pour gérer correctement les deux charges de travail prédominantes, OpenSearch Serverless applique différentes stratégies de partitionnement et d'indexation. Par conséquent, dans le flux de travail pour créer une collection, vous devez définir le type de collection—série temporelle ou recherche. Vous n'avez pas à vous soucier de la réindexation ou du roulement des index pour prendre en charge la taille croissante de vos données, car cela est géré automatiquement par le système.

Ensuite, vous effectuez les choix de configuration concernant la clé de chiffrement à utiliser, l'accès réseau à vos collections (point de terminaison public ou VPC) et qui doit accéder à votre collection. OpenSearch Serverless a un outil facile à utiliser et très efficace modèle de sécurité qui prend en charge les politiques hiérarchiques pour vos collections et index. Vous pouvez créer des politiques de sécurité granulaires au niveau des collections et des comptes pour toutes vos collections et tous vos index. La politique centralisée au niveau du compte vous offre une visibilité et un contrôle complets, et simplifie la sécurisation opérationnelle des collections à grande échelle. Pour les stratégies de chiffrement, vous pouvez spécifier un Service de gestion des clés AWS (AWS KMS) pour une seule collection, toutes les collections ou un sous-ensemble de collections à l'aide d'un modèle de correspondance générique. Si les règles de plusieurs stratégies correspondent à une collection, la règle la plus proche du nom complet est prioritaire. Vous pouvez également spécifier des modèles de correspondance génériques dans les stratégies d'accès au réseau et aux données. Plusieurs stratégies d'accès au réseau et aux données peuvent s'appliquer à une même collection, et les autorisations s'additionnent. Vous pouvez mettre à jour les politiques d'accès au réseau et aux données pour votre collection à tout moment.

Les tableaux de bord OpenSearch sont désormais accessibles à l'aide de votre SAML et Gestion des identités et des accès AWS (IAM). OpenSearch Serverless prend également en charge les autorisations IAM précises afin que vous puissiez définir qui peut créer, mettre à jour et supprimer les politiques de chiffrement, de réseau et d'accès aux données, permettant ainsi l'alignement organisationnel. Toutes les données dans OpenSearch Serverless sont chiffrées en transit et au repos par défaut.

Mise à l'échelle automatique, tolérance aux pannes et durabilité

OpenSearch sans serveur découple le stockage et le calcul, ce qui permet à chaque couche d'évoluer indépendamment en fonction des demandes de charge de travail. Ce découplage permet également d'isoler les nœuds de calcul d'indexation et de requête afin que les flottes puissent s'exécuter simultanément sans aucun conflit de ressources. Les ressources de calcul telles que le processeur, l'utilisation du disque, la mémoire et l'état des partitions actives sont surveillées et gérées par le service. Lorsque ces seuils système sont dépassés, le service ajuste la capacité afin que vous n'ayez pas à vous soucier de la mise à l'échelle des ressources. Par exemple, lorsqu'une charge de travail de surveillance d'application reçoit une rafale soudaine d'activités de journalisation lors d'un événement de disponibilité, OpenSearch Serverless augmentera les nœuds de calcul d'indexation. Lorsque ces activités de journalisation diminuent et que la consommation de ressources dans les nœuds de calcul tombe en dessous d'un certain seuil, OpenSearch Serverless redimensionne les nœuds. De même, lorsqu'un moteur de recherche de site Web reçoit un pic soudain de requêtes après un événement d'actualité, OpenSearch Serverless redimensionne automatiquement le interrogez les nœuds de calcul pour traiter les requêtes sans affecter les performances d'ingestion des données.

Le diagramme suivant illustre cette architecture de haut niveau.

OpenSearch Serverless est conçu pour les charges de travail de production avec redondance pour les pannes de zone de disponibilité et les pannes d'infrastructure. Par défaut, OpenSearch Serverless répliquera les index dans les zones de disponibilité. Les nœuds de calcul d'indexation s'exécutent en mode actif-veille. Le plan de contrôle de service est également construit avec redondance et récupération automatique des pannes. Toutes les données indexées sont stockées dans Service de stockage simple Amazon (Amazon S3) pour fournir la même durabilité des données qu'Amazon S3 (11 neuf). Les instances de calcul de requête téléchargent les données indexées directement à partir d'Amazon S3, exécutent des opérations de recherche et effectuent des agrégations. Le calcul de requête redondant est déployé dans les zones de disponibilité en mode actif-actif pour maintenir la disponibilité pendant les pannes. L'intervalle d'actualisation (le temps entre le moment où un document est ingéré par OpenSearch Serverless et le moment où il est disponible pour la recherche) est actuellement inférieur à 15 secondes.

Coût et rentabilité

Avec OpenSearch Serverless, vous n'avez pas besoin de dimensionner ou de provisionner les ressources à l'avance, ni de surprovisionner pour les pics de charge dans les environnements de production. Vous ne payez que pour les ressources de calcul et de stockage consommées par vos charges de travail. La capacité de calcul utilisée pour l'ingestion de données, la recherche et l'interrogation est mesurée en unités de calcul OpenSearch (OCU). Le nombre d'OCU correspond directement au CPU, à la mémoire, Boutique de blocs élastiques Amazon (Amazon EBS) et les ressources d'E/S requises pour ingérer des données ou exécuter des requêtes. Une OCU comprend 6 Go de RAM, le vCPU correspondant, 120 Go de stockage GP3 (utilisé pour fournir un accès rapide aux données les plus fréquemment consultées) et les transferts de données vers Amazon S3. Une fois les données ingérées, les données indexées sont stockées dans Amazon S3. Vous avez la possibilité de contrôler la conservation et de supprimer des données à l'aide des API.

Lorsque vous créez le premier point de terminaison de collecte dans un compte, OpenSearch Serverless provisionne 4 OCU (2 ingest qui incluent le primaire et le standby, et 2 search qui incluent deux copies pour la haute disponibilité). Ces OCU sont instanciées même s'il n'y a aucune activité sur le point de terminaison sans serveur pour éviter toute latence de démarrage à froid. Toutes les collections suivantes de ce compte utilisant la même clé KMS partagent ces OCU. Pendant la mise à l'échelle automatique, OpenSearch Serverless ajoutera plus d'OCU pour prendre en charge le calcul nécessaire à vos collections. Ces OCU copient les données indexées d'Amazon S3 avant de pouvoir commencer à répondre aux requêtes d'indexation ou de requête. De même, le plan de contrôle OpenSearch Serverless surveille en permanence la consommation de ressources des OCU. Lorsque le taux de demande d'indexation ou de recherche diminue et que la consommation d'OCU tombe en dessous d'un certain seuil, OpenSearch Serverless réduira le nombre d'OCU à la capacité minimale requise pour votre charge de travail. Les OCU minimales empêchent les retards de démarrage à froid.

OpenSearch Serverless fournit également un niveau de mise en cache intégré pour les charges de travail de séries chronologiques afin d'offrir un meilleur rapport qualité-prix. OpenSearch Serverless met en cache les données de journal les plus récentes, généralement les premières 24 heures, sur un disque éphémère. Pour les données de plus de 24 heures, OpenSearch Serverless met uniquement en cache les métadonnées et récupère les blocs de données nécessaires à partir d'Amazon S3 en fonction de l'accès aux requêtes. Ce modèle permet également d'emballer plus de données tout en maîtrisant les coûts. Pour les collections de recherche, le nœud de calcul de requête met en cache l'ensemble du corpus de données localement sur des disques éphémères pour fournir des réponses rapides aux requêtes en quelques millisecondes.

Intégrations écosystémiques

La plupart des outils qui fonctionnent avec OpenSearch fonctionnent également avec OpenSearch Serverless. Vous n'avez pas à réécrire les pipelines et les applications existants. OpenSearch Serverless a le même modèle de données logique et le même moteur de requête qu'OpenSearch, vous pouvez donc utiliser les mêmes API d'ingestion et de requête que vous connaissez et utiliser les tableaux de bord OpenSearch sans serveur pour l'analyse et la visualisation interactives des données. En raison de son interface compatible, OpenSearch Serverless prend également en charge le riche écosystème OpenSearch existant de clients de haut niveau et de pipelines d'ingestion de streaming—Firehose de données Amazon Kinesis, FluentD, FluentBit, Logstash, Apache Kafka et Amazon Managed Streaming pour Apache Kafka (AmazonMSK). Pour plus d'informations, voir Ingestion de données dans les collections Amazon OpenSearch Serverless. Vous pouvez également automatiser le processus de création de collection à l'aide de AWS CloudFormation et les terres parsemées de CDK AWS. Avec Amazon Cloud Watch l'intégration, vous pouvez surveiller les principales métriques OpenSearch Serverless et définir des alarmes pour vous informer de tout dépassement de seuil.

Choisir entre les clusters gérés et OpenSearch Serverless

Les clusters gérés et OpenSearch Serverless sont des options de déploiement sous OpenSearch Service et sont alimentés par le projet open source OpenSearch. OpenSearch Serverless facilite l'exécution de charges de travail cycliques, intermittentes ou imprévisibles sans avoir à penser au dimensionnement, à la surveillance et au réglage des clusters OpenSearch. Cependant, vous pouvez préférer utiliser des clusters gérés dans des scénarios où vous avez besoin d'un contrôle étroit sur la configuration du cluster ou des personnalisations spécifiques. Avec les clusters gérés, vous pouvez choisir vos instances et versions préférées et avoir plus de contrôle sur la configuration, comme des intervalles d'actualisation plus courts ou des stratégies de partage de données, ce qui peut être critique pour les cas d'utilisation qui ne correspondent pas aux modèles typiques pris en charge par OpenSearch Serverless. De plus, OpenSearch Serverless ne prend actuellement pas en charge toutes les fonctionnalités et plugins avancés d'OpenSearch tels que l'alerte, la détection d'anomalies et k-NN. Vous pouvez utiliser les clusters gérés pour ces fonctionnalités jusqu'à ce qu'OpenSearch Serverless ajoute leur prise en charge.

Mises à jour depuis l'aperçu

Avec la version de disponibilité générale, OpenSearch Serverless évoluera désormais vers les ressources minimales requises pour prendre en charge vos charges de travail. La limite maximale d'OCU par compte a été augmentée de 20 à 50 pour l'indexation et la requête. De plus, vous pouvez désormais utiliser les clients OpenSearch de haut niveau pour ingérer et interroger vos données, et également migrer les données de vos clusters OpenSearch à l'aide de Logstash. De plus, nous avons ajouté la prise en charge de trois autres régions. OpenSearch Serverless est désormais disponible dans huit régions du monde : USA Est (Ohio), USA Est (Virginie du Nord), USA Ouest (Oregon), Asie-Pacifique (Singapour), Asie-Pacifique (Sydney), Asie-Pacifique (Tokyo), Europe ( Francfort) et l'Europe (Irlande).

Résumé

Le voyage sans serveur vient de commencer. La plupart des efforts initiaux ont été consacrés à la définition et à la construction de la bonne architecture de service qui peut efficacement prendre en charge les exigences croissantes en matière de performances et d'échelle. OpenSearch Serverless sépare les composants de stockage et de calcul, ainsi que l'indexation et le calcul des requêtes, afin qu'ils puissent être gérés et mis à l'échelle indépendamment. OpenSearch Serverless utilise Amazon S3 comme principal stockage de données pour les index, vous n'avez donc pas à vous soucier de la durabilité. Nous avons dissocié vos choix de configuration du provisionnement approprié des ressources, afin que les erreurs de configuration ne provoquent pas de pannes. OpenSearch Serverless appliquera également les mises à jour de sécurité et logicielles à l'avenir sans perturber vos charges de travail. Cette architecture flexible basée sur des microservices nous permettra de continuer à proposer régulièrement de nouvelles fonctionnalités, d'augmenter la barre d'échelle et de performances, et de réduire davantage les coûts, par exemple en arrêtant complètement les nœuds de calcul lorsqu'il n'y a pas d'activité.

Nous vous encourageons à essayer OpenSearch Serverless et à fournir vos commentaires dans la section des commentaires avec vos cas d'utilisation et vos questions. Nous avons un certain nombre de ressources pour vous aider à démarrer :

A propos de l'auteure

Pavani Baddepudi est chef de produit senior travaillant dans les services de recherche chez AWS. Ses intérêts incluent les systèmes distribués, les réseaux et la sécurité.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
• La source: https://aws.amazon.com/blogs/big-data/amazon-opensearch-serverless-is-now-generally-available/