굿리치의 온프레미스 DNS에서 HAQM Route 53 마이그레이션, 그 여정의 기록

굿리치는 국내 대표적인 법인보험대리점 (General Agency) 로 보험 판매와 인슈어테크 (보험+기술) 서비스를 제공하는 회사 입니다. 고객이 보험을 분석하고 상담받을 수 있는 서비스인 보험 관리 플랫폼, 종합 금융 컨설팅, 보험 비교 서비스 등 다양한 영역의 사업을 영위중이며 온프레미스 데이터센터에서 서비스 제공을 위한 다수의 IT 인프라를 보유하고 있었습니다.

최근 굿리치는 클라우드로의 전면적인 마이그레이션을 결정했습니다. 이는 IT 인프라의 민첩성, 비용 효율성, 총소유비용(TCO) 절감 등 클라우드 도입의 다양한 장점을 활용하기 위함입니다. 온프레미스에서 운용 중이던 서버, 스토리지, 데이터베이스 등의 서비스들을 단계적으로 클라우드 기반의 HAQM EC2, HAQM Aurora, HAQM MQ, HAQM ElastiCache 등의 매니지드 서비스로 마이그레이션하고 있습니다. 마이그레이션 과정에서 일부 서비스가 온프레미스에서 사용 중이던 버전이 낮아 버전을 맞추기 위한 작업에 어려움을 겪기도 했습니다. 하지만 이를 해결하며 점차 대부분의 서비스들을 성공적으로 클라우드로 이관하였습니다.

클라우드 마이그레이션 과정에서 고려 사항

클라우드 마이그레이션 시 고려했던 주요 비기능 요구사항은 보안성, 안정성, 그리고 확장성이었습니다. 금융 IT 서비스 기업인 굿리치는 규제 환경 속에 있어 보안 요구사항을 반드시 충족해야 했습니다. 이를 위해 멀티 계정 아키텍처를 설계하고, 온프레미스-클라우드 간 Direct Connect 연결을 구축하였습니다. DMZ VPC 를 통해 외부에서 들어오는 트래픽은 Gateway Load Balancer (GWLB) 와 자체 방화벽 Appliance 를 거쳐 안전한 트래픽으로 확인 된 경우 Transit Gateway 를 통해 내부 VPC 로 접근할 수 있습니다.

[다이어그램1. 굿리치 마이그레이션 아키텍처 오버뷰]

법인보험대리점에서는 보험업의 특성상 다양한 마케팅 활동이 발생하고 이를 지원하기 위하여 여러 부서의 내부 사용자와 마케팅에 참여하는 고객들이 이용하는 서비스를 개발 및 운영합니다. 원할한 비지니스 지원을 위해 워크로드를 안정적으로 운영할 수 있어야 하며, 늘어가는 사용자의 트래픽에도 대비할 수 있도록 확장성있게 아키텍처 설계를 할 수 있어야 합니다. 멀티 어카운트 전략에 따라 인프라와 애플리케이션 서비스들을 분리된 AWS 계정에 배포하였습니다. 이를 통해 계정 단위로 자원 격리, 권한 관리, 비용 추적 등이 용이해졌습니다. 또한 각 계정의 VPC와 보안 그룹, IAM 정책 등을 독립적으로 관리하여 보안성과 가용성을 강화할 수 있을 것으로 기대하였습니다.

DNS 마이그레이션: 온프레미스 DNS에서 HAQM Route 53으로

대부분의 엔터프라이즈 환경에서는 온프레미스를 유지하며 클라우드와 하이브리드 아키텍처를 구성하게 됩니다. 따라서 온프레미스 DNS 인프라를 유지하면서 클라우드 DNS 의 통합 관리가 주요 관심사가 됩니다. 반면에 굿리치는 여전히 사무실에 업무 및 개발 환경을 유지하지만 클라우드 상에 IT 자원을 관리하는 것을 목표로 하므로 도메인을 관리하는 DNS 인프라 또한 클라우드에서 일원화 하여 운영 가능한 방안을 검토하여야 했습니다. 따라서 온프레미스에서 관리되던 DNS 자원을 전부 클라우드로 이관하여 운영할 수 있는 아키텍처 설계가 필요했습니다. 여기에는 수백개에 이르는 다수의 Public, Private 도메인을 관리할 수 있어야 하는 확장성이 주요 고려사항이 되었습니다. 특히 DNS 인프라의 장애는 서비스의 장애를 넘어 비지니스 장애로 이어질 수 있으므로, 안정성은 강조하지 않을 수 없습니다. 이를 위해 기존 온프레미스에서 운영 중이던 DNS(Domain Name System) 인프라를 HAQM Route 53으로 마이그레이션하기로 결정했습니다.

