요약

  • Cloudflare는 기존 SaaS 업체의 정확한 호스트 이름이 새 업체의 와일드카드보다 우선해, CNAME을 바꾼 뒤에도 기존 콘텐츠가 나오는 경우를 설명한다.
  • 새 업체는 해당 호스트 이름을 개별 등록하는 대응을 할 수 있다. 호스트와 인증서 준비, DNS 전환, 실제 요청의 도착 확인을 마친 뒤 기존 설정을 정리해야 인수가 완료된다.

이전 완료 메일과 손님의 화면

쇼핑몰 이전 상황을 가정해 보자. 계약 담당자는 새 계약서를 받았고, 기술팀은 DNS 변경을 끝냈다. 프로젝트 담당자는 완료 메일을 보낸다. 손님이 익숙한 주소를 열자 옛 페이지가 나온다. 암호화 연결도 정상이다. 각 팀의 증빙은 있는데 손님이 도착한 곳만 다르다.

Cloudflare의 문제 해결 문서에는 이런 결과를 낳을 수 있는 조합이 나온다. 기존 SaaS 업체가 특정 호스트 이름을 등록하고 새 업체가 와일드카드를 구성했다면, CNAME 업데이트 뒤에도 예전 설정이 우선할 수 있다.

계약은 날짜를 보고 새 업체를 골랐다. 요청 처리 규칙은 이름을 얼마나 정확히 지정했는지를 본다. 서류상의 교체를 실제 서비스 교체까지 전달하는 일이 남아 있는 셈이다.

정확한 주소가 넓은 안내판보다 앞선다

mystore.example.com처럼 하나의 이름을 등록하면 정확히 그 주소를 지정한다. 와일드카드는 여러 이름을 넓게 처리한다. 관리할 항목을 줄이는 데는 후자가 편하지만, 기존의 개별 지정과 만나는 이전 현장에서는 순서를 확인해야 한다.

Cloudflare의 호스트 이름 우선순위는 여러 영역에 같은 이름의 프록시 레코드가 있을 때 하나만 영역 설정과 연결된 원본 서버를 제어한다고 설명한다. 이 조건에서는 정확히 일치하는 이름이 와일드카드보다 먼저 온다. 문서의 사례에도 기존 방식의 정확한 호스트 이름이 새 와일드카드보다 우선하는 조합이 등장한다.

새 사업자는 많은 고객을 한꺼번에 받기 쉬운 규칙을 택했을 수 있다. 그 고객의 이전 설정은 한 주소만 정확히 붙잡고 있을 수 있다. 일괄 관리로 절약한 수고에는 개별 고객이 이동할 때 확인해야 할 일이 붙는다.

고객의 선택은 이미 분명하다. 그러나 선택이 요청의 목적지로 바뀌려면 새 업체의 등록과 고객의 DNS 변경이 같은 주소에서 맞물려야 한다. 둘 중 하나의 완료 보고만 받으면 납품의 마지막 구간이 비어 있게 된다.

새 업체가 바로 확인할 항목

Cloudflare는 새 공급자가 와일드카드 대신 해당 호스트 이름을 구체적으로 등록하도록 요청하는 방법을 권장한다. 계정의 Super Administrator가 Cloudflare Support에 SaaS 설정 업데이트를 요청하는 경로도 제시한다.

인수 회의는 새 업체가 이 정확한 주소를 등록했는지부터 물을 수 있다. 기존 업체가 고객을 붙잡는다고 단정하면 새 업체 쪽의 문서화된 해결 방법을 놓친다. 공개 자료에는 특정 고객의 설정 목록, 요청 로그, 중단 비용이 없어 개별 이전의 영향을 판단하려면 그 증거가 필요하다.

새 애플리케이션과 계약이 준비돼도 손님의 요청을 받지 못하면 구매한 서비스는 아직 제 역할을 시작하지 못한다. 생성 완료와 수정 완료를 모은 서류는 실제 서비스가 전달됐다는 증거와 연결돼야 한다.

자물쇠 표시가 수령증은 아니다

Cloudflare for SaaS 설정 안내는 호스트 이름 활성화와 인증서 발급·배포를 별도로 다룬다. 운영 트래픽을 받을 조건은 두 상태가 모두 active이고 DNS가 해당 SaaS 대상으로 향하는 것이다.

TLS 연결은 새 인증서가 active가 되기 전에 성공할 수도 있다. Cloudflare가 이름에 맞는 다른 인증서를 제시할 수 있기 때문이다. 암호화 연결의 성공으로 새 업체의 인증서 배포까지 완료됐다고 판정하면 다른 결과 두 개를 하나로 합친다.

대체 원본 서버의 active 상태도 범위가 정해져 있다. 안내서는 Cloudflare가 지정된 DNS 레코드로 트래픽을 보낼 준비가 됐다는 뜻이며, 올바른 원본 위치를 가리키는지는 확인해야 한다고 설명한다. 초록불이 켜진 준비 단계와 손님이 원하는 서비스에 도착한 결과를 구별해야 한다.

계약서에 기술 필드를 끝없이 붙일 필요는 없다. 정확한 호스트 이름의 활성화, 준비된 인증서, 올바른 DNS 대상, 새 영역과 예상 애플리케이션에서 실제 처리한 요청이 서로 맞는지 받으면 된다. 손님에게 보이는 결과는 마지막에 있지만 앞의 준비가 그 결과를 성립시킨다.

두 업체가 준비된 뒤에 넘긴다

호스트 이름 검증과 이전 안내에 따르면 여러 SaaS 업체가 같은 도메인에 대해 active인 사용자 지정 호스트 이름을 동시에 보유할 수 있다. 이미 Cloudflare에 있는 이름을 사전 검증해도 그 동작만으로 트래픽이 이동하지 않는다.

일반적인 권장 절차는 새 영역에 이름을 만들고 사전 검증을 마친 뒤, TXT나 위임된 검증으로 인증서를 준비하는 순서다. 이어 고객이 CNAME을 바꾸고 새 영역으로 트래픽이 옮겨 갔는지 확인한다. 그 뒤 기존 업체가 자기 설정을 삭제한다. 이 절차를 진행할 때 정확한 이름과 와일드카드의 우선순위도 함께 확인해야 한다.

준비 기간의 중복에는 가치가 있다. 기존 서비스가 자리를 지키는 동안 새 업체가 받을 준비를 할 수 있다. 반면 DNS 변경 뒤에 실시간 호스트 검증이나 자동 HTTP 인증서 검증을 진행하면 활성화를 기다리는 동안 짧은 중단이 생길 수 있다고 설정 안내서는 알린다.

기존 설정 삭제는 도착 확인 뒤의 마무리로 두는 편이 합리적이다. 너무 일찍 지우면 아직 필요한 준비를 버린다. 계속 남겨 두면 다음 장애 조사 때 읽어야 할 과거 설정이 늘어난다. 준비, 전환, 정리를 다른 사건으로 기록하면 인수 과정이 분명해진다.

고객이 업체를 바꾸면서도 기존 주소를 쓸 수 있다는 것은 중요한 자산이다. 그 주소 뒤에서 선택한 업체가 실제로 응대하도록 만드는 일까지가 이전 서비스다.