AWS DynamoDB & SQS(FIFO)를 활용한 대규모 트래픽 분산 처리 전략
📚 목차
프로젝트 개요
사내 물류 시스템의 독립 서비스 분리로 인해 기존 시스템과의 데이터 통합이 필수 과제로 떠올랐습니다. 특히 WMS에서 발생하는 수불 데이터는 초당 최대 4만 건의 트래픽을 기록하며 순간적인 트래픽 급증 문제를 야기했습니다. 이 글에서는 AWS 환경에서 이러한 문제를 효율적으로 처리하기 위해 적용한 분산 이벤트 처리 전략을 다룹니다. AWS의 DynamoDB, EventBridge, FIFO SQS를 활용해 데이터 처리 효율을 최적화하고 안정성을 확보한 아키텍처 구성 및 구체적인 구현 방법을 제시합니다.
문제 정의 및 기술 선택
사내 물류시스템(WMS)이 독립 서비스로 분리되면서 기존 기간계 시스템과 데이터 통합 작업이 필요했다. 특히 WMS에서 발생하는 수불 데이터가 짧은 순간 초당 최대 4만 건 이상의 트래픽이 집중되는 문제가 있었다.
- WMS: 창고의 물류 흐름을 관리하는 시스템
- 수불: 창고 내 상품의 입고, 출고 등 재고 변동 내역
이러한 대규모 트래픽의 실시간 처리는 DB 및 네트워크 과부하로 서비스 지연이나 중단이 발생할 수 있어 다음 요구사항을 만족하는 시스템 구성이 필요했다.
- 일시적으로 집중된 트래픽을 저장 후 분산 처리
- 데이터 처리 순서 보장
- 트래픽 증가에도 대응 가능한 안정적 확장성
범용적으로 Kafka나 Redis 등을 고려할 수 있지만 AWS 환경에서 빠른 구축과 비용 효율성을 위해 DynamoDB, EventBridge, FIFO SQS 조합을 선택했다.
전체 아키텍처 구성
DynamoDB (데이터 저장 및 분산)
↓
EventBridge (스케줄러, 데이터 조회 및 SQS 전송)
↓
FIFO SQS (순서 보장된 분산 메시징)
↓
서비스 처리 (실패 건은 S3 로깅)
세부 구현 방법
DynamoDB를 통한 데이터 분산 저장
초당 4만 건 이상의 데이터 발생 환경에서 DynamoDB를 선택한 이유:
- 온디맨드 확장성: 유연한 확장 가능
- 관리형 서비스: 관리 오버헤드 최소화
- 저지연: 실시간 저장에 적합
하지만 DynamoDB는 데이터 분산 전략이 중요하다. 특히 핫 파티션 현상은 특정 파티션에 트래픽 집중으로 쓰로틀링이 발생한다.
📌 핫 파티션이란?
DynamoDB 내부에서 데이터가 특정 파티션에 집중될 때 발생하는 병목 현상
이를 방지하기 위해 다음과 같은 버킷 방식을 적용했다.
- 파티션키: 날짜(
yyyy-MM-dd) + 버킷 번호 - 정렬키: EpochMilli(밀리초 단위 타임스탬프)
이를 통해 데이터가 균등 분산되어 쓰로틀링 문제를 해결했다.
EventBridge를 활용한 주기적 스케줄링
데이터 처리를 위해 AWS EventBridge를 선택했다. 관리가 간편하고 설정이 쉽다.
역할 및 설정:
- 5분 주기로 이벤트 서버 호출 → DynamoDB 데이터 조회
- 조회 데이터를 FIFO SQS로 전송하여 순차 처리 구성
FIFO SQS를 이용한 순차적이고 안정적인 메시지 처리
수불 데이터의 순서를 보장하기 위해 FIFO SQS를 활용했다.
📌 FIFO SQS 주요 특징:
- 메시지 순서 보장: 메시지 그룹 ID 내 순서 보장
- 중복 처리 방지: 중복 메시지 처리 방지
- 높은 처리량 모드: 서울 리전 초당 최대 2,400 TPS
FIFO 큐는 동일 메시지 그룹 ID 내에서만 메시지 순서를 보장하며, 그룹이 다른 메시지는 병렬로 처리할 수 있다. 순차 적용 할 수불(트랜잭션)에 대해 동일 그룹 ID로 지정하면, 데이터 순서를 유지하면서도 높은 처리량을 안정적으로 확보할 수 있다.
S3를 통한 실패 데이터 로깅 및 관리
처리되지 않은 데이터는 별도 관리가 필요하다.
구현 방법:
- 실패 데이터를 JSON 형태로 S3에 저장
- CloudWatch와 Slack 알림을 통해 즉시 인지 가능
이를 통해 데이터 유실 방지 및 원인 추적이 용이하다.
추가적으로 고려 가능한 대안 (카프카 등)
대안으로 Apache Kafka와 FIFO SQS를 비교했다.
| 기술 | Kafka | FIFO SQS |
|---|---|---|
| 장점 | 초고속 처리 성능, 다양한 처리 기능 제공 | 관리 간편, 쉬운 확장성, 순서 보장 |
| 단점 | 초기 구축 비용 및 운영 관리 복잡 | 높은 트래픽에서 비용 발생 |
Kafka는 초대규모 데이터와 초저지연 처리에 적합하나, 운영 관리와 비용이 높다. AWS 환경에서는 FIFO SQS가 효과적인 선택이다.
마무리
본 글에서는 AWS 기반에서 대규모 트래픽을 효율적으로 소화하기 위한 분산 이벤트 전략을 소개했습니다. DynamoDB, EventBridge, FIFO SQS를 활용해 안정적이고 확장 가능한 아키텍처를 설계했으며, 대규모 트래픽 처리에 참고가 되길 바랍니다. 운영을 통해 얻은 인사이트는 지속 공유할 예정입니다.
Reference
https://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/high-throughput-fifo.html
https://aws.amazon.com/ko/blogs/database/choosing-the-right-dynamodb-partition-key/?nc1=h_ls
https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/bp-partition-key-sharding.html
👍