소프트웨어를 만드는 모든 고객은 필연적으로 버그를 가지게 되지만, 동시에 제품 및 기능 개발에 대한 압박으로 인해 종종 버그 해결 우선순위를 낮추게 됩니다. 이러한 버그는 개발자의 집중력을 흐트러뜨리고, 사용자 경험을 저하시키며, 사용자 경험에 대한 오해의 소지가 있는 지표를 유발할 수 있습니다. 고객이 버그 수정을 우선시하더라도 버그를 이해하고 수정하는 데 많은 시간과 집중을 투자하려면 경험/숙련된 엔지니어 형태의 비즈니스 투자가 필요한 경우가 많습니다.
이 리포지토리에는 Amazon CloudWatch, AWS Lambda 및 Amazon Bedrock을 결합하여 버그를 자동으로 감지하고 수정하여 애플리케이션 안정성과 전반적인 고객 경험을 향상시키는 엔드 투 엔드 시스템을 만드는 엔드 투 엔드 시스템이 포함되어 있습니다. Log Driven Bug Fixer는 AWS Lambda 구독을 통해 애플리케이션의 Amazon CloudWatch Logs 로그 그룹에 연결됩니다. 애플리케이션 오류가 포함된 모든 로그는 처리를 위해 전송됩니다. 여기서 Lambda 함수는 스택 추적 및 관련 코드 파일을 포함하여 프롬프트를 생성한 다음 Amazon Bedrock(Claude v1)으로 보내 코드 수정 사항을 생성합니다. 수정된 코드는 소스 제어(git)로 푸시되고 검토 및 배포를 위한 풀 요청을 생성합니다.
다음 표에는 미국 동부(버지니아 북부) 지역에서 한 달 동안 기본 매개변수를 사용하여 이 지침을 배포하는 데 대한 샘플 비용 분석이 나와 있습니다.
AWS 서비스 | 치수 | 월 비용 [USD] |
---|---|---|
아마존 다이나모DB | 메시지당 평균 항목 크기 0.5kb, 0.5 RCU 및 1 WCU | $ 17.08 |
아마존 클라우드워치 | 메시지당 33kb의 로그가 작성 및 저장됨 | $ 8.77 |
AWS 람다 | 고유한 오류 메시지당 실행 시간 45초 | $2.43 |
아마존 SQS | 메시지당 요청 3개, 메시지 크기 1,000개 | $ 0.01 |
아마존 기반암 | 입력 토큰 1,000개, 출력 토큰 1,000개 | $ 32.00 |
총 | $ 60.29 |
이 솔루션은 Mac 또는 Linux의 빌드 환경을 지원합니다.
이 배포를 위해서는 다음 AWS 서비스에 대한 액세스 권한이 필요합니다.
이러한 배포 지침은 Mac 또는 Amazon Linux 2023에서 가장 잘 작동하도록 최적화되어 있습니다. 다른 OS에 배포하려면 추가 단계가 필요할 수 있습니다.
솔루션을 구성하는 데 필요한 입력이므로 기존 애플리케이션에 대한 다음 정보를 수집하세요.
git clone https://github.com/aws-solutions-library-samples/guidance-for-self-healing-code-on-aws.git
명령을 사용하여 리포지토리를 복제합니다.
repo 폴더로 CD cd guidance-for-self-healing-code-on-aws
pip install -r requirement.txt
명령을 사용하여 요구 사항에 패키지를 설치합니다.
필요한 환경 변수를 내보냅니다.
# 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
변경이 필요한 경우 위 스크립트를 다시 실행하세요. 또는 ${PARAMETER_STORE_PREFIX} 접두사 아래에 저장된 SSM Parameter Store 값을 직접 수정할 수 있습니다.
# Create a deployment package (Lambda function source code)
cloudformation/package.sh
# Deploy the CloudFormation template
cloudformation/deploy.sh
CloudFormation 콘솔을 열고 배포 단계 4단계에서 지정한 스택 이름으로 템플릿 상태를 확인합니다.
6단계에서 구성된 애플리케이션의 Amazon CloudWatch 로그 그룹에서 Python 스택 추적을 수신하면 소스 제어 시스템에 풀 요청이 생성됩니다. 처리가 완료되는 데 몇 분 정도 걸릴 수 있습니다. 솔루션을 빠르게 검증하려면 기존 애플리케이션에 오류를 삽입하여 애플리케이션 로그에 Python 스택 추적을 기록할 수 있습니다.
Github의 출력 풀 요청 예시:
이 지침은 Python 3.9+ 코드 베이스를 대상으로 하는 샘플 프로젝트입니다. 이 시스템을 확장하고 향상할 수 있는 추가 기회가 있습니다. 일부는 다음 단계를 제안했습니다.
src/handlers/providers
의 공급자별 프롬프트를 조정하여 LLM의 응답을 구체화합니다.src/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}
고객은 본 지침의 정보를 독립적으로 평가할 책임이 있습니다. 본 지침은 (a) 정보 제공의 목적으로만 제공되며, (b) 사전 통지 없이 변경될 수 있는 AWS의 현재 제품 제공 및 관행을 나타내며, (c) AWS 및 그 계열사, 공급업체 또는 라이센스 제공자. AWS 제품 또는 서비스는 명시적이든 묵시적이든 어떠한 종류의 보증, 진술 또는 조건 없이 "있는 그대로" 제공됩니다. 고객에 대한 AWS의 책임과 의무는 AWS 계약에 의해 통제되며, 본 지침은 AWS와 고객 간의 계약의 일부가 아니며 계약을 수정하지도 않습니다.