DNS 는 도메인 이름을 머신이 읽을 수 있는 IP 주소로 변환합니다. 엔터프라이즈 환경에서는 이와 함께 도메인과 DNS 레코드를 관리할 수 있어야 합니다. 여기에는 외부에서 엔터프라이즈 자원에 접근할 수 있도록 Public DNS 를 관리하는 것과 더불어 내부 자원이 퍼블릭 인터넷에 노출하지 않은 DNS 레코드를 조회할 수 있는 Private DNS 를 운영 관리할 수 있어야 합니다. AWS 에서 제공하는 대표적인 DNS 서비스가 HAQM Route 53 입니다. Public DNS 관리는 HAQM Route 53 을 활용할 수 있고, Private DNS 는 HAQM Route 53 Resolver 를 이용할 수 있습니다.

HAQM Route 53은 확장 가능하고 고가용성을 보장하는 클라우드 DNS 서비스입니다. 다음과 같은 주요 기능을 제공합니다:

도메인 등록 및 DNS 관리: Route 53을 통해 도메인을 등록하고 DNS 레코드를 관리할 수 있습니다. 수천 개의 도메인과 수만 개의 레코드를 관리할 수 있는 확장성을 제공합니다.
라우팅 정책: 지리적 위치, 지연 시간, 가중치 등 다양한 기준으로 트래픽을 라우팅할 수 있습니다.
상태 확인: 엔드포인트의 상태를 모니터링하고 트래픽을 정상 엔드포인트로 자동 라우팅할 수 있습니다.
보안: DDoS 완화, VPC 링크 등의 기능을 통해 보안성을 강화할 수 있습니다.

한편, Route 53 Resolver는 Route 53의 프라이빗 DNS 기능을 제공합니다. 주요 기능은 다음과 같습니다:

프라이빗 호스팅 영역: VPC 내부에서 사용할 수 있는 프라이빗 DNS 영역을 생성할 수 있습니다.
인바운드 엔드포인트: 온프레미스 네트워크의 DNS 쿼리를 VPC의 프라이빗 호스팅 영역으로 전달할 수 있습니다.
아웃바운드 엔드포인트: VPC 내부의 DNS 쿼리를 온프레미스 네트워크의 DNS 서버로 전달할 수 있습니다.

HAQM Route 53과 HAQM Route 53 Resolver를 함께 활용하면 온프레미스 DNS 인프라가 했었던 업무를 그대로 클라우드로 마이그레이션 할 수 있습니다.

기술적 해결 과정

DNS 마이그레이션을 위해 Route 53 도메인 이전, 온프레미스에서 Route 53 Private Hosted Zone에 대한 도메인 서비스 접근하기 위한 Route 53 Inbound Endpoint 구성, 멀티 어카운드 환경에서 통합된 도메인 관리를 위한 구성 등의 과제를 하나씩 수행하였습니다.

먼저 도메인 통합 관리를 위해 관리 계정에서 320여 개의 public hosted zone, 500개가 넘는 private hosted zone 및 서브 도메인을 포함하여 총 1,300여 개에 달하는 서브 도메인을 구성하였습니다. AWS Route 53에서는 계정 당 생성 가능한 호스팅 영역(zone 파일)의 초기 할당량이 500개 입니다. 1,300개의 존 파일 생성이 필요해서 AWS 서비스팀에 1,300개 존 파일 생성을 위한 할당량 증가를 요청해서 지원을 받았습니다.

DNS 마이그레이션 영역은 온프레미스에 있는 DNS 서버 뿐 아니라 DNS Resolver 기능까지 모두 다 AWS Route53으로 이전하기로 했습니다. 이를 위해 먼저 기 구성된 전용선 AWS Direct Connect 회선을 통해 온프레미스에 있는 클라이언트 단말 및 시스템에서 Route 53 Resolver 접근을 위한 Route 53 Resolver Inbound 엔드포인트를 생성하였습니다. 일반적인 Hybrid DNS 구성환경은 온프레미스에서 DNS Resolver를 유지하고, AWS 내 도메인에 대해서는 DNS Resolver에서 Route 53 Resolver Inbound 엔드포인트로 DNS 요청을 포워딩하는 구성입니다. 이번 마이그레이션은 온프레미스의 모든 DNS 기능을 AWS Route 53으로 이전해야 하기 때문에, 먼저 온프레미스 내 모든 클라이언트/시스템이 AWS Route 53 Inbound Endpoint 를 통해서 DNS 서비스가 가능한지 아래와 같은 간단한 PoC 환경을 구성하여 기능 점검을 실시했습니다. Direct Connect를 통해 온프레미스 내 클라이언트에서 Route 53 Resolver Inbound Endpoint로 DNS 쿼리를 요청하면, VPC 내 Route 53 Resolver로 전달되어, 미리 생성한 존 파일내 레코드를 검색하여 해당 DNS 레코드가 정상적으로 반환됨을 확인했습니다. 참고로 Inbound Endpoint는 최대 초당 10,000개의 쿼리를 처리할 수 있으며, 이중화 및 부하 부산을 위해 각 서브넷 별로 하나씩 생성하였습니다.

