D-KMS(Data Key Management System)는 삼성전자 내 서비스에서 개인정보 데이터를 안전하게 암호화/복호화할 수 있도록 지원하는 시스템입니다. 당사의 개인정보 암호화가 필요한 서비스는 D-KMS Portal에서 암호화/복호화 권한을 신청하며, 권한에 따라 발급되는 암호키를 통해 서비스 내에 존재하는 개인정보를 암호화/복호화할 수 있습니다.

그림 1. D-KMS 시스템

D-KMS를 운영하기 위해 중점적으로 고려해야 했던 사항은 보안성과 고가용성입니다.

암호키는 중앙에서 관리되므로 안전하게 암호키를 관리하여 유실되지 않도록 하는 것이 중요합니다. 잘못하면 암호키로 인해 개인정보가 유출될 수 있으니까요.

또한 만약 D-KMS에 장애가 발생해서 복호화 기능이 정상적으로 동작하지 않는다면 어떻게 될까요? 개인정보인 이메일 주소를 로그인 수단으로 사용하는 시스템에서 사용자가 로그인할 수 없게 되겠죠.

이렇듯 D-KMS는 장애 영향도가 매우 높은 시스템이기 때문에 고가용성(99.999%)을 반드시 유지해야 합니다.

이 두 가지 요구사항을 만족하기 위해서는 SW 품질이 보장되어야 하므로 보수적으로 릴리즈하게 될 가능성이 높죠. 하지만 기능 요구사항이 빈번히 추가됨에 따라 높은 수준의 보안성과 고가용성을 유지하면서도 빠르게 릴리즈하기 위한 방안을 고민해야 했습니다.

저희는 목표한 주요 시스템 요구사항을 만족하기 위해 신속하면서도 장애를 최소화하는 배포 프로세스를 구축하였고, 이 프로세스가 잘 동작하는지 확인하는 수단으로 DORA Metrics를 도입했습니다.

DORA Metrics는 구글의 DORA(DevOps Research And Assessment) 팀이 만든 DevOps 성과 측정 지표입니다. 속도와 안정성을 측정할 수 있는 다음과 같은 4가지 지표로 구성되어 있으며, 각 지표의 수치에 따라 High, Medium, Low로 클러스터가 구분됩니다.

• Deployment Frequency(배포 빈도)
  
• Lead Time for Changes(변경 리드 타임)
• Time to Restore Service(서비스 복구 시간)
• Change Failure Rate(실패율)

저희는 최우선 요구사항인 고가용성을 만족하기 위해 약 2주에 한 번 배포를 진행하기로 계획하고, 안정성과 관련된 두 가지 지표에서 High 클러스터 수치를 달성하는 것을 목표로 삼았습니다. 또한 릴리즈마다 DORA Metrics를 측정하고 지속적으로 추적함으로써 배포 프로세스를 점진적으로 개선하고자 했습니다.

그림 2. DORA Metrics

저희는 배포 프로세스의 속도와 안정성을 높이기 위해 제일 먼저 다양한 테스트를 구축했습니다. 조기에 결함을 찾아낼 수 있도록 개발 단계에서 테스트를 수행하는 shift left testing을 적용하였고, 커밋이 발생하면 정적 분석, 테스트 커버리지와 같은 코드 품질 지표를 측정하도록 CI 파이프라인을 구축했습니다. 또한 D-KMS에서 MSA(Micro Service Architecture)를 채택했기 때문에 매번 배포 시 integration test를 수행하는 shift right testing도 적용하여 안정성을 높였습니다.

하지만 테스트를 구축했더라도 여전히 배포 시에 문제가 발생하는 경우가 많았습니다. 초기에는 dev, staging, production으로 환경이 구축되어 있었는데 dev 환경은 production 환경과 인프라가 상당히 달랐고, staging은 D-KMS와 연동하려는 서비스들의 검증환경과 연동되어 있어 내부 검증 용도로 사용하기 어려웠습니다.

따라서 저희는 dev와 staging 사이에 qa라는 환경을 추가했습니다. qa를 production과 동일한 세트로 구성하여 검증환경으로 활용했으며, qa에서 모든 테스트가 통과해야만 staging을 배포할 수 있도록 배포 프로세스를 구성했습니다. 그리고 staging 배포 후에는 1주일간의 모니터링 기간을 거쳐 production 배포를 수행함으로써 안정성 높은 2주 단위의 배포 프로세스를 구성하였습니다.

그림 3. D-KMS 환경별 배포 전략

하지만 환경이 많아짐에 따라 저희가 배포하고 관리해야 할 서비스가 늘어나 신속한 릴리즈에 어려움이 있었습니다. 이에 GitHub Action을 활용하여 CI/CD 파이프라인을 구성하게 되었습니다.

Commit Workflow는 커밋이 발생할 때마다 실행되어 다양한 품질 지표를 수집하며, Build Workflow는 배포를 위해 tag가 생성될 때마다 실행되어 각 마이크로서비스의 이미지를 빌드하고 AWS로 업로드합니다. 그리고 dev와 qa의 경우에는 릴리즈 속도를 위해 GitOps 배포 전략 중 push type으로 배포가 이루어지도록 CD 파이프라인을 구성하였습니다.

GitHub Action을 활용함으로써 배포마다 발생한 수동 작업이 92% 감소하는 동시에 릴리즈 속도를 높일 수 있었습니다.

그림 4. D-KMS의 CI/CD 파이프라인

아울러 저희는 D-KMS의 주요 애플리케이션인 EKS 클러스터를 배포하기 위해 helm chart를 관리하고 있었는데, 초기에 개발자의 각 로컬에서 모든 환경에 대한 배포를 수행하다 보니 variable과 환경을 일치시키지 않고 배포하는 이슈가 흔히 발생했습니다. 그래서 휴먼 에러를 최소화하기 위해 환경별로 ArgoCD를 구축하였습니다.

그림 5. D-KMS helm chart 구조도

마지막으로 적용한 것은 테라폼입니다. 환경이 늘어남에 따라 관리해야 할 인프라가 증가했고, 추후 multi region, multi cloud로 확장될 경우를 고려해서라도 테라폼을 적용하는 것이 필요했습니다.

테라폼을 적용하면서 재밌는 CI 파이프라인도 추가해보았는데요. 테라폼이 작성된 PR이 생성되면 변경되는 리소스에 대해 terraform plan을 수행하고 terraform visual이 구축된 AWS S3에 업로드하여 가시화된 plan 결과를 조회할 수 있도록 구성하였습니다.

현재는 Plan Workflow만 구성되어 있지만, 추후에는 PR이 머지되는 시점에 terraform apply를 자동화하는 Apply Workflow도 구성하려고 계획 중입니다.

그림 6. 테라폼 CI 파이프라인

저희는 DORA Metrics로 배포와 관련된 지표들을 수치화하여 측정함으로써 배포 프로세스의 어떤 부분이 비효율적이고 개선이 필요한지 파악할 수 있었습니다. 또한 SW 구조가 변경될 때마다 새로운 도구 및 배포 프로세스를 검토하고 채택하는 과정을 반복함으로써 안정성 있으면서도 빠른 릴리즈를 계속 만들어 나가고 있습니다.

앞으로 어떤 변화가 생기든 저희는 변화가 있을 때마다 지속적으로 배포 프로세스와 CI/CD를 개선하고 발전시키고자 합니다.

Big Data Center BD플랫폼팀의 황연성이었습니다. 감사합니다.