20241227 TIL: aws lambda 실행 오류 해결하기 [진행중]

4일 만에 이슈를 다시 잡았다. 여전히 배포를 목표로 했던 도메인 주소를 입력하니 사이트에 연결할 수 없다는 메시지가 뜬다. 그래서 이번에는 api gateway에서 lambda 함수로 잘 연결을 하고 있나 싶어서 api gateway의 퍼블릭 엔드포인트를 입력했더니 request timed out 메시지가 떴다.

 

그렇다는 것은 api gateway가 lambda에 제대로 연결하지 못했거나, lambda 자체에 문제가 있어서 실행이 종료되었을 수 있다는 거였다. 구체적인 lambda 로그를 봐 보았다. 'zappa tail dev' 명령어를 입력했더니 'calling tail for stage dev...' 라는 로그만 출력하고는 아무 반응이 없다. 그러다가 이런 반복적인 패턴의 로그를 출력하더라. 

[1735266140183] Instancing..
[1735266155772] Instancing..
[1735266170217] 2024-12-27T02:22:50.217Z e11db634-ef8a-4258-9d46-0b5e878cd834 Task timed out after 30.03 seconds
[1735266170235] INIT_START Runtime Version: python:3.12.v38 Runtime Version ARN: arn:aws:lambda:ap-northeast-2::runtime:7515e00d6763496e7a147ffa395ef5b0f0c1ffd6064130abb5ecde5a6d630e86

 

대강 이런 형식의 로그가 반복되는 것으로 봐서, 초기화를 시도했다가 task가 모종의 이유로 timed out 되었다는 것까지만 추측했다. 그리고 예전에 warm callback으로 설정했던 것처럼 2분마다 해당 로그가 반복되고 있었다. 

 

그렇다면 왜 timed out이 되었을까? 30초 이후에 task가 timed out이 되었다고 나와 있다. 일단 내가 이해한대로 질의를 해 보자. 

현재 zappa를 사용해서 python(django)코드를 aws lambda에 배포한 상태야. 그리고 api gateway의 퍼블릭 엔드포인트를 통해 url로 람다 함수를 호출할 수 있도록 설정해 놓았어. 그런데 두 가지 [문제]가 있어. 이 문제에 대한 [추측]을 보고 [추측]이 합당한지 말해주고, 합당하지 않다면 다른 가능성은 무엇이 있을지 말해줘

[문제]
1. api gateway의 퍼블릭 엔드포인트로 접속하면 request timed out 오류가 발생한다. 
2. 'zappa tail dev'를 통해 배포 로그를 보면 다음과 같은 패턴이 반복된다. 
2-1. 'Instancing.... '이라는 초기화 로그가 찍힌다. 
2-2. 'Task timed out after 30 seconds' 라는 문구가 찍힌다. 

[추측]
1. api gateway에서 request timed out 오류가 나는 이유는 문제 2번의 task timed out 오류 때문이다. 
2. 문제 2번에서 task timed out 오류가 나는 이유는 lambda 함수가 실행되는 데 30초가 넘게 걸려서일 수 있다. 

문제는 aws lambda를 처음 api gateway를 통해 퍼블릭 엔드포인트로 접속할 수 있도록 설정했을 때는 접속이 잘 되었다는 거야. 시간이 지났을 때 접속이 불가능해지는 것도 가능할까? [추측]이 그럴듯한지 말해주고 그럴 가능성이 없다면 다른 대안을 제시해줘

[추측]
매번 lambda 함수를 호출할 때마다 로그나 메모리가 쌓이고, 이것이 기존 설정해 놓은 메모리 값을 초과하여 lambda 함수가 제대로 응답하지 못할 수 있다. 

 

GPT가 제시한 오류 가능성들은 다음과 같았다. 

1. lambda의 cold start로 인해 실행시간이 길어지고, 이로 인해 api gateway나 lambda의 timeout 시간을 넘어서는 경우
2. lambda 함수가 사용하는 메모리가 zappa로 설정해 준 메모리 값을 초과하는 경우
3. cloudwatch 로그가 과도하게 쌓이는 경우 (그런데 왜 이게 lambda 실행에 영향을 주는지는 정확히 이해하진 못했다)
4. VPC의 네트워크 대역폭 제한으로 인해 접근이 불가능해서 발생하는 오류

비록 GPT가 제시해 주었으나 각 항목별로 개인적으로는 이해가 잘 되지 않는 부분들이 있었다. 

