UNiDAYS 아키텍처 분석

클라우드 인프라를 운영하다 보면 언젠가 반드시 마주치는 고민이 있다. 우리 서비스가 지금 이 서버 하나로 전 세계 유저를 다 감당할 수 있을까? 처음에는 단일 리전으로도 충분하다. 하지만 사용자가 늘고 특히 서버와 지리적으로 먼 나라의 유저들이 늘어나기 시작하면 이야기가 달라진다. 응답이 느려지고 특정 리전 장애가 곧 전체 서비스 다운으로 이어지는 구조적 취약점이 드러난다.

이번 글에서는 이 문제를 단 3주 만에 해결한 실제 사례를 분석한다. 영국의 에듀테크 플랫폼 UNiDAYS가 AWS 위에서 멀티 리전 Active-Active 아키텍처를 구축한 과정이다.

 

UNiDAYS

UNiDAYS는 영국에 본사를 둔 학생 전용 혜택 플랫폼이다.

학생 신분을 인증한 회원에게 나이키, 애플, 아디다스 같은 글로벌 브랜드의 독점 할인 혜택을 제공하는 서비스이다.

• 전 세계 2900만 명 이상의 인증된 학생 회원 보유
• 수백 개의 글로벌 브랜드 파트너십
• 영국, 미국, 호주, 유럽, 아시아 등 전 세계 서비스

플랫폼의 핵심 가치는 신뢰성이다.

학생들이 할인 혜택을 받으러 들어왔는데 페이지가 느리거나 서비스가 다운되면 그 순간 브랜드와의 파트너십 기회를 날리는 것과 다름없다.

따라서 낮은 응답 지연 (Low Latency)과 높은 가용성 (High Availability)은 비즈니스의 생존 조건과 직결된다.

 

문제의 시작

지리적 확장이 불러온 레이턴시 문제

UNiDAYS는 빠른 성장세를 타며 글로벌 파트너십을 늘려갔다.

그런데 서비스가 넓어질수록 한 가지 문제가 드러났다.

서버는 특정 지역에 고정되어 있는데 사용자는 전 세계에 분산되어 있다는 것이다.

물리적으로 서버와 멀리 떨어진 지역의 사용자들은 데이터가 대륙을 가로질러 왕복하는 시간만큼 기다려야 한다.

이 글에서 소개되는 사례에서는 실제로 약 200ms의 응답 지연이 측정됐다.

0.2초처럼 짧아 보이지만 웹 서비스에서 이 숫자는 사용자 이탈률과 직결되는 임계점이다.

Google의 연구에 따르면 페이지 로딩 시간이 1초에서 3초로 늘어나면 이탈률이 32% 증가한다.

B2C 서비스에서 레이턴시는 단순한 기술 지표가 아니라 비즈니스 숫자이다.

 

단일 리전 가용성 리스크

단일 리전 구조의 또 다른 문제는 단일 장애점(Single Point of Failure)이다.
AWS 리전은 매우 안정적이지만 완벽하지는 않다.

과거에도 특정 AWS 리전 장애로 수많은 서비스가 동시에 다운된 사례가 있었다.

단일 리전에 모든 것을 집중한 구조에서는 리전 장애 = 서비스 전체 다운을 의미한다.
글로벌 파트너사들이 늘어날수록 이 리스크는 더욱 커졌다.

파트너 브랜드 입장에서 서비스 다운은 곧 신뢰의 문제이다.

 

몇 주 안에 해결하래..

비즈니스 요구사항은 냉정했다.

글로벌 확장을 위한 인프라 개선을 빠른 시일 내에 완료해야 했다.

기술팀 입장에서 현실적인 선택지는 두 가지였다.

Option A. 기존 모놀리식 애플리케이션 전체를 멀티 리전에 최적화되도록 재설계한다.
Option B. 기존 시스템은 건드리지 않고 멀티 리전 요구사항을 충족하는 보완 서비스를 새로 만들어 연동한다.

Option A는 근본적인 해결책이지만 몇 달이 걸리는 대공사다. 주어진 시간 안에 불가능했다.

UNiDAYS는Option B를 선택했다. 그리고 그것이 3주가 걸렸다.

 

UNiDAYS의 접근법의 핵심은 기존 시스템을 유지하면서 그 위에 새로운 멀티 리전 서비스 레이어를 덧붙인다 는 것이다.
기존 모놀리식 애플리케이션은 그대로 살려두되 글로벌 성능이 필요한 부분만 새로운 마이크로서비스로 만들어 연동했다.

