하프스, 인턴십 그리고.. Lambda?
안녕하세요, 하프스에서 4개월 간의 인턴십을 마치고, Backend 개발자로 입사한 Mino 입니다.
하프스에서 인턴십을 진행하면서 크롤러 개발, IDE 활용, Javascript, AWS 인프라 등 정말 많은 것들을 처음 배웠습니다. 그 중에서도 가장 많이 저를 괴롭히고 싸웠던 것이 바로 AWS Lambda 였습니다..
인프라 자체에도 익숙하지 않았고, 당연히 될 줄 알았던 것들이 Lambda 의 구동 환경 특성 상 당연히 안되는 것을 보고(RDS🤬..) 하루 종일 관련 Documentation, Google, Stackoverflow를 들락거렸던 기억이 납니다.
그래서 인턴십을 마무리하면서, 가장 많이 고통받은 인상깊었던 AWS Lambda 로컬 테스트 환경 구성에 대해서 정리해보고자 합니다.
이유인즉슨..
지난 번에 Jenkins를 통해서 Lambda를 배포할 때는 디버깅에 어려움이 많았습니다.. 배포하고 테스트하고, CloudWatch 들락거리고.. 그래서 아, 꼭 로컬 디버깅 설정을 해야겠다고 느꼈는데 다른 프로젝트를 하면서 미루고 미루다 Chuck이 오늘 Lambda 로컬 디버깅하는 방법을 물어보셔서 '아, 맞다...' 하면서 다시 공부해서 부랴부랴 정리했습니다..
1. 준비
필요한게 참 많네요..
AWS Account
(지금 계정상황에서는 별다른 설정은 필요없는 것 같습니다)
2. AWS IAM User & Permission
(지금 계정상황에서는 별다른 설정은 필요없는 것 같습니다2)
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
정상적으로 설치가 됐는지도 확인해야합니다.
sam --version
5. Install Docker
도커는 로컬 환경에서 AWS Lambda를 디버깅하기 위해서 필요한 조건입니다.
6. AWS Toolkit Plugin for Webstorm 설치
Preference - Plugin - Marketpalce 에서 검색할 수 있습니다!
저는 처음에 Installed 에서 하루종일 찾았습니다…
2. 새로운 Lambda를 AWS Toolkit으로 만들기
설치가 모두 잘 됐다면, 이제 프로젝트를 하나 만들어보겠습니다.
프로젝트 만들기 메뉴에 들어가보면 처음 보는 선택 항목이 하나 있습니다.
Hello Word!
이 메뉴를 이용해서 프로젝트를 하나 생성해주면 됩니다. 프로젝트를 생성하고나면 최하단과 좌측 하단에 또 새로운 버튼들이 보입니다.
AWS Explorer 에는 현재 설정된 계정과 관련하여 Lambda, CloudFormation 등의 현황을 볼 수 있습니다.
$ aws configure AWS Access Key ID [None]: 액세스키 AWS Secret Access Key [None]: 비밀키 Default region name [None]: us-west-2 Default output format [None]: json
만약 프로필을 설정하라는 문구가 나오거나 에러가 뜬다면 aws 프로필 설정이 없을 확률이 높으므로, 터미널에서 위와 같이 aws configure 를 통해서 설정을 해줍니다.
Lambda 현황이 보이긴 하는데, 처음보는 lambda 들이 있거나 비어있다면 다른 region 으로 설정되어있을 확률이 큽니다. 아래와 같이 맞는 region으로 변경해주세요.
기본적인 설정이 끝났다면 이제 Lambda를 실행할 차례입니다.
app.js 파일을 열어보면 Lambda에서 메인 역할을 하는 handler 함수 옆에 Lambda 로고 (Psi라고 합니다) 가 그려져있고, Run 또는 Debug를 할 수 있는 우측 상단 메뉴에 [Local]:FuntionName 형식으로 버튼이 만들어진 것을 볼 수 있습니다.
원하는 코드에 Breakpoint를 걸고, 디버깅을 진행하면 정상적으로 작동하는 것을 볼 수 있습니다.
3. 기존에 만들어진 Lambda 디버깅하기
제약사항이 존재합니다. 모든 Lambda를 로컬 테스트할 수 있지는 않습니다..
AWS Toolkit을 이용해서 AWS에 올라가있는 Lambda를 원격으로 실행할 수도 있고, 로컬에서 디버깅도 할 수 있습니다. 다만 후자를 위해서는 몇 가지 파일과 설정이 필요합니다.
기본적으로 AWS Toolkit 에서는 Local 실행 환경을 만들기 위해서
배포 패키지 ( node_modules, source code 등 )
템플릿 파일 ( template.yaml )
을 요구합니다. 이 두 파일은 AWS Console - Lambda - 함수로 들어가시면 상단 부분에 내보내기 기능에서 받을 수 있습니다.
원하는 함수의 배포 패키지와 템플릿 파일을 받았다면, 템플릿 파일을 배포 패키지 안으로 넣어주고 Webstorm으로 열어줍니다. 별다른 설정 없이 템플릿 파일을 열어서 실행 환경을 만들 수 있습니다.
Webstorm이 Indexing 상태인 경우 위의 화살표 모양 아이콘이 뜨지 않습니다.
화살표 아이콘을 누르면 Create [Local] FuntionName 과 같은 선택 메뉴가 뜨고 이를 누르면, 간단한 설정 이후에 실행할 수 있습니다.
이대로 안되는 경우는 목차 4번으로 가야합니다😢
특별한 경우를 제외하고는 From template 버튼이 체크되어 있고, 경로도 다운받았던 템플릿으로 잡혀있습니다. 오른쪽에 함수 이름만 골라주고 적용해주면 됩니다.
성공적으로 Breakpoint에 걸립니다!
4. 특별한 경우?
3번 마지막 파트에서 (핸들러 찾기) 가끔 이런 경우가 있습니다.
Error: Cannot find handler ‘xxx.handler’ in project.
슬프게도 AWS Toolkit for Webstorm은 aws에서 Kotlin으로 제작이 됐는데, 내부적으로 배포 패키지 내 소스코드의 핸들러를 찾는 LambdaHandlerResolver가 존재합니다. 여기서 핸들러의 형식을 상당히 제한적으로 명시하고 있는데 주요한 것만 살펴보겠습니다.
LambdaHandlerResolver
aws/aws-toolkit-jetbrains You can't perform that action at this time. You signed in with another tab or window. You signed out in another tab or…github.com
handler는 다음 포맷으로 export 되어야만 한다.
lambdaHandler 부분은 어떤 이름이 와도 상관없습니다.
exports.lambdaHandler = functionExpression
2. = 연산자 우측에 오는 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
5. 마무리
이제는…
Lambda 하나 만들어야 될 것 같은데요..?
라는 얘기가 나오면 개발환경 구성하는 것에 있어서는 좀 더 수월하게 진행할 수 있을 것 같네요.
확실히 처음에 Lambda를 접했을 때 보다는 시야가 한결 명확해진 느낌이 듭니다. AWS Lambda 자체를 인턴십을 진행하면서 처음 다뤄봤는데, 참 많이 Lambda와 싸운 것 같네요. AWS에서 기본적으로 Docs도 제공하지만, 일정 수준 파고들면 관련 정보를 찾기가 정말 어려웠습니다..😢
그래서인지.. 큰 오픈소스를 뒤적거리면서 직접 문제가되는 코드를 찾는 방식으로 트러블 슈팅을 해본 적이 처음이라 참 뿌듯하기도 하고 재밌었습니다.
단순한 AWS Lambda 사용법에서 시작해서 Babel과 Webpack의 필요성, Lambda를 자동 배포하는 방법, Lambda 로컬 테스트 환경을 구성하는 방법 등 정말 많은 내용들을 가지에서 뻗어나가면서 배웠기에 스스로 성장한다는 느낌을 많이 받고 있습니다.
감사합니다.🙇♂️
가입하기
