이 글은 삼성전자의 기술블로그(Samsung Tech Blog)에 기재된 원문 [https://techblog.samsung.com/blog/article/53]을 인용하여 작성 하였습니다. 대 규모 서비스에서 AWS의 다중 리전과 Route 53을 활용한 Active-Active DR 구성사례를 AWS 한국 기술 블로그를 통해 게시되도록 지원해 주신 삼성전자 이정현 프로님에게 감사의 말씀을 드립니다.
1. 삼성 계정 서비스 소개
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/08/img01.jpg]
[그림1. 삼성 계정 소개]
글로벌 계정 서비스인 삼성 계정
삼성 계정은 전 세계 256개국에서 60여 개의 서비스와 앱을 하나로 이어주며 18억 명 이상의 사용자를 둔 글로벌 계정 서비스입니다. 여러분이 잘 알고 계시는 Samsung Pay, SmartThings, Samsung Health 같은 삼성전자 서비스에 사용될 뿐만 아니라 Mobile, Wearable, TV, PC 등 다양한 기기에서 계정 서비스로 활용되고 있습니다.
“삼성의 모든 것을 삼성 계정 하나로 시작하세요”라는 말처럼 삼성 계정은 삼성 유니버스를 하나로 묶어 18억 사용자에게 제공하는 삼성의 코어 서비스입니다.
이렇듯 삼성 계정은 삼성의 모든 기기와 서비스를 연결하는 비즈니스 크리티컬 시스템이므로 높은 수준의 RTO(Recovery Time Objective)를 갖고 있습니다. 따라서 기존에 구축한 AZ(Availability Zone) 단위의 장애조치 아키텍처를 넘어 글로벌 서비스로서 이따금 발생하는 클라우드 사업자의 리전 단위 장애도 극복 가능한 아키텍처가 필요했기에 글로벌 리전 장애조치 아키텍처를 새롭게 구축했습니다.
2. 글로벌 리전 장애조치 아키텍처
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/08/img02.jpg]
[그림2. 글로벌 Active-Active 아키텍처로의 고도화]
글로벌 ACTIVE-ACTIVE 아키텍처
리전 단위 장애까지 극복 가능한 높은 수준의 DR(Disaster Recovery)을 위해 삼성 계정에서는 여러 차례 대대적으로 아키텍처를 개선하고 기존 문제점을 해결해야 했습니다. 우선, 기존 EU와 US 2개 리전에 이어서 신규로 AP리전을 구축했습니다. 당시 이미 2개의 리전은 대용량 트래픽을 처리하며 클라우드 인프라의 한계에 달하는 리소스를 사용하고 있었습니다. 이런 상황에서 한 리전 전체에 장애가 발생할 경우 나머지 리전에서 두 리전의 트래픽을 모두 처리하기에는 역부족이었습니다. 이를 해소하기 위해 트래픽을 분산 처리할 수 있는 AP리전의 신규 구축을 작년에 완료했습니다.
삼성 계정의 또 한 가지 문제점은 70여 개의 마이크로서비스가 서로 다른 리전에 분산 배포되어 각 리전의 서비스 형상이 맞지 않는 것이었습니다. 즉, A기능을 수행하는 마이크로서비스가 EU리전에만 존재하여 US리전에서는 A기능을 직접 제공하지 못하고 EU리전을 통해 제공해야만 했습니다. 이 문제를 해결하기 위해 삼성 계정에서는 AP리전 구축 시 각 리전에 분산되어 있는 마이크로서비스들을 모든 리전에 구축하는 형상 일치화 작업을 진행했습니다. 이 작업을 통해 단일 리전에서 모든 서비스와 기능을 제공할 수 있는 100% 커버리지를 가진 아키텍처로 새롭게 구성했습니다.
마지막으로, 글로벌 3개 리전의 필수 데이터 동기화 아키텍처를 구축했습니다. PostgreSQL의 경우 자체 개발한 동기화 파이프라인과 MSK 기반 동기화 아키텍처를 구축했고, DynamoDB의 경우 동기화에 Global Table을 사용했습니다.
이처럼 신규 AP 리전 구축, 모든 리전의 서비스 형상 일치화, 데이터 동기화를 바탕으로 하나의 서비스를 각 리전에서 개별적으로 수행할 수 있는 Active-Active 아키텍처로 고도화했습니다. 즉, 특정 리전에 장애가 발생해도 다른 두 리전에서 트래픽을 바로 수용할 수 있는 구조로 개선했습니다.
트래픽 전환 제어
그런 다음, 개선된 Active-Active 구조에서 장애 트래픽을 다른 리전으로 어떻게 전환할지 고민했습니다. 첫째로 검토한 방안은 글로벌 로드 밸런서 기반의 트래픽 전환입니다. 개별 리전에 종속되지 않는 글로벌 로드 밸런서를 구축하고, 리전 장애 발생 시 이 로드 밸런서에서 정상 리전으로 트래픽을 전환하는 방식입니다. 이 방법은 즉각적인 트래픽 전환을 통해 RTO 수준을 아주 짧게 가져갈 수 있다는 장점이 있습니다. 하지만 대용량 트래픽을 처리하기에는 큰 비용이 들고, 10년 이상의 삼성 계정 개발 기간 동안 시스템이 복잡해지며 수많은 Endpoint를 가진 구조가 되어 글로벌 로드 밸런서를 적용해야 할 Endpoint가 너무 많았습니다.
장애 발생 시 빠른 트래픽 전환도 중요하지만 비용 부담을 줄이고 복구 작업을 단순화해야 했기에 저희는 DNS 기반의 트래픽 전환 방식을 선택했습니다. DNS 기반의 장애 트래픽 전환 방식은 AWS의 Route53을 활용하여, 리전 단위 장애 발생 시 서비스 도메인의 Endpoint를 정상 리전의 Endpoint 정보로 변경해 Client의 접근 경로를 변경하는 방식입니다.
그런데 DNS 기반으로 장애 트래픽 제어 아키텍처를 만드는 과정에서 한 가지 큰 문제를 알게 됐습니다. Route53은 DNS Record의 추가와 변경을 처리하는 Control plane이 US리전에만 구축되어 있어 US리전이나 Control plane에 장애가 발생할 경우 원하는 대로 DNS Record를 추가하거나 변경할 수 없으며 Data plane의 사전 정의된 기능만 동작 가능하다는 것입니다.
Route53의 Control plane이 동작하지 않는다면 장애 시나리오에서 트래픽 전환이 필요해도 DNS Record를 변경하지 못하여 장애 트래픽 전환 제어가 불가능하므로 리전 장애를 복구할 수 없게 됩니다.
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/08/img03.jpg]
[그림3. 리전 단위 장애 복구 방식]
리전 단위 장애 복구 방식
다행히 이러한 Control plane 문제를 해결할 수 있는 솔루션이 있습니다. 바로 Route 53 Application Recovery Controller(ARC)입니다. Route53 ARC는 Control plane에 장애가 발생하더라도 Data plane에 미리 준비한 Primary와 Standby 라우팅 제어 세트가 Health Check를 통해 장애 감지 시 트래픽을 제어할 수 있는 기능을 제공합니다
이때 장애 복구는 셀 단위로 이루어집니다. 여기서 셀이란 서비스의 독립적인 장애조치 단위를 포함하는 Silo를 의미합니다. 삼성 계정은 리전 단위의 장애를 복구할 수 있도록 셀을 리전으로 구성했고, 각 리전은 독립적인 서비스가 가능한 Active-Active 형태로 구축했습니다. 결과적으로 삼성 계정은 Route53 ARC의 고가용성 기능을 활용하여 리전 단위의 장애조치 아키텍처를 확보할 수 있게 되었습니다.
3. 운영환경 모의 장애 훈련
모의 장애 훈련 계획
운영환경에서 모의 장애 훈련을 실시하기에 앞서, 검증환경에서 글로벌 장애조치 아키텍처의 기능을 점검하는 기능 검증과 장애 복구 트래픽의 부하를 점검하는 부하 검증으로 사전 검증을 진행했습니다.
기능 검증에서는 전체 2% 수준의 트래픽 전환으로 기능을 점검했습니다. 삼성 계정에는 내부 URL이 많이 있어 트래픽 전환 간에 문제가 발생할 수 있는데, 기능 검증 과정에서 누락된 URL 설정을 미리 확인하고 조치할 수 있었습니다.
부하 검증은 전체 10%와 50% 두 단계로 나누어 수행했습니다. 서비스와 EKS, DB를 포함한 전 영역의 부하 검증을 수행했고, 이 과정에서 인증 토큰 재발급 트래픽과 리전 간 호출 급증 등 아키텍처 개선이 필요한 부분을 추가로 확인하고 빠르게 개선했습니다. 이런 절차를 거친 후 실제 운영환경에서 모의 장애 훈련을 진행했습니다.
1차 모의 장애 훈련
많은 사전 작업과 테스트를 통해 마침내 1차 모의 장애 훈련을 진행했습니다. 5분 내에 90%의 주요 트래픽이 전환되었고, 시스템이나 사용자 VOC(Voice of Customer) 없이 성공적으로 훈련을 완료했으나 개선해야 할 부분이 있었습니다.
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/08/img04.jpg]
[그림4. MTTR 10분 이상]
먼저, 예상했던 일부 잔여 트래픽이 10분 이상 존재하는 것을 확인했습니다. 위의 그래프에서 붉게 색칠된 롱테일 영역이 바로 잔여 트래픽입니다. 이 잔여 트래픽은 클라이언트 영역의 DNS cache가 장애조치 전 서버의 IP를 캐싱하고 있기 때문에 발생한 것입니다.
삼성 계정의 RTO는 장애조치를 통해 5분 내에 99%의 트래픽을 정상 처리해내는 것입니다. 1차 훈련에서 약 90% 수준의 주요 트래픽이 5분 내 전환에 성공했지만 99%라는 복구 목표에는 도달하지 못해 MTTR(Mean Time To Recovery)이 10분 이상 소요됐습니다.
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/08/img05.jpg]
[그림5. 사용자 네트워크 분석]
또한 잔여 트래픽을 분석한 결과, 사용자 영역의 네트워크 경험을 개선해야 한다는 것을 확인했습니다. 일반적으로 네트워크의 응답 시간은 도메인 주소를 질의하여 대상 서버의 IP로 변환되는 과정과 대상 서버와의 TCP 연결, SSL 연결, 마지막으로 서버 처리 후 데이터가 클라이언트에 전송되는 과정으로 구성됩니다.
글로벌 서비스인 삼성 계정은 전 세계에 걸쳐 요청이 들어오지만 실제 처리는 글로벌 3개 리전에서 수행하다 보니 모든 사용자의 네트워크 연결이 빠르진 않았습니다. 저희 분석 결과로는 TCP 연결과 안전한 통신을 위한 TLS handshake 과정에서 특히 많은 시간이 소요 됐습니다.
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/08/img06.jpg]
[그림6. 잔여 트래픽 처리]
아키텍처 개선
이러한 문제를 어떤 방식으로 해결했는지 이야기해보겠습니다.
먼저 잔여 트래픽 문제의 경우, 주요 원인은 클라이언트의 DNS cache 처리 문제입니다. Client의 OS나 네트워크 구성에는 DNS에서 수신된 TTL(Time To Live)을 재정의하는 자체 캐싱 메커니즘이 있을 수 있습니다. 그래서 저희가 1분의 TTL을 갖는 서비스 도메인을 US리전에서 AP리전으로 장애조치하여 서비스 도메인의 IP를 변경하고 응답해도 일부 클라이언트에서는 10분이 넘어도 갱신하지 못할 수 있습니다.
저희는 이 문제를 AWS의 CloudFront로 해결했습니다. CloudFront의 본질은 CDN 서비스입니다. 그 특성으로 600개 이상의 edge location이 전 세계에 걸쳐 존재하고 세계 각지에 있는 사용자가 자신의 위치에서 가장 빠른 edge location에 연결됩니다. 이때 사용자는 삼성 계정 서버의 IP가 아닌 최적화되어 연결된 edge location의 IP를 캐싱하게 되어 삼성 계정 서버의 IP가 변경되어도 client cache 문제가 발생하지 않습니다.
또한 사용자 환경의 네트워크 경험 문제도 해결해야 했습니다. 보통 인터넷 산업에서 사용자와 실제 서버 사이를 크게 First mile, Middle mile, Last mile이라는 3가지 세그먼트로 나눕니다. 이 중 가장 문제가 되는 구간은 바로 Middle mile입니다. 이 구간은 ISP가 관리하는 이른바 인터넷 영역입니다. 가장 방대하고 거리가 긴 영역으로 곳곳에 수많은 네트워크 장비가 있고 많은 네트워크 오류가 존재하며 잘못된 라우팅이 발생하기도 합니다.
이 문제 역시 CDN으로 해결했습니다. 모든 요청이 혼잡한 Middle mile을 통과하지 않고, 사용자 위치에 가까운 edge location에 연결되어 네트워크 connection overhead가 현저히 감소합니다. 또한 CDN 사업자의 전용 백본망으로 통신하기 때문에 Middle mile을 public 망으로 통과해 origin 서버에 연결되는 것보다 훨씬 속도가 빠릅니다.
이처럼 삼성 계정은 CloudFront를 솔루션으로 사용해 잔여 트래픽과 사용자 네트워크 경험 문제를 모두 해결했습니다.
2차 모의 장애 훈련
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/08/img07.jpg]
[그림7. MTTR 3분 이내]
기존 서비스 아키텍처의 최상단에 CloudFront를 적용하는 개선 작업을 진행한 뒤 다시 한 번 운영환경에서 무중단으로 2차 훈련을 진행했습니다. 결과는 성공이었습니다. 기존 1차 훈련에서 나타났던 롱테일 현상이 사라지고 3분 내에 99% 이상의 트래픽이 전환되었습니다.
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/08/img08.jpg]
[그림8. 네트워크 연결 속도 개선]
또한 사용자의 네트워크 환경도 크게 개선되었습니다. CloudFront 적용 효과로 사용자의 연결이 가장 가까이 있는 edge location에서 종료되어 연결 설정에 필요한 전체 왕복 시간이 현저히 감소했으며, 이 밖에도 CloudFront의 Origin에 대한 지속적인 TCP 연결 등으로 전체 네트워크 연결 속도가 65% 이상 개선되었습니다.
마치며
1년 넘게 이 아키텍처를 설계하고 구축하는 과정에서 처음 계획한 대로 순조롭게 진행된 부분은 거의 없었습니다. 늘 새로운 문제가 나타나 문제 해결을 위해 기존 계획을 변경하고 더 나은 대안을 찾는 과정을 수도 없이 반복한 끝에 비로소 좋은 결과를 얻을 수 있었습니다. 지금까지 그래왔듯이 더욱 신뢰할 수 있는 안전한 삼성 계정을 만들기 위해 앞으로도 끊임없이 노력하겠습니다.
감사합니다.
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/08/author_jh_Lee.jpg] 이정현, 삼성전자
이정현님은 그 동안 통신과 커머스 업계에서 플랫폼 개발과 DevOps로 많은 프로젝트를 수행했습니다. 현재는 삼성전자 Big Data센터에서 삼성 계정의 클라우드 인프라를 담당하는 DevOps 엔지니어로 근무하고 있으며, 더욱 안전하고 튼튼한 삼성 계정 인프라를 만들기 위한 다양한 노력을 하고 있습니다.