Canary 배포 - Rollbacks

카나리아의 상태를 모니터링하면 CodeDeploy에서 롤백이 필요한지 여부를 결정할 수 있습니다. 지정된 CloudWatch 경보 중 하나라도 ALARM 상태가 되면 CodeDeploy는 배포를 자동으로 롤백합니다.

 

오류를 넣어봅니다.

배포 중에 CanaryErrorsAlarm이 트리거되도록 의도적으로 Lambda 함수를 중단할 수 있습니다. 

sam-app/hello-world/app.js의 람다 코드를 업데이트하여 다음과 같이 모든 호출에서 오류를 발생시킵니다.

 

let response;

exports.lambdaHandler = async (event, context) => {
    throw new Error("This will cause a deployment rollback");
    // try {
    //     response = {
    //         'statusCode': 200,
    //         'body': JSON.stringify({
    //             message: 'hello my friend with canaries',
    //         })
    //     }
    // } catch (err) {
    //     console.log(err);
    //     return err;
    // }

    // return response
};

unit test를 업데이트해야 합니다. 그렇지 않으면 빌드가 실패합니다. 

sam-app/hello-world/tests/unit/test-handler.js 파일의 모든 줄을 주석 처리합니다.

git push

INVOKE THE CANARY

 

배포가 실행되는 동안 새 Lambda 함수에 대한 트래픽을 생성하여 실패하게 하고 CloudWatch 경보를 트리거해야 합니다. 실제 프로덕션 환경에서 사용자는 카나리아 함수에 대한 유기적 트래픽을 생성할 가능성이 높으므로 이 작업을 수행할 필요가 없습니다.

터미널에서 다음 명령을 실행하여 Lambda 함수를 호출합니다.

이 상태가 될때 함수를 요청해야합니다!

 

aws lambda invoke --function-name \
$(aws lambda list-functions | jq -r -c '.Functions[] | select( .FunctionName | contains("sam-app-HelloWorldFunction")).FunctionName'):live \
--payload '{}' \
response.json

"FunctionError": "Unhandled"

위 문구가 떠야 breaking 되어 rollback이 됩니다.

 

새 파일 response.json이 생성됩니다. 여기에는 람다 호출의 응답이 포함됩니다. 열면 이전 Lambda 버전의 응답을 볼 수도 있고 오류를 일으키는 새 버전을 볼 수도 있습니다.

경고!:  배포하는 동안 트래픽의 10%만 새 버전으로 라우팅됩니다. 따라서 계속해서 람다를 여러 번 호출하십시오. 10번의 호출 중 1번은 롤백을 일으키려는 새로운 깨진 람다를 트리거해야 합니다.

다음은 루프에서 함수를 15번 호출하는 명령입니다. 터미널에서 자유롭게 실행하십시오.

 

counter=1
while [ $counter -le 15 ]
do
    aws lambda invoke --function-name \
    $(aws lambda list-functions | jq -r -c '.Functions[] | select( .FunctionName | contains("sam-app-HelloWorldFunction")).FunctionName'):live \
    --payload '{}' \
    response.json
    sleep 1
    ((counter++))
done

 

"FunctionError": "Unhandled"

 

그러면 rollback 된것을 볼 수 있습니다.