Dimensionnement des domaines Amazon OpenSearch Service

Il n'existe pas de méthode parfaite pour dimensionner les domaines Amazon OpenSearch Service. Cependant, en commençant par comprendre vos besoins en stockage, le service et OpenSearch lui-même, vous pouvez faire une première estimation éclairée de vos besoins en matériel. Cette estimation peut servir de point de départ utile pour l'aspect le plus critique du dimensionnement des domaines : tester ceux-ci avec des charges de travail représentatives et surveiller leurs performances.

Calcul des exigences de stockage

La plupart des OpenSearch charges de travail se répartissent dans l'une des deux grandes catégories suivantes :

• Index à longue durée de vie : vous écrivez du code qui traite les données dans un ou plusieurs OpenSearch index, puis vous mettez à jour ces index périodiquement à mesure que les données source changent. Parmi les exemples courants, figurent les recherches de site web, de documents et de commerce en ligne.

• Index glissants : les données arrivent en continu dans un jeu d'index temporaires, avec une période d'indexation et une fenêtre de conservation (par exemple, un jeu d'index quotidiens qui sont conservés pendant deux semaines). Parmi les exemples courants, figurent l'analyse des journaux, le traitement de séries chronologiques et l'analyse des flux de clics.

Pour les charges de travail à index de longue durée, vous pouvez examiner les données source sur le disque et facilement déterminer l'espace de stockage qu'elles consomment. Si les données proviennent de plusieurs sources, il vous suffit de rassembler ces sources.

Pour les index glissants, vous pouvez multiplier la quantité de données générées au cours d'une période de temps représentative par la période de conservation. Par exemple, si vous générez 200 Mio de données de journal par heure, cela représente 4,7 Gio par jour, soit 66 Gio de données à un instant donné si vous disposez d'une période de conservation de deux semaines.

Cependant, la taille de vos données source n'est qu'un aspect de vos exigences de stockage. Vous devez également tenir compte des éléments suivants :

• Nombre de réplicas : chaque réplica est une copie complète d'un index et a besoin de la même quantité d'espace disque. Par défaut, chaque OpenSearch index possède une réplique. Nous vous recommandons d'en avoir au moins un pour empêcher toute perte de données. Les réplicas améliorent également les performances de recherche. Vous souhaiterez donc en avoir plus en cas de charge de travail à lecture intensive. Utilisez PUT /my-index/_settings pour mettre à jour le paramètre number_of_replicas de votre index.

• OpenSearch surcharge d'indexation : la taille sur disque d'un index varie. La taille totale des données source et de l'index correspond souvent à 110 % de la source, l'index pouvant atteindre 10 % des données source. Après avoir indexé vos données, vous pouvez utiliser l'API _cat/indices?v et la valeur pri.store.size pour calculer la surcharge exacte. _cat/allocation?v offre également un résumé utile.

• Espace réservé par le système d'exploitation : par défaut, Linux réserve 5 % du système de fichiers à l'utilisateur root pour les processus critiques, la récupération du système et la protection des données contre les problèmes de fragmentation de disque.

• OpenSearch Frais de service : le OpenSearch service réserve 20 % de l'espace de stockage de chaque instance (jusqu'à 20 GiB) aux fusions de segments, aux journaux et à d'autres opérations internes.

  En raison de ce plafond de 20 Gio, la quantité totale d'espace réservé peut varier considérablement en fonction du nombre d'instances dans votre domaine. Par exemple, un domaine peut comporter trois instances m6g.xlarge.search, chacune dotée de 500 Gio d'espace de stockage, pour un total de 1,46 Tio. Dans ce cas, l'espace réservé total est seulement de 60 Gio. Un autre domaine peut comporter 10 instances m3.medium.search, chacune dotée de 100 Gio d'espace de stockage, pour un total de 0,98 Tio. Dans ce cas, l'espace réservé total est de 200 Gio, même si le premier domaine est 50 % plus grand.

  Dans la formule suivante, nous appliquons une estimation du « pire scénario » pour les frais généraux. Cette estimation inclut de l'espace libre supplémentaire afin de minimiser l'impact des défaillances des nœuds et des pannes de zone de disponibilité.

En résumé, si vous disposez de 66 Gio de données à un instant donné et que vous voulez un réplica, votre espace de stockage minimal requis se rapproche de 66 * 2 * 1,1/0,95/0,8 = 191 Gio. Vous pouvez généraliser ce calcul comme suit :

