[Project] Serverless Framework를 이용하여 자동 재고 확보 시스템 구현하기

프로젝트 개요

📑 AWS 클라우드 환경을 기반으로 하는 느슨하게 연결된(loosely coupled) 애플리케이션 아키택처에 대한 이해를 목표로 하며 요구사항에 따라 인프라를 구현

💡 loose coupling(느슨한 결합) 이란?
시스템의 구성 요소들이 서로에게 최소한의 의존성을 가지고 상호작용하는 디자인 원칙입니다. 이를 통해 각 구성 요소는 독립적으로 개발, 배포 및 확장될 수 있으며, 변경 사항이 다른 구성 요소에 미치는 영향을 최소화할 수 있습니다. AWS에서 제일 오래된 서비스인 SQS의 장점중 하나인 느슨한 결합은 시스템 아키텍처의 유연성과 견고성을 향상시키는데 도움을 줍니다. 각각의 구성 요소가 독립적으로 작동하면서도 메시지를 통해 통신할 수 있기 때문에, 시스템의 유지보수, 확장 및 변경이 용이해집니다.

프로젝트 시나리오

🎬 온라인으로 도넛을 판매하며 웹사이트를 통해서 주문 버튼으로 구매가 가능합니다.
창고에 재고가 있다면 재고가 감소하고 구매가 완료 됩니다.
창고에 재고가 없기 때문에 구매가 불가능한 경우 제조 공장으로 주문 하여 창고에 재고를 확보하는 시스템을 구축
주문이 되면 일정 시간이 지난 후 창고에 재고가 증가합니다.

Day 1 – Tutorial(프로젝트전 사전 학습 및 연습)

사전 학습

Serverless Framework란?

🔠 Serverless Framework란?
Node.js를 사용하여 작성된 오픈 소스 웹 프레임 워크이며 AWS Lambda에서 Application을 구축하기 위해 개발된 최초의 Framework입니다. 코드와 인프라를 관리할 수 있으며 여러 언어 (Node.js, python, Java 등)를 지원합니다.
serverless 공식 홈페이지

📌 본 실습은 Amazon Web Service에 계정이 있고 ubuntu OS 안에서 AWS 자격증명 설정이 완료 되었다는 전제하에 진행됩니다. 
주로 CLI에서 실습을 진행을 했기에 주석으로 삽입한 설명이 다소 있습니다.

SQS와 SNS 서비스

[AWS] SQS(Simple Queue Service)

[AWS] SNS(Simple Notification Service)

AWS SQS (Simple Queue Service)와 SNS (Simple Notification Service)은 모두 AWS (Amazon Web Services)에서 제공하는 메시징 서비스입니다. 그러나 두 서비스는 목적과 동작 방식에서 차이가 있습니다.

목적:
- SQS: SQS는 비동기 메시지 큐 서비스로, 애플리케이션 구성 요소 간에 메시지를 전송하고 저장하는 데 사용됩니다. 메시지를 수신한 애플리케이션이 해당 메시지를 처리할 수 있을 때까지 메시지는 SQS에서 저장되며, 다른 구성 요소에서 메시지를 수신할 수도 있습니다.
- SNS: SNS는 게시-구독 (Publish-Subscribe) 서비스로, 메시지를 발행하고 구독하는 데 사용됩니다. 메시지를 발행한 후 해당 메시지를 구독한 모든 구성 요소에게 전달합니다.
동작 방식:
- SQS: SQS는 메시지를 저장하는 대기열로 작동합니다. 메시지를 보내는 애플리케이션은 메시지를 SQS 큐에 보내고, 메시지를 처리할 애플리케이션이 해당 큐에서 메시지를 읽습니다. 애플리케이션 간의 결합도가 낮고 확장성이 좋으며, 메시지 처리량을 제어할 수 있습니다.
- SNS: SNS는 메시지를 게시하고, 해당 메시지를 구독한 모든 애플리케이션에게 전달합니다. 메시지 발행 시 모든 구독자에게 동일한 메시지가 전송되며, 구독자가 관심 있는 메시지를 구독하고 처리합니다. 이는 한 번에 여러 구독자에게 메시지를 브로드캐스트할 수 있는 유연성을 제공합니다.
메시지 전송 방식:
- SQS: SQS는 P2P(Point-to-Point) 메시징을 지원합니다. 메시지를 전송한 후 해당 메시지를 수신할 수 있는 단일 애플리케이션이 메시지를 처리합니다.
- SNS: SNS는 발행-구독(Publish-Subscribe) 메시징을 지원합니다. 메시지를 발행한 후 해당 메시지를 구독한 모든 애플리케이션이 메시지를 독립적으로 처리합니다.
메시지 수신 방식:
- SQS: SQS는 폴링(Polling) 방식을 사용하여 메시지를 수신합니다. 애플리케이션은 주기적으로 SQS에 대해 폴링하여 메시지를 수신할 준비가 되었는지 확인합니다.
- SNS: SNS는 메시지를 구독한 애플리케이션에게 전달하는 방식으로, 애플리케이션은 SNS에게 등록된 구독자로서 메시지를 수신합니다.

