guidance for self healing code on aws
1.0.0
Tout client qui crée un logiciel présente inévitablement des bogues, mais en même temps, il doit souvent faire face à la pression du développement de produits et de fonctionnalités, ce qui le pousse souvent à ne plus donner la priorité à la résolution des bogues. Ces bogues peuvent détourner l'attention des développeurs, dégrader l'expérience utilisateur et générer des mesures trompeuses sur l'expérience utilisateur. Même si les clients donnent la priorité à la correction des bogues, cela nécessite souvent un investissement commercial sous la forme d'ingénieurs expérimentés et qualifiés pour consacrer beaucoup de temps et se concentrer sur la compréhension et la correction des bogues.
Ce référentiel contient un système de bout en bout qui combine Amazon CloudWatch, AWS Lambda et Amazon Bedrock pour créer un système de bout en bout qui détecte et corrige automatiquement les bogues afin d'améliorer la fiabilité des applications et l'expérience client globale. Le Log Driven Bug Fixer se connecte au groupe de journaux Amazon CloudWatch Logs d'une application via un abonnement AWS Lambda. Tous les journaux contenant des erreurs d'application sont envoyés pour traitement ; où une fonction Lambda crée une invite, comprenant la trace de pile et les fichiers de code pertinents, puis l'envoie à Amazon Bedrock (Claude v1) pour générer des correctifs de code. Le code modifié est ensuite transféré dans le contrôle de code source (git) et crée une demande d'extraction pour examen et déploiement.
Le tableau suivant fournit un exemple de répartition des coûts pour le déploiement de ce guide avec les paramètres par défaut dans la région USA Est (Virginie du Nord) pendant un mois.
| Service AWS | Dimensions | Coût mensuel [USD] |
|---|---|---|
| Amazon DynamoDB | Taille moyenne des éléments 0,5 Ko, 0,5 RCU et 1 WCU par message | 17,08 $ |
| Amazon CloudWatch | 33 Ko de journaux écrits et stockés par message | 8,77 $ |
| AWS Lambda | Temps d'exécution de 45 secondes par message d'erreur unique | 2,43 $ |
| AmazonSQS | 3 requêtes par message, taille de message 1 000 | 0,01 $ |
| Substrat amazonien | 1 000 jetons d'entrée, 1 000 jetons de sortie | 32,00 $ |
| Total | 60,29 $ |
Cette solution prend en charge les environnements de build sous Mac ou Linux.
Ce déploiement nécessite que vous ayez accès aux services AWS suivants :
Ces instructions de déploiement sont optimisées pour fonctionner au mieux sur Mac ou Amazon Linux 2023. Le déploiement sur un autre système d'exploitation peut nécessiter des étapes supplémentaires.
Rassemblez les informations suivantes sur votre application existante car ce sont des entrées nécessaires pour configurer la solution
Clonez le dépôt à l'aide de la commande git clone https://github.com/aws-solutions-library-samples/guidance-for-self-healing-code-on-aws.git
cd dans le dossier du dépôt cd guidance-for-self-healing-code-on-aws
Installez les packages dans les exigences à l'aide de la commande pip install -r requirement.txt
Exportez les variables d'environnement requises :
# CloudFormation stack name.
export STACK_NAME=self-healing-code
# S3 bucket to store zipped Lambda function code for deployments.
# Note: the S3 bucket must be in the same region as the CloudFormation stack deployment region.
export DEPLOYMENT_S3_BUCKET=<NAME OF YOUR S3 BUCKET>
# All variables and secrets for this project will be stored under this prefix.
# You can define a different value if it's already in use.
export PARAMETER_STORE_PREFIX=/${STACK_NAME}/
pip3 install -r requirements.txt
# Follow the resulting series of prompts to store configuration details in SSM Parameter Store. This steps will use information gathered during Step 1
python3 bin/configure.py
Réexécutez le script ci-dessus si vous devez apporter des modifications. Vous pouvez également modifier directement les valeurs du magasin de paramètres SSM qui sont stockées sous le préfixe ${PARAMETER_STORE_PREFIX}.
# Create a deployment package (Lambda function source code)
cloudformation/package.sh
# Deploy the CloudFormation template
cloudformation/deploy.sh
Ouvrez la console CloudFormation et vérifiez l'état du modèle avec le nom de la pile spécifié à l'étape 4 des étapes de déploiement.
Dès réception d'une trace de pile Python dans le groupe de journaux Amazon CloudWatch de votre application configuré à l'étape 6, une demande d'extraction sera créée dans le système de contrôle de source. Notez que le traitement peut prendre plusieurs minutes. Si vous souhaitez une validation rapide de la solution, vous pouvez injecter une erreur dans votre application existante ce qui peut entraîner une trace de pile python dans les logs de votre application
Exemple de demande d'extraction de sortie dans Github :
Ce guide est un exemple de projet qui cible les bases de code Python 3.9+. Il existe d’autres possibilités d’étendre et d’améliorer ce système. Quelques prochaines étapes suggérées :
src/handlers/providers pour affiner les réponses des LLMsrc/handlers/source_code.py )src/providers/source_code.py ) aws cloudformation delete-stack --stack-name ${STACK_NAME}
aws ssm delete-parameters-by-path --path ${PARAMETER_STORE_PREFIX}
Les clients sont responsables de faire leur propre évaluation indépendante des informations contenues dans ce guide. Ce guide : (a) est fourni à titre informatif uniquement, (b) représente les offres et pratiques de produits actuelles d'AWS, qui sont susceptibles d'être modifiées sans préavis, et (c) ne crée aucun engagement ou assurance de la part d'AWS et de ses sociétés affiliées, fournisseurs ou concédants de licence. Les produits ou services AWS sont fournis « tels quels » sans garanties, représentations ou conditions d'aucune sorte, expresses ou implicites. Les responsabilités d'AWS envers ses clients sont contrôlées par les accords AWS, et ce Guide ne fait pas partie, ni ne modifie, d'un accord entre AWS et ses clients.