이 전략은 두 가지 이점을 동시에 가져다준다.

첫째 속도이다. 기존 코드를 건드리지 않으니 테스트와 배포 범위가 줄어든다. 새 서비스만 검증하면 된다.
둘째 안정성이다. 검증된 기존 시스템을 그대로 유지하면서 새 기능을 붙이니 전면 재개발에 따른 리그레션 위험이 없다.

기존 시스템과의 연동은 Amazon EventBridge를 활용한 이벤트 기반(Event-Driven) 비동기 방식으로 처리했다.

두시스템이 직접 호출하지 않고 이벤트 버스를 통해 느슨하게 연결되니 서로 독립적으로 발전할 수 있다.

 

아키텍처의 핵심 AWS 서비스 선택과 이유

아키텍처 분석 전에 어떤 서비스를 왜 선택했는지 간략하게 먼저 이해해본다.

서비스	선택 이유
Amazon CloudFront	전 세계 엣지에서 컨텐츠 전달, 레이턴시 최소화
Amazon Route 53	지연 기반 라우팅으로 최적 리전 자동 선택
AWS WAF	애플리케이션 레이어 공격 엣지에서 차단
Amazon ALB	리전 내 Multi-AZ 트래픽 분산
Amazon ECS	컨테이너 오케스트레이션, 인프라 관리 부담 제거
Amazon ECR	컨테이너 이미지 저장 및 리전 간 복제
Amazon DynamoDB Global Tables	멀티 리전 자동 복제, 글로벌 데이터 일관성
Amazon EventBridge	레거시 시스템과의 느슨한 비동기 연동
AWS KMS Multi-Region Key	리전 간 공유되는 암호화 키 관리
VPC Endpoint (PrivateLink)	AWS 서비스 접근 시 인터넷 우회 제거
Terraform + CloudFormation	인프라 코드화, 리전 확장 자동화

 

아키텍처 분석

Layer 1. 글로벌 엣지: CloudFront + AWS WAF

모든 사용자 요청은 가장 먼저 Amazon CloudFront에 도달한다.

CloudFront는 전 세계 400개 이상의 엣지 로케이션을 운영하며 사용자와 물리적으로 가장 가까운 지점에서 요청을 처리한다.

CloudFront의 역할은 크게 세 가지이다.
1. 캐싱을 통한 레이턴시 감소
정적 콘텐츠(이미지, CSS, JS 등)는 엣지에 캐싱되어 오리진 서버까지 요청이 도달하지 않아도 된다.

캐시 히트율이 높을수록 사용자는 더 빠른 응답을 받고 오리진 서버의 부하는 줄어든다.

2. Shared Secret 헤더 삽입
CloudFront는 오리진(ALB)으로 요청을 전달할 때 사전에 정의된 커스텀 Shared Secret 헤더를 자동으로 요청에 추가한다.

ALB는 이 헤더가 없는 요청을 즉시 거부한다.

이 메커니즘 덕분에 해커가 CloudFront를 우회해 ALB IP로 직접 공격을 시도해도 차단된다.

즉 모든 정상 트래픽은 반드시 CloudFront를 통과해야 한다는 규칙이 강제된다.

3. DDoS 완화
대규모 DDoS 공격 발생 시 트래픽이 수백 개의 엣지 로케이션으로 분산되어 흡수된다.

오리진 서버가 직접 공격에 노출되지 않는다.

AWS WAF는 CloudFront에 직접 통합된다. 요청이 오리진 서버로 가기 전 엣지에서 이미 보안 검사가 이루어진다.

• SQL Injection 패턴 차단
• XSS 차단
• AWS Managed Rules로 최신 위협 자동 반영
• Rate Limiting으로 비정상적인 대량 요청 차단

WAF까지 통과한 요청만 다음 단계로 넘어간다.

 

Layer 2. 글로벌 라우팅: Amazon Route 53

WAF를 통과한 요청은 Amazon Route 53이 받아 어느 리전으로 보낼지 결정한다.
여기서 핵심은 Latency-Based Routing(지연 기반 라우팅)이다.

Route 53은 각 리전의 ALB와 주기적으로 응답 시간을 측정하고 있다.

새 요청이 들어오면 요청자의 IP 위치를 기반으로 현재 시점에서 레이턴시가 가장 낮은 리전의 ALB로 요청을 전달한다.