1. cold start의 경우, 이미 2분 간격으로 ping을 쏘고 있는데 cold start가 일어난다는 것이 아이러니했다. 
2. 메모리 값을 초과하는 경우, 애초에 처음부터 아예 접속이 안 되었어야 한다. lambda는 stateless해서 이전 요청의 메모리를 저장하지 않는다고 했는데, 그렇다면 초기에는 잘 동작하다가 이후부터 동작이 안 되는 것을 설명하기 애매하다. 
3. cloudwatch의 로그가 lambda의 직접적인 실행에 영향을 미치는지 잘 모르겠다. 
4. VPC의 네트워크 대역폭 제한으로 접근이 불가능하려면 처음부터 접근이 불가능했어야 했다. 

우선은 이 원인들 중 2번의 메모리와 3번의 cloudwatch 로그의 경우 추가적인 처리를 해줄 수 있는 원인들이었으므로 처리를 해 주기로 했다. 

 

2번의 경우 'zappa update dev' 명령어를 통해 설정을 바꾸면 되려나 싶었다가도, 이게 단순 코드 변경 사항만 반영되는 것인지가 헷갈렸다. 즉 lambda 함수에 할당된 메모리 값을 바꾸려면 zappa_settings.json 파일을 직접 수정해야 하는데 이 수정사항이 deploy가 아닌 update 명령어로도 반영될지를 모르겠었다. 

 

zappa 공식문서를 읽어보니 update 명령어와 별개로 redeploy 명령어도 있었다. redeploy 명령어를 실행하면 왠지 모르게 .json 설정 파일의 설정들도 반영이 될 것 같았다. 그렇다면 update와 redeploy의 차이점은 뭘까?

 

기본적으로 zappa update는 기존의 실행 중인 lambda 함수/리소스에 변경된 사항만 덮어쓰는 명령어인 반면, redeploy 명령어는 아예 기존에 실행 중인 리소스를 종료하고(내리고) 새 컨테이너나 리소스를 다시 만들어서 올리는 작업을 수행한다고 한다. 그래봤자 결과는 똑같은 거 아닌가? 라는 의문이 들었다. 결론적으로 결과값이 아예 똑같은 건 아니었고, 무언가를 변경할 때 update로만 가능한 경우가 있고 redeploy 명령어를 써야 하는 경우도 있었다. 

 

대표적인 경우가 코드나 라이브러리만 설치할 때와 api gateway, iam 설정 등을 모두 변경하는 경우의 차이였다. 전자는 lambda 외부의 리소스를 변경하는 것이 아니라서 update 명령어로 가능하지만, 후자는 lambda 외부의 리소스(api gateway, iam)를 변경하는 것이라서 update 명령어로 반영이 안 되고 redeploy 명령어를 써야 한다고 이해했다. 

 

메모리 크기를 변경하는 경우는 lambda 외부의 리소스를 변경하는 것이 아니라서 update 명령어로도 반영이 가능하다고 했다. 그런데 우선은 지금 lambda 함수에 얼만큼의 최대 메모리가 할당되어 있고, 해당 함수는 지금 어느 정도의 메모리를 쓰고 있는지를 알아봐야 할 것 같았다. 이건 cloudwatch의 로그로 확인할 수 있다고 한다. 

 

로그를 확인해보니 의외로 1번 원인인 cold start에 주목하게 되었다. 왜냐하면 21초 정도에 'Instancing' 이라는 컨테이너 초기화 로그가 뜨고, 30초간 아무 로그가 없다가 task가 timed out 되면서 request timed out 요청이 떨어진 것으로 보였기 때문이다. 그리고 이 로그는 약 2분 간격으로 반복되고 있었다. 즉 warm callback 함수는 잘 적용되었는데 그럼에도 불구하고 cold start 패턴이 보였다. 이게 가능한가? 그런데 그렇다면 왜 배포 당일에는 이런 문제가 없었을까?

 

우선은 2가지 문제가 있어 보였다. 

1. cold start가 발생하는 문제
2. cold start가 발생할 때 초기화 시간이 api gateway, lambda의 timeout 시간인 30초보다 길게 걸린다는 문제

1번도 문제이지만 2번도 제법 문제라고 생각했다. 단순히 api gateway, lambda의 timeout을 늘리고 cold start를 방지한다고 해도, 몇 초가 걸리는 것이면 모르겠는데 30초 이상이면 분명 문제가 있다고 생각했다. 문제는 나는 뭐 때문에 이렇게 길게 걸리는지를 알고 싶은 것인데, 로그에는 그 정보가 다 안 담겨 있다는 거였다. 더 자세한, 아예 실행 환경에서의 로그를 볼 수 있는 방법은 없을까?