[디지털데일리 권하영기자] 전세계 256개국에서 18억명 이상이 사용하고 있는 ‘삼성 계정’ 서비스에서 장애가 발생하면 어떻게 될까?

이정현 삼성전자 빅데이터센터 데브옵스(DevOps)엔지니어는 21일 온라인으로 진행된 ‘삼성 개발자 컨퍼런스(SDC) 코리아 2024’에서 ‘삼성 계정은 DR에 진심, 글로벌 리전 장애 조치 아키텍처’ 발표를 통해 삼성 계정의 재해복구(DR) 프로세스를 공유했다.

삼성 계정은 60개 이상 서비스와 애플리케이션을 하나로 이어주는 삼성의 글로벌 계정 서비스다. 삼성페이와 삼성헬스, 스마트싱스 등 삼성전자 주요 서비스는 물론 모바일과 웨어러블, TV, PC 등 다양한 기기에서 활용되고 있다.

삼성 계정 서비스는 유럽(EU)과 미주(US) 리전(데이터센터 권역), 별도 분리된 중국 리전에 더해, 지난해 구축한 아시아태평양(AP) 리전까지 총 4개 리전에서 중이다. 디바이스와 웹 연계 서비스로부터 초당 270만이라는 대용량 트래픽을 안정적 처리하고 있으며, 70여개 이상 마이크로(Micro) 서비스를 쿠버네티스에서 서비스하고 있다.

이처럼 삼성 계정은 삼성의 모든 기기와 서비스를 연결하는 매우 크리티컬한 시스템이기 때문에, 삼성 내부적으로는 매우 높은 수준의 RPO(Recovery Point Objective, 복구지점목표)와 RTO(Recovery Time Objective, 복구시간목표)를 갖고 있다. 즉, 최대한 백업을 자주하고 빠른 시간 내 정상 서비스로 복구해야 한다는 뜻이다.

이 엔지니어에 따르면 클라우드 기반 재해복구 전략은 4가지가 있다. 하나는 ‘백업&리스토어(Backup & Restore)’다. 평소 데이터를 정기 백업해뒀다가, 재해발생시 백업 기반으로 복구하는 작업이다. 구현이 간단하고 비용이 저렴한 장점이 있지만, 백업을 얼마나 자주하냐에 따라 복구 속도가 느리고 데이터 손실 위험이 있을 수 있다.

두 번째는 ‘파일럿 라이트(Pilot light)’ 전략이다. 데이터베이스(DB)나 오브젝트 스토리지 같은 데이터 리소스를 복구 사이트에 항상 유지하고, 서버는 장애 조치가 필요할 때만 켜서 프로덕션 환경 수준으로 프로비저닝한다. 앞의 전략에 비해 RPO는 상당히 단축되지만, 실시간 데이터 복제를 위해 추가 비용이 발생하는 게 단점이다.

다음은 웜 스탠바이(Warm standby) 전략이 있다. 실제 트래픽을 처리하는 또 하나의 프로덕션 사이트를 복구 사이트에 구축, 장애 발생시 복구 사이트 인프라의 트래픽 처리를 확장하고 유입되는 트래픽을 페일오버(Failover, 대체작동)해서 서비스를 정상화하는 것이다. 이 경우 RTO, 즉 복구에 걸리는 시간이 수분 단위로 줄어든다.

마지막은 ‘멀티 사이트 액티브-액티브(Multi site active-active) 전략이다. 기존 운영 시스템과 동일 수준의 환경을 복구 사이트에 사전 구성해서, 재해발생시 장애환경에서 정상환경으로 트래픽을 라우팅하는 방식이다. 이렇게 되면 RPO와 RTO는 제로에 가깝게 줄일 수 있는데, 문제는 시스템 복잡도가 높아지고 많은 비용이 소모된다.

삼성은 멀티 사이트 액티브-액티브 전략을 지향하되 웜 스탠바이 방식의 장점도 함께 가져가고 있다. 이 엔지니어는 “클라우드 사업자의 리전 단위 장애에도 극복 가능한 아키텍처가 필요했고, 이를 위해 글로벌 장애 복구 아키텍처 새롭게 구축했다”며 “기존 EU와 US 리전은 클라우드 인프라 한계에 이르는 리소스를 사용하고 있었기 때문에 AP 리전 신규 구축을 작년에 완료했다”고 전했다.

이에 삼성은 AP 리전을 구축하면서 리전마다 형상 일치화 작업을 진행, 단일 리전에서 모든 서비스 및 기능을 제공할 수 있도록 100% 커버리지를 가진 아키텍처로 새롭게 구성했다. 또한 데이터 동기화 기반으로 각 리전은 하나의 서비스를 개별 수행 하는 액티브-액티브 아키텍처로 고도화해, 특정 리전에서 장애가 발생해도 다른 리전에서 트래픽을 바로 수용할 수 있는 구조로 개선했다.

이 엔지니어는 “개별 리전에 종속되지 않는 글로벌 로드 밸런서를 구축해, 리전 장애 발생시 로드밸런스에서 정상 리전으로 트래픽을 전환하게 했다”며 “또한 장애 발생시 빠른 트래픽 전환도 중요하지만 비용 문제와 복구 작업 단순화도 필요했기 때문에, DNS 기반 장애 트래픽 전환 방식을 선택했다”고 밝혔다.

예컨대 A 리전에서 장애가 발생하면 B 리전의 IP로 도메인 레코드를 변경해 실제 사용자는 B리전으로 요청할 수 있게 함으로써 운영 비용이 제로에 가깝고 장애 대응 작업도 단순화시킬 수 있는 것이다. 삼성 차원에서 제어할 수 없는 클라이언트의 DNS 캐시로 인한 문제는 아마존웹서비스(AWS)의 라우팅 제어 서비스인 라우트53 ARC(Application Recovery Controller)를 통해 해결했다.

이 엔지니어는 “우리는 이를 실제 운영 환경에서 검증해보기로 하고, 글로벌 장애복구 아키텍처의 기능을 점검하는 ‘기능 검증’과 장애복구 트래픽 부하를 점검하는 ‘부하 검증’을 진행했다”며 “그 결과 삼성 계정의 새로운 인프라 아키텍처는 전세계 600개 이상 엣지 로케이션을 통해 네트워크 연결 속도를 65% 이상 개선했고, 리전 단위 장애가 발생해도 99% 이상 트래픽을 3분 내 전환할 수 있게 됐다”고 말했다.

그는 “1년 넘는 아키텍처 설계 구축 과정에서 늘 새로운 문제가 나타났지만 더 나은 대안을 찾는 과정을 수도 없이 반복함으로써 좋은 결과를 얻을 수 있었다”며 “내년에 다시 말할 기회를 얻는다면 새로 구축 중인 B2B(기업용) 삼성 계정의 진보한 아키텍처로 인사드리겠다”고 마무리했다.