2023.05.24-05.30
세 번째 프로젝트가 끝났습니다 👏
일차별 작업 진행 사항과 모든 트러블슈팅은 TIL로 정리하였기 때문에, 해당 회고에서는 변경점이나 주요 트러블슈팅 등을 기록합니다!
(TIL 링크: Tutorial Step1 Step2 Step3 Step4)
프로젝트 목표
AWS 클라우드 환경을 기반으로 하는 느슨하게 연결된(loosely coupled) 애플리케이션 아키택처에 대한 이해
- Serverless를 이용한 메시지 대기열 활용 이해 및 구현
- 요구사항에 따른 애플리케이션과 인프라 구현
- 문제사항 해결을 위한 추가 리소스 생성 → DLQ, Legacy 시스템 성능문제 해결, SES
- 아키택처 다이어그램 제작
진행 일정
- Day 1: Serverless를 이용한 Lambda 생성, Serverless를 이용한 Lambda - SQS - Lambda 구조 생성, DLQ 연결 및 K6 성능테스트, 요구사항 분석 및 초기 다이어그램 작성
- Day 2: Lambda 서버 - DB 연결, “재고 없음” 메시지 전달 시스템 구성, 레거시 시스템 연결을 위한 Lambda 구성 및 DLQ 추가
- Day 3: 데이터베이스의 재고를 증가시키는 Lambda 함수 생성, 다이어그램 작성, 팀별 평가
- Day 4: 야크쉐이빙, IaC 코드 작성
프로젝트 시나리오
<자동 재고 확보 시스템>을 위한 MSA
<도넛-스테이츠>는 온라인으로 도넛을 판매합니다. 웹사이트를 통해서 주문 버튼을 누르는 것으로 구매(Sales API)가 가능합니다. 창고에 재고가 있다면 재고가 감소하고 구매가 완료됩니다. 유튜브스타 hoyong.LEE가 도넛-스테이츠의 도넛이 맛있다고 영상을 올렸습니다. 그를 따르는 데브옵스 수강생들이 몰려듭니다. 주문이 급등합니다. 창고에 재고가 없기 때문에 구매가 불가능한 경우가 발생합니다. 창고의 도넛의 재고가 다 떨어지면 제조 공장에 알려서 다시 창고를 채우는 시스템을 구축해야 합니다. 제조 공장인 <팩토리-스테이츠>에 주문을 요청(Leagcy Factory API)할 수 있습니다. 주문이 요청되면 일정 시간이 지난 후 창고에 재고가 증가합니다.
프로젝트 요구사항
요구사항 1 : 재고부족으로 인한 구매실패에 대한 조치
- Sales API를 통해 요청을 받은 서버가 데이터베이스에서 재고 상황을 확인합니다.
- 재고가 있다면 감소시키고 응답으로 판매완료 내용을 전달합니다.
- 재고가 없는 경우 공장에 주문을 진행합니다
- 재고가 없다는 내용을 담은 메시지 페이로드가 주제별로 생성됩니다.
- 메시지가 느슨하게 연결된 시스템을 통해 처리될 수 있도록 따로 보관됩니다.
요구사항 2 : 메시지 누락 상황에 대한 조치
- 빈번한 요청으로 메시지 누락이 발생합니다.
- 메시지가 처리되지 않은 경우 메시지들을 체계적으로 관리할 다른 처리 공간을 생성해야 합니다.
- 메시지 처리 보관 리소스와 처리되지 않은 메시지 처리 리소스가 연결되어야 합니다.
요구사항 3 : Legacy 시스템(Factory → Warehouse) 성능문제에 대한 조치
- 안정적으로 이벤트가 전달될 수 있는 시스템을 구축해야 합니다.
- 메시지를 소비하는 리소스를 통해 Factory API가 호출됩니다.
- Factory의 생산 완료 메시지를 수신한 컴퓨팅 리소스가 상품 재고를 증가시킵니다.
추가 시나리오
a. 광고 중단 요청 진행 시나리오
재고가 없는 상황에서도 광고가 계속 진행되고 있습니다. 광고 비용 절감과 고객불만을 낮추기 위한 조치가 필요합니다. 메시지가 유실되는 상황을 막기 위해 내구성을 갖춘 시스템이 필요합니다.
- 요구사항
- 재고를 채우기 위한 과정이 진행될 때 광고 담당자에게 광고 중단 요청 내용을 담은 이메일이 전송되어야 합니다.
- 메시지에 대한 내구성을 강화하기 위해 메시지 Queue가 사용되어야 합니다.
- AWS SES 서비스를 이용해서 이메일을 전송해야 합니다.
b. VIP 고객관리 프로세스 추가 시나리오
모니터링 결과 대량 주문을 하는 일부 고객들이 확인되었습니다. 대량 구매 고객들의 사용자 정보를 식별할 수 있어야 합니다. 고객정보는 별도의 서버(EC2)와 데이터베이스(RDS)에서 관리되고 있습니다. 데이터베이스 기록과 외부 마케팅 시스템으로의 연결과정의 오류를 대비하기 위한 내구성 갖춘 시스템이 필요합니다.
- 요구사항
- 100개 이상 구매가 발생 시 해당 유저의 타입이 normal에서 Vip로 변경되어야 합니다.
- 메시지에 대한 내구성을 강화하기 위해 메시지 Queue가 사용되어야 합니다.
- 고객관리는 별도의 데이터베이스(RDS)로 관리되고 있기 때문에 해당 데이터베이스에 접근해서 정보를 수정해야 합니다.
다이어그램
초기 다이어그램
총 3개의 람다 함수가 사용된다고 판단하였다
1. 주문을 받고, 재고를 확인해서 재고 요청메시지를 보내는 람다 함수
2. 재고 요청 메시지를 받고, 생산 요청을 보낼 람다 함수
3. 생산 요청을 받고, 데이터베이스의 재고를 늘려줄 람다 함수
1->2 과정에서 메시지를 전달하는 방법으로 SNS와 SQS를 선택했고, 누락된 요청을 보관할 DLQ 또한 추가했다
처음 다이어그램을 작성하는 과정에서는 요구사항 1-4의 주제별 페이로드 생성이 무슨 뜻인지 이해가 안돼서 '도넛 별로 주제가 생성되는 건가?'라는 생각을 했다
중간 다이어그램
초기 다이어그램과 구성한 서비스 로직을 토대로 다이어그램을 작성하였고, 추가 시나리오를 구현하였다
광고 중단 요청 진행 시나리오 구현을 위해 기존 SNS를 구독하는 SQS를 추가하였다
VIP 고객 관리 프로세스 추가 시나리오 구현을 위해 고객 관리를 위한 서버와 데이터베이스, 그 내용을 수정할 람다 함수를 추가하였다
최종 다이어그램
API를 트리거로 람다 함수 2개를 실행하는 것은 안된다는 피드백을 받았고, 람다 함수 대신 SNS 토픽을 2개 발행하는 것으로 수정하였다
SQS 메시지를 바로 SES 서비스로 전송하는 것은 안된다는 피드백을 받았고, SQS 메시지를 받는 람다 함수를 추가하였다
aws에 람다 함수를 배포하기 전, 로컬에서 npm install을 해야하는가?
코드에 사용할 모듈이 써있으니 aws에 올리면 자동으로 설치돼야 한다고 생각했다
그러나 npm install 작업 없이 배포하면 cannot find module 에러가 발생하는 것을 볼 수 있었다
관련 내용을 chatGPT를 이용해 알아보았다
AWS에서 서버리스 Lambda 함수를 배포할 때 일반적으로 배포하기 전에 필요한 패키지를 로컬에 설치해야 합니다. 이는 배포 프로세스에 Lambda 함수 코드 및 해당 종속성을 포함하는 배포 패키지 생성이 포함되기 때문입니다.
필요한 패키지를 로컬로 설치하면 배포 패키지에 포함되어 있는지 확인할 수 있습니다. 이는 AWS의 Lambda 함수가 로컬 개발 환경과 별도로 격리된 환경에서 실행되기 때문에 중요합니다. 따라서 Lambda 함수에 필요한 모든 종속성 또는 패키지는 Lambda 환경 내에서 제대로 실행될 수 있도록 배포 패키지에 포함되어야 합니다.
필요한 패키지로 배포 패키지가 생성되면 AWS에 배포할 수 있습니다. AWS Lambda는 클라우드에서 함수를 실행할 때 이러한 패키지와 해당 종속성을 올바르게 처리하도록 설계되었습니다. 따라서 로컬로 설치하는 패키지는 Lambda 실행 환경과 호환되는 한 배포 후 정상적으로 작동해야 합니다.
요약하면 배포하기 전에 패키지를 로컬에 설치하는 목적은 필요한 모든 종속성이 배포 패키지에 포함되어 Lambda 함수가 AWS Lambda 환경에서 올바르게 실행되도록 하는 것입니다.
패키지를 로컬에 설치하지 않으면 AWS Lambda가 자동으로 패키지를 설치하지 않습니다. Lambda 함수를 배포할 때 필요한 모든 코드와 종속성을 포함하는 배포 패키지를 제공해야 합니다.
AWS Lambda는 서버리스 환경에서 실행되므로 런타임에 필요한 모든 종속성에 액세스할 수 있어야 합니다. 패키지를 동적으로 설치할 수 있는 기존의 서버 기반 환경과 달리 Lambda 함수는 로컬 개발 환경과 독립적인 격리된 환경에서 실행됩니다.
필요한 패키지를 로컬에 설치하지 않고 배포 패키지에 포함하면 AWS Lambda가 런타임 중에 종속성을 해결할 수 없습니다. 결과적으로 Lambda 함수가 제대로 실행되지 않아 오류 또는 예기치 않은 동작이 발생할 수 있습니다.
Lambda 함수에 필요한 모든 종속성이 있는지 확인하려면 배포 전에 로컬로 설치하여 배포 패키지에 종속성을 포함하는 것이 중요합니다. 이렇게 하면 필요한 패키지가 코드와 함께 패키징되고 AWS Lambda에 배포되어 실행 중에 사용할 수 있습니다.
필요한 패키지를 로컬에 설치하지 않고 배포 패키지에 포함하면 람다 함수의 런타임 중에 종속성을 해결할 수 없다고 한다
배포 전에 로컬로 설치하여 배포 패키지에 종속성을 포함하여야 필요한 패키지가 코드와 함께 패키징 되고, 람다에 배포되어 실행 중에 사용할 수 있다고 한다
람다의 수평 확장 방법은?
람다 함수의 경우 들어오는 트래픽을 기반으로 동시성을 자동으로 조정한다
람다의 비용은?
최초 백만건의 경우 무료이며, 그 이후 시간당 비용이 청구된다
공식 문서에 보면 시간당 비용 옆에 건당 비용도 써있는데, 이 건당 비용은 무엇인가..?
AWS Lambda에는 함수와 관련된 명시적인 "시간당 비용"이 없습니다. 대신 Lambda 요금은 요청 수와 함수 실행 기간의 조합을 기반으로 합니다.
AWS Lambda의 요금 모델은 두 가지 주요 구성 요소로 구성됩니다.
요청 수: Lambda 함수에 대한 총 요청 수에 대해 요금이 청구됩니다. 함수가 호출될 때마다 요청을 구성합니다. 여기에는 동기 및 비동기 호출이 모두 포함됩니다.기간: 또한 100밀리초 단위로 측정되는 함수 실행 기간을 기준으로 요금이 청구됩니다. 기간은 코드가 실행되기 시작하여 완료되거나 종료될 때까지 계산됩니다. 함수의 모든 호출에 대한 총 기간에 대해 요금이 청구됩니다.
Lambda 함수 비용 표에 언급된 "작업당 비용"은 함수에 대한 각 개별 호출 또는 요청과 관련된 비용을 의미할 수 있습니다. 이 비용에는 기간과 요청 횟수가 모두 포함됩니다.
Lambda 함수의 비용을 계산하려면 일반적으로 총 요청 수와 지정된 청구 기간 내 모든 호출의 누적 기간을 고려합니다.
- chatGPT
그 둘의 조합으로 비용을 정산하는 것 같다
공식 문서를 다시 보니 아래 사진과 같은 문장이 있었다
DLQ를 처리하는 방법은?
람다 함수 등을 이용하여 처리할 수 있다
람다를 만드는 방법은?
Terraform, Sam, Serverless, sdk, aws cli, aws 콘솔 등을 통해 생성할 수 있다
마이크로서비스의 특징은?
유지 보수에 유리하고 테스트가 가능해야 한다
느슨하게 결합되어야 한다
독립적으로 배포 가능해야 한다
비즈니스 역량을 중심으로 구성해야 한다
작은 팀에 의해 소유된다
SQS FIFO와 표준의 차이점은?
FIFO는 메시지의 순서를 보장하며 한 번만 전송한다
반면 표준은 메시지의 순서를 보장하지 않고, 여러 번 전송될 수 있으므로 중복의 가능성이 있다
FIFO가 더 비싸다
SNS를 FIFO로 만들었을 때의 주의사항은?
그에 연결되는 SQS 또한 FIFO로 구성되어야 한다
SNS에 연결할 수 있는 서비스는?
이메일, SQS, 람다 함수, kinesis data firehouse, 웹서버, 모바일 알림 등이 있다
'그래도 학부 생활이 헛되지는 않았구나, 나 전공생이기는 하구나'라는 생각이 들었던 부분이 코드 해석이었다..
오류가 발생하면 코드를 보고 파일들을 타고 타고 가면서 문제 부분을 찾아낼 수 있었다
프로젝트 2보다 쉬운 건지, 내가 실력이 늘은 건지 알 수 없지만.. 확실한건 지식이 늘긴 늘었다!
프로젝트 뿐만 아니라 부트캠프를 진행하면서 이런 저런 오류를 만나면서 지식이 느는 것 같다
이론 공부보다 실전에서 맞으면서 배우는게 확실하게 느는 기분.. 😂
이쪽 전공에서 중요한 덕목이 구글링 실력이라고 하는 것처럼 .. 구글링 실력과 해석 능력이 늘고있다 ㅋㅋㅋ
에러를 만났을 때 어떤 키워드로 조합해서 검색을 해야할지도 점점 명확해지는 것 같고
관련 문서나 커뮤니티들이 죄다 영어라서.. 영어 해석 능력이 늘고 있다..
'Code States > 회고' 카테고리의 다른 글
| Final Project - 마라톤 대회 결과 기록 시스템, 마라마라톤! (1) | 2023.06.28 |
|---|---|
| 코드스테이츠 DevOps 부트캠프 세 달차, Section 3 종료! (1) | 2023.05.30 |
| 코드스테이츠 DevOps 부트캠프 두 달차, Section 2 종료! (1) | 2023.05.02 |
| Section 2. 프로젝트 - AWS 배포 (1) | 2023.05.02 |
| 코드스테이츠 DevOps 부트캠프 한 달차, Section 1 종료! (0) | 2023.04.05 |