Utiliser la mise à l'échelle gérée dans Amazon EMR

Dans les cas suivants Régions AWS, la mise à l'échelle gérée par Amazon EMR est disponible avec Amazon EMR 6.14.0 et versions supérieures :

Dans les cas suivants Régions AWS, la mise à l'échelle gérée par Amazon EMR est disponible avec Amazon EMR 5.30.0 et 6.1.0 et versions supérieures :

La mise à l'échelle gérée par Amazon EMR fonctionne uniquement avec des applications YARN, telles que Spark, Hadoop, Hive, Flink. Elle ne prend pas en charge les applications non basées sur YARN, telles que Presto et HBase.

Minimum (MinimumCapacityUnits) : limite inférieure de la capacité EC2 autorisée dans un cluster. Elle est mesurée par le biais de cœurs ou d'instances d'unités centrales virtuelles (vCPU) pour les groupes d'instances. Elle est mesuré par des unités, par exemple des flottes d'instance.

Maximum (MaximumCapacityUnits) : limite supérieure de la capacité EC2 autorisée dans un cluster. Elle est mesurée par le biais de cœurs ou d'instances d'unités centrales virtuelles (vCPU) pour les groupes d'instances. Elle est mesuré par des unités, par exemple des flottes d'instance.

On-Demand limit (MaximumOnDemandCapacityUnits) (Facultatif) : limite supérieure de la capacité EC2 autorisée pour On-Demand le type de marché d'un cluster. Si ce paramètre n'est pas spécifié, une valeur par défaut de MaximumCapacityUnits sera utilisée.

Nombre maximum de nœuds principaux (MaximumCoreCapacityUnits) (Facultatif) : limite supérieure de la capacité EC2 autorisée pour le type de nœud principal dans un cluster. Si ce paramètre n'est pas spécifié, une valeur par défaut de MaximumCapacityUnits sera utilisée.

La mise à l'échelle gérée est prise en charge dans les versions limitées Régions AWS et Amazon EMR. Pour de plus amples informations, veuillez consulter Disponibilité de la mise à l'échelle gérée.

Vous devez configurer les paramètres requis pour la mise à l'échelle gérée par Amazon EMR. Pour de plus amples informations, veuillez consulter Paramètres de mise à l'échelle gérée.

Pour utiliser la mise à l'échelle gérée, le processus de collecte de mesures doit pouvoir se connecter au point de terminaison d'API public pour une mise à l'échelle gérée dans la passerelle d'API. Si vous utilisez un nom DNS privé avec Amazon Virtual Private Cloud, Managed Scaling ne fonctionnera pas correctement. Pour garantir le bon fonctionnement de la mise à l'échelle gérée, nous vous recommandons de prendre l'une des mesures suivantes :

Si vos tâches YARN sont ralenties par intermittence pendant la réduction et que les journaux du gestionnaire de ressources YARN indiquent que la plupart de vos nœuds ont été placés sur liste noire pendant cette période, vous pouvez ajuster le seuil de délai de mise hors service.

Réduisez le spark.blacklist.decommissioning.timeout d'une heure à une minute pour que le nœud soit disponible et que d'autres conteneurs en attente puissent poursuivre le traitement des tâches.

Vous devez également définir YARN.resourcemanager.nodemanager-graceful-decommission-timeout-secs sur une valeur plus élevée afin de vous assurer qu'Amazon EMR ne force pas la fermeture du nœud alors que la plus longue « tâche Spark » est toujours en cours d'exécution sur le nœud. La valeur par défaut actuelle est de 60 minutes, ce qui signifie que YARN force la fermeture du conteneur au bout de 60 minutes une fois que le nœud entre en état de mise hors service.

L'exemple de ligne de journal du gestionnaire de ressources YARN suivant montre les nœuds ajoutés à l'état de mise hors service :

2021-10-20 15:55:26,994 INFO org.apache.hadoop.YARN.server.resourcemanager.DefaultAMSProcessor (IPC Server handler 37 on default port 8030): blacklist are updated in Scheduler.blacklistAdditions: [ip-10-10-27-207.us-west-2.compute.internal, ip-10-10-29-216.us-west-2.compute.internal, ip-10-10-31-13.us-west-2.compute.internal, ... , ip-10-10-30-77.us-west-2.compute.internal], blacklistRemovals: []

