S.H.

뭔가 뭔가 하고 있음. 아마도

Project3 Day1 회고

업데이트:     Updated:

카테고리:

태그:

Day 1

Step 1

Serverless Framework 를 사용 한 AWS Lambda 생성 실습을 진행 하였다.

Serverless 튜토리얼 을 통해 직접 콘솔로 생성 하지 않고 YAML 파일 안에 IAC 코드를 넣는 것 만으로 콘솔에 생성 되도록 진행

AWS 리전 바꾸는 레퍼런스 Serverless.yml 레퍼런스

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

module.exports.hello = async (event) => {
  let inputValue, outputValue
  console.log(event.body)

  if (event.body) {

    let body = JSON.parse(event.body)

    // 추가 도전과제: body가 { input: 숫자 } 가 맞는지 검증하고, 검증에 실패하면 응답코드 400 및 에러 메시지를 반환하는 코드를 넣어봅시다.

    inputValue = parseInt(body.input)
    outputValue = inputValue + 1
  }

  const message = `메시지를 받았습니다. 입력값: ${inputValue}, 결과: ${outputValue}`

  return {
    statusCode: 200,
    body: JSON.stringify(
      {
        message
      },
      null,
      2
    ),
  };
};

이 와 같은 코드를 추가해 cURL 테스트를 진행 하면

1
2
3

$ curl -X POST https://API_GATEWAY_ID.execute-api.ap-northeast-2.amazonaws.com \
--header 'Content-type: application/json' \
--data-raw '{ "input": 1 }'

입력값 +1 의 반환을 확인 하는 실습이었다.

Step 2

메시지큐 및 기본 SQS의 개념에 대해 실습하였다.

Serverless framework의 YAML생성 마법사를 이용하여 메시지 큐(SQS)를 이용한 producer/consumer 구조를 생성/배포.

  1. Serverless CLI를 통한 프로젝트 생성 (AWS - Node.js - SQS Worker)

  2. Serverless.yml 레퍼런스를 참고하여 리전 변경

  3. handler.js 편집 (컨슈머 구현)

    1
2
3
4
5
6
7
8
9
10
11
12

    const consumer = async (event) => {
  for (const record of event.Records) {
    console.log("Message Body: ", record.body);
   
    let inputValue, outputValue
    // TODO: Step 1을 참고하여, +1 를 하는 코드를 넣으세요
   
    const message = `메시지를 받았습니다. 입력값: ${inputValue}, 결과: ${outputValue}`
    console.log(message)
   
  }
};

  4. serverless deploy를 통한 배포

  5. 프로듀서 실행 → CloudWatch를 통해 컨슈머가 메시지를 소비하는 것을 확인

  6. 프로듀서를 여러 번 반복해서 실행

Step 3

DLQ 연결 및 K6를 통한 성능 테스트 방법 실습

DLQ를 연결하고, K6 성능테스트 도구를 사용하여 여러 번의 producer 함수 실행을 보다 전문적으로 테스트할 수 있습니다. DLQ에 쌓이는 메시지의 현황은 AWS 콘솔에서 확인할 수 있습니다.

  1. DLQ의 원리 이해

  2. consumer에 실행 시간을 늘리는 코드 추가 
    1
2
3
4
5
6
7
8
9
10

    function delay(time) {
  return new Promise(resolve => setTimeout(resolve, time));
}
   
const consumer = async (event) => {
  await delay(15000) // 15초 딜레이
  for (const record of event.Records) {
    // 생략
  }
}

  3. serverless deploy를 통한 배포

  4. 프로듀서를 반복적으로 실행 및 테스트 진행

    • k6 성능 테스트 도구 활용

SQS에서의 Visibillity Timeout 조절 하여 DLQ 로 이동 하는 것 확인

  1. Visibility Timeout 조정
  2. 프로듀서에서 메시지 생성 후 DLQ에 도달하는 메시지 확인

요구 사항 Diagram 작성

Project 요구 사항 및 시나리오

  • 구성 요소

1. Sales API

2. Factory API

3. 프론트엔드(웹사이트) : cURL / postman / k6 등을 통한 API 호출로만 구현

  • Sales API를 통해 백엔드에 요청

