Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Modes de mise à l’échelle des sondeurs d’événements Apache Kafka dans Lambda

Vous pouvez choisir entre deux modes de mise à l’échelle des sondeurs d’événements pour Amazon MSK et les mappages des sources d’événements Apache Kafka autogéré :

Mode à la demande (par défaut)

Lorsque vous créez initialement une source d’événement Kafka, Lambda alloue un nombre de sondeurs d’événements par défaut pour traiter toutes les partitions de la rubrique Kafka. Lambda augmente ou diminue automatiquement le nombre de sondeurs d’événements, en fonction de la charge de messages.

Toutes les minutes, Lambda évalue le décalage entre toutes les partitions dans la rubrique. Si le décalage est trop élevé, la partition reçoit des messages plus rapidement que Lambda ne peut les traiter. Si nécessaire, Lambda ajoute ou supprime des sondeurs d’événements dans la rubrique. Cette mise à l’échelle automatique consistant à ajouter ou à supprimer des sondeurs d’événements a lieu dans les trois minutes suivant l’évaluation.

Si votre fonction Lambda cible est limitée, Lambda réduit le nombre de sondeurs d’événements. Cette action réduit la charge de travail de la fonction en diminuant le nombre de messages que les sondeurs d’événements peuvent échanger avec la fonction.

Mode alloué

Pour les charges de travail où vous devez optimiser le débit de votre mappage des sources d’événements, vous pouvez utiliser le mode provisionné. En mode provisionné, vous définissez des limites minimales et maximales pour le nombre de sondeurs d’événements alloués. Ces sondeurs d’événements alloués sont dédiés à votre mappage des sources d’événements et peuvent gérer les pics de messages inattendus grâce à une mise à l’échelle automatique réactive. Nous vous recommandons d’utiliser le mode provisionné pour les charges de travail Kafka soumises à des exigences de performance strictes.

Dans Lambda, un sondeur d'événements est une unité de calcul dont les capacités de débit varient selon le type de source d'événements. Pour Amazon MSK et Apache Kafka autogéré, chaque sondeur d'événements peut gérer jusqu'à 5 % MB/sec du débit ou jusqu'à 5 appels simultanés. Par exemple, si la source de votre événement produit une charge utile moyenne de 1 Mo et que la durée moyenne de votre fonction est de 1 seconde, un seul sondeur d'événements Kafka peut prendre en charge 5 MB/sec débits et 5 appels Lambda simultanés (en supposant qu'il n'y ait aucune transformation de charge utile). Pour Amazon SQS, chaque sondeur d'événements peut gérer jusqu'à 1 % MB/sec du débit ou jusqu'à 10 appels simultanés. L'utilisation du mode provisionné entraîne des coûts supplémentaires en fonction de l'utilisation de votre sondeur d'événements. Pour plus d’informations sur la tarification, consultez Tarification AWS Lambda.

En mode provisionné, la plage de valeurs acceptées pour le nombre minimal de sondeurs d’événements (MinimumPollers) est comprise entre 1 et 200 inclus. La plage de valeurs acceptées pour le nombre maximal de sondeurs d’événements (MaximumPollers) est comprise entre 1 et 2 000 inclus. MaximumPollers doit être supérieur ou égal à MinimumPollers. En outre, pour maintenir un traitement ordonné au sein des partitions, Lambda limite le nombre de MaximumPollers au nombre de partitions dans la rubrique.

Pour plus de détails sur le choix des valeurs appropriées pour le nombre minimal et maximal de sondeurs d’événements, consultez Bonnes pratiques.

Vous pouvez configurer le mode provisionné pour le mappage des sources d’événements Kafka à l’aide de la console ou de l’API Lambda.

Vous pouvez configurer le mode provisionné par programmation à l'aide de l'ProvisionedPollerConfigobjet de votre. EventSourceMappingConfiguration Par exemple, la commande UpdateEventSourceMappingCLI suivante configure une MinimumPollers valeur de 5 et une MaximumPollers valeur de 100.

aws lambda update-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
    --provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'

Après avoir configuré le mode alloué, vous pouvez observer l’utilisation des sondeurs d’événements pour votre charge de travail en surveillant la métrique ProvisionedPollers. Pour de plus amples informations, veuillez consulter Métriques de mappage des sources d’événements.

Pour désactiver le mode provisionné et revenir au mode par défaut (à la demande), vous pouvez utiliser la commande UpdateEventSourceMappingCLI suivante :

aws lambda update-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
    --provisioned-poller-config '{}'

Fonctionnalités avancées de gestion des erreurs et de performance

Pour les mappages de sources d'événements Kafka avec le mode provisionné activé, vous pouvez configurer des fonctionnalités supplémentaires pour améliorer la gestion des erreurs et les performances :

Bonnes pratiques et considérations lors de l’utilisation du mode provisionné

La configuration optimale du nombre minimal et maximal de sondeurs d’événements pour votre mappage des sources d’événements dépend des exigences de performances de votre application. Nous vous recommandons de commencer avec le nombre minimal de sondeurs d’événéments par défaut afin de définir le profil de performances. Ajustez votre configuration en fonction des modèles de traitement des messages observés et du profil de performances souhaité.

