Post

[DevBid - 실시간통신] AWS EC2 Redis 환경에서 Pub/Sub와 분산락 검증

[DevBid - 실시간통신] AWS EC2 Redis 환경에서 Pub/Sub와 분산락 검증

📚 실시간 경매 시스템 구축기 시리즈

  1. WebSocket으로 실시간 경매 구현하기
  2. WebSocket 메시지 동기화 문제와 Redis 선택
  3. Redis 분산락과 Pub/Sub으로 멀티서버 동시성 제어
  4. Redis 도입 후 마주한 문제와 해결
  5. 멀티서버 환경에서 Pub/Sub와 분산락 검증 ← 현재 글

들어가며

앞선 글에서 로컬 환경에 Redis를 설치하고 기본 동작을 확인해봤습니다. 이제 실제 배포 환경을 위해 AWS EC2에 Redis를 구축하고, 멀티서버 환경에서 Pub/Sub와 분산락이 제대로 동작하는지 테스트해보겠습니다.

1. AWS EC2 Redis 서버 구축

EC2 인스턴스 생성

AWS 콘솔에서 EC2 서비스로 이동한 후 “인스턴스 시작” 버튼을 클릭합니다.

image.png

이름 및 AMI 선택

운영체제는 프리티어인 Amazon Linux 2023 (kernel-6.1)을 선택했습니다.

image.png

인스턴스 유형 선택

프리티어로 사용 가능한 t3.micro를 선택합니다.

image.png

키 페어 생성

image.png

새 키 페어를 생성하면 .pem 파일이 자동으로 다운로드 됩니다.

이 파일은 나중에 SSH 접속 시 필요하기 때문에 잘 보관합니다.

네트워크 설정

image.png

보안 그룹에서 SSH(22번 포트)와 Redis(6379번 포트) 접속을 허용해야 합니다.

소스는 0.0.0.0/0으로 설정했는데, 이는 어디서든 접속 가능하다는 의미입니다.

  • 장점: 집, 카페, 회사 등 어디서든 접속 가능
  • 단점: 보안상 누구나 접속 시도 가능 (Redis 비밀번호 설정 필수!)

스토리지 구성

기본값으로 설정하고 인스턴스를 시작합니다.

인스턴스 실행 확인

image.png

“내 인스턴스 보기”를 클릭하고, 상태가 “실행 중”으로 표시되면 준비 완료입니다.

2. SSH 접속 및 Docker 설치

SSH 접속

CMD 또는 터미널에서 다운로드한 키 파일이 있는 위치로 이동한 후 접속합니다.

1
ssh -i "C:\Users\%USERNAME%\Desktop\devbid-redis-key.pem" ec2-user@EC2 퍼블릭 IP

image.png

비둘기 나오면 접속 성공

Docker 설치

1
2
sudo yum update -y
sudo yum install docker -y

Docker 시작 및 자동 실행 설정

1
2
sudo systemctl start docker
sudo systemctl enable docker

ec2-user를 docker 그룹에 추가

1
sudo usermod -aG docker ec2-user

이제 sudo 없이도 Docker 명령어를 사용할 수 있습니다. 변경사항을 적용하기 위해 재접속합니다.

1
2
exit
ssh -i "C:\Users\%USERNAME%\Desktop\devbid-redis-key.pem" ec2-user@EC2 퍼블릭 IP

Docker 버전 확인

1
docker --version

image.png

버전이 정상적으로 출력되면 설치 완료입니다.

3. Redis 컨테이너 실행

Redis 이미지 다운로드 및 실행

1
2
3
4
docker run --name redis -d \
          -p 6379:6379 \
          --restart unless-stopped \
          redis:7-alpine redis-server --requirepass 내비밀번호

옵션 설명:

  • --name redis: 컨테이너 이름
  • -d: 백그라운드 실행
  • -p 6379:6379: 포트 매핑
  • --restart unless-stopped: 서버 재시작 시 자동 실행
  • --requirepass: Redis 비밀번호 설정 (보안을 위해 반드시 설정!)

컨테이너 실행 확인

1
docker ps

STATUS가 “Up”으로 표시되면 정상 실행 중입니다.

Redis CLI 접속

1
docker exec -it redis redis-cli

PING-PONG 테스트

Redis CLI에 접속한 후 AUTH 명령어로 인증하고, PING 명령어를 입력합니다.

1
2
AUTH 내비밀번호
PING

image.png

PONG 응답이 오면 Redis가 정상적으로 동작하는 것입니다!

4. Spring Boot 연동

application.yml 설정

1
2
3
4
5
6
7
8
9
10
11
12
13
server:
  port: ${SERVER_PORT:3000}

