마이크로서비스 배포 툴
SAM(Serverless Application Model)
Lambda 콘솔을 통해 직접 애플리케이션을 개발하는 것은 다소 불편하기 때문에 AWS에서는 서버리스 애플리케이션을 쉽게 테스트하고 배포할 수 있는 서버리스 애플리케이션 모델을 제공하며 그것을 SAM이라고 부른다.
SAM이 제공하는 대표적인 기능
- 한번에 배포
- Lambda 함수, API Gateway 등의 리소스를 CLI 명령어 한 번으로 배포가 가능하게 만들 수 있다.
- 로컬에서의 테스트
- 꼭 배포하지 않아도 로컬 환경에서 테스트가 가능하다.
- AWS CloudFormation 기능을 이용한 단일 작업을 통한 리소스(인프라) 관리
- AWS CloudFormation은 이후에 배우게 될 Terraform과 같은 Infrastructure as Code 도구다.
SAM CLI 설치 및 실습
brew tap aws/tap
brew install aws-sam-cli
위 명령어를 통해 쉽게 sam을 깔 수 있다.
그 후 hello world 애플리케이션을 배포해보겠다.
먼저 sam init를 통해 샘플 애플리케이션을 다운받는다.
여기서 주의해야 할 점은 인기 있는 런타임으로 파이선을 고른다는 문장이 있는데 n를 치고 노드 14 버전으로 설정해줘야 한다.
그러면 sam-app이란 폴더가 생기고 그 폴더에서 sam build를 한다.
그 후 sam deploy --guided를 통해 배포할 수 있다.
위 +Add를 전부 만들어 배포하는 것이다.
성공적으로 배포가 되면 이런 화면이 뜨고 두 번째 벨류인 엔드포인트와 3번째 벨류인 arn을 확인할 수 있다.
그리고 람다에 들어가 보면 배포가 잘 된 것을 확인할 수 있다.
그리고 터미널에서 curl arn을 보내면 성공적으로 람다 함수를 통해 hello world를 반환하는 것을 볼 수 있다.
삭제는 cloud formation 가서 스택을 지우면 한 번에 삭제할 수 있다.
API Gateway와 서버리스 애플리케이션 실습
Bare Minimum Requirement
- 다음 아키텍처로 구성된 서버리스 애플리케이션을 배포합니다.
- API Gateway - Lambda - DynamoDB
- 직접 API Gateway로 실행해봅니다.
- API Gateway의 인증 기능을 이용해서, HTTP 요청에 특정 API Key를 사용하는 예제를 다음 두 가지 방법으로 구현합니다.
- API Key
- 권한 부여자
- CloudWatch Logs를 통해서 API 호출을 모니터링할 수 있어야 합니다.
이번엔 API Gateway - Lambda - DynamoDB를 구성하여 배포하여야 한다. 먼저 Lambda - DynamoDB를 먼저 구성해보자
https://serverlessland.com/patterns/lambda-dynamodb
이 주소로 들어가면 친절하게도 깃 클론 주소를 알려주고 그 주소를 클론한 뒤 똑같이 빌드 후 배포하면 된다.
다이나모디비뿐만 아니라 수많은 서비스가 있다.
다이나모와 람다는 연결되었고 api gateway를 연결해보자. 람다 홈페이지에 들어가 트리거를 추가하고 api gateway를 고르고 설정한다.
그럼 api 게이트웨이도 추가되었고 포스트맨으로 api게이트웨이 앤드포인트로 한번 get 요청을 보내보겠다.
200 Ok로 잘 연결된 모습이다 그럼 다이나모DB에서도 로그가 쌓이나 보겠다
잘 저장되는 모습을 확인할 수 있다. 그럼 이제 api 게이트웨이에 제한을 추가해보겠다.
- POST 전용으로만 작동하게 만들기
- 이 레퍼런스를 참고하세요
- 본문만 저장하도록 만들기
- API 키를 이용한 인증 추가하기
- 권한 부여자를 이용한 인증 부여하기 (optional)
먼저 post 전용으로 작동하게 만들어 보겠다.
api gateway로 들아가서 리소스를 보면 any라는 메소드가 있고 이건 어떤 요청이던 다 받아들인다는 뜻이다.
any는 삭제하고 메소드를 하나 post로 만들어주면 된다.
여기서 Lambda 함수는 본인 lambda arn 값을 넣으면 된다.
이처럼 post 메소드가 만들어졌고 한번 포스트맨으로 확인해보자!! 라고 하면 아마 get을 보내도 200번 ok를 뛰울 것이다. 왜냐면 변경이 생기면 api 배포를 해줘야 변경값이 적용된다. 작업에서 api 배포를 하고 다시 해보자!
이처럼 get은 안되지만 포스트는 되는 모습을 볼 수 있고 람다와 다이나모디비에서도 확인할 수 있다.
그럼 POST 전용으로만 작동하는 것은 완료했고 본문만 저장하도록 해보자
람다에서 코드를 보면 ID와 만든 시간 메타데이터로 이벤트를 다 받아오도록 코드가 짜져 있고, 본문만 저장해야 하니 만든 시간은 주석처리로 날리고 이벤트 뒤에. body를 붙이면 바디 값만 가져오기 때문에 본문만 저장이 된다.
그리고 포스트맨으로 post를 보내고 확인해보자! 그럼 당연히 똑같을 것이다. 이것도 역시 배포를 해줘야 변경사항이 적용된다. 배포 후 다시 해보자! 그럼 아이디 값과 바디 값만 오는 것을 확인할 수 있다.
그럼 두 번째 요구사항도 클리어했고 3번째로 api key를 인증 수단으로 추가해보자!
먼저 api gateway에서 api key로 들어가서 key를 만든다.
그 후 사용량 계획을 만든다.
그 후 api key 사용량 계획을 추가한다.
그리고 다시 메소드로 들어가서 api key를 true로 열여줘야한다.
그럼 이제 post 요청을 보내려면 api key가 필요하다. 그전에 배포는 꼭 하고 포스트맨으로 한번 요청을 보내보겠다.
포스트맨으로 요청을 보낼 때 authorization에 api key로 선택 후 키값을 X-api-key로 하고 밸류 값을 아까 만든 api key를 넣으면 된다.
그 후 다이나모 디비를 보면 잘 들어간 것을 확인할 수 있다.
그럼 이제 마지막인 권한 부여자를 넣어보자.
권한 부여자는 람다 함수를 새로 만들어야 하므로 람다에 들어가서 함수를 만들어보자.
그리고 밑에 내려가서 코드 소스를 변경해주면 된다. 소스는 공식 홈페이지인 https://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html
에 친절하게도 다 나와있다. 수정 후 배포까지 해야 한다!
수정하고 배포까지 했으면 Api gateway에 들어가 권한 부여자로 들어가 생성해준다.
만든 후 api gateway에 들어가 메소드에서 승인을 token으로 주고 배포를 하면 끝이다.
포스트맨으로 요청을 보내보면
토큰 값을 안 넣으면 401번이 뜬다. 하지만 토근을 넣으면 200이 뜨는 걸 확인할 수가 있고 다이나모DB에 가도 확인 가능하다.
그럼 요구사항은 끝이다! 와아~
'TIL' 카테고리의 다른 글
| 49일차 Infrastructure as Code (0) | 2022.06.24 |
|---|---|
| 47~48일차 마이크로서비스 작성 (0) | 2022.06.23 |
| 46일차 마이크로서비스 작성 (0) | 2022.06.21 |
| 45일차 마이크로서비스 (0) | 2022.06.20 |
| 44일차 마이크로서비스 (0) | 2022.06.17 |