AWS의 serverless application을 local에서 테스트하는 방법

AWS SAM(Serverless Application Model) 마스코트

AWS serverless 모델 중 하나이자 대표격인 Lambda를 사용하다가 불만이 생겼다. "단위테스트를 좀 더 편하게 할만한 방법이 없을까?", "꼭 AWS에 올려놓고 테스트해야 하나?" 등이었다. 물론 AWS에 올려서 테스트해도 된다. 하지만 로컬의 IDE에서 debugging하는 것 만큼 편하지 않다.

AWS의 샘플코드인 아래 코드를 복붙하여, 보통 메인함수 실행시키듯 로컬에서 실행시키면 다음과 같은 에러가 발생한다.

package main

import (
    "context"
    "fmt"
    "github.com/aws/aws-lambda-go/lambda"
)

type MyEvent struct {
    Name string `json:"name"`
}

func HandleRequest(_ context.Context, name MyEvent) (string, error) {
    return fmt.Sprintf("Hello %s!", name.Name), nil
}
func main() {
    lambda.Start(HandleRequest)
}

# Error 내용
2023/05/17 11:23:00 expected AWS Lambda environment variables [_LAMBDA_SERVER_PORT AWS_LAMBDA_RUNTIME_API] are not defined
Exiting.

선택지

2023-05-17 기준(갱신 내용은 원문 참조)

IDE(VSCode, Jetbrains 제품) + AWS Toolkit 플러그인
AWS Cloud9

 | 장점 | 단점
IDE | - 익숙한 도구를 사용할 수 있음 - 보통 인터넷 연결과 무관하게 개발 가능 - 빠른 반응속도 | - 높은 H/W, S/W 의존성(컴퓨터 바꾸면, 개발환경 셋팅 다시 해야 함. OS가 바뀌는 경우 최악)
Cloud9 | - AWS 도구들과 높은 통합성 - 하드웨어와 무관하게 개발 가능 | - 네트워크에 높은 의존성(네트워킹 규칙/상황에 따라, 개발 환경에 접속이 불가하거나 끊길 수 있음) - EC2 등 원격 서버 이용 비용 발생

참고로 Cloud9은 AWS가 만든 브라우저 환경에서 동작하는 IDE다. AWS가 직접 만들었으니, 장기적으로 봤을 때 통합성, 사용성 측면에서 Cloud9이 좋은 선택지일 수 있다. 하지만 나의 경험은 아직까진 browser 환경에서의 IDE가 local application IDE보다 나은 경우를 겪지 못했기에, 조금 보수적으로 접근했다.

+ EC2와 코드를 저장할 H/W비용까지 고려하여 딱히 쓸 이유를 못 느꼈던 것도 사실이다. 나는 이미 Jetbrains 제품을 구독 중이기에... 만약 IDE를 구독하지 않았다 거나, github 등이 아닌 private 리포지토리를 자주 이용하는 경우, 괜찮은 선택지였을 것 같다.

AWS Toolkit 이용하기

AWS Toolkit 설치

원하는 IDE에서 AWS Toolkit을 설치한다. 이 문서에 어떤 IDE를 지원하고 있는지 나와있다.

설치가 끝났다면, Run/Debug Configurations에서 +버튼을 눌러, AWS Lambda가 추가되었는지 확인해본다.

꼭대기의 샘플 코드를 기준으로 Local configuration을 생성

AWS Lambda로 실행하기

AWS Toolkit이 설치 완료되었다면, 메인함수 옆에 AWS Lambda 아이콘이 활성화된다.

초록색 화살표를 클릭 > Debug > [Local] main을 눌러서 실행해본다.

Local AWS API gateway resource 연동

이 문서를 참조 계층화된 어플리케이션을 로컬에서 디버깅하려면 학습해야할 게 참 많다.

Troubleshooting - Credentials 에러

Error: Select AWS credentials in 'AWS Connection'와 같은 에러가 나는 경우, configuration settings > AWS Connection > credentials를 확인한다.

이렇게 선택가능한 옵션들이 제공될텐데, 만약 없다면, aws CLI에 configuration이 없는 거다.

aws configure명령어를 터미널에서 입력하여, AWS key와 AWS secret을 입력해주고, Configuration settings를 다시 켜면, 옵션이 뜰 것이다.

Troubleshooting - Could not find public.ecr.aws/lambda/go 에러

Error: Could not find public.ecr.aws/lambda/go:1-rapid-x86_64 image locally and failed to pull it from docker.

위와같은 에러를 만났다면, SAM CLI탭에서 Build function inside a container 옵션을 체크해준다. 보통 이미지가 없으면, 알아서 이미지를 pull하여 사용하는데, 최초엔 registry 등의 문제로 잘 동작하지 않는 듯하다.

이후, Run 버튼으로 빌드하게 되면 도커이미지가 로컬에 추가된다.

이후에는 Build function inside a container 옵션을 꺼도, 잘 동작한다.

그래서 AWS Lambda로 Debugging 방법은?

AWS lambda는 애초에 docker에 의존적이므로, local이라 하더라도 breakpoint를 활용하기 쉽지 않았다. 이 부분은 나중에 기회가 되면, 해결하고 새 글로 작성 예정이다.

← prev

Go 단위 테스트 방법

좋은 개발자란?