온프레미스 모놀리식에서 확장 가능한 AWS 아키텍처로: 티켓 판매 사례 연구
Source: Dev.to
문제 설명
다음 시나리오를 상상해 보세요: 물리 서버(온프레미스)에 존재하는 티켓‑판매 애플리케이션.
현재 이 애플리케이션은 Node.js 로 작성된 모놀리식이며, 동일 서버에 호스팅된 MySQL 데이터베이스에 영속성을 저장하고, 정적 파일(예: 이벤트 포스터)을 로컬 하드 드라이브에 직접 저장합니다.
이 아키텍처는 유명 아티스트의 티켓이 판매될 때 다음과 같은 치명적인 문제에 직면합니다:
- 트래픽 급증으로 서버가 다운되고,
- 데이터베이스가 잠기며,
- 이미지 로딩이 매우 느려집니다.
이러한 근본적인 문제를 해결하기 위해 애플리케이션을 AWS 로 마이그레이션하기로 결정했습니다. 여기서부터는 다음과 같은 기능적 요구사항을 기반으로 아키텍처를 설계합니다:
| 요구사항 | 설명 |
|---|---|
| 고가용성 (HA) | 서버나 가용 영역이 실패하더라도 애플리케이션이 중단 없이 계속 운영되어야 합니다. |
| 확장성 | 시스템은 사용자 부하를 처리하고 주요 이벤트 시 트래픽 급증을 수요에 따라 흡수할 수 있어야 합니다. |
| 지속성 | 트랜잭션 무결성이 중요하며, 판매가 하나라도 손실될 수 없습니다. |
| 보안 | 데이터베이스는 공개 인터넷 접근으로부터 보호되고 격리되어야 합니다. |
도전 과제
- Compute – 애플리케이션을 어디서 실행하고 트래픽을 어떻게 관리할까요?
- Database – MySQL에 어떤 서비스를 사용할 것이며 시스템을 포화시키지 않으면서 읽기를 어떻게 최적화할까요?
- Static Storage – 포스터 이미지를 어떻게 제공하여 빠른 로딩을 보장할까요?
- Network & Security – 데이터를 보호하면서 사용자가 웹에 접근할 수 있도록 네트워크(VPC)를 어떻게 구성할까요?
아키텍처 제안
Compute
EC2 인스턴스를 Auto Scaling Group으로 관리하면서 애플리케이션을 실행합니다.
Application Load Balancer (ALB) 가 앞에 배치되어 서로 다른 가용 영역 (AZ) 에 퍼져 있는 인스턴스들에 요청을 분산시켜 고가용성을 보장합니다.
Database
관리형 서비스 Amazon RDS for MySQL 을 사용합니다.
성능 최적화를 위해 두 가지 전략을 평가합니다:
- Read Replicas – 읽기‑중심 워크로드 확장을 위해.
- Amazon ElastiCache – 자주 조회되는 쿼리를 캐시하여 기본 DB 부하를 감소시킴.
(테스트 후 최적의 옵션을 결정합니다.)
Static Content
포스터 이미지를 Amazon S3 버킷으로 이전하고, Amazon CloudFront (CDN)를 통해 제공하여 전 세계적으로 콘텐츠를 캐시하고 로드 시간을 크게 단축합니다.
Network & Security
VPC 내에 3계층 아키텍처를 구현합니다:
| Tier | Placement | Purpose |
|---|---|---|
| 로드 밸런서 | Public subnet | 인터넷 트래픽 진입점 |
| 애플리케이션 서버 | Private subnet | Node.js 앱 실행 |
| 데이터베이스 | Private subnet | RDS 인스턴스 호스팅 |
Security Groups 를 사용해 계층 간 트래픽을 엄격히 제한합니다 (예: 로드 밸런서만 애플리케이션 서버에 접근 가능하고, 애플리케이션 서버만 데이터베이스에 접근 가능).
Source: …
심층 분석: 분산 시스템 과제
위의 아키텍처는 인프라 요구 사항을 충족하지만, 모놀리식에서 분산 환경으로 전환하면 두 가지 중요한 논리적 문제가 드러납니다.
1. 사용자 세션
원래 애플리케이션은 세션을 서버의 RAM에 저장했습니다. 새로운 아키텍처에서는 Auto Scaling + Load Balancer 조합으로 인해 요청이 세션을 만든 인스턴스와 다른 인스턴스로 라우팅될 수 있어, 사용자가 예기치 않게 로그아웃되는 현상이 발생합니다.
어떻게 해결할까요?
애플리케이션을 무상태(stateless) 로 전환합니다. 세션을 로컬에 저장하는 대신 Amazon ElastiCache(Redis 또는 Memcached)로 외부화합니다. 인‑메모리 데이터 스토어인 ElastiCache는 서브밀리초 수준의 지연 시간을 제공하며, 사용자의 요청이 다른 인스턴스로 전달되더라도 세션이 중앙에서 이용 가능하도록 보장합니다.
2. 데이터 일관성 (경합 조건)
여기서는 Read Replicas와 ElastiCache 사용에 대한 논의를 다시 살펴봅니다.
사용자 A가 티켓을 구매합니다.
몇 밀리초 후, 사용자 B가 같은 좌석을 확인합니다. Read Replicas를 사용하면 복제 지연(replication lag) 때문에 사용자 A의 구매가 모든 복제본에 반영되기까지 약간의 시간이 소요됩니다. 이로 인해 사용자 B가 이미 판매된 좌석을 다시 구매하려 시도하게 되어 오류가 발생하거나, 더 나아가 초과 예약(over‑booking)이 일어날 수 있습니다.
데이터베이스를 과부하 시키지 않으면서 즉시 가용성을 어떻게 보장할까요?
가장 이상적인 해결책은 ElastiCache (Redis) 입니다. 앞서 언급한 지연 때문에 Read Replicas는 실시간 재고 관리에 적합하지 않습니다. 대신 Redis는 원자성(atomicity) 을 활용할 수 있습니다. Redis는 연산을 순차적으로 처리하므로, 동일 좌석에 대한 여러 구매 요청이 동시에 들어오면 Redis가 이를 큐에 넣어 하나씩 처리하고 첫 번째 트랜잭션만 성공하도록 합니다. 이렇게 하면 경합 조건을 해결하고 프라이머리 데이터베이스에 대한 읽기 트래픽을 크게 감소시킬 수 있습니다.
결론
온‑프레미스 environment에서 클라우드로 마이그레이션하는 것은 단순히 서버를 옮기는 것(Lift & Shift)만이 아니라, 애플리케이션이 상태와 동시성을 처리하는 방식을 재고하는 것입니다.
**Amazon ElastiCache (Redis)**를 우리 아키텍처에 통합함으로써 읽기 속도만 향상된 것이 아니라, 분산 시스템에서 가장 복잡한 문제 두 가지를 해결했습니다:
- 무상태 애플리케이션에서 Session management.
- 경쟁 조건에서 Data integrity.
이 아키텍처를 통해 유명 아티스트의 수요에 무너지는 서버에서, 수요에 따라 자동으로 확장 가능한 탄력적이고 견고한 인프라로 전환했습니다.