[AWS 학습] Lambda 사용 점검 - 현 상황 분석과 솔루션

시스템 디자인 + 클라우드/AWS 탐구

[AWS 학습] Lambda 사용 점검 - 현 상황 분석과 솔루션

공대키메라 2026. 3. 25. 23:22

회사에서 현재 람다를 쓰고 있는데 소비자에게 서비스를 하는 상황이 아닌데도

이상하게 자꾸 timeout이 나는 상황이었다.

그래서 왜 자꾸 별로 하지도 않는 작업인데 timeout이 나는지 찾아보았다.

목표

1. timeout이 나는 경우에 대해 조사한다.

2. 나의 상황에 대입해 솔루션을 생각해본다.

3. 개선점에 대해 고려한다.

0. 람다에 대해서

AWS Lambda는 서버 관리가 필요 없이 코드를 실행할 수 있는 컴퓨팅 서비스입니다.
코드는 자동으로 확장 및 축소되며, 사용량에 따라 요금이 부과됩니다.

AWS Lambda is a compute service that runs code without the need to manage servers.
Your code runs, scaling up and down automatically, with pay-per-use pricing

- What is AWS Lambda? 중 발췌

그렇다. 불과 몇년전에 그렇게 유명했던 서버리스 서비스로 사용자가 서버를 관리할 필요가 없다.

해당 내용은 검색해보면 정말 금방 금방 나온다.

AWS에서 제공하는 서버리스 덕분에 개발자는 비즈니스로직에만 집중할 수 있으며

해당 서비스는 고가용성 (High Availability)이기에 확장에 크게 걱정하지 않아도 된다.

심지어 무료 제공량도 넉넉하고 사용량과 컴퓨팅 시간의 곱에 비례하여 요금을 부과하니 토이프로젝트를 하기에는 정말 안성맞춤이라고 생각한다.

Lambda서비스를 제공할 때 수많은 Lambda Trigger를 설정할 수 있다.

말 그대로 Inbound 시에 어떤 요청으로 해당 Lambda로 접근할 수 있는지 설정하는 것이다.

1. 나의 상황 설명

키메라는 회사에서 판매하는 제품을 직접 테스트하기 위해 구매를 했다.

사실 배포는 되어있고 실제로 동작은 하게 만들었지만 회사의 테스트 인원을 제외하고는 실제로 사용할 일이 없다.

현재 서비스는 사실 많은 람다를 사용중이다.

순서대로 설명을 하자면

1. 사용자에게 보여지는 구매화면 제공용 람다

2. 결제 확인용 람다

3. 결제 프로세스 후 데이터 처리 람다.

4. 결제 후처리 람다 작업 후 구매화면에서 완료가 된 후 SMS전송 람다를 요청해 결과를 전송한다.

5. 모든 프로세스가 완료되면 구매화면 제공용 람다로 다시 들어와, 완료된 정보를 보여준다.

이렇게 세어보니 4개의 람다가 있다.

그런데 1 -> 2 -> 3 -> 4 -> 5 까지 프로세스가 진행된 후 5 -> 1로 다시 돌아오는 길에 Timeout이 나 버렸다.

각각의 Lambda의 용량은 128MB이고 최대 프로비저닝 갯수는 20개로 설정했다.

람다가 벌써 4개이다. 긜고 필수적으로 보내져야하지만 약간의 시간차를 두고 일어나도 되는 서비스도 있다.

우선 SMS전송은 약간의 시간차를 두고 보내져도 되니 이벤트요청으로 코드를 작성해도 좋을듯 하다.

우선 Cloudwatch에 들어가서 로그를 봤는데, 중도에 Timeout이라는 것을 보았다.

...

END RequestId: 6daf2c76-c2c6-41ba-afe3-3349055ee16b
REPORT RequestId: 6daf2c76-c2c6-41ba-afe3-3349055ee16b
Duration: 7000.00 ms
Billed Duration: 7000 ms
Memory Size: 128 MB
Max Memory Used: 91 MB
Status: timeout

...

왜 timeout인가?

2. 문제점 고민

필자는 7초를 맥시멈 Lambda 작동시간으로 설정했는데, 7초가 넘어도 람다가 끝나지 않아서 Timeout에러가 발생한 것이다.

우선 메모리 사이즈가 128MB인데 최대 메모리 사용량이 91MB인게 이상했다.

또한, 람다의 Cold Start가 문제가 되는지가 의심되었다.

1. 메모리를 늘리면 비용이 더 나오는지, 이것이 그렇게 치명적인지 궁금했고

2. Cold Start를 해결하게 되면 비용에 문제가 없는지도 궁금했다.

3. 또 이렇게 람다 제공 서비스가 많아지는것이 올바른지 궁금했다.

3.솔루션 고민

3.1) 메모리 사이즈는 적절한가?

컴퓨터의 상식중이 상식으로 물론 미래에는 달라질 수 있겠지만...

메모리의 종류로는 RAM(랜덤 액세스 메모리)과 ROM(읽기 전용 메모리)가 있으며

CPU가 이 메모리들의 정보를 읽으며 연산에 사용한다.

그런데 람다 설정시에 CPU를 설정한 기억은 없다.

기본적으로 람다에서는 메모리 할당이 직접적으로 CPU 파워를 결정한다고 한다.

AWS Lamba는 메모리와 CPU사이에 선형 관계를 사용한다.

즉, 메모리가 커지면 CPU성능도 좋아지도록 서비스를 제공한다는 말이다.

서버리스의 특징은 가상의 서버에서 우리의 코드를 실행시킨다는 점이다.

