AWS Lambda의 배포 및 개발 환경 구축 With AWS SAM CLI

 

시작하면서

---

Lambda...

회사에서 사이드 프로젝트로 AWS Lambda를 사용하게 됐는데, 전혀 사용해본 경험이 없어서 상당히 애를 먹었다. 인프라 자체에도 익숙하지 않았고, Lambda의 구동 환경 특성 상 당연히 될 줄 알았던 것들이 당연히 안되는 것을 보고(RDS🤬..) 하루 종일 관련 구글을 들락거렸던 기억이 난다.

그래서 가장 고통받은 인상깊었던 AWS Lambda 로컬 개발환경에 대해서 정리해보고자 한다.

이유인즉슨..

지난 번에 똑같이 Lambda를 구성할 일이 있어서 Jenkins를 통해서 배포했는데, 디버깅에 많이 애를 먹었다. 배포하고 테스트하고, CloudWatch 들락거리고.. 그래서 아, 꼭 로컬 디버깅 설정을 해야겠다고 느꼈는데, 다른 프로젝트를 하면서 미루고 미루다가, 다시 공부해서 부랴부랴 정리하게 됐다.

Webpack 등으로 번들링된 파일이나 serverless-http 라이브러리를 통해 원래 AWS Lambda handler의 export 형식이 달라지는 경우 Webstorm에서 핸들러를 못찾는 문제가 있습니다. 이 부분은 방법을 찾는대로 수정할 계획입니다.

 

1. 준비

필요한게 참 많네..

---

1. AWS Account

2. AWS IAM User & Permission

3. Install Homebrew

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

4.Install AWS SAM CLI

brew tap aws/tap
brew install aws-sam-cli

Taps (Third-Party Repositories)

정상적으로 설치가 됐는지도 확인해야한다.

sam --version

5. Install Docker

도커는 로컬 환경에서 AWS Lambda를 디버깅하기 위해서 필요한 조건!

6. AWS Toolkit Plugin for Webstorm 설치

Preference - Plugin - Marketpalce 에서 검색할 수 있다!

Installed에서 찾으면 안된다..

 

2. 새로운 Lambda를 AWS Toolkit으로 만들기

---

설치가 모두 잘 됐다면, 이제 프로젝트를 하나 만들어보자.

프로젝트 만들기 메뉴에 들어가보면 처음 보는 선택 항목이 하나 있다.

Hello World!

이 메뉴를 이용해서 프로젝트를 하나 생성해주면 된다. 프로젝트를 생성하고나면 최하단과 좌측 하단에 또 새로운 버튼들이 보인다.

AWS Explorer 에는 현재 설정된 계정과 관련하여 Lambda, CloudFormation 등의 현황을 볼 수 있다.

$ aws configure
AWS Access Key ID [None]: 액세스키
AWS Secret Access Key [None]: 비밀키
Default region name [None]: 지역
Default output format [None]: json

만약 프로필을 설정하라는 문구가 나오거나 에러가 뜬다면 aws 프로필 설정이 없을 확률이 높으므로, 터미널에서 위와 같이 aws configure 를 통해서 설정을 해줘야 한다.

스울

Lambda 현황이 보이긴 하는데, 처음보는 lambda 들이 있거나 비어있다면 다른 region 으로 설정되어있을 확률이 크다. 아래와 같이 맞는 region으로 변경해야 한다.

기본적인 설정이 끝났다면 이제 Lambda를 실행해보자.

app.js 파일을 열어보면 Lambda에서 메인 역할을 하는 handler 함수 옆에 Lambda 로고 (Psi라고 한다) 가 그려져있고, Run 또는 Debug를 할 수 있는 우측 상단 메뉴에 [Local]:FuntionName 형식으로 버튼이 만들어진 것을 볼 수 있다.

gif가 그렇게 비효율적이라던데.. 

원하는 코드에 Breakpoint를 걸고, 디버깅을 진행하면 정상적으로 작동하는 것을 볼 수 있다.

 

3. 기존에 만들어진 Lambda 디버깅하기

