야크쉐이빙
이번 실습과제를 진행하면서 만났던 잘못생각했던 부분이나 에러? 등을 야크쉐이빙을 해보도록 합시당.
1. serverless 프레임 워크로 배포한 애플리케이션은 삭제시에도 serverless 프레임워크로 삭제
실수로 serverless로 배포를 해서 aws 콘솔에서 삭제를 했었다.
lamda와 apigateway가 만들어져서 각각 삭제를 해주었는데
이후 해당 앱을 다시 배포하니
해당 람다를 찾을 수 없다는 메시지가 나왔다.
람다를 콘솔에서 생성해야하나.. 싶었는데 팀원들의 도움으로
serverless remove 명령어를 이용하여 serverless 프레임워크로 삭제를 시켜주고 배포하니 정삭적으로 배포가 되었다.
2. 하나의 람다에서 각기 다른 두 가지 로직을 처리하는 구조
재고가 100개 이상 주문한 고객을 따로 VIP로 디비 저장하는 추가 시나리오를 추가하는 과제가 있었다.
APIGATEWAY를 트리거로 사용하는 다른 람다함수를 만들어서 재고가 100이상이 주문되었는지를 판단하게 했다.
그리고는 해당 메시지를 큐로 전송하여 EC2에서 DB로 저장하게 만들었다.
하지만 굳이 람다를 하나 더 만들어 컴퓨팅을 늘리는것보다 기존에 람다에서 주문 수량을 파악하는 로직을 추가하는 방식으로 변경하였다.
그리고 주문수량이 100개가 넘었을때 해당되는 메시지를 vip_user라는 SNS에 보내고 재고가 없을때의 메시지는 stock_empty라는 SNS로 보냈다
그러면 각각의 메시지를 각각의 큐가 받아서 다음 로직을 처리할 수 있도록 전달한다.
아래는 변경한 아키텍쳐이다.
Section3 실습과제를 마치면서..
예전보다 에러를 만나면 해결하는 시간이 많이 짧아졌다고 느꼈다.
이전에 진행한 과제에서는 에러가 나타나면 오류를 잡는데까지 시간이 많이 걸렸는데
이번 과제는 비교적 빨리 해결이 되었당
운인지.. 검색왕이 된건지.. 모르겠지만..?
그래도 과제로 만들어진 구조는 완전히 이해가 되었다.
아키텍쳐도 이제는 보면 처리되는 방식이 좀 머리속에서 그려지는 것 같다.
'코드스테이츠_Devops_4기 > section3) 마이크로서비스와 인프라스트럭처 관리' 카테고리의 다른 글
| Section3 실습과제 Day3 (3) | 2023.05.30 |
|---|---|
| Section3 실습과제 Day2 (1) | 2023.05.30 |
| Section3 마이크로서비스 (1) | 2023.05.08 |