196. (TWOK/LOGIC) [Aws] AWS SQS 서비스를 활용한 Server To Server 서버 간 이벤트 처리 로직 정리 - Simple Queue Service

---

[로직 정리]

​

정리 로직 : AWS / SQS / Simple Queue Service

​

제 목 : [Aws] AWS SQS 서비스를 활용한 Server To Server 서버 간 이벤트 처리 로직 정리 - Simple Queue Service

​

 

---

[설 명]

​

// --------------------------------------------------------------------------------------
[사전) 설정 및 정보 확인 사항]
// --------------------------------------------------------------------------------------

1. 제 목 : [Aws] AWS SQS 서비스를 활용한 Server To Server 서버 간 이벤트 처리 로직 정리 - Simple Queue Service


2. 테스트 환경 : AWS / SQS / Server


3. 사전) 👉 SQS 간략 설명 : 

  >> Aws SQS 란 서버들끼리 주고 받을 수 있는 메세지 큐를 제공하는 AWS 서비스 입니다

  >> Aws SQS 는 특정 플랫폼 서비스 확장 시 각 기능들을 여러 서버에서 처리하게 되면서, 서버들끼리 주고 받는 메세지를 잃어버리지 않고 정확하게 처리하는 데 도움을 주는 서비스입니다

  >> Aws SQS 는 시스템이 처리 해야할 일을 나중에 처리하거나, 다른 시스템이 처리할 수 있도록 하기 위한 비동기 메세징을 지원합니다

  >> Aws SQS 기본 개념 및 속성 용어 설명 : 

    - 메세지 : SQS 의 기본 데이터 단위 / XML, JSON과 같은 텍스트 형태이며 최대 64KB 까지 보낼 수 있음 / 메세지마다 고유한 ID가 부여 됨

    - 큐 (Queue) : 메세지를 담는 공간 / 리전 별로 생성 필요 / 자료형의 큐와 이름이 같지만, 선입선출(FIFO)을 보장 하지 않음

    - 배치 API : 한 번에 메세지를 최대 10개 혹은 최대 256KB까지 동시 처리 가능

    - 보기 제한 시간 (Visibility Timeout) : 메세지를 받은 뒤 특정 시간 동안 다른 곳에서 동일한 메세지를 다시 꺼내볼 수 없음 / 큐 하나에 여러 서버가 메세지를 받을 때 동일한 메세지를 동시에 처리하는 것을 방지 함

    - 지연 전송 (Delay Delivery) : 특정 시간 동안 메세지를 받지 못하게 한다

    - 처리 실패 큐 (Dead Letter Queues) : 메세지를 받고 작업이 처리되면 메세지를 삭제 하지만, 설정한 횟수를 초과하여 메세지를 받았는데 삭제되지 않고 남아있다면 처리 실패 큐로 보내진다

    - 짧은 폴링 (Short Polling) : 메세지 받기 요청을 하면 결과를 즉시 받을 수 있음

    - 긴 폴링 (Long Polling) : 메세지가 있으면 바로 가져오고, 메세지가 없으면 메세지가 올 때까지 기다림 / 기본 제한시간은 20초이며, 1초부터 최대 20초까지 설정할 수 있음

// --------------------------------------------------------------------------------------






// --------------------------------------------------------------------------------------
[로직 설명]
// --------------------------------------------------------------------------------------

----------------------------------------------------------------------
✅ [API 서버가 서로 분리 되어 있는 구조]
----------------------------------------------------------------------
👉 [해당 구조 장점]
----------------------------------------------------------------------

- 서비스 완전 분리 : A ←→ B 직접 연결 없음 , 오직 SQS로만 연결

- 장애 격리 : B 죽어도 메시지 유지됨 , 나중에 재처리 가능

- 확장성 : Lambda 자동 스케일 , 트래픽 폭주 대응

- B 서버 보호 : 요청 속도 조절 가능 , burst 완충 (큐 역할)

----------------------------------------------------------------------
👉 [해당 구조 사용 시 고려 사항]
----------------------------------------------------------------------

- B 서버 idempotency : SQS는 중복 메시지 가능 →  B 서버에서 반드시 중복 처리 방지 로직 필요 (eventId 기준 처리 여부 체크)

- 재시도 전략 : Lambda → API 호출 실패 시 자동 재시도 발생 , 동일 요청 반복 가능

- 타임아웃 설정 : Lambda → API 호출 timeout 너무 길면 backlog 쌓임

- DLQ 설정 : SQS → Lambda 실패 반복 → DLQ

- Rate limit (중요🔥) : Lambda가 너무 빠르게 호출하면 → B 서버 터짐 (Batch size 조정 , concurrency 제한)

----------------------------------------------------------------------

1. 🟦 간략 구조 : [A] API Server → SQS → Lambda (Consumer) → [B] API Server → DB


2. A 서버 : 

  >> 이벤트 발생

  >> SQS에 메시지 넣기


3. SQS : 

  >> 이벤트 저장

  >> 비동기 연결

  >> 람다 함수 자동 트리거 동작 설정


