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.

Support Rust pour les instances gérées Lambda

Configuration de la simultanéité

Le nombre maximum de demandes simultanées que Lambda envoie à chaque environnement d'exécution est contrôlé par le PerExecutionEnvironmentMaxConcurrency paramètre de configuration de la fonction. Il s'agit d'un paramètre facultatif, et la valeur par défaut pour Rust est de 8 requêtes simultanées par vCPU, ou vous pouvez configurer votre propre valeur. Cette valeur détermine le nombre de tâches Tokio générées par le moteur d'exécution et est statique pendant toute la durée de vie de l'environnement d'exécution. Chaque travailleur traite exactement une demande en vol à la fois, sans multiplexage par travailleur. Lambda ajuste automatiquement le nombre de demandes simultanées jusqu'au maximum configuré en fonction de la capacité de chaque environnement d'exécution à absorber ces demandes.

Création de fonctions pour la multisimultanéité

Vous devez appliquer les mêmes pratiques de sécurité des threads lorsque vous utilisez des instances gérées Lambda que dans tout autre environnement multithread. Étant donné que l'objet du gestionnaire est partagé entre tous les threads de travail, tout état mutable doit être sûr pour les threads. Cela inclut les collections, les connexions aux bases de données et tous les objets statiques modifiés lors du traitement des demandes.

Pour activer le traitement des demandes simultanées, ajoutez l'indicateur de concurrency-tokio fonctionnalité à votre Cargo.toml fichier.

[dependencies]  
lambda_runtime = { version = "1", features = ["concurrency-tokio"] }

Le point lambda_runtime::run_concurrent(…) d'entrée doit être appelé depuis un environnement d'exécution Tokio, généralement fourni par l'#[tokio::main]attribut de votre fonction principale. La fermeture de votre gestionnaire doit implémenter Clone+ Send. Cela permet au framework de partager votre gestionnaire entre plusieurs tâches asynchrones en toute sécurité. Si ces limites ne sont pas respectées, votre code ne sera pas compilé.

Lorsque vous avez besoin d'un état partagé entre les invocations (un pool de base de données, une structure de configuration), intégrez-le Arcet clonez-le dans chaque appelArc.

Tous les AWS SDK pour les clients Rust sont sécurisés en matière de concurrence et ne nécessitent aucune manipulation particulière.

Exemple : AWS client SDK

L'exemple suivant utilise un client S3 pour télécharger un objet à chaque appel. Le client est cloné directement dans la fermeture sans Arc :

let config = aws_config::load_defaults(BehaviorVersion::latest()).await;  
let s3_client = aws_sdk_s3::Client::new(&config);  
  
run_concurrent(service_fn(move |event: LambdaEvent<Request>| {  
    let s3_client = s3_client.clone(); // cheap clone, no Arc needed  
    async move {  
        s3_client.put_object()  
            .bucket(&event.payload.bucket)  
            .key(&event.payload.key)  
            .body(event.payload.body.into_bytes().into())  
            .send()  
            .await?;  
        Ok(Response { message: "uploaded".into() })  
    }  
}))  
.await

Exemple : pools de connexions aux bases de données

Lorsque votre gestionnaire a besoin d'accéder à un état partagé tel qu'un client et une configuration, intégrez-le Arcet clonez-le à chaque appel : Arc

#[derive(Debug)]  
struct AppState {  
    dynamodb_client: DynamoDbClient,  
    table_name: String,  
    cache_ttl: Duration,  
}  
  
let config = aws_config::load_defaults(BehaviorVersion::latest()).await;  
let state = Arc::new(AppState {  
    dynamodb_client: DynamoDbClient::new(&config),  
    table_name: std::env::var("TABLE_NAME").expect("TABLE_NAME must be set"),  
    cache_ttl: Duration::from_secs(300),  
});  
  
run_concurrent(service_fn(move |event: LambdaEvent<Request>| {  
    let state = state.clone();  
    async move { handle(event, state).await }  
}))  
.await

Répertoire /tmp partagé

Le /tmp répertoire est partagé entre toutes les invocations simultanées dans le même environnement d'exécution. Utilisez des noms de fichiers uniques par appel (par exemple, incluez l'ID de demande) ou implémentez un verrouillage de fichier explicite pour éviter la corruption des données.

Logging

L'entrelacement des journaux (les entrées des journaux provenant de différentes demandes sont entrelacées dans des journaux) est normal dans les systèmes multiconcurrents. Les fonctions utilisant des instances gérées Lambda prennent en charge le format de journal JSON structuré via les commandes de journalisation avancées de Lambda. Ce format inclut lerequestId, ce qui permet de corréler les entrées du journal à une seule demande. Pour de plus amples informations, voirImplémentation de la journalisation avancée avec la caisse Tracing.

Contexte de la demande

L'Contextobjet est transmis directement à chaque appel de gestionnaire. Permet event.context.request_id d'accéder à l'ID de demande pour la demande en cours.

event.context.xray_trace_idÀ utiliser pour accéder au X-Ray Trace ID. Lambda ne prend pas en charge la variable d'_X_AMZN_TRACE_IDenvironnement avec les instances gérées par Lambda. L'identifiant de trace X-Ray est propagé automatiquement lors de l'utilisation du AWS SDK pour Rust.

event.context.deadlineÀ utiliser pour détecter les délais d'invocation : il contient le délai d'invocation en millisecondes.

Initialisation et arrêt

L'initialisation de la fonction a lieu une fois par environnement d'exécution. Les objets créés lors de l'initialisation sont partagés entre les demandes.

Pour les fonctions Lambda avec extensions, l'environnement d'exécution émet un signal SIGTERM lors de l'arrêt. Ce signal est utilisé par les extensions pour déclencher des tâches de nettoyage, telles que le vidage des tampons. lambda_runtimepropose une aide pour simplifier la configuration de la gestion progressive des signaux d'arrêt,. spawn_graceful_shutdown_handler() Pour en savoir plus sur le cycle de vie de l'environnement d'exécution, veuillez consulter Comprendre le cycle de vie de l’environnement d’exécution Lambda.

Versions de dépendance

Les instances gérées Lambda nécessitent la version minimale du package suivante :