이 글은 삼성전자의 기술블로그(Samsung Tech Blog)에 기재된 원문 [https://techblog.samsung.com/blog/article/51]을 인용하여 작성 하였습니다. D-KMS(Data Key Management Service)는 삼성전자에서 제공하는 다양한 서비스의 민감정보 암호화 키를 중앙에서 관리하는 서비스입니다. 이 서비스를 안정적으로 제공하기 위해 고심한 결과물을 AWS 한국 기술 블로그를 통해 게시 되도록 지원해 주신 삼성전자 백승규 프로님에게 감사의 말씀을 드립니다.
시작하며,
이 글에서는 삼성의 개인정보 암호화 시스템 D-KMS에서 고가용성과 안정적인 배포를 위해 적용한 Multi-Cluster Architecture 기반의 무중단 Canary 배포 기술과 배포를 자동화하기 위해 개발한 도구 및 전략을 공유합니다.
D-KMS와 고가용성
D-KMS(Data Key Management System)는 삼성전자의 다양한 서비스에서 개인정보 데이터를 안전하게 암호화/복호화할 수 있도록 암호화 키를 제공하고 관리해주는 시스템입니다. 당사 서비스들과 연동되어 동작하는 D-KMS는 장애 영향도가 매우 높은 시스템이기 때문에 고가용성(99.999%)과 빠른 처리속도(250ms)를 보장해야 합니다.
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/12/download-1-1024x532.png] 그림 1. D-KMS 시스템
고가용성을 위한 D-KMS의 기존 아키텍처
D-KMS 서비스는 당사 서비스에 통합되는 SDK와 SDK의 요청을 처리하는 Backend 서버로 구성됩니다. Backend 서버는 AWS Cloud 기반의 EKS(Elastic Kubernetes Service) 클러스터를 사용하며, Global Service 지원을 위해 총 4개의 Region에서 서비스를 제공합니다. 또한 GCP Cloud를 사용한 Multi-Cloud 기반의 암호화 키 관리를 통해 서비스 안정성을 더욱 강화하고 있습니다.
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/12/download-2.png] 그림 2. Multi Region 및 Cloud 구조
D-KMS는 SDK의 요청을 처리하기 위해 글로벌 엣지 네트워크 서비스인 Global Accelerator(이하 GA)를 사용하고 있습니다. GA는 엔드포인트의 요청을 가장 가까운 Region으로 라우팅하여 네트워크 성능을 최적화하고, Health Check와 Failover 기능을 제공하며, 트래픽 다이얼 기능을 통해 세분화된 트래픽 제어를 지원합니다. 이러한 기능을 바탕으로 D-KMS 서비스는 250ms 이내의 처리속도를 보장하며, Global Multi-Region Failover를 지원합니다.
단일 클러스터와 배포 안전성 문제
그러나 이러한 설계에서도 다음과 같이 보완해야 할 부분이 있습니다.
ISSUE1) 단일 클러스터 구조
– Region 내에서 단일 클러스터 구조로 동작하고 있으므로 클러스터 장애 시 동일한 성능으로 요청을 처리할 클러스터가 존재하지 않아 장애로 이어질 수 있습니다. 만약 Failover로 요청을 처리하더라도 다른 Region으로 요청이 전달되어 응답 속도가 느려지는 상황이 발생할 수도 있습니다.
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/12/download-3.png] 그림 3. Multi-Region Failover
ISSUE 2) 배포 안전성과 중단 가능성
– 또한 안전성에 큰 영향을 미치는 애플리케이션 배포 시에 신규 배포 버전에 에러가 있다면 그 에러가 사용자에게 직접 노출될 수 있습니다. 클러스터 업그레이드의 경우 내부적으로는 Rolling Update를 통해 무중단으로 수행되지만 서빙 중인 API 품질에 영향을 주거나 업그레이드 후 호환성 이슈 등의 치명적인 문제가 나타나 중단 시간이 발생할 가능성이 드물게 있습니다.
이러한 문제를 해결하기 위해 다음과 같은 설계 변경 및 개발을 통해 서버 구조와 배포 프로세스를 개선했습니다.
* Solution 1) 클러스터 이중화(Multi-Cluster Architecture) : 클러스터를 Origin Cluster와 Replication Cluster로 이중화하여 Issue1을 개선했습니다.
* Solution 2) 무중단 Canary 배포 구현 : GA의 Endpoint Group Traffic Routing을 통해 Origin Cluster와 Replication Cluster 간에 Canary Traffic을 분배하여 무중단 배포를 구현함으로써 Issue2를 개선했습니다.
* Solution 3) 배포 자동화(Release Automation) : 복잡한 단계의 무중단 Canary 배포 프로세스를 자동화하여 효율성을 개선했습니다
클러스터 이중화
D-KMS는 고가용성을 위해 SDK 수준에서 Failover를 지원하지만 기존의 단일 클러스터 구조에서는 클러스터 장애가 곧 서비스 장애로 이어질 수 있습니다. 따라서 클러스터에 장애가 발생하더라도 장애를 회복하는 동안 사용자의 요청을 처리할 수 있는 클러스터가 필요했고, 이를 위해 클러스터 이중화 구조를 채택했습니다. 고가용성이 중요한 만큼 Active/Active 상태로 동작하여 실시간으로 양쪽 클러스터에서 요청을 처리할 수 있도록 설계하였습니다. 또한 클러스터 이중화에 따라 Integration Test를 위한 Test 이중화도 함께 진행했습니다.
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/12/download-4-914x1024.png] 그림 4. 이중화 클러스터 구조
클러스터 이중화를 위해 다음과 같은 작업을 진행했습니다.
* SDK의 Public 요청 처리를 위한 ALB 이중화
* DKMS Portal 및 암호화 키 생성을 위한 Airflow 등의 Internal 요청을 처리할 NLB/ALB 이중화
* Integration Test 이중화
* Public Test 요청을 처리할 Global Accelerator 이중화
* Internal Test 요청을 처리할 NLB/ALB 이중화
이로써 Active/Active 구조의 이중화 클러스터를 운영할 수 있게 되었고, 클러스터의 안정성이 한층 향상되었습니다.
무중단 CANARY 배포 구현
이중화 클러스터에서 배포 안전성을 확보하기 위해서는 배포된 신규 애플리케이션에 문제가 발생하여도 사용자에게 노출되지 않아야 하며, 배포 중에도 사용자 요청을 처리할 수 있어야 합니다. 따라서 배포할 클러스터에서 트래픽 유입을 차단한 상태로 배포와 테스트가 이루어지고, 동작 중인 클러스터로의 트래픽 전환은 클러스터 처리량과 Autoscaling 속도를 고려하여 이루어져야 했습니다. 이를 위해 점진적인 Canary 배포 전략을 채택하여 안전하게 트래픽을 전환하고 배포와 테스트를 수행할 수 있도록 설계하였습니다.
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/12/download-5-1024x485.png] 그림 5. 무중단 Canary 배포 전략
멀티 클러스터와 Canary 배포 설계를 적용하여 기존의 Release Process를 수정하고 실행하는 데는 많은 단계와 환경설정, 툴이 필요했습니다. 이로 인해 Release Process가 복잡해지고 휴먼 에러가 발생할 가능성이 높아졌습니다. 이에 따라, 복잡한 과정을 단순화해줄 통합 배포 도구도 개발했습니다.
* Custom Controller : Global Accelerator의 Endpoint Group Weight를 변경하고 상태 정보를 가져오는 기능을 수행합니다. D-KMS는 EKS 환경에서 ArgoCD를 통해 배포를 수행하고 있었으며, 이 환경에 맞게 동작하도록 Operator SDK와 AWS SDK를 기반으로 Kubernetes Custom Controller를 통해 기능을 구현하였습니다.
* Custom Resource : 다음으로, Canary 배포 Step과 이를 통해 동작할 Resource 정보를 기록하여 EKS 환경에 등록하고 Custom Controller에서 읽어들여 리소스에 정의된 순서로 배포를 진행해야 했습니다. Kubernetes 환경에 맞게 저희는 yaml 형식으로 Custom Resource Definition을 생성했고, Custom Resource 파일에 Canary 배포 Step과 AWS Resource ARN을 기록하여 클러스터에 등록하는 방법을 사용했습니다.
* Command Line Interface : Custom Controller에 Custom Resource 등록, Canary 배포 진행, Rollback, 모니터링 등의 명령을 내려 배포를 용이하게 할 수 있는 통합 명령어 도구를 개발했습니다.
통합 배포 도구의 아키텍처는 다음과 같습니다.
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/12/download-6-1024x603.png] 그림 6. 통합 배포 도구의 동작 구조
MULTI-CLUSTER 무중단 배포와 회고
위와 같이 준비한 Multi-Cluster Architecture와 통합 배포 도구를 사용하여 한 달간 테스트와 배포를 진행했습니다. QA/STG/PRD 환경에서 2개의 Region, 총 12개의 클러스터에 배포를 진행했는데 Zero Downtime과 트래픽 손실률 0%로 연동 이슈 없이 성공적으로 배포를 완료하였습니다.
배포는 성공적이었지만 과정을 회고해보면, 통합 배포 도구를 개발했음에도 불구하고 Canary Step만 환경별로 약 40단계를 거쳐야 했으며 Integration Test, Rollback, Monitoring과 같은 모든 요소를 고려했을 때 사람이 배포를 진행하기에 복잡도가 높고 많은 시간 및 인력 투입이 필요했습니다. 저희는 이 과정을 효율화하기 위해 Github Actions를 통한 Multi-Cluster Release 자동화를 구현했습니다.
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/12/download-7-1024x898.png] 그림 7. 이중화 클러스터 배포 프로세스
D-KMS Multi-Cluster 배포의 흐름은 위 그림과 같습니다. 애플리케이션 배포에 ArgoCD를, 통합 테스트에 Testkube를 사용하고 있으며, 두 가지 툴 모두 CLI와 API를 통한 원격 실행 및 결과 확인을 지원합니다. 위 과정을 자동화하기 위해 D-KMS의 CI/CD에서 활용 중인 Github Actions를 사용했습니다. Workflow를 통해 통합 배포 도구, ArgoCD CLI, Testkube API를 호출하여 트래픽 전환, 배포, 테스트를 포함하는 전체 과정을 자동화할 수 있었습니다.
마무리하며
Multi-Cluster Architecture와 무중단 Canary 배포 구현을 통해 D-KMS는 한층 더 강력한 안전성과 고가용성을 보장할 수 있게 되었습니다. 또한 배포 중 잠재적으로 발생할 수 있는 Alert에 대비하여 모니터링 시스템과 Slack 연동 등을 통해 관제를 강화하고 있습니다. 앞으로도 D-KMS 팀은 서비스 안정성을 위해 지속적으로 시스템을 발전시키고자 노력할 것입니다.
[https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2025/08/13/seungkyu_baek.png] 백승규, 삼성전자
삼성전자에서 Backend/DevOps 업무를 진행 해 왔으며, 현재는 D-KMS Technical Leader 로써 삼성전자의 개인 정보를 암/복호화 하여 안전하게 보호하는 서비스를 개발/운영 하고 있습니다.
특히 전사 연동 서비스인 D-KMS 안정성과 보안성을 강화하기 위해 노력을 기울이고 있습니다.