Données source* (1 + nombre de répliques) * (1 + surcharge d'indexation)/(1 - espace réservé Linux)/(1 - surcharge de OpenSearch service) = espace de stockage minimal requis

Vous pouvez également utiliser cette version simplifiée :

Données source * (1 + nombre de réplicas) * 1,45 = Exigences minimales de stockage

L'insuffisance d'espace de stockage est l'une des causes les plus courantes d'instabilité des clusters. Vous devez donc vérifier les chiffres lorsque vous choisissez les types d'instances, le nombre d'instances et les volumes de stockage.

D'autres considérations en matière de stockage existent :

• Si vos exigences de stockage minimal dépassent 1 Po, consultez Échelle en pétaoctets dans Amazon Service OpenSearch .

• Si vous avez des index glissants et que vous voulez utiliser une architecture hot-warm, consultez UltraWarm stockage pour Amazon OpenSearch Service.

Choix du nombre de partitions

Une fois que vous avez déterminé vos exigences de stockage, vous pouvez examiner votre stratégie d'indexation. Par défaut, dans OpenSearch Service, chaque index est divisé en cinq partitions principales et une réplique (10 partitions au total). Ce comportement est différent de celui de l'open source OpenSearch, qui utilise par défaut une partition principale et une partition de réplique. Comme vous ne pouvez pas modifier aisément le nombre de partitions principales pour un index existant, vous devez décider du nombre de partitions avant d'indexer votre premier document.

L'objectif général du choix d'un nombre de partitions est de répartir un index de manière uniforme sur tous les nœuds de données du cluster. Toutefois, ces partitions ne doivent pas être trop grandes, ni trop nombreuses. En règle général, la taille des partitions doit être comprise entre 10 et 30 Gio pour les charges de travail où la latence de recherche est un objectif de performance clé, et entre 30 et 50 Gio pour les charges de travail lourdes en écriture, telles que l'analyse des journaux.

Les partitions volumineuses peuvent compliquer le rétablissement après une panne, mais comme chaque partition utilise une certaine quantité de processeur et de mémoire, le fait d'avoir trop de petites partitions peut entraîner des problèmes de performances et des erreurs de mémoire insuffisante. OpenSearch En d'autres termes, les partitions doivent être suffisamment petites pour que l'instance de OpenSearch service sous-jacente puisse les gérer, mais pas au point de surcharger inutilement le matériel.

Par exemple, supposons que vous disposez de 66 Gio de données. Vous ne prévoyez pas que ce nombre augmente au fil du temps, et vous voulez maintenir vos partitions autour de 30 Gio chacune. Le nombre de partitions doit donc être d'environ 66 * 1,1/30 = 3. Vous pouvez généraliser ce calcul comme suit :

(Données source + marge de croissance) * (1 + surcharge d'indexation) / taille de partition souhaitée = Nombre approximatif de partitions principales

Cette équation permet de compenser la croissance du volume de données au fil du temps. Si vous vous attendez à ce que ces 66 Gio de données quadruplent au cours de l'année suivante, le nombre approximatif de partitions est de (66 + 198) * 1,1/30 = 10. Gardez toutefois à l'esprit que vous ne disposez pas encore de ces 198 Gio de données supplémentaires. Vérifiez que cette préparation pour l'avenir ne crée pas de partitions inutilement petites qui consomment actuellement d'énormes quantités d'UC et de mémoire. Dans ce cas, 66 * 1,1/10 partitions = 7,26 Gio par partition, ce qui consomme des ressources supplémentaires et se situe au-dessous de la plage de tailles recommandées. Vous pourriez envisager l' middle-of-the-road approche de six partitions, ce qui vous laisse avec des partitions de 12 Go aujourd'hui et des partitions de 48 Go dans le futur. Là encore, vous préférerez peut-être commencer avec trois partitions et réindexer vos données lorsque les partitions dépasseront 50 Gio.

Un problème beaucoup moins fréquent consiste à limiter le nombre de partitions par nœud. Si vous dimensionnez vos partitions de manière appropriée, vous manquez généralement d'espace disque longtemps avant d'atteindre cette limite. Par exemple, une instance m6g.large.search a une taille de disque maximale de 512 Go. Si vous restez en dessous de 80 % d'utilisation du disque et que vous dimensionnez vos partitions à 20 Go, il peut accueillir environ 20 partitions. Elasticsearch 7. x et versions ultérieures, ainsi que toutes les versions de OpenSearch, ont une limite de 1 000 partitions par nœud. Pour régler le nombre maximal de partitions par nœud, configurez le paramètre cluster.max_shards_per_node. Pour obtenir un exemple, consultez Paramètres du cluster.

Le dimensionnement approprié des partitions vous permet de rester presque toujours en dessous de cette limite, mais vous pouvez également prendre en compte le nombre de partitions pour chaque Go de segments de mémoire Java. Sur un nœud donné, ne dépassez pas 25 partitions par Gio de segments de mémoire Java. Par exemple, une instance m5.large.search présente un segment de mémoire de 4 Gio, de sorte que chaque nœud ne devrait pas avoir plus de 100 partitions. Avec un tel nombre de partitions, chacune d'elles a une taille d'environ 5 Go, ce qui est bien inférieur à notre recommandation.

Choix des types d'instances et test

Une fois que vous avez calculé vos exigences de stockage et choisi le nombre de partitions dont vous avez besoin, vous pouvez commencer à prendre des décisions en termes de matériel. Les exigences matérielles varient considérablement selon la charge de travail, mais nous pouvons quand même vous fournir quelques recommandations de base.

En général, les limites de stockage pour chaque type d'instance sont mappées à la quantité d'UC et de mémoire dont vous pouvez avoir besoin pour des charges de travail légères. Par exemple, une instance m6g.large.search possède une taille de volume EBS maximale de 512 Gio, 2 cœurs vCPU et 8 Gio de mémoire. Si votre cluster comporte de nombreuses partitions, effectue des regroupements de taxe et met à jour des documents fréquemment, ou traite un grand nombre de requêtes, ces ressources peuvent être insuffisantes pour vos besoins. Si votre cluster se trouve dans l'une de ces catégories, essayez de commencer avec une configuration plus proche de 2 cœurs vCPU et de 8 Gio de mémoire tous les 100 Gio de votre espace de stockage requis.

Astuce

Pour obtenir un résumé des ressources matérielles allouées à chaque type d'instance, consultez la tarification d'Amazon OpenSearch Service.

Cependant, même ces ressources peuvent être insuffisantes. Certains OpenSearch utilisateurs signalent qu'ils ont besoin de plusieurs fois ces ressources pour répondre à leurs besoins. Pour trouver le matériel adéquat pour votre charge de travail, vous devez réaliser une estimation initiale informée, effectuer des tests avec des charges de travail représentatives, ajuster et tester à nouveau :

Étape 1 : Effectuer une estimation initiale

Pour commencer, nous recommandons un minimum de trois nœuds afin d'éviter des OpenSearch problèmes potentiels, tels qu'un état de division du cerveau (lorsqu'une interruption de communication entraîne la création d'un cluster de deux nœuds principaux). Si vous disposez de trois nœuds principaux dédiés, nous recommandons au moins deux nœuds de données pour la réplication.

Étape 2 : Calculer les besoins en stockage par nœud

Si votre espace de stockage requis est de 184 Gio et le nombre minimal de nœuds recommandé de trois, utilisez l'équation 184/3 = 61 Gio pour trouver la quantité de stockage dont chaque nœud a besoin. Dans cet exemple, vous pouvez sélectionner trois instances m6g.large.search, ou chacune utilise un volume de stockage EBS de 90 Gio pour vous permettre de disposer d'un filet de sécurité et d'une marge de croissance au fil du temps. Cette configuration fournit 6 cœurs vCPU et 24 Gio de mémoire. Elle est donc adaptée à des charges de travail plus légères.

Pour un exemple plus significatif, envisagez un espace de stockage requis de 14 Tio et une charge de travail importante. Dans ce cas, vous pouvez choisir de commencer le test avec 2 * 144 = 288 cœurs vCPU et 8 * 144 = 1152 Gio de mémoire. Ces numéros fonctionnent sur environ 18 instances i3.4xlarge.search. Si vous n'avez pas besoin d'un stockage rapide en local, vous pouvez également tester 18 instances r6g.4xlarge.search, chacune utilisant un volume de stockage EBS de 1 Tio.

Si votre cluster inclut des centaines de téraoctets de données, consultez Échelle en pétaoctets dans Amazon Service OpenSearch .

Étape 3 : Effectuer des tests représentatifs

Après avoir configuré le cluster, vous pouvez ajouter vos index en utilisant le nombre de partitions que vous avez calculé précédemment, effectuer des tests clients représentatifs à l'aide d'un ensemble de données réaliste et surveiller CloudWatch les métriques pour voir comment le cluster gère la charge de travail.

Étape 4 : Réussir ou itérer

Si les performances répondent à vos besoins, que les tests réussissent et que CloudWatch les indicateurs sont normaux, le cluster est prêt à être utilisé. N'oubliez pas de définir CloudWatch des alarmes pour détecter une mauvaise utilisation des ressources.

Si les performances ne sont pas acceptables, que les tests échouent ou que les valeurs de CPUUtilization ou JVMMemoryPressure sont élevées, vous devez choisir un autre type d'instance (ou ajouter des instances) et continuer les tests. Au fur et à mesure que vous ajoutez des instances, la distribution des partitions est OpenSearch automatiquement rééquilibrée dans le cluster.

Étant donné qu'il est plus facile de mesurer la capacité excédentaire d'un cluster suralimenté que le déficit d'un cluster sous-alimenté, nous vous recommandons de commencer par un cluster plus large que ce dont vous pensez avoir besoin. Ensuite, testez et passez à un cluster efficace qui dispose des ressources supplémentaires pour assurer la stabilité des opérations pendant les périodes d'activité accrue.

Les clusters de production ou les clusters avec des états complexes tirent profit des nœuds principaux dédiés, qui améliorent les performances et la fiabilité du cluster.