제약사항이 있다. 모든 Lambda를 로컬 테스트할 수 있지는 않다..

---

AWS Toolkit을 이용해서 AWS에 올라가있는 Lambda를 원격으로 실행할 수도 있고, 로컬에서 디버깅도 할 수 있다. 다만 후자를 위해서는 몇 가지 파일과 설정이 필요하다.

기본적으로 AWS Toolkit 에서는 Local 실행 환경을 만들기 위해서

1. 배포 패키지 ( node_modules, source code 등 )
2. 템플릿 파일 ( template.yaml )

을 요구하는데, 이 두 파일은 AWS Console - Lambda - 함수로 들어가시면 상단 부분에 내보내기 기능에서 받을 수 있다.

함수 내보내기

원하는 함수의 배포 패키지와 템플릿 파일을 받았다면, 템플릿 파일을 배포 패키지 안으로 넣어주고 Webstorm으로 열어주자. 별다른 설정 없이 템플릿 파일을 열어서 실행 환경을 만들 수 있다.

Webstorm이 Indexing 중인 경우 위의 화살표 모양 아이콘이 뜨지 않는다.

화살표 아이콘을 누르면 Create [Local] FuntionName 과 같은 선택 메뉴가 뜨고 이를 누르면, 간단한 설정 이후에 실행할 수 있다.

여기서 많이 고통받았었다.,

특별한 경우를 제외하고는 From template 버튼이 체크되어 있고, 경로도 다운받았던 템플릿으로 잡혀있다. 오른쪽에 함수 이름만 골라주고 적용해주면 된다.

gif

성공적으로 Breakpoint에 걸린다!

 

4. 특별한 경우?

---

3번 마지막 파트에서 (핸들러 찾기) 가끔 이런 경우가 있다.

Error: Cannot find handler 'xxx.handler' in project.

슬프게도 AWS Toolkit for Webstorm은 aws에서 Kotlin으로 제작이 됐는데, 내부적으로 배포 패키지 내 소스코드의 핸들러를 찾는 LambdaHandlerResolver가 존재한다. 여기서 핸들러의 형식을 상당히 제한적으로 명시하고 있는데 주요한 것만 살펴 보자.

LambdaHandlerResolver

aws/aws-toolkit-jetbrains

 

handler는 다음 포맷으로 export 되어야만 한다. - lambdaHandler 부분은 어떤 이름이 와도 상관없다.

exports.lambdaHandler = functionExpression

 

= 연산자 우측에 오는 functionExpression이 async 일 경우 파라미터는 2개 이하, async가 아닐 경우는 3개 이하이다.

(isAsyncFunction && parameterSize <= 2) || (!isAsyncFunction && parameterSize <= 3)

그래서, exports.handler 형식은 당연히 지켜주어야 하고, 인자의 수까지 맞춰야한다.

예를 들어서 async function을 인자 3개로 export 하려고 하면 위와 같이 Psi(Lambda Logo)마크가 없어진다.

그러나 2개 이하로 맞춰주면 Psi 마크가 생성된다.

꼼수...😗

그렇다고 async function은 callback을 전혀 못쓰는 것은 아니고... Javascript의 Spread Expression을 사용하면 제대로 핸들러를 찾을 수 있다. 이 상태로 , ...requests 를 request 변수에 담아서 Lambda를 Debug해보면 Array에 원래 event, context, callback이 차례대로 들어오는 것을 확인할 수 있다.

원래 event, context, callback으로 들어있어야할 아이들

최근에는 Javascript 공부를 하고있다. 서버 개발 쪽으로 공부하고 있고.. 원래 워낙에 실력이 모자라서 포스팅할 시간이 잘 없다.. 다음에는 크롤러와 관련된 포스팅으로 돌아와야지..

 

5. 아, 혹시...

---

Nextunicorn에서는 Medium 팀블로그를 운영하고 있습니다.

NextUnicorn – Medium

해당 포스팅도 업로드 되어있고, 개발 뿐아니라 다양한 소스들로 구성할 예정입니다.

관심있으신 분은 참고하시면 좋을 것 같습니다