[다이어그램2. 굿리치 Client 의 DNS Resolving]

복수개의 계정에 다수의 VPC가 있는 클라우드 환경에서, 모든 VPC는 각자 필요한 도메인에 대한 호스트 존을 생성하는 대신에, 관리 계정에 공통으로 생성한 호스트 존 파일을 참조하도록 하는 “DNS 통합 관리 방안”을 고려했습니다. 이를 위한 전제조건은 각 VPC에서는 관리 계정의 호스트 존에 생성한 Private Hosted Zone 도메인 검색 뿐 아니라, 자신의 VPC내에 생성한 AWS 관리형 서비스 리소스 (예, DB, 로드밸런스 등)에 대한 도메인 및 인터넷 Public 도메인 검색이 모두 가능하도록 설계를 하는 것이었습니다. VPC에 생성한 AWS 관리형 서비스 리소스에 대해서는 AWS에서는 호스트 이름(DNS name)을 부여하고, 자체적으로 운영하는 호스트 존(Hosted Zone) 파일내에 등록하여 관리합니다.

[콘솔 화면 1. VPC에 생성한 NLB 에 대한 DNS 이름과 Hosted zone 정보]

AWS Route 53 Resolver는 DNS 쿼리에 대해서 VPC에 연결된 고객이 생성한 Private 호스트존 도메인 이름, AWS가 자체적으로 운영하는 관리형 서비스 리소스에 대한 호스트 존 도메인 이름, 그리고 전달규칙에 정의한 도메인 이름들 중에 가장 길게 일치(longest match)한 도메인 이름에 해당하는 Zone 파일을 검색하여 레코드를 반환합니다. 그리고 기본적으로 .(Root Domain) 에 대해서는 퍼블릭 인터넷 도메인을 통해 쿼리하도록 전달규칙이 default로 설정되어 있습니다.

[콘솔 화면 2. . (Root Domain)에 대해서 퍼블릭 인터넷 도메인을 통해 쿼리하도록 모든 VPC에 기본적으로 설정된 전달규칙]

위와 같은 AWS Route 53 Resolver의 기본 동작방식을 참고하여 설계한 DNS 통합관리 방안은 2가지 방법을 검토했습니다.

첫번째 방법은 아래와 같이 관리 계정에서 생성한 도메인 별 호스트 존을 다른 계정의 모든 VPC 에 연결(associate)하는 간단한 방식으로 구현이 가능합니다. 도메인 관리는 관리 계정내에서만 호스트 존 파일을 관리하며 다른 계정에서는 DNS에 대한 관리 및 설정 없이, 자신의 VPC 내에 생성한 리소스에 대한 도메인 및 관리 계정에 생성한 private, public 도메인을 모두 조회할 수 있습니다.

[다이어그램 3. Private Hosted zone을 여러개의 VPCs에 연결]

[콘솔 화면 4. Private hosted zone 도메인에 여러개의 VPCs를 연결(associate)하기]

참고로, 다른 어카운트의 VPC를 연결하는 것은 웹 콘솔이 아닌 AWS CLI, SDK 또는 Route 53 API를 통해서만 가능합니다.

두번째 방법은 온프레미스에서 Route 53 Resolver Inbound Endpoint 통해서 관리 계정의 Route 53 Resolver에 DNS 질의를 보내는 방식을 다른 VPC 에서도 그대로 사용하도록 구성하는 것입니다. 차이점은 온프레미스에서는 모든 client나 시스템에서 직접 Route 53 Resolver Inbound Endpoint를 Resolver로 직접 지정한 반면, VPC 에서는 디폴트로 제공하는 Route 53 Resolver를 사용하고, 해당 Resolver에 별도의 포워딩 규칙을 정의하여 모든 DNS 쿼리를 관리 계정에 생성한 Inbound Endpoint로 포워딩하도록 설정합니다.

[다이어그램 4. Inbound Endpoint를 이용하여 Route 53 DNS 통합관리]