Découvrez plus de détails sur la manière dont Amazon EMR s'intègre à la liste noire YARN lors de la mise hors service des nœuds, sur les cas où des nœuds Amazon EMR peuvent être répertoriés sur la liste de refus et sur la configuration du comportement de mise hors service des nœuds Spark.

Pour les charges de travail Spark, la désactivation de Spark Dynamic Resource Allocator (DRA) en modifiant la propriété Spark spark.dynamic Allocation.enabled pour FALSE peut entraîner des problèmes de Managed Scaling, dans lesquels les clusters peuvent être redimensionnés plus que nécessaire pour vos charges de travail (jusqu'au maximum de calcul). Lorsque vous utilisez Managed Scaling pour ces charges de travail, nous vous recommandons de laisser Spark DRA activé, qui est l'état par défaut de cette propriété.

Over-utilization des volumes EBS peuvent entraîner des problèmes de Managed Scaling. Nous vous recommandons de maintenir le volume EBS en dessous de 90 % d'utilisation. Pour de plus amples informations, veuillez consulter Options de stockage des instances et comportement dans Amazon EMR.

Les CloudWatch métriques Amazon sont essentielles au bon fonctionnement de la mise à l'échelle gérée par Amazon EMR. Nous vous recommandons de suivre de près les CloudWatch statistiques d'Amazon pour vous assurer que les données ne sont pas manquantes. Pour plus d'informations sur la façon dont vous pouvez configurer CloudWatch des alarmes pour détecter les métriques manquantes, consultez la section Utilisation CloudWatch des alarmes Amazon.

Les opérations de mise à l'échelle gérées sur des clusters 5.30.0 et 5.30.1 sans Presto installé peuvent provoquer des défaillances d'applications ou empêcher le maintien d'un groupe d'instances ou d'une flotte d'instances uniforme dans l'état ARRESTED, en particulier lorsqu'une opération de réduction est rapidement suivie d'une opération d'augementation.

Pour contourner le problème, choisissez Presto comme application à installer lorsque vous créez un cluster avec les versions 5.30.0 et 5.30.1 d'Amazon EMR, même si votre travail ne nécessite pas Presto.

Lorsque vous définissez le nombre maximal de nœuds principaux et la On-Demand limite pour la mise à l'échelle gérée par Amazon EMR, tenez compte des différences entre les groupes d'instances et les parcs d'instances. Chaque groupe d'instances comprend le même type d'instance et la même option d'achat pour les instances : On-Demand ou Spot. Pour chaque parc d'instances, vous pouvez spécifier jusqu'à cinq types d'instances, qui peuvent être provisionnés en tant qu' On-Demand instances ponctuelles. Pour plus d'informations, consultez Créer un cluster avec des flottes d'instances ou des groupes d'instances uniformes, Options des flottes d'instances et Scénarios d'allocation de nœuds.

Avec Amazon EMR 5.30.0 et versions ultérieures, si vous supprimez la règle Autoriser tous les accès sortants par défaut sur 0.0.0.0/ pour le groupe de sécurité principal, vous devez ajouter une règle qui autorise la connectivité TCP sortante à votre groupe de sécurité pour l'accès au service sur le port 9443. Votre groupe de sécurité pour l'accès aux services doit également autoriser le trafic TCP entrant sur le port 9443 à partir du groupe de sécurité principal. Pour plus d'informations sur la configuration des groupes de sécurité, consultez Groupe EMR-managed de sécurité Amazon pour l'instance principale (sous-réseaux privés).

Vous pouvez l'utiliser AWS CloudFormation pour configurer la mise à l'échelle gérée par Amazon EMR. Pour plus d'informations, consultez AWS::EMR::Cluster dans le Guide de l'utilisateur AWS CloudFormation .

Si vous utilisez des nœuds Spot, pensez à utiliser des étiquettes de nœud pour empêcher Amazon EMR de supprimer des processus applicatifs lorsqu'Amazon EMR supprime des nœuds Spot. Pour plus d'informations sur les libellés des nœuds, consultez la section Nœuds de tâches.

L'étiquetage des nœuds n'est pas pris en charge par défaut dans les versions 6.15 ou antérieures d'Amazon EMR. Pour plus d'informations, voir Comprendre les types de nœuds : nœuds principaux, principaux et nœuds de tâches.

Si vous utilisez les versions 6.15 ou antérieures d'Amazon EMR, vous ne pouvez attribuer des étiquettes de nœud que par type de nœud, tel que les nœuds principaux et les nœuds de tâches. Toutefois, si vous utilisez la version 7.0 ou supérieure d'Amazon EMR, vous pouvez configurer les libellés des nœuds par type de nœud et par type de marché, par exemple On-Demand et Spot.

Si la demande du processus d'application augmente et que la demande de l'exécuteur diminue lorsque vous limitez le processus d'application aux nœuds principaux, vous pouvez rajouter des nœuds principaux et supprimer des nœuds de tâches lors de la même opération de redimensionnement. Pour plus d'informations, voir Comprendre la stratégie et les scénarios d'allocation de nœuds.

Amazon EMR n'étiquette pas les nœuds de tâches. Vous ne pouvez donc pas définir les propriétés YARN pour restreindre les processus d'application uniquement pour les nœuds de tâches. Toutefois, si vous souhaitez utiliser des types de marché comme étiquettes de nœud, vous pouvez utiliser les SPOT étiquettes ON_DEMAND ou pour le placement du processus de candidature. Nous ne recommandons pas d'utiliser des nœuds Spot pour les processus principaux de l'application.

Lorsque vous utilisez des étiquettes de nœuds, le nombre total d'unités en cours d'exécution dans le cluster peut temporairement dépasser le calcul maximal défini dans votre politique de dimensionnement gérée pendant qu'Amazon EMR met hors service certaines de vos instances. Le total des unités demandées restera toujours égal ou inférieur au calcul maximal de votre police.

La mise à l'échelle gérée ne prend en charge que les étiquettes de nœud SPOT et/ou ON_DEMAND CORE etTASK. Les étiquettes de nœud personnalisées ne sont pas prises en charge.

Amazon EMR crée des étiquettes de nœud lors de la création du cluster et du provisionnement des ressources. Amazon EMR ne prend pas en charge l'ajout d'étiquettes de nœud lorsque vous reconfigurez le cluster. Vous ne pouvez pas non plus modifier les étiquettes des nœuds lors de la configuration de la mise à l'échelle gérée après le lancement du cluster.

Managed Scaling fait évoluer les nœuds principaux et les nœuds de tâches indépendamment en fonction du processus applicatif et de la demande de l'exécuteur. Pour éviter les problèmes de perte de données HDFS lors de la réduction de la taille du cœur, suivez les pratiques standard pour les nœuds principaux. Pour en savoir plus sur les meilleures pratiques concernant les nœuds principaux et la réplication HDFS, consultez la section Considérations et meilleures pratiques.

Vous ne pouvez pas placer à la fois le processus d'application et les exécuteurs sur le ON_DEMAND nœud core ou uniquement. Si vous souhaitez ajouter à la fois le processus d'application et les exécuteurs sur l'un des nœuds, n'utilisez pas la yarn.node-labels.am.default-node-label-expression configuration.

Par exemple, pour placer à la fois le processus d'application et les exécuteurs dans ON_DEMAND des nœuds, définissez max compute sur le même que le maximum du ON_DEMAND nœud. Supprimez également la yarn.node-labels.am.default-node-label-expression configuration.

Pour ajouter à la fois le processus d'application et les exécuteurs sur core les nœuds, supprimez la yarn.node-labels.am.default-node-label-expression configuration.

Lorsque vous utilisez la mise à l'échelle gérée avec des étiquettes de nœuds, définissez la propriété yarn.scheduler.capacity.maximum-am-resource-percent: 1 si vous prévoyez d'exécuter plusieurs applications en parallèle. Cela garantit que les processus de votre application utilisent pleinement les ON_DEMAND nœuds CORE ou disponibles.

Si vous utilisez une mise à l'échelle gérée avec des étiquettes de nœud, définissez la propriété yarn.resourcemanager.decommissioning.timeout sur une valeur plus longue que l'application la plus ancienne de votre cluster. Cela réduit le risque que la mise à l'échelle gérée par Amazon EMR doive replanifier vos applications vers une remise en service ou des nœuds. CORE ON_DEMAND

Pour réduire le risque de défaillances des applications dues à la perte de données issues du shuffle, Amazon EMR collecte des métriques à partir du cluster afin de déterminer les nœuds qui contiennent des données de shuffle transitoires existantes datant de l'étape en cours et de l'étape précédente. Dans de rares cas, les métriques peuvent continuer à signaler des données obsolètes pour des applications déjà terminées ou résiliées. Cela peut avoir un impact sur la réduction rapide des instances de votre cluster. Pour les clusters contenant une grande quantité de données mélangées, pensez à utiliser les versions 6.13 et ultérieures d'EMR.