Pour les charges de travail associées à des pics de trafic et à des exigences de performances strictes, augmentez le nombre minimal de sondeurs d’événements de manière à gérer les pics soudains de messages. Pour déterminer le nombre minimal de sondeurs d'événements requis, prenez en compte le nombre de messages par seconde de votre charge de travail et la taille moyenne de la charge utile, et utilisez la capacité de débit d'un seul sondeur d'événements (jusqu'à 5 MBps) comme référence.

Pour maintenir un traitement ordonné au sein d’une partition, Lambda limite le nombre maximal de sondeurs d’événements au nombre de partitions dans la rubrique. En outre, le nombre maximal de sondeurs d’événements auxquels votre mappage des sources d’événements peut être mis à l’échelle dépend des paramètres de simultanéité de la fonction.

Lorsque vous activez le mode provisionné, mettez à jour vos paramètres réseau pour supprimer les points de terminaison AWS PrivateLink VPC et les autorisations associées.

Optimisation des coûts pour le mode provisionné

Tarification du mode provisionné

Le mode provisionné est facturé en fonction du nombre minimum de sondeurs d'événements provisionnés et des sondeurs d'événements consommés lors du dimensionnement automatique. Les frais sont calculés à l'aide d'une unité de facturation appelée Event Poller Unit (EPU). Vous payez en fonction du nombre et de la durée d' EPUs utilisation, exprimés en Event-Poller-Unit-hours. Vous pouvez utiliser le mode provisionné avec un seul ESM pour les applications sensibles aux performances ou vous pouvez en regrouper plusieurs au sein d'un même VPC pour partager ESMs la capacité et les coûts de l'EPU. Nous aborderons en détail deux fonctionnalités qui vous aident à optimiser les coûts de votre mode provisionné. Pour plus de détails sur les tarifs, consultez la section Tarification AWS Lambda.

Utilisation améliorée de l'EPU

Chaque EPU prend en charge une capacité de MB/s débit allant jusqu'à 20 pour l'interrogation d'événements et prend en charge 10 sondeurs d'événements par défaut. Lorsque vous créez un mode provisionné pour Kafka ESM en définissant un minimum et un maximum de sondeurs, il utilise un nombre minimum d'interrogateurs pour le provisionnement sur la EPUs base de 10 sondeurs d'événements par EPU par défaut. Cependant, chaque sondeur d'événements peut évoluer indépendamment pour prendre en charge jusqu'à 5 % de la capacité MB/s de débit, ce qui peut nécessiter une plus faible densité de sondeurs d'événements sur un EPU spécifique et peut déclencher une mise à l'échelle de. EPUs Le nombre de sondeurs d'événements alloués sur un EPU dépend de la capacité de calcul consommée par chaque sondeur d'événements. Cette approche d'utilisation améliorée de l'EPU permet aux enquêteurs ayant des exigences de débit variables d'utiliser efficacement la capacité de l'EPU, réduisant ainsi les coûts pour tous. ESMs

Regroupement ESM

Pour optimiser davantage les coûts de votre mode provisionné, vous pouvez regrouper plusieurs Kafka ESMs afin de partager la capacité de l'EPU. Grâce au regroupement ESM et à l'utilisation améliorée de l'EPU, vous pouvez réduire les coûts du mode provisionné jusqu'à 90 % pour les charges de travail à faible débit par rapport à l'exécution en mode ESM unique. Tous ceux ESMs qui nécessitent moins d'une capacité EPU bénéficieront du regroupement ESM. Cela nécessite ESMs généralement un nombre minimal de sondeurs d'événements pour répondre à leurs besoins en matière de débit. Cette fonctionnalité vous permettra d'adopter le mode provisionné pour toutes vos charges de travail Kafka et de bénéficier de fonctionnalités telles que la validation du schéma, le filtrage des Avro/Protobuf événements, les appels à faible latence et la gestion améliorée des erreurs, uniquement disponibles en mode provisionné.

Lorsque vous configurez le PollerGroupName paramètre avec la même valeur pour plusieurs éléments d' ESMs un même Amazon VPC, ceux-ci ESMs partagent des ressources EPU au lieu de nécessiter chacun une capacité EPU dédiée. Vous pouvez regrouper jusqu'à 100 ESMs par groupe de sondeurs et le nombre maximum de sondeurs par groupe ne peut pas dépasser 2 000. ESMs

Pour configurer le regroupement ESM (console)

Pour configurer le regroupement ESM (AWS CLI)

L'exemple suivant crée un ESM avec un groupe de sondeurs nommé : production-app-group

aws lambda create-event-source-mapping \
  --function-name myFunction1 \
  --event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \
  --topics topic1 \
  --starting-position LATEST \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "production-app-group"
  }'

Pour ajouter un autre ESM au même groupe (partageant la capacité de l'EPU), utilisez le même : PollerGroupName

aws lambda create-event-source-mapping \
  --function-name myFunction2 \
  --event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \
  --topics topic2 \
  --starting-position LATEST \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "production-app-group"
  }'

# Move ESM to a different group
aws lambda update-event-source-mapping \
  --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "new-group-name"
  }'

# Remove ESM from group (use dedicated resources)
aws lambda update-event-source-mapping \
  --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": ""
  }'

Considérations relatives aux stratégies de regroupement

Exemple d'optimisation des coûts

Imaginons un scénario dans lequel vous en avez 10 ESMs, chacun étant configuré avec un sondeur d'événements et un débit inférieur à 2 Mo/s :

Sans regroupement :

Avec regroupement :