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é :

On-demand mode (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 d'événement 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 plus d’informations, consultez 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 des données utiles, et utilisez la capacité de débit d’un seul sondeur d’événements (jusqu’à 5 Mbit/s) 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 des EPU utilisés, 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 regrouper plusieurs ESM au sein d'un même VPC afin de partager la capacité et les coûts de l'EPU. Les sections suivantes décrivent deux fonctionnalités qui vous aident à optimiser les coûts du 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 des sondeurs minimum et maximum, il utilise un nombre minimum d'interrogateurs pour approvisionner les EPU sur la 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 le dimensionnement des EPU. 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 d'événements ayant des exigences de débit variables d'utiliser efficacement la capacité de l'EPU, réduisant ainsi les coûts pour tous les ESM.

Regroupement ESM

Pour optimiser davantage les coûts de votre mode provisionné, vous pouvez regrouper plusieurs eSM Kafka 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 les ESM qui nécessitent moins d'une capacité EPU bénéficient du regroupement ESM. Ces ESM ont généralement besoin d'un minimum de sondeurs d'événements pour répondre à leurs besoins en matière de débit. Grâce à cette fonctionnalité, vous pouvez adopter le mode provisionné pour toutes vos charges de travail Kafka et 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 eSM au sein d'un même Amazon VPC, ces derniers partagent les ressources EPU au lieu de nécessiter chacun une capacité EPU dédiée. Vous pouvez regrouper jusqu’à 100 ESM par groupe d’observateurs. Le nombre maximum d’observateurs agrégés pour tous les ESM d’un groupe ne peut pas dépasser 2 000.

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 disposez de 10 ESM, chacun étant configuré avec un sondeur d'événements et un débit inférieur à 2 : MB/s

Sans regroupement :

Avec regroupement :