그래서 글을 보니 그냥 CPU라고 하지 않고 vCPU (Virtual Central Processing Unit) 이라고 한다.

이 vCPU의 성능이 메모리에 따라 증가하며, 니는 공식문서에 이렇게 나와 있다.

번역
메모리 설정을 사용하여 함수에 할당된 메모리와 CPU 성능을 늘리거나 줄일 수 있습니다.

메모리는 1MB 단위로 128MB에서 10,240MB까지 설정할 수 있습니다. 1,769MB를 할당하면 함수는 vCPU 1개(초당 1vCPU-초 크레딧)에 해당하는 성능을 갖게 됩니다.

원문
You can increase or decrease the memory and CPU power allocated to your function using the Memory
setting.

You can configure memory between 128 MB and 10,240 MB in 1-MB increments. At 1,769 MB, a function has the equivalent of one vCPU (one vCPU-second of credits per second).

여기서 " one vCPU-second of credits per second" 이라는데, 이게 사실 이해가 안돼서 Gemini에게 물어봣는데 다음과 같이 알려줫다.

저 문장을 그대로 직역하면 **"1초마다(per second), 1개의 vCPU를 1초 동안 100% 가동할 수 있는 크레딧(one vCPU-second of credits)을 지급한다"**는 뜻입니다.

이 개념은 AWS EC2의 **T 시리즈(t2, t3, t4g 등) 같은 '버스터블(Burstable) 성능 인스턴스'**의 작동 원리를 설명하는 가장 핵심적인 문장입니다.
AWS SAA 자격증 시험을 비롯해 클라우드 아키텍처 설계 시 단골로 등장하는 아주 중요한 개념이기도 합니다.

현재 128MB를 메모리로 설정했는데 하나의 CPU 도 사용하지 못하고 있는 상황인 것이다.

사실 생각해보니 lambda서비스지만 이 lambda서비스를 html을 다 읽어서 tag에 맞춰서 변환 혹은 데이터 replace 작업을 해주기에 생각보다 작업이 오래 걸릴 수 있겠다는 생각이 든다.

vCPU의 성능을 올리기 위해서 그러면 메모리를 늘렸다고 치자.

그러면 요금은 문제가 없을까? 하는 고민이 든다.

3.2) 용량을 늘리면 비용이 많이 증가할까?

요금에 관한 정보는 다음 주소에서 확인이 가능하다. (람다 pricing 관련 공식문서 주소)

해당 주소에서 서울 리전 기준으로 요금을 보았다.

GB-초당 이라는 번역이 맘에 안들어서 다시 영어로 봤다.

CPU의 경우 동일하게 요청(Request)의 경우 100만번 호출당 $ 0.2의 가격이다. 즉, 1회 호출당 $ 0.0000002 비용이 청구된다.

실행 시간(Duration)의 경우 x86의 경우 GB*시간당 요금과 Arm 의 요금이 다르니 참고하도록 하자.

전체적으로 Arm 의 실행시간 가격이 다 적은데, 이건 또 왜그런가? 해서 보니 이마저 여윽시! 공식문서에서 찾아볼 수 있었다.

(AWS Developer Guide - foundation-arch)

(AWS 블로그 - AWS Graviton2 프로세서 지원 출시 내용)

이유는 Arm의 경우 Graviton2 CPU를 사용하는데 메모리 읽기 시간을 단축시켜서 성능이 20%정도 좋다고 한다.

(~~x86쓰지 말고 Arm 으로 쓰라는 무언의 압박~~)

그렇다면... 용량을 늘리면 사실 비용이 증가할 수 있다.

그런데 용량이 늘어나면서 vCPU성능이 좋아져서 실행 시간이 줄어들어서 용량이 늘어나도 작동시간이 짧아서 크게 차이가 없을 수 있다. (Find the Sweet Spot for Cost & Performance)

다만 용량을 늘려서 vCPU의 성능을 높이는 경우 I/O-bound 작업, 매우 짧은 실행, 외부 api 지연시간에 족송적인 상황에서는 추천하지 않는다.

3.3) Cold Start에서 Snap Start(Warm Start)로 변경하면?

Cold Start란?

시스템, 서비스, 기계가 초기화되지 않았거나 데이터가 부족한 상태에서 시작되어 초기 성능 저하, 긴 응답 시간, 혹은 맞춤형 기능 제공에 어려움을 겪는 현상

Warm Start란?

시스템, 애플리케이션 또는 서버리스 환경에서 이미 초기화된 리소스를 재사용하여 시스템을 다시 시작하거나 작업을 처리하는 방식

Warm Start를 지원하기 위해 AWS Lambda에서 SnapStart라는 기능을 제공한다.

이를 사용하면 지연 시간을 몇초에서 1초 미만으로 줄일 수 있다고 한다. (최적의 시나리오에서)

여기서 재미있는 점은 SnapStart를 사용해도 비용이 들지 않는다고 한다.

For Java managed runtimes, there's no additional cost for SnapStart. You're charged based on the number of requests for your functions, the time that it takes your code to run, and the memory configured for your function.

출처 : https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html#snapstart-use-cases

그런데 SnapStart말고 Provisioned Concurrency(프로비저닝된 동시성)을 통해서도 콜드스타트를 없앨 수 있다고 하는데,

이는 항상 원하는 갯수만큼 컨테이너를 띄우는 것인데... 이러면 비용 최대 절감할 수 있는 람다를 안쓰지 않나 하는 생각이 든다.

고로, SnapStart를 써도 쓸데없는 지연 시간을 늦출 수 있다는 생각이다.