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 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énement. 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 votre source d'événements produit une charge utile moyenne de 1 Mo et que la durée moyenne de votre fonction est d'une seconde, un seul sondeur d'événements Kafka peut prendre en charge 5 MB/sec débits et 5 invocations Lambda simultanées (en supposant qu'aucune transformation de charge utile ne soit effectuée). 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 UpdateEventSourceMapping CLI 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 UpdateEventSourceMapping CLI 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 afin d'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 d'interrogateurs d'événements provisionnés et des sondeurs d'événements consommés lors de la mise à l'échelle automatique. Les frais sont calculés à l'aide d'une unité de facturation appelée Event Poller Unit (EPU). Vous payez pour le nombre et la durée des EPU utilisés, mesurés en Event-Poller-Unit-hours.

Vous pouvez utiliser le mode provisionné avec un seul ESM pour les applications sensibles aux performances ou regrouper plusieurs ESM au sein du 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 liés au mode Provisioned. 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 les sondages d'événements et prend en charge par défaut 10 sondeurs d'événements. Lorsque vous créez un mode provisionné pour Kafka ESM en définissant des sondeurs minimum et maximum, il utilise un nombre d'interrogateurs minimum pour provisionner 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 densité plus faible de sondeurs d'événements sur une EPU spécifique et peut déclencher une mise à l'échelle des EPU. Le nombre de sondeurs d'événements alloués à une 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 sondeurs événementiels 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 vos coûts en mode Provisioned, vous pouvez regrouper plusieurs Kafka ESM afin de partager la capacité EPU. Grâce au regroupement ESM et à l'utilisation améliorée de l'EPU, vous pouvez réduire vos coûts en mode provisionné jusqu'à 90 % pour les charges de travail à faible débit par rapport à l'exécution en mode ESM unique. Toutes les ESM nécessitant une capacité inférieure à 1 EPU bénéficient du regroupement ESM. Ces ESM nécessitent généralement 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 Provisioned pour toutes vos charges de travail Kafka et bénéficier de fonctionnalités telles que la validation des schémas, le filtrage des Avro/Protobuf événements, les invocations à faible latence et la gestion améliorée des erreurs, uniquement disponibles en mode Provisioned.

Lorsque vous configurez le PollerGroupName paramètre avec la même valeur pour plusieurs ESM au sein du même Amazon VPC, ces ESM partagent des 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é 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 :