4. Lambda (중요 포인트)

  >> SQS 메시지 받기

  >> B 서버 API 호출 (람다 내에서 직접 호출을 할 수 있지만, API Gateway 를 통해서 호출 가능)

  >> 소스 코드 예시 : 

    export const handler = async (event) => {
      for (const record of event.Records) { // SQS 👉 메시지 꺼내기
        const data = JSON.parse(record.body);

        await fetch("https://b-server/api/process", {
          method: "POST",
          headers: {
            "Content-Type": "application/json"
          },
          body: JSON.stringify(data)
        });
      }
    };


5. B 서버 : 

  >> 핵심 비즈니스 로직

  >> DB 처리

  >> 트랜잭션 관리





----------------------------------------------------------------------
✅ [API 서버가 같은 경우 Lambda 에서 직접 처리 구조]
----------------------------------------------------------------------
👉 [해당 구조 장점]
----------------------------------------------------------------------

- 서버 없음 (완전 serverless)

- 자동 확장

- 구현 간단

- 비용 효율

----------------------------------------------------------------------
👉 [해당 구조 사용 시 고려 사항]
----------------------------------------------------------------------

- 복잡하거나, API 서버가 분리 된 경우에는 해당 로직이 부적합 : 

  $ B 서버처럼 별도 도메인/서비스가 존재할 때
  $ 비즈니스 로직이 중앙화돼야 할 때
  $ API 기반 시스템일 때

- 해당 로직이 적합한 경우 정리 : 

  $ 단순 이벤트 처리
  $ DB insert/update
  $ 로그 처리
  $ 알림/메일
  $ 이미지 처리

----------------------------------------------------------------------

1. 🟦 간략 구조 : [A] API Server → SQS → Lambda (Consumer) → DB


2. A 서버 : 

  >> 이벤트 발생

  >> SQS에 메시지 넣기


3. SQS : 

  >> 이벤트 저장

  >> 비동기 연결

  >> 람다 함수 자동 트리거 동작 설정


4. Lambda (중요 포인트)

  >> SQS 메시지 받기

  >> DB 에 데이터 저장

  >> 성공 시 메시지 삭제

  >> 소스 코드 예시 : 
  
    export const handler = async (event) => {
      for (const record of event.Records) { // SQS 👉 메시지 꺼내기
        const data = JSON.parse(record.body);

        // DB 저장 로직
        await db.insert(data);
      }
    };





----------------------------------------------------------------------
✅ 로직 사용 간 중요 공통 사항 정리
----------------------------------------------------------------------
1. Lambda 실행 성공 및 실패 시 정리 : 

  👉 Lambda 가 “정상적으로 끝나야” SQS 메시지가 삭제됩니다 / 수동으로 delete 할 필요 없습니다 (자동 처리됨)

  >> Lambda 정상 종료 → SQS 메시지 자동 삭제 ✅

  >> 에러 발생 → 메시지 삭제 안됨 ❌ → 다시 재시도 ✅

  >> 여러 번 실패하면 → DLQ 이동 (설정 시)

  👉 “부분 성공” 문제 : 10개 메시지 중 5개 성공 / 5개 실패

    - 기본 설정이면 : ❌ 전체 실패로 간주 → 메시지 전체 다시 처리

    - Partial batch response (중요) : Lambda 에서 실패한 메시지만 재처리 가능

      return {
        batchItemFailures: [
          { itemIdentifier: "failed-message-id" }
        ]
      };

    - 람다에서 예외를 삼키면 안 됨 ❌ : 내부에서 에러 발생 시 try catch 로 감싼 경우 → Lambda는 "성공"으로 판단 → 메시지 삭제됨

    - 람다에서 예외를 반드시 던져야함 : 반드시 이렇게 throw e; 실패 처리 제대로 해야 함


2. 응답 결과를 확인하고 싶은 경우 정리 : 

  >> SQS 는 비동기 메시지 큐로 응답 (Response) 을 주지 않습니다 (A → SQS → (언젠가 처리됨) → Lambda → DB)

    - 특징 : ✅ “처리 요청만 던지고 끝”

      $ 즉시 처리 보장 ❌
      $ 결과 반환 ❌
      $ 상태 모름 ❌

  >> 응답 확인이 필요한 경우 로직 정리 : 

      ------------------------------------
      A → SQS → Lambda → DB
                          ↑
                      A가 폴링 조회
      ------------------------------------
      A → SQS → Lambda → DB
                 ↓
              A 서버 API 호출
      ------------------------------------

// --------------------------------------------------------------------------------------






// --------------------------------------------------------------------------------------
[참고 사이트]
// --------------------------------------------------------------------------------------

▶️ [AWS 사이트 SQS 설명]

https://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html


▶️ [Aws SQS Message Queue] SQS (Simple Queue Service) 심플 큐 서비스 개념 및 설명 정리

https://kkh0977.tistory.com/7620

https://blog.naver.com/kkh0977/223733090215?trackingCode=blog_bloghome_searchlist


▶️ [Aws SQS Message Queue] SQS 에서 Queue 큐에 메시지 전송 및 Lambda 트리거 함수 등록 Receive 응답 처리 정리

https://kkh0977.tistory.com/8144

https://blog.naver.com/kkh0977/223934877161?trackingCode=blog_bloghome_searchlist

// --------------------------------------------------------------------------------------

 

---

[참고 사이트]

​

https://kkh0977.tistory.com/7620

18. (Aws/Amazon) [Aws SQS Message Queue] SQS (Simple Queue Service) 심플 큐 서비스 개념 및 설명 정리

---