이 방법을 사용하면, 모든 DNS 쿼리가 관리 계정의 Route 53 Resolver를 통해서 처리되기 때문에, 관리 계정의 Route 53 Resolver에서 DNS 관련 모니터링 및 방화벽 기능 등을 적용하여 중앙 통제가 가능하다는 장점이 있습니다. 하지만, VPC에서 오는 DNS 쿼리가 Transit Gateway를 통해 Inbound endpoint로 들어오기 때문에 Transit Gateway와 Inbound endpoint에서 DNS 데이터에 대한 처리 비용이 발생합니다. 현재는 이 방법을 통해서 구현이 된 상태이며, 비용 및 운영의 효율성을 고려해서 첫번째 방법, 즉 각 VPC에서 관리 계정의 호스트 존 파일을 직접 연결(associate) 하는 방법으로 전환도 검토하고 있습니다. 참고로, 방안 1 처럼 각 계정에서 Route 53 Resolver를 각각 독립적으로 이용하는 경우, DNS firewall manager 서비스를 이용하여 계정별 DNS 방화벽 규칙을 중앙에서 구성하고 관리할 수 있습니다.

DNS 마이그레이션 실행

DNS 마이그레이션 과정에서는 무중단 운영을 최우선 목표로 삼았습니다. 기존 DNS 인프라와 Route 53을 병행 운영하며, 점진적으로 도메인과 레코드를 이관해 나갔습니다. 먼저 AWS Route 53에 온프레미스에서 관리하고 있는 Public Hosted Zone과 Private Hosted Zone 도메인을 동일하게 생성하였습니다. 레코드의 수가 많아 작업량이 많은 어려움은 있었으나 기존 온프레미스에서 운영하는 도메인 서비스에 영향이 전혀 없기 때문에 DNS 서비스에는 아무런 영향을 미치지 않았습니다. 일반적으로 DNS 레코드 변경이 완전히 전파되어 모든 사용자에게 반영되기까지는 최대 48시간 정도가 소요됩니다. 이는 DNS 레코드의 TTL(Time To Live) 값에 따라 달라질 수 있는데 외부 사용자를 고려하여 수일 전 작업을 완료하여 마이그레이션에 의해 갑작스런 도메인 레코드 변경에 따라 서비스에 접근할 수 없는 문제를 예방하였습니다. 내부 사용자가 접근하는 클라이언트에서는 DHCP (Dynamic Host Configuration Protocol) 서버에서 DNS 정책을 변경하여 전파할 수 있어 내부 사용자 서비스에 큰 영향은 없었습니다. 최종적으로는 nslookup 커멘드로 변경 확인 후 기존 레코드를 제거해나갔습니다. 또한 이 과정은 HAQM CloudWatch 와 내부 모니터링 툴을 활용하여 서비스 접근 이상 유무를 확인하여 마이그레이션을 최종 완료할 수 있었습니다.

결론 및 교훈

DNS 마이그레이션 프로젝트를 통해 굿리치는 안정적이고 확장 가능한 DNS 인프라를 구축할 수 있었습니다. 특히 Route 53 Resolver를 활용하여 프라이빗 DNS 관리까지 일원화할 수 있었던 점이 큰 성과였습니다.

이 과정에서 얻은 주요 교훈은 다음과 같습니다:

철저한 계획 수립과 단계적 실행: DNS 마이그레이션은 서비스 전반에 걸쳐 큰 영향을 미치므로, 면밀한 계획 수립과 단계적인 실행이 필수적이었습니다. 점진적으로 도메인과 레코드를 이관하며 모니터링하는 접근법을 통해 무중단 운영을 달성할 수 있었습니다.
효과적인 도메인 및 레코드 통합 관리: 다수의 도메인과 레코드를 효과적으로 관리하기 위해 중앙 집중식 DNS 관리 방안을 도입하였습니다. 관리 계정 중심의 호스팅 영역 생성 및 다른 계정의 VPC와 공유하는 방식으로 통합 관리를 실현할 수 있었습니다.
지속적인 보안 강화 필요성: 마이그레이션 이후에도 DNS 보안 강화를 위해 DNS Firewall 도입과 도메인 차단 관리 자동화 등의 방안을 고려하고 있습니다. 빠르게 변화하는 보안 위협에 대응하기 위한 지속적인 노력이 필요할 것으로 판단됩니다.

향후 굿리치는 DNS 인프라의 안정성과 확장성을 바탕으로 더욱 견고한 IT 환경을 구축해 나갈 계획입니다.

참조 자료

What is HAQM Route 53 Resolver?

AWS 기술 블로그