예를 들어 이런 방식이다.

• 미국 동부 사용자 -> us-east-1 ALB
• 유럽 사용자 -> eu-west-1 ALB
• 한국 사용자 -> ap-northeast-1 ALB

자동 장애 복구도 Route 53이 담당한다.

각 ALB에 대한 Health Check를 주기적으로 수행하다가 특정 리전의 Health Check가 연속으로 실패하면 해당 리전으로의 라우팅을 자동으로 중단하고 정상 리전으로 트래픽을 전환한다.

사람이 개입하지 않아도 자동으로 리전 페일오버가 이루어진다.

 

Layer 3. 리전별 수신: Application Load Balancer

Route 53이 선택한 리전에는 Application Load Balancer(ALB)가 있다.

이 아키텍처는 Active-Active 구성이므로 모든 활성화된 리전에 각각 독립적인 ALB가 존재하며 두 ALB 모두 실시간으로 트래픽을 처리한다.

ALB는 다음 역할을 수행한다.

1. 보안 검증

• 보안 그룹(Security Group)에 CloudFront Prefix List를 적용해 CloudFront IP 대역에서 온 트래픽만 수신한다.
• CloudFront가 삽입한 Shared Secret 헤더를 ALB 리스너 규칙에서 검증한다. 헤더가 없거나 값이 다르면 요청을 즉
  시 거부하고 403을 반환한다.
• HTTPS(TLS 1.2 이상)만 허용하며 ACM 인증서로 암호화한다.

2. 트래픽 분산

• VPC 내부의 여러 AZ에 걸쳐 배포된 ECS 컨테이너들로 트래픽을 균등하게 분산한다.
• 각 컨테이너의 Health Check를 수행해 비정상 컨테이너로는 트래픽을 보내지 않는다.

 

Layer 4. 컴퓨팅 레이어: ECS + Spot Instance (Multi-AZ)

ALB가 트래픽을 넘기는 곳은 Amazon ECS 클러스터이다.
각 리전의 VPC 안에는 3개의 Availability Zone에 걸쳐 ECS 서비스가 배포되어 있다.

리전 VPC
AZ-a: ECS Service + Spot Instance
AZ-b: ECS Service + Spot Instance
AZ-c: ECS Service + Spot Instance

ECS를 선택한 이유
Kubernetes(EKS) 대신 ECS를 선택한 것은 운영 단순성 때문이다.

ECS는 컨테이너 오케스트레이션의 복잡한 부분을 AWS가 관리해주기 때문에 작은 팀이 단기간에 멀티 리전을 구축하기에 적합하다.

개발팀은 컨테이너 이미지를 만들어 배포하는 것에만 집중할 수 있다.

Spot Instance를 선택한 이유
온디맨드 대비 최대 90% 저렴한 Spot Instance를 활용해 비용을 크게 절감했다.

ECS는 Spot Instance가 중단되더라도 자동으로 새 인스턴스를 시작하고 컨테이너를 재배치하기 때문에 Spot의 불안정성을 서비스 수준에서 흡수한다.

Multi-AZ 배치의 의미
3개 AZ에 분산된 덕분에 하나의 데이터센터에 화재, 정전, 네트워크 장애가 발생해도 나머지 2개 AZ가 서비스를 이어받는다.

이게 리전 내 고가용성의 기반이다.

 

Layer 5. 내부 통신: VPC Endpoint (AWS PrivateLink)

ECS 컨테이너가 DynamoDB나 S3에 접근할 때는 VPC Endpoint를 통한다.
일반적으로 VPC 내부에서 AWS 관리형 서비스에 접근하려면 인터넷 게이트웨이를 통해 퍼블릭 인터넷을 거쳐야 한다.

그럼 세 가지 문제가 발생한다.

1. 인터넷을 경유하므로 보안 위험 존재
2. 데이터 전송 거리가 늘어나 레이턴시 증가
3. 인터넷 데이터 전송 비용 발생

 

VPC Endpoint(AWS PrivateLink)를 사용하면 트래픽이 AWS 내부 사설 네트워크만을 통해 DynamoDB, S3에 도달한다.

인터넷을 전혀 경유하지 않는다.

보안, 성능, 비용 세 가지를 동시에 개선하는 설계 포인트이다.

