01.15.23{개발일기} 가비아에서 구매한 개별 도메인 netlify에 배포 자동화 셋팅 및 HTTPS 도메인 인증
개요
DNS 구성 요소 및 네임서버에 대한 개념없이 그저 강의에서 알려주는 대로 따라 셋팅 했을 때 초기 배포엔 문제가 없었습니다. Netlify에서 제공해주는 도메인이 아닌 가비아 DNS 호스팅 서비스에서 구매한 도메인 주소를 Netlify 네임 서버로 연결 시도했을 때, 해당 도메인 주소로 호스팅 서비스 연결이 안되었을 뿐만 아니라, 기존에 배포했던 도메인 주소로 자동 배포까지도 작동이 안되었습니다. 해당 문제를 해결하는 과정에서 알게 된 내용을 기록하고자 본 포스팅을 작성하게 되었습니다. 해당글은 2023년 1월 15일에 초안이 작성되고 1월20일 기준으로 최종 작성완료 된 글이기에, 이 글을 읽으시는 시점이 많이 최근이 아닌 경우, netlify 서비스 UI 및 호스팅 정책이 변경 될 수 있는 점도 참고하여 확인 하시길 바랍니다. 추가로 저는 금번 배포하는 프로젝트에 번들러를 적용하지 않았지만, 만약 적용하셨다면 package.json에서 build 명령어를 반드시 아래와 같이 추가해주어야 합니다.
//parcel 번들러 활용 예시
"build" : "parcel build index.html"
문제 발단
https://answers.netlify.com/t/support-guide-finding-the-ip-addresses-for-netlifys-nameservers/8366
[Support Guide] Finding the IP addresses for Netlify's nameservers
Last reviewed by Netlify Support: February 2022 When you configure Netlify’s DNS hosting, we create a list of nameservers that you’ll tell your domain registrar to use to complete transition to our DNS hosting service. It’ll look something like this:
answers.netlify.com
위 Netlify 문서를 참조하였을 때, 처음에는 Netlify DNS 네임서버 IP주소를 가비아에 반드시 등록해야 된다고 이해했습니다. 사실 가비아 DNS 네임서버만으로도 충분히 호스팅 서비스가 가능했는데, 이에 대한 지식이 없었기 때문에 발생한 문제였습니다. 관련 배경 지식은 초기 셋팅과정 오류를 설명한 후, 가비아에 있는 문서를 기반으로 다시 설명드리겠습니다. 초기 셋팅과정은 아래와 같습니다.
가비아 서비스관리 > 도메인 통합관리툴에 들어가면 홈>도메인정보변경 탭에서 현재 구매한 도메인 주소 정보를 변경할 수 있습니다. 도메인 주소 정보 변경을 원하는 주소를 클릭하고, Netlify 문서 가이드에 나와 있는 Netlify 호스트 네임서버 IP주소를 4개 등록했습니다.
그리고 홈>전체도메인>도메인상세페이지>DNS설정탭에 들어가서 연결할 도메인 DNS 정보를 설정했습니다.
위 버튼을 클릭 후 DNS 정보를 설정할 때, recommend가 아닌 후자 방법으로 설정했습니다. 위 주소는 임시로 만든 주소라서 도메인이 특이한 점 양해바랍니다.
이때, CNAME이 무엇인지 ALIAS, ANAME이 무엇인지 몰라서 첫번째 권장하는 방법이 아닌 두번째 대체 방법의 A record 형식으로 DNS 정보를 설정했습니다.
위와 같은 방법으로 설정했을 때 배포 및 배포자동화 문제 모두 동시에 발생 했었습니다.
호스트 서버와 도메인 및 DNS 구성요소
문제의 원인을 분석하기에 앞서 해당 문제와 관련된 배경 지식부터 설명드리겠습니다. 과거, 한대의 컴퓨터에서 다른 컴퓨터 서버에 데이터 요청을 보내려면 해당 컴퓨터 네트워크 주소를 알아야 했고, 개별 호스트들은 hosts.txt라는 파일로 다른 호스트의 정보를 NIC에 저장해서 보관했고 필요한 경우에 다운받아 사용했습니다. NIC는 네트워크 안에서 컴퓨터끼리 통신하는데 쓰이는 하드웨어 중 하나입니다. 이때 네트워크에 연결된 컴퓨터 또는 모바일 기기 및 기타 장치를 모두 네트워크 호스트라고 정의합니다.
만약, 수십, 수백, 수천대 혹은 수십억대의 호스트 정보를 하나의 호스트 서버가 알아야 한다면 어떻게 될까요? hosts.txt 파일용량이 너무 커질 것입니다. 반대로, 한대의 호스트 서버가 가지고 있는 hosts.txt 파일을 수십억대의 호스트들이 동시에 다운받아야 한다면 어떻게 될까요? 마치 명절에 고속도로 휴게소의 좁은도로에 수천대의 차량이 몰려 한꺼번에 빠져나가는데 어려움을 겪는 '병목현상'이 네트워크 처리과정에서 발생할 것입니다. 결국, 요청 응답 처리 속도가 매우 느려져 성능 저하를 겪게됩니다. 나아가서는 개별 호스트들 중 중복된 이름을 설정할 경우, 이름은 같지만 다른 서버로 접속하는 문제가 발생할 수 도 있습니다.
이런 문제를 해결하기 위해, 여러개의 기관에서 책임지고 호스트들을 개별 영역으로 관리하게 되었습니다. 우리나라에선 대표적으로 '가비아'에서 호스트를 관리합니다. 앞서 Netlify도 호스트를 관리하는 개별 기관 중 하나에 속합니다. 이러한 개별기관 모든 영역을 관리하는 기관이 바로 ICANN 산하의 IANA입니다. 각각의 관리 영역은 점(.)으로 구분하여 표시하며, 표현문법은 아래와 같습니다.
호스트 이름(WWW).호스트관리기관 영역(GABIA).최상위영역(COM)
호스트 이름(WWW).호스트관리기관 영역(GABIA).최상위영역(ORG)
-> 왼쪽에서 오른쪽 방향으로 '야, 너 애알아?' 이런느낌으로 도메인을 알고 있는 관리기관을 모든 DNS에서 찾는다.
하위영역에서 '다 모름ㅇㅅㅇ'이라고 응답한다면 최상위 영역의 DNS에서 찾게된다.
이처럼 최상위 영역부터 하위 영역의 관리기관을 DNS(Domain Name Server)라고 합니다. 각 관리 기간은 책임지는 영역의 호스트 정보가 담긴 데이터를 'zone 파일'이라는 곳에 저장합니다. 예를들면 Netlify DNS의 zone파일에는 www, domain, hosting등의 Netlify가 관리하는 영역의 호스트 이름과 주소가 담긴 정보가 들어있습니다. 만약 다른 호스트로부터 Netlify의 www호스트를 찾는 요청이 있으면, 연결된 해당 ip주소를 찾아서 알려주는 역할을 하는것이 Netlify DNS입니다.
DNS 동작원리
그렇다면, 우리가 모바일 폰으로 구글브라우저에서 넷플릭스 서비스에 접속한다고 가정해봅시다. 'www.netflix.com'을 입력하고 엔터를 치면 무슨 일이 발생할까요?
브라우저는 어떻게 하위요소 개별기관 및 최상위 기관요소에 접근해서 넷플릭스 웹페이지 정보를 가져올까요?
우리는 그냥 'netflix.com' 도메인 주소만 입력할 뿐인데, 어떻게 미국 캘리포니아에 있는 netflix 호스트 서버까지 찾아내서 요청을 보낼 수 있는걸까요?
물론 netflix서버가 반드시 미국에만 있는 것은 아닙니다. 2011년에 넷플릭스는 자체 CDN 및 데이터센터를 전세계에 구축했지만, 이해를 돕기위해 미국 캘리포니아에만 존재한다고 가정합시다.
만약 한 명이 아닌 전세계 2억명이 넘는 넷플릭스 유저가 동시에 넷플릭스 서버에 요청을 보낸다면
2억개가 넘는 요청을 넷플릭스 서버는 어떻게 처리할까요?
질문들이 많았는데 위 질문들의 모든 답은 DNS 동작원리에 있습니다. 앞서 언급했듯이, 우리는 표면적으로 홈페이지(WWW)라는 관문을 통해 연결되어 있는 넷플릭스를 포함한 각종 서비스를 이용하지만, 사실 해당 서비스를 제공하는 것은 개별 호스트서버에 포함된 'WWW 서버, 메일서버, 도메인서버, 호스팅 서버'입니다. 예를들면, 넷플릭스 호스트 서버에는 WWW서버, 메일서버,도메인서버, 호스팅 서버가 포함된 구조입니다. 이러한 서버들의 정보(IP와 서버이름)를 가지고 있는 관리하는 개별기관이 가비아 혹은 Netlify DNS라고 이해하시면 됩니다. 우리가 넷플릭스 주소를 브라우저 주소창에 입력해 엔터를 치면 곧바로 해당 DNS를 찾아갈 수 없습니다. 우선 가장 가까운 DNS의 zone 파일정보에 'www.netflix.com' 라는 요청 정보가 있는지 확인합니다. 아래 그림을 보면 우리가 돈을내고 인터넷을 사용하는 ISP서버에서 관리하는 DNS resorver라는 프로그램이 최상위 루트네임서버에 곧바로 요청을 보내는게 아닙니다.
가장 가까운 DNS에도 찾는 정보가 없으면 그때 3번 DNS 루트 네임서버에 'www.netflix.com' 정보요청을 전달합니다. 그러면 루트네임서버에서는 도메인 최상단 루트인 '.com' 도메인의 TLD(Top Level Domain)서버 중 하나에 'www.netflix.com' 정보요청을 전달합니다. 이때 만약 'www.netflix.net'이면 '.net' 도메인의 TLD로 가게 됩니다. 참고로 TLD 종류는 셀수없이 매우 다양합니다.
TLD 네임서버중 'www.netflix.com'정보를 아는 서버가 있으면, 이 서버는 요청한 정보에 해당하는 도메인과 관련된 네임서버 중 하나에 대한 정보를 DNS resorver에 반환합니다. 그 다음, 응답받은 네임서버 주소에 다시 'www.netflix.com'를 아는지 묻게 되고, 해당 네임서버가 요청한 도메인주소와 호스트 IP주소를 알고 있다면, IP주소를 resorver에 반환하게 됩니다.
그러면 DNS resorver는 그 즉시 해당 IP주소를 클라이언트 브라우저에 반환하게 되고, 브라우저는 응답받은 IP주소를 통해 HTTP/HTTPS통신으로 웹페이지를 요청하게 됩니다. 이때 ISP서버는 반환 받은 IP주소를 일정시간 캐시서버에 저장하고 있다가, 동일한 도메인으로 재요청이 들어오면 즉시 응답을 반환합니다. 이를통해 요청시간을 줄일 수 있습니다. 참고로 넷플릭스는 Amazon의 웹서버 인스턴스를 엣지 서버로 사용하고 있습니다.
미국 캘리포니아 주에 있는 넷플릭스 원본 서버에 요청을 보내지 않더라도, 위와 같은 AWS 엣지서버에 넷플릭스 웹페이지 정보를 담아 보관하고 있습니다. 엣지서버는 POP(Points Of Presence) 형태로 전세계 지역 곳곳에 캐시서버로 배치되어 있는 서버를 의미합니다. 만약 해당 IP주소로 요청이 들어오면 트래픽을 처리하여 거리상 멀리있는 서버와의 물리적인 한계를 해결 해줍니다. 나아가서는 정적데이터의 양이 무한대로 커지면 이와이와 관련된 개념이 CDN입니다. 추후 CDN 아키텍쳐에 관한 글도 포스팅할 예정입니다.
문제 해결방법
호스트서버와 DNS구성요소 및 동작원리 등 배경설명이 필요했던 이유는 앞서 서론에 언급한 배포 문제의 원인과 관련 되었기 때문입니다. 문제의 원인은 크게 2가지였습니다. 첫째는 bluevulpe.com과 연결된 네임서버를, 만료된 Netlify 네임서버 주소로 설정한 점과, 둘째는 DNS레코드 용도를 모르고 사용하여 가비아에서 CNAME레코드가 지원되는데도 불구하고 A 레코드로 설정했던 점이었습니다. 사실 당시엔, 네임서버 용도도 제대로 이해하지 못하고 설정했었습니다. 디폴트로 설정된 가비아 호스트 네임서버로 설정 하더라도, Netlify 가이드 문서에서 안내해주는 IP주소로 DNS레코드 값을 설정시 문제를 해결할 수 있었습니다. 참고로 가비아에선 가비아 호스트 네임서버 정보를 자동으로 설정해주는 버튼이 우측 상단에 존재합니다.
아래와 같은 지식과 DNS 구성 요소 및 호스트 네임서버와 DNS 동작원리에 대한 이해를 갖추고 난후 문제의 원인을 더욱 빠르게 진단하기가 수월했습니다.
결론
위에 원인들을 파악한 뒤 문제를 해결하고, verification 인증 후 2시간만에 정상적으로 잘 https 관련 인증서도 발급 되었음을 확인할 수 있었습니다. 설정 방법은 아래 사진 첨부합니다.