AWS 계정 분리에 따른 CloudFront 무중단 이전
안녕하세요. 스푼라디오 SRE 팀의 DevOps 엔지니어 Ash(박민호)입니다. 지난 포스팅에서 Amazon Cloudfront로 글로벌 웹 서비스 전개하여 웹 앱의 성능을 향상시킬 수 있었습니다. 엣지 서버에 캐싱을 제공함으로써 중복으로 발생하는 내부 트래픽을 줄이고, 페이지 로딩 시간을 줄일 수 있었습니다.
스푼라디오는 리소스, 보안, 비용 관리를 위해 AWS 계정을 여러개로 분리하여 운영하고 있습니다. 분리 작업에 따라 CloudFront를 다른 계정으로 이전하는 작업을 수행하였으며, 그 과정에 대해 이야기하고자 합니다.
작업은 CloudFront와 S3 버킷, 백엔드 서비스를 Target 계정에 동일하게 구성하고 트래픽만 전환하면 끝나는 간단한 작업이었습니다. 하지만 CloudFront의 특정 옵션때문에 간단한 작업이 서비스를 일시 중단할 수 있다는 리스크에 놓여지게 됩니다.
대체 도메인 이름(CNAME)으로 인하여 트래픽 전환이 불가능
CloudFront를 배포할때 기본 도메인은 *.cloudfront.net 으로 제공하고 있습다. 이 이름 대신에 www.example.com 같은 고유 도메인 이름을 사용하려는 경우, 대체 도메인 이름을 추가할 수 있습니다. 대체 도메인을 구성하지 않고 다른 이름의 도메인으로 접근 할 경우 403 에러가 발생합니다.
하지만 대체 도메인은 중복으로 사용할 수 없습니다. 한 쪽에서 대체 도메인을 사용할 경우, 다른 쪽 CloudFront에는 추가할 수 없다는걸 알았습니다. 계획은 양 계정의 대체 도메인을 동일하게 설정하고 Route53의 가중치를 활용하여 트래픽을 옮기려 하였지만 불가능한 시나리오가 되어버렸습니다. 만약 옮기기 위해 한쪽의 대체 도메인을 제거 할 경우 바로 403 에러가 발생하게 됩니다.
안전하게 가중치 테스트로 작업하려고 하였지만 대체 도메인때문에 403 에러가 발생하지 않도록 CloudFront를 연결을 해제 후 연결과 와일드카드 도메인을 이용하여 장애없이 옮길수가 있었습니다.
1. CloudFront에서 제외
도메인의 트래픽양을 확인해보니, spooncast.net 의 도메인으로 유입되는 양이 적다는 것을 확인 하였고, 따라서 해당 도메인을 가장 먼저 CloudFront 에서 제거 하기로 선택하였습니다.
우선 S3 버킷에 있는 리소스를 요청할 가능성이 있어 백엔드 서비스의 White List 이외의 요청은 S3로 전달 처리하였습니다. 이후 spooncast.net 도메인을 제거 하였습니다.
2. 백엔드 서비스 점검
새로운 계정으로 변경 하기 위해선 CI/CD 환경의 변경이 필요 했고, 필요한 리소스의 권한 및 위치가 변경 되기 때문에 안정성을 검증하여야 했습니다.
따라서 Route53의 가중치 기반 정책을 활용 하여 백엔드 서비스의 트래픽을 순차적으로 이동하며 안정성을 검증하는 테스트를 진행 하였습니다.
3. 대체 도메인 변경
CloudFront로 흐르지 않는 spooncast.net 이전을 위해 기존 계정의 대체 도메인을 제거할 수 있게 되었습니다. 값을 제거하고, 타겟 계정에 등록하면서 설정값을 옮길 수 있게 되었습니다. 이후, ALB로부터 받던 트래픽을 타겟 CloudFront로 변경하면, 2차 도메인인 spooncast.net에 대한 이전이 완료됩니다.
3차 도메인 이전하기
www.spooncast.net는 웹 앱을 구성하는 데 지속적인 트래픽이 발생하는 중요한 지점입니다. spooncast.net와 같이 CloudFront를 사용하지 않는 대안을 고려할 수는 있었으나, 이미 캐싱을 통해 서비스를 제공하고 있기 때문에 스펙 저하를 감내하기에는 적절하지 않은 방법으로 판단하였습니다. 따라서 CloudFront를 유지하면서 이전할 수 있는 방법을 검토하였습니다.
a. 대체 도메인 이름에서 와일드카드(*) 사용
www.spooncast.net의 중복을 피하기 위해, 타겟 계정에 *.spooncast.net을 추가합니다. 이로써 spooncast.net으로 끝나는 모든 도메인을 수용할 수 있는 환경을 구성하고, www 요청이 들어와도 에러가 발생하지 않게 됩니다.
그 후, 기존 계정에서 www.spooncast.net을 제거합니다. 기존 계정의 대체도메인에 www.spooncast.net이 없음에고 불구하고 Route53에 설정된 기존 CloudFront로 접근을 하게 될 경우 다른계정의 *.spooncast.net이 있는 CloudFront로 흘러가는 모습을 볼 수 가 있습니다.
b. 대체 도메인 변경
제거한 www.spooncast.net 을 타겟 계정의 대체 도메인에 다시 추가하였며, Route53을 새로운 CloudFront로 변경합니다. 마지막으로 임시로 넣어놓은 *.spooncast.net을 제거함으로써 이전 작업이 완료되었습니다.
대체 도메인 이름에서의 와일드카드*
AWS 계정에서 다른 배포를 소유하더라도 동일한 대체 도메인 이름이 다른 CloudFront 배포 안에 이미 있는 경우에는 대체 도메인 이름을 CloudFront 배포에 추가할 수 없습니다.
하지만 와일드카드 대체 도메인 이름을 추가할 수 있는데 여기에는 비 와일드카드 대체 도메인 이름이 포함(중첩)됩니다. 배포 2개의 대체 도메인 이름이 겹치는 경우 CloudFront는 DNS 레코드가 가리키는 배포에 상관 없이 보다 구체적으로 일치하는 이름을 사용하여 배포에 요청을 보냅니다.
Amazon CloudFront는 계정마다 논리적으로 서비스를 생성하는게 아닌 설정만 구성한다는 점을 알게되었습니다. 생성된 설정은 CloudFront라는 공용 CDN에 배포되어 모든 계정에서 같이 쓰는 논리적, 물리적 장비로 추측할 수 있습니다. 프록시에 대한 기준을 대체 도메인을 이용하여 전송하여 다수의 계정에서 ACM만 공유된다면 제한사항에 대하여 회피가 가능합니다.
이 부분을 이용하여 대체 도메인이 없는 CloudFront Endpoint로 트래픽을 흘려 보냈지만 계정은 다르지만 와일드카드로 생성된 대체 도메인이 있어 트래픽이 흘러가는 흐름을 만들수가 있습니다. 물론 이 설정은 중복 방지를 피해가는 방법으로써 작업이 완료되면 원상태로 돌려놓는 작업은 필수입니다.
마치며
AWS Support에 마이그레이션 상황에 대한 문의를 했으나, 무중단 전환에 대한 명확한 가이드를 얻을 수 없었습니다. 그럼에도 불구하고 문서를 검토하고 가능성을 확인한 결과, 대체 도메인을 활용한 방법을 사용하여 CloudFront 이전을 무중단으로 완료할 수 있었습니다.
스푼라디오는 AWS를 이용하면서 안정적인 서비스를 제공하기 위해 Legacy 서비스의 개선 작업을 지속적으로 수행하고 있습니다. 이 작업은 고객이 직접 체감할 수 있는 부분은 아니지만, 서비스 안정성과 효율성 향상에 기여하고 있습니다.
