무중단 클라우드 인프라 업그레이드, 그 비결은?
김제민
삼성전자 빅데이터센터
삼성의 모든 서비스와 온/오프라인 스토어까지 삼성 유니버스를 하나로 묶어주는 글로벌 계정 서비스인 삼성계정은 대규모 트래픽을 안전하게 안정적으로 처리하고 있습니다. 삼성의 중심 서비스로서 삼성계정에 대한 모든 작업은 일반적인 서비스 배포부터 클라우드 인프라 업그레이드까지 무중단으로 진행되어야 합니다. 이러한 요구사항 속에서 특히 이번 Elastic Kubernetes Service 업그레이드를 위해 설계한 아키텍처를 소개하고 경험을 공유합니다.
삼성계정이란?
삼성계정은 17억 이상 사용자 계정을 기반으로 256개국에서 60여 개의 서비스와 앱을 하나로 이어주는 계정 서비스입니다. Samsung Pay, SmartThings, Samsung Health 등 삼성전자 서비스에 사용될 뿐만 아니라 Mobile, Wearable, TV, PC 등 다양한 기기에서 인증 서비스로도 활용됩니다. 온라인 스토어(samsung.com)와 오프라인 매장부터 customer service까지 다양한 고객 접점에서 하나의 계정으로 안전하고 안정적인 고객 경험을 제공하고 있습니다.
발전을 거듭하며 구축된 현재 삼성계정 아키텍처
사용자 계정 수와 연동 서비스가 많아지면서 삼성계정의 인프라와 서비스도 함께 변화를 거듭해 나갔습니다. 2019년에는 서비스 안정성 및 효율화를 위해 AWS 기반의 Cloud 전환이 이루어졌으며, 현재 Global 3 Region(EU, US, AP)과 China Region을 포함한 총 4개 Region에서 서비스를 제공하고 있습니다.
현재 70개 이상의 Microservice들로 구성된 삼성계정은 2022년에 MSA(Micro-Service Architecture)를 안정적으로 지원하기 위해 Kubernetes 기반으로 전환했습니다. Kubernetes는 컨테이너화된 애플리케이션을 자동으로 간편하게 배포, 확장, 관리할 수 있도록 지원하는 오픈소스 오케스트레이션 플랫폼이죠. 2023년에는 Global Region Failover를 제공할 수 있도록 DR(Disaster Recovery)을 강화하고 사용자 경험을 개선하고자 AP Region을 확장했습니다.
이처럼 삼성계정은 인프라와 서비스를 발전시켜 나가며 현재 2.7M requests per second (RPS) 이상의 트래픽과 200K transactions per second (TPS) 이상의 DB 트랜잭션 속에서도 안정적으로 운영되고 있습니다.
AWS를 기반으로 하는 삼성계정의 각 Region은 개별 virtual private cloud (VPC)를 가지고 device, server to server, web을 통해 접근할 수 있습니다. 특히 Web의 경우 Content Delivery Network (CDN)인 AWS CloudFront를 기반으로 samsung.com, TV QR login 등 다양한 기능을 제공합니다.
삼성계정의 각 Microservice들은 EKS(Elastic Kubernetes Service) Cluster에서 Container 기반으로 서비스 중이며 Region 간 내부 통신은 VPC Peering 형태로 이루어집니다.
다양한 기능을 제공하기 위해 삼성계정은 AWS의 여러 가지 Managed Service를 이용하고 있습니다. 데이터 저장소로 Aurora, DynamoDB, Managed Streaming for Apache Kafka (MSK))를 사용해 각 Region 간에 데이터 동기화를 구축하고 있으며, ElastiCache, Pinpoint, SQS(Simple Queue Service) 등 다양한 Managed Service를 기반으로 계정 서비스를 제공 중입니다.
삼성계정이 이용하는 AWS Managed Service에 대해 부연 설명 드리자면, 우선 MSA 아키텍처에서 70여 개의 Microservice들을 운영하기 위해 Kubernetes Service인 EKS를 사용 중이고요. 데이터를 저장하고 Query하기 위해 RDB로는 Aurora를, NoSQL Database로는 DynamoDB를 활용하고 있습니다. 아울러 Cache와 Session을 관리하기 위해 Redis용 ElastiCache (Redis OSS)를 사용하며, 연동 서비스 Event 전달과 데이터 동기화를 위해 Kafka용 MSK를 사용하고 있습니다. 여러분도 AWS를 기반으로 서비스를 구축한다면 위와 같은 Managed Service를 기본적으로 사용하실 것이라 생각되네요.
편리한 Managed Service에 수반되는 불편한 업그레이드
그런데 이러한 Managed Service를 이용할 때는 한 가지 큰 문제점을 고려해야 합니다. EKS는 평균 1년 6개월, Aurora는 평균 2년 이후에 지원이 종료되며, 그 외에 ElastiCache, MSK 등 다양한 서비스에 지원 종료가 발생합니다. 이러한 서비스 지원 종료는 AWS 입장에서는 당연한 일이겠지요. 하지만 서비스를 운영하는 입장에서는 지원 종료에 따른 Managed Service 업그레이드가 곤혹스러운 작업일 수밖에 없습니다. 운영 리소스를 클라우드 서비스로 옮기면서 줄였기 때문에 1년 내지 2년마다 발생하는 대규모 업그레이드 시 급히 대응할 리소스가 부족한 상태로 작업을 진행해야 하거든요.
이러한 Managed Service 업그레이드는 삼성계정에 커다란 부담을 안깁니다. 60개 이상의 연동 서비스가 존재하여 무중단으로 업그레이드를 진행해야 하며, Global 3개 Region과 China에 걸쳐 작업을 수행해야 합니다. 더욱이 70여 개의 Microservice들을 개발/운영하고 있어 많은 개발팀의 지원과 협업이 필요합니다. 가장 힘든 부분은 2.7M RPS 이상의 트래픽과 200K TPS DB 트래픽 속에서 업그레이드 작업을 수행해야 한다는 점입니다.
EKS 업그레이드 순서 및 제약 사항
AWS에서 EKS 업그레이드는 쉬울 것이라 생각하실 수 있습니다. 일반적으로 EKS 업그레이드 시에는 먼저 EKS를 관리하는 etcd, api 등 Control Plane을 업그레이드한 다음, 실제 서비스 Pod 등이 떠있는 Data Plane을 업그레이드하고, 마지막으로 EKS Add-on을 업그레이드합니다. “이론적으로” 이러한 순서를 따라 EKS를 서비스 운영과 무관하게 업그레이드할 수 있습니다.
하지만 일반적인 EKS 업그레이드에는 제약 사항이 있습니다. 위 3개의 단계에서 EKS API Spec을 누락하거나 호환성이 안 맞는 부분과 같은 이슈가 발생하여 업그레이드가 실패할 경우 롤백이 전혀 불가능합니다. 더욱이 서비스와 Add-On에 대한 호환성을 사전에 체크하기도 어렵습니다.
무중단 EKS 업그레이드를 위한 Multi-cluster 아키텍처
여러 고민 끝에 삼성계정은 단순하지만 안정적으로 EKS 업그레이드를 수행하는 방법을 택했습니다. 아마 많은 곳에서도 비슷한 방식으로 EKS 업그레이드 혹은 실제 운영까지 하고 있을 수 있습니다.
삼성계정은 2개의 EKS Cluster로 이루어진 Multi-cluster 아키텍처를 기반으로 EKS를 업그레이드했습니다. 기존 버전의 EKS에서 서비스를 지속적으로 제공할 수 있도록 하면서, 신규 버전의 EKS에서 다양한 Microservice들과 Add-On 호환성을 먼저 검증한 후에 트래픽을 받을 수 있도록 아키텍처를 구축했습니다.
이 방식의 장점은 신규 버전 EKS로 트래픽이 전환되어 이슈가 발생하는 경우에 다시 기존 버전 EKS가 트래픽을 수용해주는 롤백 플랜을 구현할 수 있다는 것입니다. 그리고 대용량 트래픽 속에 삼성계정 서비스를 제공하며 깨달은 점은 아무리 인프라나 서비스가 완벽히 구축되었더라도 실제 트래픽을 받으면 발생하는 이슈가 있다는 것입니다. 따라서 서비스를 배포하거나 인프라를 업그레이드할 때는 항상 이슈 발생에 따른 롤백 플랜을 구현해야 합니다.
Multi-cluster로 업그레이드를 수행할 때는 기존 EKS와 신규 EKS 간의 트래픽 전환이 반드시 이루어져야 합니다. 간단히 생각해보면 두 가지 방식이 떠오를 수 있습니다. 한 가지 방법은 두 Cluster 사이에 Proxy Server를 두고 트래픽을 전환하는 방법이고, 또 다른 방법은 DNS를 이용해 Target IP를 전환하는 방법입니다. 물론 이외에도 다양한 방법이 존재할 수 있습니다.
Proxy Server를 두는 첫번째 방식에서는 삼성계정처럼 대용량 트래픽을 처리해야 하는 경우 부하 과중 문제가 발생할 수 있습니다. 또한 70여 개의 Microservice들에 사용되는 ALB(Application Load Balancer) 수가 많아 모든 ALB에 대해 Proxy Server를 만들 수 없는 문제도 존재합니다.
DNS를 이용하는 두번째 방식에서는 실제 사용자, Client, Server가 DNS Lookup 과정에서 기존 EKS의 서비스 IP를 신규 EKS의 서비스 IP로 대체하여 사용자 레벨에서 요청 대상을 변경합니다. DNS를 이용하는 방식은 Proxy Server를 두지 않아도 되며 DNS Record 변경만으로 트래픽을 간단히 전환할 수 있습니다. 다만 DNS의 경우 Propagation 관련 지연이 발생하여 즉시 트래픽 전환이 이루어지지 않을 수 있는 이슈가 존재합니다.
삼성계정 무중단 EKS 업그레이드에는 DNS 기반의 트래픽 전환 아키텍처를 적용했습니다.
가상의 예시를 들어 삼성계정의 DNS Layer를 설명해 보겠습니다. account.samsung.com이라는 최상위 Domain이 있고, 그 하위에 Global 3개 Region Domain을 Latency 또는 Geolocation을 기반으로 분류합니다. 그리고 us.account.samsung.com의 경우 기존/신규 2개의 internal domain인 service.us-old-eks.a.s.com과 service.us-new-eks.a.s.com의 구성으로 Layer를 나눕니다. 이는 간단한 가상의 예시이며 실제로는 좀더 많은 DNS Layer를 계정에서 사용하고 있습니다. 이번 EKS 업그레이드 과정에서는 2개 EKS의 Internal Domain에 대해 Weighted Record를 기반으로 한 번에 트래픽을 전환하지 않고 비율을 조정하며 트래픽을 전환할 수 있도록 했습니다. 예를 들어 사용자가 account.samsung.com Domain에 요청을 하면 us.account.samsung.com을 거쳐 마지막에는 지정된 weight를 기반으로 실제 EKS 서비스 IP를 적용하여 요청을 하게 됩니다.
무중단 EKS 업그레이드 과정 및 회고
한마디로 “연동 서비스들이 눈치채지 못하였다면 우리에겐 성공적인 업그레이드”라 할 수 있을 것 같습니다. 이번 EKS 업그레이드에서는 총 3개 Region, 6개 EKS Cluster, 210여 개의 Microservice들을 배포 및 트래픽 전환을 한 달 동안 수행했습니다. 서비스 부하와 특성에 맞춰 트래픽 전환 비율을 설정해 트래픽을 전환했고 EKS 업그레이드를 진행한 한 달 동안 어떠한 연동 서비스 이슈도 없었습니다.
물론, 끝날 때까지 끝난 게 아니라는 말이 있듯이 작은 소동은 있었습니다. 많은 EKS Node와 서비스 Pod가 뜨면서 내부 Subnet의 Internal IP가 부족해지는 현상이 발생해 가슴이 철렁했습니다. 이에 신속하게 EKS Node를 Scale Up하여 Kubelet이나 Add-On의 Pod 수를 천 개 정도 줄여서 필요한 IP 리소스를 확보했습니다. DNS로 트래픽 전환을 수행하며 한 가지 알게 된 사항은 DNS Weight 조절 시 5분 내로 전체 트래픽의 99.9%가 즉시 전환된다는 것입니다.
마무리하며
버진 그룹 회장인 리처드 브랜슨은 이런 말을 하였습니다. “사람은 걷는 규칙을 배워서 걷지 않는다. 걸음을 시도하고, 넘어지면서 배운다.” 삼성계정은 계속 발전해왔고 여러 이슈도 많았지만 넘어지면서 배운다는 생각을 가지고 서비스의 안정성에 우선을 두며 다양한 문제를 해결해 나가고 있습니다. 감사합니다.