spring:
  data:
    redis:
      host: ${REDIS_HOST} # EC2 퍼블릭 IP
      port: 6379
      password: 설정한비밀번호
  session:
    store-type: redis
    redis:
      namespace: devbid:session

Redis 이벤트 확인

Spring Boot 애플리케이션을 실행하고, Redis CLI에서 실시간으로 이벤트를 모니터링해봅시다.

1
2
3
docker exec -it redis redis-cli
AUTH 내비밀번호
MONITOR

image.png

애플리케이션에서 Redis를 사용할 때마다 명령어가 실시간으로 출력 됩니다.

3. 멀티서버 환경 테스트

이제 본격적으로 Redis의 핵심 기능들을 테스트해보겠습니다.

테스트 환경 구성

멀티서버 환경을 시뮬레이션하기 위해 IntelliJ에서 Run Configuration을 2개 추가했습니다.

image.png

3개의 서버를 다른 포트로 실행합니다:

3.2 Pub/Sub 동작 확인

브라우저 3개 탭 열기

각 서버에 접속합니다:

Redis CLI에서 채널 확인

1
2
PUBSUB CHANNELS
PUBSUB NUMSUB [auction.events](http://auction.events)

image.png

구독자 수가 3으로 표시됩니다. 3개의 서버가 모두 Redis의 같은 채널을 구독하고 있다는 의미입니다!

실시간 메시지 브로드캐스트 테스트

image.png

redis test.gif

한 서버에서 입찰하면 Redis Pub/Sub을 통해 모든 서버로 메시지가 전달되고, 3개 브라우저 모두 실시간으로 업데이트됩니다!

분산락 동시성 테스트

여러 서버에서 동시에 입찰이 들어왔을 때, 분산락이 제대로 동작해서 데이터 정합성을 보장하는지 확인해보겠습니다.

JMeter 테스트 시나리오

테스트 설정:

  • 총 사용자 수: 90명 (각 서버당 30명)
  • 서버 구성: 3개 (3000, 8080, 8081 포트)
  • 입찰 금액: 랜덤 (1,000,000~5,000,000 원)
  • 동시 요청: 90개

테스트 1: 대량 동시 요청 순차 처리 확인

image.png

image.png

결과:

90명이 랜덤 금액(100만~500만원)으로 동시 입찰했지만, Redisson 분산락이 모든 요청을 순차적으로 처리했습니다.

  • 입찰가는 항상 이전 입찰가보다 높은 금액만 허용되어 정확히 증가
  • 3개 서버에서 발생한 입찰 이벤트가 Redis Pub/Sub을 통해 실시간으로 모든 클라이언트에게 전달
  • 데이터 정합성 100% 보장 (중복 입찰 0건)

테스트 2: 동일 금액 중복 입찰 방지 확인

image.png 테스트 시나리오:

90명의 사용자가 모두 동일한 금액(5,000,000원)으로 동시 입찰

결과:

Redisson 분산락이 90개의 동시 요청을 순차적으로 처리:

  • 성공한 입찰: 1건 (최초로 락을 획득한 사용자만)
  • 실패한 입찰: 89건 (현재가와 동일한 금액으로 비즈니스 로직에 의해 거부)

같은 금액으로 동시에 입찰하더라도 단 1명만 입찰에 성공하며, 나머지는 정상적으로 거부됩니다. 이는 분산 환경에서도 데이터 정합성이 완벽하게 보장된다는 것을 의미합니다.

마치며

AWS EC2에 Redis를 구축하고, 실제 분산 환경에서 Pub/Sub와 분산락이 어떻게 동작하는지 확인했습니다.

특히 분산락 테스트를 통해 여러 서버에서 동시에 요청이 들어와도 데이터 정합성이 보장된다는 것을 확인할 수 있었습니다. 이는 실시간 경매 시스템에서 매우 중요한 부분입니다.

향후 개선 방향

현재는 Redis Pub/Sub으로 입찰 성공 시 변경된 경매 정보를 멀티서버 간 동기화하고 있습니다. 향후 서비스 확장 시 다음과 같은 구조를 고려하고 있습니다:

  • Redis Pub/Sub: 실시간 경매 데이터 동기화 (현재)
    • 입찰 성공 시 현재가, 입찰자 등 즉각 반영
    • 낮은 지연시간이 중요한 실시간 상태 전파
  • Kafka 추가 도입: 채팅, 알림 등 영속성이 필요한 메시지
    • 실시간 채팅 메시지 처리
    • 입찰 알림, 낙찰 알림 등 메시지 전달 보장
    • 이벤트 소싱, 사용자 행동 분석 등

각 메시징 시스템의 특성에 맞게 용도를 분리하여, 실시간성과 안정성을 모두 확보하는 것이 목표입니다.

This post is licensed under CC BY 4.0 by the author.