이 아키텍처에서는 두 개의 VPC Endpoint가 각 리전에 존재한다.
• ECS -> DynamoDB용 VPC Endpoint
• ECS -> S3용 VPC Endpoint

 

Layer 6. 데이터 레이어: DynamoDB Global Tables + Cross-Region Replication

DynamoDB Global Tables는 여러 리전에 걸쳐 동일한 테이블을 자동으로 복제하는 기능이다.

구조는 다음과 같다.
us-east-1 DynamoDB <- 자동 양방향 CRR -> eu-west-1 DynamoDB

Active-Active 복제
양쪽 리전 모두 읽기와 쓰기가 가능하다. 어느 리전에서 데이터를 변경해도 AWS가 자동으로 다른 리전에 복제한다.
단일 리전에만 쓰기가 허용되는 Active-Passive와는 다르다.

Eventual Consistency (최종적 일관성)
복제는 보통 1초 이내에 완료된다. 극단적으로 짧은 시간 내에 같은 데이터를 두 리전에서 동시에 수정하는 충돌이 발생하면 "Last Writer Wins" 방식으로 처리된다.

대부분의 유스케이스에서는 이것으로 충분하다.

Last Writers Wins는 쉽게 말해 가장 마지막에 쓴 사람(가장 최신 타임스탬프를 가진 데이터)이 이긴다는 뜻이다.

리전 장애 대응
us-east-1이 다운되어도 eu-west-1의 DynamoDB에는 이미 최신 데이터가 복제되어 있다. 데이터 손실 없이 다른 리전에서 즉시 서비스를 이어갈 수 있다.

개발팀 집중
DynamoDB가 복제, 일관성, 가용성을 모두 관리해주기 때문에 개발팀은 데이터 동기화 로직을 직접 구현할 필요가 없다. 비즈니스 로직에만 집중할 수 있다.

 

Layer 7. 컨테이너 이미지 관리: Amazon ECR + Private Image Replication

발생한 문제
멀티 리전 배포 초기 테스트에서 예상치 못한 문제가 발생했다.

eu-west-1 ECS가 컨테이너를 시작할 때 us-east-1의 ECR에서 이미지를 다운로드해야 했는데 리전 간 네트워크를 거치는 탓에 컨테이너 시작 지연이 심하게 발생했다.

빠른 Auto Scaling이 필요한 상황에서 새 컨테이너를 띄울 때마다 대용량 이미지를 원격 리전에서 다운받아야 한다면 확장 속도 자체가 걸림돌이 된다.

해결책: ECR Private Image Replication
Amazon ECR의 프라이빗 이미지 복제 기능을 활성화했다.

개발팀이 us-east-1 ECR에 이미지 push -> ECR CRR이 eu-west-1 ECR로 자동 복제 -> eu-west-1 ECS는 로컬 ECR에서 바로 pull

이미지가 이미 각 리전의 ECR에 존재하므로 컨테이너 시작 시 원격 다운로드가 필요 없어진다. 시작 시간이 획기적으로 단축됐다.

 

Layer 8. 암호화: AWS KMS Multi-Region Key

다이어그램에서 두 리전 중앙에 KMS Multi-Region Key 구조가 표현된다.

us-east-1 KMS (Primary Key) --복제--> eu-west-1 KMS (Replica Key)

Multi-Region Key의 장점
일반적으로 리전 A의 KMS 키로 암호화된 데이터를 리전 B에서 복호화하려면 별도의 키를 생성하고 재암호화 과정을 거쳐야 한다. Multi-Region Key는 양쪽 리전이 동일한 키 ID와 키 소재를 공유한다.

덕분에 DynamoDB Global Tables가 리전 간 데이터를 복제할 때 재암호화 없이 원활하게 처리된다. KMS의 Key Rotation, 접근 제어, 사용 감사 로그도 중앙에서 통합 관리된다.

 

Layer 9. 기존 시스템 연동: Amazon EventBridge

EventBridge는 이 아키텍처에는 보이지 않지만 중요한 역할을 한다.

기존 모놀리식 시스템과 새 멀티 리전 서비스 사이의 연결 다리이.

새 멀티 리전 서비스 -> EventBridge -> 기존 모놀리식 시스템
기존 모놀리식 시스템 -> EventBridge -> 새 멀티 리전 서비스

이벤트 기반 비동기 통신의 장점은 느슨한 결합이다.

두 시스템이 서로를 직접 호출하지 않으므로 한쪽이 다운되어도 다른 쪽은 영향을 받지 않는다. 또한 두 시스템이 서로 독립적으로 발전할 수 있다.

 