요약하면, SQS는 비동기 메시징 큐로 작동하여 메시지를 전송하고 저장하며, SNS는 게시-구독 메시징 서비스로 작동하여 메시지를 발행하고 구독한 모든 애플리케이션에게 전달합니다.

Tutorial

📌 프로젝트 진행 전에 필요한 선행 실습이며 Tutorial을 진행하면서 다음과 같은 이해가 필요합니다.
1. Serveless를 이용한 AWS 리소스(Lambda, SQS, SNS) 생성
2. 메시지 Queue가 사용되는 구조 이해
3. SQS에서의 Producer - Consumer 패턴
4. DLQ 동작원리
5. Lambda 내에서 AWS-SDK 라이브러리를 통해 자바스크립트 작성

Create Severless Project (HTTP API)

GitHub Link

Serverless Framework install
Serverless create project
Serverless는 기본적으로 다양한 Template을 제공합니다.
aws-sdk install
AWS 리소스를 관리하고 조작하는 데 필요한 도구와 라이브러리

# Serverless Framework를 사용하기 위해서 아래와 같이 설치를 진행한다.
user01@ubuntu:~/project03$ sudo npm install -g serverless

 Serverless 템플릿 생성 진행 ##
user01@ubuntu:~/project03$ serverless

Creating a new serverless project

? What do you want to make?
  AWS - Node.js - Starter
❯ AWS - Node.js - HTTP API
  AWS - Node.js - Scheduled Task
  AWS - Node.js - SQS Worker
  AWS - Node.js - Express API
  AWS - Node.js - Express API with DynamoDB
  AWS - Python - Starter
  AWS - Python - HTTP API
  AWS - Python - Scheduled Task
  AWS - Python - SQS Worker
  AWS - Python - Flask API
  AWS - Python - Flask API with DynamoDB
  Other
? What do you want to call this project? (aws-node-http-api-project)
✔ Project successfully created in aws-node-http-api-project folder

? Do you want to deploy now? (Y/n) Y
 Serverless 템플릿 생성 진행 ##
# 생성 완료 후 프로젝트 폴더 파일
user01@ubuntu:~/project03/aws-node-http-api-project$ ll
합계 28
drwxrwxr-x 3 user01 user01 4096  5월 24 10:34 ./
drwxrwxr-x 3 user01 user01 4096  5월 24 10:23 ../
-rw-r--r-- 1 user01 user01   86  5월 24 10:23 .gitignore
drwxrwxr-x 2 user01 user01 4096  5월 24 10:24 .serverless/
-rw-r--r-- 1 user01 user01 2886  5월 24 10:23 README.md
-rwxr--r-- 1 root   root      0  5월 24 10:34 createCustomer.js*
-rw-r--r-- 1 user01 user01  253  5월 24 10:23 index.js
-rw-r--r-- 1 user01 user01  217  5월 24 10:23 serverless.yml

 AWS-SDK 설치 ##
user01@ubuntu:~/project03/aws-node-http-api-project$ npm install --save-dev aws-sdk
npm WARN deprecated querystring@0.2.0: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.

added 31 packages, and audited 32 packages in 6s

13 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
 AWS-SDK 설치 ##

Deploy Serverless

user01@ubuntu:~/project03/aws-node-http-api-project$ ll
합계 60
drwxrwxr-x  4 user01 user01  4096  5월 24 10:43 ./
drwxrwxr-x  3 user01 user01  4096  5월 24 10:23 ../
-rw-r--r--  1 user01 user01    86  5월 24 10:23 .gitignore
drwxrwxr-x  2 user01 user01  4096  5월 24 10:24 .serverless/
-rw-r--r--  1 user01 user01  2886  5월 24 10:23 README.md
-rwxr--r--  1 root   root       0  5월 24 10:34 createCustomer.js*
-rw-r--r--  1 user01 user01   253  5월 24 10:23 index.js
drwxrwxr-x 34 user01 user01  4096  5월 24 10:43 node_modules/
-rw-rw-r--  1 user01 user01 23496  5월 24 10:43 package-lock.json
-rw-rw-r--  1 user01 user01    58  5월 24 10:43 package.json
-rw-r--r--  1 user01 user01   217  5월 24 10:23 serverless.yml
user01@ubuntu:~/project03/aws-node-http-api-project$ serverless deploy -r ap-northeast-2
user01@ubuntu:~/project03/aws-node-http-api-project$ curl -X POST https://op4jrexi5m.execute-api.ap-northeast-2.amazonaws.com/ --header 'Content-type: application/json' --data-raw '{ "input": 1 }'
{
  "message": "메시지를 받았습니다. 입력값: 1, 결과: 2"
}user01@ubuntu:~/project03/aws-node-http-api-project$ curl -X POST https://op4jrexi5m.execute-api.ap-northeast-2.amazonaws.com/ --header 'Content-type: application/json' --data-raw '{ "input": 2 }'
{
  "message": "메시지를 받았습니다. 입력값: 2, 결과: 3"
}user01@ubuntu:~/project03/aws-node-http-api-project$ curl -X POST https://op4jrexi5m.execute-api.ap-northeast-2.amazonaws.com/ --header 'Content-type: application/json' --data-raw '{ "input": 3 }'
{
  "message": "메시지를 받았습니다. 입력값: 3, 결과: 4"
user01@ubuntu:~/project03/aws-node-http-api-project$ sls remove
Removing aws-node-http-api-project from stage dev (ap-northeast-2)

✔ Service aws-node-http-api-project has been successfully removed (26s)

Create Severless Project (SQS Worker)

GitHub Link

🔠 SQS에서의 message와 queue
AWS에서 제공하는 Simple Queue Service의 약자이며 서버들끼리 사용할 수 있는 'message queue'를 제공하는 서비스이다.
여기서 'message' 와 'queue'를 간단하게 설명하자면
'message'는 XML, JSON과 같은 text 형태의 SQS의 기본 데이터 단위 이고 
'queue'는 message를 담는 공간이다.

📌 두번째로 배포할 프로젝트는 SQS Worker로 배포할 것이며 Producer Consumer 구조(멀티스레드 환경에서 데이터를 생성하는 프로듀서(Producer)와 데이터를 소비하는 컨슈머(Consumer) 사이의 협력적인 작업을 조정하기 위한 디자인 패턴)로 되어있습니다.

Producer-Consumer 패턴의 장점

생산자와 소비자의 역할 분리
데이터 생성과 처리를 별개의 스레드로 분리함으로써, 생산자와 소비자 간의 독립성과 유연성을 제공합니다.
동기화 및 협력
큐나 버퍼와 같은 중간 데이터 구조를 통해 생산자와 소비자 사이의 협력을 조정하고 동기화합니다.
처리량 조절
프로듀서와 컨슈머 사이의 데이터 처리 속도를 조절하여, 시스템 전반적인 처리량을 향상시킬 수 있습니다.
확장성
여러 개의 생산자 및 소비자 스레드를 동시에 사용하여 시스템을 확장할 수 있습니다.

아키텍처 이미지 예시

serverless 템플릿 중 SQS Worker 을 선택하여 생성 한후 index.js 파일을 아래와 같이 편집하였습니다. 생성 과정은 HTTP API 템플릿 생성과정과 동일합니다.

DLQ 실습

🔠 DLQ란?
Dead-letter Queue의 약자로 소프트웨어 시스템에서 오류로 인해 처리할 수 없는 메시지를 임시로 저장하는 특수한 유형의 메시지 대기열입니다. 잘못된 메시지 및 실패한 메시지의 임시 저장소 역할을 합니다. DLQ는 소스 대기열에 처리되지 않은 메시지가 넘치지 않도록 합니다. DLQ로 메시지가 보관됨으로서 개발자가 오류의 원인을 식별하는 데 집중할 수 있습니다. 수신자가 메시지를 처리할 수 없는 이유를 조사하고, 수정 사항을 적용한 후, 메시지를 전송하는 새로운 시도를 수행할 수 있습니다.
[AWS docs] DLQ(Dead Letter Queue)란 무엇인가요?

📌 consumer 함수에서 함수의 실행을 15초를 지연 시켜서 에러를 발생시키고 메세지가 리드라이브 정책(배달할 수 없는 메시지를 다시 시도하거나 대기열로 전송하는 방식을 정의하는 정책)으로 DLQ로 메세지가 넘어가게 해보겠습니다. 기존에 생성한 SQS Worker 템플릿에서 아래와 같이 index.js 파일만 수정하여 진행하겠습니다.

배포 진행 후 "body": "hello world" 값으로 테스트를 진행하여 SQS에서 메시지가 dlq로 넘어가는지 확인

💡 Visibility Timeout
AWS Lambda에서 "기본 표시 제한 시간" 또는 "Visibility Timeout"은 SQS 대기열에서 메시지가 다른 Lambda 함수에게 보이지 않고 대기하는 기간입니다. 기본값은 30초이며, 이 시간이 경과하면 메시지는 다시 사용 가능한 상태로 설정됩니다. Lambda 함수가 메시지 처리를 완료하지 못한 경우, 시간이 경과하면 대기열은 해당 메시지를 다시 사용 가능한 상태로 설정하여 다른 Lambda 함수가 메시지를 처리할 수 있게 됩니다. 이러한 방식으로 기본 표시 제한 시간은 메시지 처리의 성공 또는 실패에 따라 대기열에서 메시지의 가용성을 제어합니다.
예를 들어 이번 실습에서 consumer 함수가 15초가 지연되게 했는데 Visibility Timeout 시간을 15초보다 적은 시간으로 설정 하게 되면 해당 Lambda가 메세지를 소비하도 DLQ에도 메세지 대기열에 추가되는 상황이 발생되므로 참고해야 한다.

요구사항 분석 및 초기 다이어그램 작성

프로젝트 요구사항

재고부족으로 인한 구매실패에 대한 조치
- Sales API 를 통해 요청을 받은 서버가 데이터베이스에서 재고 상황을 확인합니다.
- 재고가 있다면 감소시키고 응답으로 판매완료 내용을 전달합니다.
- 재고가 없는 경우 공장에 주문을 진행합니다
- 재고가 없다는 내용을 담은 메세지 페이로드와 함께 SNS topic이 생성됩니다.
- 메시지가 SQS로 구현된 stock_queue에 수신됩니다.
메시지 누락 상황에 대한 조치
- 빈번한 요청으로 메시지 누락이 발생합니다.
- SQS에서 처리완료되지 않은 메시지들을 체계적으로 관리할 DLQ(dead_letter_queue)를 생성해야합니다.
- stock_queue와 DLQ(dead_letter_queue)를 연결합니다.
Legacy 시스템(Factory → Warehouse) 성능문제에 대한 조치
- 안정적으로 이벤트가 전달 될 수 있는 시스템을 구축해야합니다.
- stock_queue 의 메시지를 소비하는 stock_lambda에 의해 Factory API가 호출됩니다.
- Factory의 생산 완료 메시지를 수신한 stock_inc_lambda가 DB에 상품 재고를 증가시킵니다.

[API게이트웨이]클라이언트가 구매버튼을 눌러 통신을 단일진입점인 API게이트웨이로 시작한다.
[Lambda] – 구매 요청(producer)
- API Gateway로 GET 요청을 받은 서버가 데이터베이스에서 재고 상황을 확인 -> [RDS]
- API Gateway로 POST 요청을 받게 되면 재고를 확인
  - 재고가 있다면 감소시키고 응답으로 판매완료 내용을 전달 -> [API게이트웨이]
  - 재고가 없는 경우 공장에 주문을 진행 -> [SNS]
[SNS] : 재고가 없다는 Topic(주제)를 생성 후 메세지를 SQS로 전달
[SQS]
- SNS를 통해 받은 메세지큐를 Lambda가 메시지를 받을 준비가 되면 처리 loose coupling
- 빈번한 요청으로 메시지 누락이 발생되므로 이 메세지들을 관리할 대기열 생성 -> [DLQ]
- DLQ에 누락된 메세지는 주기적으로 SQS 재시도 확인 시도 하고 동일한 메세지가 DLQ로 들어온다면 SNS Topic을 생성하여 운영자에게 메세지로 알린다.
[Lambda] – 공장 주문 (cosumer)
- 함수가 실행되면 공장 API로 이벤트가 전달
- 재고가 창고로 전달되면 재고 증가 프로세스를 진행하여 DB에 상품 재고를 증가시킴

Day 2 – 구매 요청 및 재고 관리 프로세스 구현

메시지 큐의 Pub/Sub 패턴과 Producer/Consumer 패턴의 차이를 이해한다
DB와 서버와의 통신이 가능하도록 연결한다
특정 상황에서 SNS, SQS로 메시지가 전달되도록 시스템을 구성한다
SQS에 들어온 메시지를 레거시 시스템(Factory API)으로 전달하는 시스템을 구성한다
레거시 시스템(Factory API)의 콜백 대상이 되는 리소스를 생성해 데이터베이스에 접근할 수 있게 한다

구매 요청 프로세스 구현

✔ 상품 정보 테이블, 공장 정보 테이블 생성
     DB와 서버 통신이 가능하도록 연결

Create Database

✔ 클라이언트가 접근할 API, 구매요청처리함수 Lambda, 재고요청할 SQS 생성

클라이언트가 요청한 상품의 재고가 존재하는 경우 product 테이블에 stock 컬럼의 number를 요청한 상품의 개수만큼 감소
클라이언트가 요청한 상품의 재고가 존재하지 않는 경우 재고 요청 메세지 큐를 생성하여 SQS로 전달
GitHub Link

💡 여기서 !Ref는 뭐지..?
Reference의 약자 이며 AWS CloudFormation 템플릿에서 사용되는 내장 함수입니다. 이 함수는 리소스나 매개 변수의 값을 참조할 때 사용됩니다.
예를 들어, !Ref SuperTopic는 SuperTopic 리소스의 식별자나 값을 참조합니다. CloudFormation은 이 참조를 통해 해당 리소스에 대한 정보를 가져올 수 있습니다. 따라서 TOPIC_ARN 환경 변수에 SuperTopic의 ARN(Amazon Resource Name)이 할당됩니다.
이러한 방식으로, !Ref 함수를 사용하여 템플릿 내에서 리소스 간에 상호 작용하거나 다른 설정에 값을 전달할 수 있습니다.

🆗배포 후 API Endpoint Get Test

🆗배포 후 API Endpoint POST Test

user01@ubuntu:~$ curl -X POST https://bukg10mi8f.execute-api.ap-northeast-2.amazonaws.com/checkout
{"message":"구매 완료! 남은 재고: 2"}
user01@ubuntu:~$ curl -X GET https://bukg10mi8f.execute-api.ap-northeast-2.amazonaws.com/product/donut
{"product_id":"082f04d0-fac9-11ed-8f43-0e2f76dd43b0","name":"부산도너츠","price":19900,"stock":2,"BIN_TO_UUID(factory_id)":"809d9d64-fac8-11ed-8f43-0e2f76dd43b0","BIN_TO_UUID(ad_id)":"809fc9f0-fac8-11ed-8f43-0e2f76dd43b0"}
user01@ubuntu:~$ curl -X POST https://bukg10mi8f.execute-api.ap-northeast-2.amazonaws.com/checkout
{"message":"구매 완료! 남은 재고: 1"}
user01@ubuntu:~$ curl -X GET https://bukg10mi8f.execute-api.ap-northeast-2.amazonaws.com/product/donut
{"product_id":"082f04d0-fac9-11ed-8f43-0e2f76dd43b0","name":"부산도너츠","price":19900,"stock":1,"BIN_TO_UUID(factory_id)":"809d9d64-fac8-11ed-8f43-0e2f76dd43b0","BIN_TO_UUID(ad_id)":"809fc9f0-fac8-11ed-8f43-0e2f76dd43b0"}

Day 3 재고 관리 시스템 완성

[Day 2 – 구현완료]재고가 없을 경우 SNS로 알림을 받아 SQS로 메세지 큐를 생성시키는 것까지 완료하였습니다.
다음으로 Lambda 함수가 해당 메세지 큐를 전달 받아 정확한 품목을 주문하기 위해 품목속성을 정의한 데이터를 공장으로 전달합니다.
공장에서 해당 품목이 생성되고 창고로 재고가 확보되면 재고 데이터베이스에 재고 수량을 업데이트 합니다.

공장 주문 프로세스 구현

✔ Lambda 생성시 SQS 트리거 추가
     생성한 Lambda는 주문할 품목을 페이로드로 공장으로 전달

GitHub Link

재고 증가 프로세스 구현

✔ 공장에서 재고 생성완료가 되면 API Gateway로 해당 페이로드를 전달 받음
     전달받은 페이로드는 Lambda 서비스가 이어서 처리를 진행
     해당 Lambda 함수는 RDS로 재고 수량을 업데이트

GitHub Link

배포 후 Test

1️⃣[POST] 도넛 요청!

구매자 : 박도넛
품목 : 부산도너츠
수량 : 9개

➡박도넛은 부산도너츠를 9개를 요청을 했다 하지만 재고가 없으므로 공장으로 해당 품목을 주문 요청을 보낸다

2️⃣주문 요청을 받은 다음 필요한 정보만 가공 후 공장으로 전달

📉SQS에서 전달받은 Request body log

3️⃣ 주문 메세지를 받은 공장에서 생산 진행⏳

4️⃣공장은 생산이 완료된 후 재고증가 API로 POST

📉공장에서 받은 Request body log

🆗재고증가 프로세스가 완료 된 후 확인

재고 관리 시스템 외 추가 시나리오

🔠 실제 구현하지는 않았지만 재고 관리 프로세스 완성 후 아래 요구사항이 추가되었다고 생각하고 다이어그램으로만 편집했으며 프로젝트 팀원과 의견을 나누면서 아키텍처를 확장을 해보았습니다.

추가 시나리오 요구 사항

광고 중단 요청 진행

재고가 없는 상황에서도 광고가 계속 진행되고 있습니다. 광고 비용 절감과 고객불만을 낮추기 위한 조치가 필요합니다. 메시지가 유실되는 상황을 막기 위해 내구성을 갖춘 시스템이 필요합니다.

요구사항
- 재고를 채우기 위한 과정이 진행될 때 광고 담당자에게 광고 중단 요청 내용을 담은 이메일이 전송되어야 합니다.
- 메시지에 대한 내구성을 강화하기 위해 메시지 Queue가 사용되어야 합니다.
- AWS SES 서비스를 이용해서 이메일을 전송해야 합니다.

VIP 고객관리 프로세스

모니터링 결과 대량 주문을 하는 일부 고객들이 확인되었습니다. 대량 구매 고객들의 사용자 정보를 식별할 수 있어야 합니다. 고객정보는 별도의 서버(EC2)와 데이터베이스(RDS)에서 관리되고 있습니다. 데이터베이스 기록과 외부 마케팅 시스템으로의 연결과정의 오류를 대비하기 위한 내구성 갖춘 시스템이 필요합니다.

요구사항
- 100개 이상 구매가 발생 시 해당 유저의 타입이 normal에서 Vip로 변경되어야 합니다.
- 메시지에 대한 내구성을 강화하기 위해 메시지 Queue가 사용되어야 합니다.
- 고객관리는 별도의 데이터베이스(RDS)로 관리되고 있기 때문에 해당 데이터베이스에 접근해서 정보를 수정해야 합니다.

추가 시나리오 구성 진행

팀원과 의견을 나누며 진행을 했으며 각 팀원명은 공개적인 노출을 피하기 위해 이니셜로만 작성했습니다.

PCK : 프로세스 별로 그룹화를 하여 가시성을 확보
ORR : 해당 서비스에서 메세지를 보낼때 어떤 리소스를 이용해서 전달되는지 표현하기 위해 리소스 아이콘 추가
OTK(Team Leader) : 프로세스 별로 SQS 서비스를 구분, 광고 중단 프로세스에서 광고 진행 여부를 확인하기 위해 RDS로 연결
KWM : 재고 관리 프로세스에서 고객관리 프로세스로 메세지를 보낼때 어떤 조건인지 명시

광고 중단 프로세스

광고 중단 요청이 SQS를 통해 들어오면 RDS에 재고가 없는지 확인하게 됨
재고가 없을 경우 SES를 통해 담당자에게 이메일을 보냄

고객 관리 프로세스

재고관리 프로세스에 있는 Sales함수에서 100개 이상 구매를 조건으로 SNS로 메세지 전달
고객정보를 관리하는 EC2 서버에 바로 전달하지 않고 VIP고객으로 변경을 보장하기 위해 중간에 SQS를 사용함

Day 4 – 프로젝트 회고

🆗 재고 관리 프로세스를 구성하기 위해 메세지를 전달 받고 가공하고 출력하는 반복의 과정

프로젝트 완료가 다가오면서 AWS 에서 왜 Lambda, SQS, SNS 서비스를 사용했을까 하면서 의문을 품어왔다. 프로젝트 진행하면서 발생된 비용 $0.04… 다시 한번 AWS의 편리함(완전 관리형)과 사용한 것 만큼의 비용(Pay-per-use)에 감탄한게 되었다.
특히 Lambda를 사용하지 않고 EC2를 사용했으면 보다 더 빠른 응답이 구현되었겠지만 불편할정도로 체감이 되지 않았고 이벤트가 발생할때만 실행된다는 점이 무척 매력적인 서비스였던거 같다. 또한 On-premise 환경이었다면 원하는 프로세스 동작이 이뤄지지 않으면 네트워크부터 시작해서 서버까지 관리 포인트 별로 확인을 안해도 된다는것이 너무 좋았다.

SQS와 SNS의 이해 부족

프로젝트를 하기전까지 단순히 메세지를 전달해주는 매개체로만 생각을 하고 그 이상 깊게 학습을 안했던것에 반성하게 되었으며 사용하는 목적과 차이를 짚어보고 만약 이 서비스가 없었다면 어떤걸 이용했을지도 생각해보는 기회가 되었다.

팀원들과의 협업

제일 흥미로웠던건 각 팀원별로 프로젝트를 바라보는 시각과 진행하면서 문제라고 생각하는것들이 다양해지면서 끊임없는 의문이 생겨났다. 문제는 너무 많은 의문이 생겨서 조금 지치기도했지만.. 나는 이것이 별 문제가 아니라고 생각했었지만 다른 팀원은 문제라고 생각하고 같이 고민을 진행을 해서 얻게 되는 경험들이 완료가 되어갈때쯤 큰 도움이 되었다.

프로젝트를 진행하면서 시간에 쫓기듯이 진행하면서 삽질도 많이 했었다. 그래도 이로운 삽질은 언제나 옳다고 하지만 어느정도는 시간관리를 하면서 팀원과의 속도가 차이나는게 아쉬운 부분이었다. 마무리를 하면서 역시 아는만큼 보인다고 프로젝트 진행 전과 후의 리소스(프로젝트를 하면서 사용했던)들을 언제 어디서 사용해야 적합할지 고민하는 계기가 되었다.
마치면서 처음에 잘못따라가서 뒤쳐지고있었는데 도움을 주시고 의견에 귀기울여 주신 팀원분들께 감사드립니다.

프로젝트 개요

프로젝트 시나리오

Day 1 – Tutorial(프로젝트전 사전 학습 및 연습)

사전 학습

Serverless Framework란?

SQS와 SNS 서비스

Tutorial

Create Severless Project (HTTP API)

Deploy Serverless

Create Severless Project (SQS Worker)

Producer-Consumer 패턴의 장점

아키텍처 이미지 예시

DLQ 실습

요구사항 분석 및 초기 다이어그램 작성

프로젝트 요구사항

Day 2 – 구매 요청 및 재고 관리 프로세스 구현

구매 요청 프로세스 구현

Create Database

🆗배포 후 API Endpoint Get Test

🆗배포 후 API Endpoint POST Test

Day 3 재고 관리 시스템 완성

공장 주문 프로세스 구현

재고 증가 프로세스 구현

배포 후 Test

재고 관리 시스템 외 추가 시나리오

추가 시나리오 요구 사항

광고 중단 요청 진행

VIP 고객관리 프로세스

추가 시나리오 구성 진행

광고 중단 프로세스

고객 관리 프로세스

Day 4 – 프로젝트 회고

Leave a Comment 응답 취소