4. 백엔드(서버) : 구매 시 창고에서 재고 확인 후 재고 감소 로직 구현

  • 재고가 부족할 경우 Factory API를 통해 재고 확보 요청

데이터베이스(창고) : RDS에 mysql db 구성

  • 요청에 따른 재고 상태 변경

  • 시나리오

<도넛-스테이츠>는 온라인으로 도넛을 판매합니다. 웹사이트를 통해서 주문 버튼을 누르는 것으로 구매(Sales API)가 가능합니다. 창고에 재고가 있다면 재고가 감소하고 구매가 완료됩니다. 유튜브스타 hoyong.LEE가 도넛-스테이츠의 도넛이 맛있다고 영상을 올렸습니다. 그를 따르는 데브옵스 수강생들이 몰려듭니다. 주문이 급등합니다. 창고에 재고가 없기 때문에 구매가 불가능한 경우가 발생합니다. 창고의 도넛의 재고가 다 떨어지면 제조 공장에 알려서 다시 창고를 채우는 시스템을 구축해야 합니다. 제조 공장인 <팩토리-스테이츠>에 주문을 요청(Leagcy Factory API)할 수 있습니다. 주문이 요청되면 일정 시간이 지난 후 창고에 재고가 증가합니다.

  • 상황

비효율적인 레거시 시스템 때문에 고객의 불만사항이 접수되고 있습니다. 제품별 재고부족 요청이 빈번하게 발생되고 있지만 전달 과정에서 지연과 누락 등 문제 상황이 발생하고 있습니다. 안정적으로 요청이 전달될 수 있도록 시스템을 개선해야 합니다. 비정상적으로 처리된 요청의 경우 운영팀에 상황을 알려야 합니다.

  • 요구사항

1 : 재고부족으로 인한 구매실패에 대한 조치

  1. Sales API를 통해 요청을 받은 서버가 데이터베이스에서 재고 상황을 확인합니다.
  2. 재고가 있다면 감소시키고 응답으로 판매완료 내용을 전달합니다.
  3. 재고가 없는 경우 공장에 주문을 진행합니다.
  4. 재고가 없다는 내용을 담은 메시지 페이로드가 주제별로 생성됩니다.
  5. 메시지가 느슨하게 연결된 시스템을 통해 처리될 수 있도록 따로 보관됩니다.

2 : 메시지 누락 상황에 대한 조치

  1. 빈번한 요청으로 메시지 누락이 발생합니다.
  2. 메시지가 처리되지 않은 경우 메시지들을 체계적으로 관리할 다른 처리 공간을 생성해야 합니다.
  3. 메시지 처리 보관 리소스와 처리되지 않은 메시지 처리 리소스가 연결되어야 합니다.

3 : Legacy 시스템(Factory → Warehouse) 성능문제에 대한 조치

  1. 안정적으로 이벤트가 전달될 수 있는 시스템을 구축해야 합니다.
  2. 메시지를 소비하는 리소스를 통해 Factory API가 호출됩니다.
  3. Factory의 생산 완료 메시지를 수신한 컴퓨팅 리소스가 상품 재고를 증가시킵니다.

#다음 베이스 이미지를 참고하여 다이어 그램 완성 하기

QHVr-EEklfGYUX092fCBp-1674805158216

팀원들과 회의 끝에 다음과 같은 다이어 그램이 완성 되었다.

img

  1. 구매자가 서버로 구매 요청을 보냈으나 재고 부족 상황.
  2. 람다가 트리거 되어 SNS로 주제 생성.
  3. SQS에서 큐로 메시지 유실되지 않도록 처리 (메시지 발송 실패 하면 DLQ처리 후 재 발송)
  4. 다시 람다로 SQS트리거되어 Factory API GATEWAY로 HTTP 요청 전송
  5. 공장 서버에서 람다로 연결되어 DB에 재고 증감.

하지만 API 서버 역시 람다가 같은 기능을 할 수 있어서 다이어 그램을 다음과 같이 수정 하였다.

img

Project 카테고리 내 다른 글 보러가기 🤠

댓글남기기