프론트엔드와 벡엔드를 어떻게 분리해야하는지 공부하다가
API 서버와 REST API가 나와서 이걸 공부하다보니 api 서버의 주소를 api.example.com 과 같이 쓰기도 한다는 점에서 저 도메인도 별도로 등록을 해야하나? 그건 좀 귀찮겠는데? 싶어서 도메인을 공부해봤다.
- 도메인 (Domain)
내가 알고 있는 도메인은 IP 주소를 매번 기억할 수 없으니 이름을 붙여준 것으로 알고 있었다.
'대한민국 국민중 주민번호가 000509-3...... 인 사람' 은 너무 길고 복잡해서 알 수 없으니 '홍길동' 라는 이름을 붙여준 것과 같다고 이해했다.
차이가 있다면 이름은 겹칠 수 있지만, 도메인은 겹칠 수 없다는 것 정도?
193.122.xxx.xxx 라는 내 서버에 아이피주소를 다른 사람에게 외우도록 할 수 없으니
everdu.ga 라는 영어이름으로 도메인을 붙여주는 느낌이다.
- 호스트네임? 서브도메인?
둘다 같은 말이다.
네이버 웹툰의 주소를 보면 대충 이런 식이다.
comic.naver.com
여기에서 naver.com 은 도메인이고, comic 은 엄밀하게 '호스트네임' 이다.
인터넷에서 정말 좋은 비유를 봤는데, 도메인은 외부에 공개된 회사번호, 호스트네임은 회사 내에서 사용하는 내선번호로 비유할 수 있다고 한다.
네이버 (naver.com) 에서 서비스하는 여러 웹어플리케이션 중, '웹툰' 이라는 서비스는 comic 이라는 서브도메인으로 빼서 관리하는 것이다.
우리가 흔히 쓰는 www.naver.com 이라는 주소에서도, www 는 호스트네임이다.
- CNAME?
이렇게 서브도메인을 관리할 때, CNAME 을 설정한다.
도메인주소를 구매하면 우리가 얻는 도메인은 'naver.com' 까지만 얻는다.
이제 여기에서 서비스를 분리하기 위해 앞에다가 이것 저것 호스트네임을 붙이면서 도메인주소를 세분화시킬 수 있다.
도메인을 구매한 곳에서 도메인 관리페이지로 가면 다음과 같이 도메인 명을 관리할 수 있는 창이 나온다.
CNAME 과 A 라는 타입이 나뉘어있다. 내가 이해한 바로는 정말정말 간단하게 아래와 같이 정리할 수 있다.
A => 아이피주소를 직접 매칭해서 도메인 네임서버에게 질의하는 단계를 줄임, 대신 IP주소가 바뀌면 일일히 바꿔야함.
CNAME => 연결될 도메인을 매칭해서, 입력한 도메인을 Target 도메인으로 요청해서 단계가 늘어남. 대신 IP주소 변동에 유동적으로 대응이 가능함.
저 A 타입 앞에 아무런 칸이 없는데, 이는 기본 도메인을 의미한다. (Name 에는 호스트명만을 적으므로, 호스트명이 없으면 기본 도메인이다)
즉 naver.com 이라는 도메인에는 Type A 로 직접 IP 주소를 매칭해서 193.122.xxx.xxx 로 직접 연결지어주도록 한 것이고,
호스트를 넣어서 ftp.naver.com 이라는 도메인에는 Type CNAME 으로 연결될 도매인을 매칭해서 naver.com 으로 연결하도록 한 것이다.
마찬가지로 www.naver.com 이라는 도메인에도 Type CNAME 으로 연결될 도메인을 매칭해서 naver.com 으로 연결하도록 세팅한다.
우리가 흔히 주소창에 웹사이트 주소를 칠 때 www 를 생략하고 치든, 넣고 치든 동일한 사이트로 이동하는 이유가 이 호스트네임 세팅때문이다.
거꾸로말해서 이 세팅이 간혹 안되어있는 사이트가 있는데, 그런 사이트는 www 를 넣어서 치면 접속이 안된다.
이제 내가 고민했던 부분이 해결되었다.
api.example.com 은 example.com 이라는 하나의 도메인의 서브도메인으로서 api기능을 서비스하는 도메인인 것이다.
Type은 이 밖에도 여러개가 더 있긴한데, 그 부분까지는 지금 당장 필요한 지식이 아니라고 생각해 공부하지 않았다.
메일 교환? 텍스트? 뭐 이런 타입이 있긴 한데, 서브도메인이 수행할 기능을 명시적으로 분류해놓은 느낌같기도 하고..
- TTL
저 이미지를 보면, TTL 을 설정하는 곳이 있다.
이는 이 도메인의 세팅 정보가 유효한 유효기간이다.
우리가 도메인을 치면 내부적으로 도메인과 IP 를 쌍으로 연결지은 정보를 모아놓은 '네임서버' 라는 곳에 이 도메인 주소에 연결된 IP 를 질의하게 된다.
이때 이미 한번 질의해서 받아놓은 도메인-IP 정보를 매번 네임서버에게 요청하는 것은 네임서버 입장에서도, 요청하는 입장에서도 번거롭고 귀찮은 일이 아닐 수 없기 때문에, 이 정보를 일정시간동안 컴퓨터에 저장해둔다. (캐싱)
바로 이 TTL이 얼마나 저장해둘 것인지 설정하는 것이다.
보통 도메인주소에 연결된 IP가 바뀌는 일은 거의 없어서 길게 길게 설정한다고 하는데, IP가 바뀔때만 잠깐 짧게 설정해두어서
우리 웹사이트에 방문할 많은 고객들이 바뀐 IP 주소를 캐싱해둘 수 있도록 한다고 하기도 한다.
일반적으로는 1시간 (3600초) 정도로 설정하기도 하고, 24시간으로 설정하기도 한다고 한다.
이 시간을 굉장히 짧게하면, 매번 도메인을 칠 때마다 네임서버에게 질의해야하니 네임서버의 부하가 커지지만, 그만큼 도메인 레코드 정보를 최신으로 캐싱해둘 수 있고
이 시간을 길게하면 네임서버의 부하가 줄어들지만, 캐싱된 정보를 상대적으로 덜 최근의 정보를 캐싱하게 된다.
이 공부를 하고나니 백엔드와 프론트엔드를 어떻게 분리할 수 있는지 이미지가 구체적으로 그려지기 시작했다.
프론트엔드에서는 html/css/javascript 로 된, 실제로 웹 브라우저에게 전송될 "파일"을 서비스한다.
그리고 프론트엔드의 버튼을 클릭해서 이런 저런 요청을 URL로 보낼텐데, 이 요청을 담당하는 서버를 별도로 두고
(백엔드 api서버, 아마 여기에서 사용할 URL이 api.example.com/REST/API/REQUEST 이런 느낌일 것 같다)
이 api 서버는 요청받은 URL에 따라 라우팅 함수를 통해 요청한 데이터를 가져와서 요청받은 대로 처리한 다음
그 결과를 JSON 형태로 가공해서 프론트엔드 서버로 전송한다.
그럼 프론트엔드 서버는 돌려받은 JSON 응답을 파싱해서 UI에 잘 뿌려 넣어 html 파일을 만들고, 만들어진 파일을 다시 클라이언트에게 보내주면 된다.
