티스토리 뷰
현재 서비스하는 서버에는 DB에 직접 접근하지 않거나 이벤트 성으로 관리할 것들은 람다로 관리한다.
그러다보니 람다가 계속해서 늘어나는데, 각각의 람다들을 매번 콘솔에서 람다를 관리하기는 꽤나 번거롭다.
이럴 때 여러 serverless 서비스(AWS Lambda의 Event나 function)을 관리하기 위한 도구가 있다.
Serverless framework인데, BE 개발만 하던 나에겐 좀 생소해서 가볍게 사용해보면서 사용법을 익혀보려고 한다.
Installation
패키지 매니저로 yarn을 사용할 것이다. npm 설치, yarn 설치
sudo apt install npm
sudo npm install --global yarn
serverless 설치
npm install -g serverless
커맨드라인에 serverless를 입력하면 아래와 같은 메시지가 나온다.
그리고 프로젝트 이름은 대충 지어준다.
세번째 물음은 Serverless 대시보드에 서비스를 등록하는건데,
이걸 등록하면 AWS 인증을 대시보드의 설정을 따라가게 된다. 그냥 skip하자.
그리고 아무것도 없으니 바로 deploy는 하지 않는다.
node-lambda 디렉토리가 생겼는데 내부는 아래와 같다.
이대로 배포해도 잘 동작한다. 배포 후 디렉토리를 보면 여러 파일이 생겼는데, 캐시를 위한 파일들이라 생각하면 편하다.
이 파일들을 업로드에서 제외해 주려고 package 설정을 해준 것이다.
index.js에는 람다에 올릴 코드가 들어있고, serverless.yml 파일에는 람다의 설정을 코드 베이스로 작성해둔 코드가 있다.
serverless.yml
service: node-lambda
frameworkVersion: '3'
provider:
name: aws
runtime: nodejs18.x
architecture: arm64
region: ap-northeast-2
memorySize: 256
timeout: 5
package:
individually: true
patterns:
- '!.*'
- '!*'
functions:
function1:
handler: index.handler
index.js
module.exports.handler = async (event) => {
return {
statusCode: 200,
body: JSON.stringify(
{
message: 'Go Serverless v3.0! Your function executed successfully!',
input: event,
},
null,
2
),
};
};
serverless.yml에는 정말 다양한 설정들을 해줄 수 있다.
region, IAM, 태그, 할당할 메모리 양, 타임아웃, 업로드시 제외할 파일, 트리거 설정, 이벤트 설정 등 콘솔에 있는 모든 옵션을 설정할 수 있다.
이번 포스팅에서는 간단하게 region, 메모리양, 타임아웃, 제외할 파일 정도만 작성해줬다.
이대로 serverless deploy 를 해보자.
$ sls deploy
Deploying node-lambda to stage dev (ap-northeast-2)
✔ Service deployed to stack node-lambda-dev (87s)
functions:
function1: node-lambda-dev-function1 (312 B)
Need a faster logging experience than CloudWatch? Try our Dev Mode in Console: run "serverless dev"
배포에 성공했다.
람다에서 확인해보면,
제대로 생성된 것을 확인할 수 있다.
네이밍 규칙은 프로젝트명-STAGE-함수명이다(STAGE는 디폴트로 dev다. 위 명령어에 나와있다.)
아쉽게도 URL을 지정하지 않았기 때문에 테스트는 해볼 수 없다.
여기서 함수만 업데이트 하고 싶으면, 추가 옵션을 주면 되는데 이렇게 배포하면 속도에 이점이 있다.
sls deploy function -f function1
Deploying function function1 to stage dev (ap-northeast-2)
✔ Function code deployed (0s)
Function configuration did not change, and the update was skipped. If you made changes to the service configuration and expected them to be deployed,
it most likely means that they can only be applied with a full service deployment.
코드만 변경해서 그런지 함수의 설정이 바뀌지 않았다고 하는데, 그냥 무시해도 된다.
마지막으로 serverless에서는 배포를 위해 S3에 람다를 생성하는데 필요한 데이터들을 저장한다.
이번에는 별도의 경로를 지정해주지 않았기 때문에 디폴트로 생성되었다.
롤백, 버전관리, 배포 이력 추적 등을 위해서 s3 경로를 픽스해주는게 좋다고 한다.( 옵션 : deploymentBucket )
GitHub
https://github.com/imsosleepy/serverless-lambda.git
마치며
앞서도 이야기했지만 콘솔을 만지는 것보다 확실히 코드 베이스가 편하다.
문제는, yaml 코드가 굉장히 낯설다는건데 argoCD나 terraform 등을 사용하려면 빨리 익숙해져야 한다.
그리고 공식문서를 보는 습관을 더 들여야겠다.
너무 기초 기능만 써서, 포스팅을 한개 정도 더하지 싶다.
참고자료
'개발 > AWS' 카테고리의 다른 글
Serverless Framework의 다양한 기능 사용해보기 (2) | 2023.12.07 |
---|---|
AWS Route 53 - API Gateway - Lambda 함께 사용하기(+ DynamoDB) (1) | 2023.12.04 |
스프링부트에서 AWS Dynamo DB 사용하기 (JAVA SDK 2.x) (0) | 2023.09.11 |
EKS에서 AWS JAVA SDK 1.0을 사용할 때 발생하는 문제... (0) | 2023.08.08 |
스프링부트에서 AWS SQS SDK 2.0 사용하기 (0) | 2023.08.07 |
- Total
- Today
- Yesterday
- JWT
- AWS EC2
- serverless
- Log
- Spring
- AWS
- GIT
- openAI API
- Elastic cloud
- 티스토리챌린지
- springboot
- OpenFeign
- terraform
- java
- 스프링부트
- docker
- 오블완
- 람다
- cache
- S3
- CloudFront
- EKS
- ChatGPT
- Kotlin
- elasticsearch
- AOP
- OpenAI
- lambda
- MySQL
- 후쿠오카
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |