Fonctions Serverless en PHP : AWS Lambda niveau avancé

Fonctions Serverless en PHP : AWS Lambda — de la théorie à la pratique avancée

L'architecture serverless n'est plus une exotique depuis longtemps, et PHP, grâce à des outils comme Bref et Laravel Vapor, a solidement conquis sa place dans le monde du calcul sans serveur. Dans cet article, nous allons explorer les techniques avancées pour travailler avec AWS Lambda en PHP : comment vaincre le démarrage à froid, configurer le travail au sein d'un VPC et traiter efficacement les événements de S3 et SQS. Ce contenu est destiné aux développeurs déjà familiers avec les bases du déploiement d'applications PHP sur Lambda.

1. Optimisation du démarrage à froid : de 2 secondes à 200 millisecondes

Le principal ennemi des applications serverless en PHP est le démarrage à froid. Contrairement à Node.js ou Python, PHP nécessite le chargement de l'interpréteur et du framework. Voici comment minimiser les latences.

1.1. Utilisation de Bref et des couches précompilées

Bref est la norme de facto pour exécuter PHP sur Lambda. Il fournit des couches (Layers) prêtes à l'emploi avec l'interpréteur PHP. Pour accélérer, utilisez bref/extra-php-extensions et n'incluez que les extensions nécessaires.

Exemple de configuration de base serverless.yml :

service: my-php-app\n\nprovider:\n  name: aws\n  runtime: provided.al2\n  region: eu-central-1\n\nplugins:\n  - ./vendor/bref/bref\n\nfunctions:\n  api:\n    handler: public/index.php\n    layers:\n      - ${bref:layer.php-81}\n    events:\n      - httpApi: '*'\n

1.2. Chargement paresseux et mise en cache des configurations

Ne chargez pas l'ensemble du framework (Laravel, Symfony) à chaque requête. Utilisez Laravel Octane avec Swoole ou RoadRunner, mais pour Lambda, Bref Laravel Bridge est plus adapté, car il met en cache les configurations et les routes.

Code pour la mise en cache de la configuration dans bootstrap.php :

// public/index.php (point d'entrée pour Lambda)\nrequire_once __DIR__ . '/../vendor/autoload.php';\n\n$app = require_once __DIR__ . '/../bootstrap/app.php';\n\n// Mise en cache de la configuration au premier démarrage\nif (! file_exists(__DIR__ . '/../bootstrap/cache/config.php')) {\n    $app->make('config')->get('app');\n    // Sauvegarde de la configuration compilée\n    file_put_contents(\n        __DIR__ . '/../bootstrap/cache/config.php',\n        '<?php return ' . var_export($app->make('config')->all(), true) . ';'\n    );\n} else {\n    $config = require __DIR__ . '/../bootstrap/cache/config.php';\n    $app->instance('config', $config);\n}\n\n$kernel = $app->make(Illuminate\\Contracts\\Http\\Kernel::class);\n$response = $kernel->handle(\n    $request = Illuminate\\Http\\Request::capture()\n);\n$response->send();\n$kernel->terminate($request, $response);\n

Conseil : Définissez memorySize à 1024 Mo et timeout à 30 secondes pour un bon équilibre entre vitesse et coût. Plus de mémoire signifie un processeur plus rapide.

2. Travail avec VPC : connexion à RDS et ElastiCache

Par défaut, les fonctions Lambda fonctionnent en dehors de votre VPC. Pour accéder aux bases de données (RDS, Aurora) ou au cache (ElastiCache), vous devez placer la fonction à l'intérieur du VPC. Cela ajoute de la complexité et augmente le démarrage à froid de 5 à 10 secondes.

2.1. Configuration du VPC dans serverless.yml

functions:\n  processUser:\n    handler: src/handlers/userHandler.php\n    layers:\n      - ${bref:layer.php-81}\n    vpc:\n      securityGroupIds:\n        - sg-0123456789abcdef0\n      subnetIds:\n        - subnet-abc123\n        - subnet-def456\n    events:\n      - sqs:\n          arn: arn:aws:sqs:eu-central-1:123456789012:user-queue\n

2.2. Gestion des connexions via PDO

Utilisez le pool de connexions RDS Proxy ou ElastiCache pour réutiliser les connexions au sein d'un même conteneur Lambda.

Exemple de classe pour travailler avec la base de données avec réutilisati