Layer 10. laC 배포 전략: Terraform + CloudFormation 3계층 구조

3주라는 짧은 시간 안에 멀티 리전 구축이 가능했던 비결 중 하나가 바로 laC(Infrastructure as Code) 계층화 전략이다.

모든 인프라를 코드로 정의했으며 이 코드를 3개의 계층으로 분리했다.

계층	내용	배포 방식
Platform	공통 기반 인프라, 네트워크, IAM	1회만 배포
Global	CloudFront, Route 53, WAF 등 전역 리소스	1회만 배포
Regional	ALB, ECS, DynamoDB, ECR 등 리전별 리소스	리전마다 반복 적용

새 리전을 추가할 때는 Regional 계층 코드만 새 리전에 다시 실행하면 된다.

마치 프로그래밍에서 함수를 재사용하듯 이미 검증된 인프라 코드를 새 리전에 그대로 찍어내는 방식이다.

발생한 기술적 장벽: CloudFormation 크로스 리전 익스포트
CloudFormation의 스택 익스포트(Export)는 설계상 같은 리전 안에서만 참조할 수 있다.

예를 들어 us-east-1에서 생성한 리소스의 ARN을 eu-west-1의 CloudFormation 스택에서 참조하는 것이 기본적으로 불가능하다.

해결책: 팀은 커스텀 CloudFormation 매크로를 직접 개발했다. 이 매크로는 다른 리전의 CloudFormation 익스포트 값을 읽어오는 기능을 제공한다. 덕분에 리전 간 리소스 참조가 필요한 배포도 자동화할 수 있었다.

 

전체 트래픽 흐름 분석

지금까지 설명한 모든 레이어가 실제로 어떻게 연결되어 동작하는지 사용자의 요청이 시스템을 통과하는 전체 과정을 따라가 본다.

1. 사용자(예: 유럽 학생)가 브라우저에서 unidays.com 접속

 

2. DNS 조회 -> Amazon Route 53
   Route 53이 eu-west-1 ALB의 레이턴시가 가장 낮음을 확인 -> eu-west-1 방향으로 라우팅 결정

 

3. 요청이 가장 가까운 CloudFront 엣지 로케이션에 도달 (예: 런던 엣지)

 

4. AWS WAF 검사

악성 패턴 감지 시 -> 즉시 차단 (403/429)

정상 요청 -> 통과

 

5. CloudFront 캐시 확인

Cache hit -> 엣지에서 바로 응답 반환 (오리진 도달 안 함)

Cache miss -> 오리진(eu-west-1 ALB)으로 전달 + Shared Secret 헤더 자동 삽입

 

6. eu-west-1 ALB 수신

Shared Secret 헤더 검증: 헤더 불일치/부재 -> 요청 거부

CloudFront Prefix List 확인: 비허가 IP -> 요청 차단

검증 통과 -> AZ에 분산된 ECS 컨테이너로 전달

7. ECS 컨테이너(Spot Instance)가 비즈니스 로직 처리 -> 인증, 할인 코드 조회 등 애플리케이션 로직 실행

8. 데이터 필요 시 VPC Endpoint 통해 DynamoDB 접근 (인터넷 경유 없음) -> eu-west-1 DynamoDB에서 데이터 읽기/쓰기

9. DynamoDB 쓰기가 발생한 경우 -> Global Table 설정에 의해 us-east-1으로 자동 복제 (Global Table Replication).

10. 응답이 역순으로 ECS -> ALB -> CloudFront -> 사용자에게 전달 

 

리전 장애 시나리오

1. us-east-1 ALB/ECS 장애 발생

2. Route 53 Health Check 실패 연속 감지

3. Route 53이 us-east-1으로의 라우팅 자동 중단

4. 미국 사용자 트래픽도 eu-west-1 ALB로 리다이렉트

5. eu-west-1 DynamoDB에 이미 최신 데이터 복제 완료 상태

6. 서비스 중단 없이 eu-west-1에서 전체 트래픽 처리

참고자료:

https://aws.amazon.com/ko/blogs/architecture/how-unidays-achieved-aws-region-expansion-in-3-weeks
Replicate DynamoDB Across Regions - Amazon DynamoDB Global Tables - AWS

Latency-based routing - Amazon Route 53

Private image replication in Amazon ECR - Amazon ECR