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 requêtes simultanées que Lambda envoie à chaque environnement d'exécution est contrôlé par le PerExecutionEnvironmentMaxConcurrency paramètre de la 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 processeur virtuel, ou vous pouvez configurer votre propre valeur. Cette valeur détermine le nombre de tâches Tokio générées par le runtime et est statique pendant toute la durée de vie de l'environnement d'exécution. Chaque travailleur gère 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 à la base de données et tous les objets statiques modifiés lors du traitement des demandes.

Pour activer la gestion 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 plusieurs invocations (un pool de base de données, une structure de configuration), enveloppez-le dans Arc et clonez-le Arc dans chaque invocation.

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 du SDK

L'exemple suivant utilise un client S3 pour 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 à la base de données

Lorsque votre gestionnaire a besoin d'accéder à un état partagé, tel qu'un client et une configuration, enveloppez-le dans Arc et clonez-le Arc dans chaque invocation :

#[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 explicite des fichiers pour éviter toute corruption des données.

Logging

L'entrelacement des journaux (les entrées de journal provenant de différentes demandes sont entrelacées dans les journaux) est normal dans les systèmes multisimultanés. Les fonctions utilisant les instances gérées Lambda prennent en charge le format de journal JSON structuré via les contrôles de journalisation avancés de Lambda. Ce format inclut lerequestId, permettant de corréler les entrées du journal à une seule demande. Pour plus d'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.

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

Utilisée event.context.deadline pour détecter les délais d'invocation : elle contient la date limite d'invocation en millisecondes.

Initialisation et arrêt

L'initialisation des fonctions se produit une fois par environnement d'exécution. Les objets créés lors de l'initialisation sont partagés entre les requêtes.

Pour les fonctions Lambda dotées d'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 buffers. lambda_runtimepropose une aide pour simplifier la configuration de la gestion gracieuse 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 :