경로 기반 라우팅과 서브도메인 관리: 문제와 해결 방안
무슨 문제가 있길래?
우리 서비스는 경로 기반 라우팅을 사용하고 있지만, 레거시 서비스가 여전히 운영 중이라 서브도메인을 완전히 배제할 수 없는 상황이다. 현재 제공 중인 서비스는 총 5개, SSO, 어드민 페이지 2개, SSL 인증, SES 인증 레코드 4개(DKIM 등)를 포함하면 10개 이상이 되는데 W/L을 사용하려는 고객은 이 레코드들을 모두 등록해야 한다.
DNS 이름 | 값 | |
서비스 | app | app.service.com |
어드민 | admin | admin.service.com |
SSO | sso | sso.service.com |
그 외... |
이 많은 정보를 고객에게 요청하면, 항상 이런 질문이 나온다.
뭐가 이렇게 등록하는게 많아요?
아무리 구조를 설명해도 고객의 부정적인 반응을 피하기 어려웠었다.
레거시 서비스의 한계
가장 간단한 해결책은 레거시 서비스를 종료하고 모든 것을 경로 기반으로 전환하는 것이다. 하지만 내가 W/L을 편하게 구축하기 위해서 사용중인 레거시 서비스를 강제로 끝낼수도 없었다. 그리고 또 다른 문제가 발생할 수 있다.
예를 들어, 다른 개발팀이 신규 서비스를 출시하면서 경로 기반 라우팅 정책을 모르고 고정된 서브도메인으로 서비스를 열어버린다면, W/L 사용 중인 모든 고객과 다시 커뮤니케이션하며 도메인을 등록해야 한다.
이 과정에서 커뮤니케이션 비용이 크게 증가하며, 반복되는 작업으로 인해 업무 효율성은 떨어지고 스트레스만 쌓이게 될 것이다.
커스텀 서브도메인의 문제
또 다른 문제는 일부 고객이 커스텀 서브도메인을 요구할 때 발생한다.
예를 들어, "일반적인 서브도메인은 보안에 취약하니 -ours를 추가해달라"는 요구가 있었다.
그 결과 app-ours.customer.com 같은 형태로 만들어야 했고, 레거시 환경에서는 리다이렉트를 처리하기 어려웠다.
결국 모든 서비스 담당자들에게 예외 처리를 요청하고, 배포 및 검증 작업까지 해야 했다. 이는 인력 리소스의 낭비로 이어진다.
Route53 Hosted Zone
이런 문제를 해결하고 고객 불만을 줄이며 작업량을 최소화할 방법을 찾던 중 Route53의 호스팅 영역(Hosted Zone)을 활용하기로 했다. 호스팅 영역의 가장 큰 장점은 고객이 한 번만 인증을 완료하면, 이후 도메인 레코드는 우리가 관리할 수 있다는 점이다. 고객과의 커뮤니케이션 과정 없이 유지보수가 가능하며, 도메인 소유권을 넘기지 않고도 트래픽 제어 권한을 할당받아 안전하게 작업할 수 있다.
호스팅 영역 도입의 원리
- 고객 도메인의 확장
예를 들어, 고객 도메인이 customer.com이라면, 우리는 이를 ours.customer.com으로 확장해 관리한다.
이렇게 하면 app-var.ours.customer.com이나 admin-hey.ours.customer.com처럼 다양한 서브도메인을 Route53 호스팅 영역에서 손쉽게 처리할 수 있다. - 고객이 해야 할 작업
고객은 호스팅 영역 생성 시 제공되는 NS 레코드 4개를 등록하기만 하면 된다. 이 작업은 한 번만 하면 되며, 이후 신규 서비스가 추가되더라도 고객은 더 이상 신경 쓸 필요가 없다.
SSL 인증과 SES 인증
SSL인증
SSL 인증은 3차 도메인에서 이루어진다.
ACM을 생성한 후, 해당 레코드를 호스팅 영역에 등록하고, NS 레코드를 고객이 등록하면 SSL 인증이 완료된다. 이 과정에서 고객은 별도의 SSL 인증 레코드를 관리할 필요가 없다.
SES인증
화이트라벨(W/L)의 발신자 이메일은 보통 메인 도메인을 사용한다. SES 인증은 호스팅 영역 대신 고객 DNS에서 직접 레코드를 등록해야 한다. 만약 이 방식이 불편하다면, 발신자 이메일을 우리 서비스 도메인으로 사용하는 선택지를 제공할 계획이다.
결론
Route53 호스팅 영역을 통해 복잡했던 DNS 관리와 서브도메인 요청 문제를 간소화할 수 있다.
고객과의 커뮤니케이션 비용을 줄이고, 우리의 작업 효율성을 높이며, 보다 안정적인 운영 환경을 구축할 수 있을 것이다.
'정리해봐요 > White label 자동화 여정' 카테고리의 다른 글
01. 지금 운영하는 White label의 구조는 어떠한가? (0) | 2024.12.22 |
---|