18. 웹 호스팅
네트워크/HTTP 완벽 가이드

18. 웹 호스팅

아주 작은 점 하나의 텍스트부터, 고화질의 동영상까지 리소스들은 정말 다양합니다. 이러한 리소스들을 웹 사이트에 편하게 배포하거나, 성능과 가격 모두 만족할만한 웹서버에 배치하는 것은 매우 중요합니다.

 

이렇게 리소스를 저장, 중개, 관리하는 일을 통틀어 웹 호스팅이라고 합니다. 이번에는 웹 호스팅에 대해 알아봅시다!

 

호스팅 서비스

초창기에는 각 회사가 컴퓨터 하드웨어 구매를 시작으로 컴퓨터 망 구축, 네트워크 연결 확보, 웹 서버 소프트웨어 관리까지 자체적으로 행했습니다. 하지만 점점 기술력이 높아 짐에 따라 그에 대한 필요 자원이 증가하고 또 많은 사람들에게 배포를 하다 보니 각 회사가 이를 감당하기가 힘들어졌습니다.

그래서 이들을 전문적으로 관리하는 웹 호스팅 서비스 회사가 생겨나게 되었습니다!

 

1. 전용 호스팅

클라이언트가 다른 누구와도 공유되지 않은 서버 전체 빌리는 인터넷 호스팅 종류입니다

웹 호스팅 서비스 회사는 많은 서버들을 가지고 여러 클라이언트들에게 빌려주지만, 임대된 각 서버들은 서로에게 관여되지 않고 독립적으로 기능을 수행합니다.

그림1. 전용 호스팅

2. 가상 호스팅

많은 사람들이 자신만의 웹사이트를 만들고 싶어 합니다.(블로그, 카페, 등등) 하지만 가격표를 보아하니 웹 서버를 통째로 빌리는 전용 호스팅은 이를 주저하게 만듭니다. 이렇게 트래픽 처리가 많은 사람과 그렇지 않은 사람이 같은 서버 공간에 같은 비용을 내는 것은 그리 좋지 못한 사업모델입니다.

 

이를 위해 하나의 서버를 여러 고객이 공유하게 해 보다 저렴하게 웹 호스팅 서비스를 제공하는 서비스를 만들게 되는데 이를 가상 호스팅이라 합니다. 이들이 가지는 웹 사이트들은 모두 각각 다른 서버에서 호스팅 하는 것처럼 보이지만 사실 같은 서버에서 호스팅 되고 있답니다.

 

 

가상 호스팅 동작 방법

HTTP/1.0에서의 가상 호스팅은 구현하기 굉장히 어려웠습니다. 요청 시 URL의 경로 컴포넌트만 서버에 전달하기 때문이죠. 그 때문에 index.html와 같이 보편적인 리소스를 요청받는 경우 서버에서는 어느 호스트의 index.html를 요청하는지 알 길이 없습니다. 이를 보완하기 위한 4가지 방법들을 소개합니다.

 

1) URL 경로를 통한 가상 호스팅

HTTP/1.0은 URL의 경로 컴포넌트만 전송합니다. (ex: tistory.com/index.html 이면. index.html만 전송) 이는 수많은 호스트 URL을 제공하는 서버 입장에서 곤혹스러운 일이 됩니다. 어느 URL인지 정확하게 밝히지 않았기 때문이죠.

그림2. URL 경로를 통한 가상 호스팅 원인

이 문제를 해결하기 위해 서버는 각 사이트에 서로 다른 URL 경로를 강제로 할당해서 구분을 하기 시작합니다.

  • www.HosturlA.com/index.html     ->      www.HosturlA.com/urlA/index.html
  • www.HosturlB.com/index.html     ->      www.HosturlA.com/urlB/index.html
  • www.HosturlC.com/index.html     ->      www.HosturlA.com/urlC/index.html
  • www.HosturlD.com/index.html     ->      www.HosturlA.com/urlD/index.html
  • www.HosturlE.com/index.html     ->       www.HosturlA.com/urlE/index.html

그리고 새로운 요청이 도착하면 경로에 있는 정보를 통해서 최종 호스트 경로를 유추하게 되는 것이죠.

  • GET/urlA/index.html ->  www.HosturlA.com/urlA/index.html

그림3. URL 경로를 통한 가상 호스팅

하지만 경로와 혼동을 하기 쉽다는 단점과. 결정적으로 추가되는 파라미터 때문에 기존의 URL은 먹히지 않습니다.

  • http://www.tistory.com (X) 
  • http://www.tistory.com/indx.html (X) 
  • http://www.tistory.com/tistory/index.html (O) 

2. 포트번호를 통한 가상 호스팅

각 사이트에 다른 포트번호를 할당하는 방식입니다.

  • www.HosturlA.com/index.html:82
  • www.HosturlB.com/index.html:83
  • www.HosturlC.com/index.html:84
  • www.HosturlD.com/index.html:85
  • www.HosturlE.com/index.html:86

이 역시 특정 URL을 알아야 하는 것처럼 특정한 포트를 알아야 한다는 것이 문제가 됩니다. 사용자들은 그런 거 신경 쓰고 싶지 않아 하거든요!

3. IP 주소를 통한 가상 호스팅

앞의 두 방법보다 훨씬 좋은 방법입니다! 각 웹 사이트에 유일한 IP 주소를 부여하는 방법입니다.

  • www.HosturlA.com/index.html  -> 209.172.34.3
  • www.HosturlB.com/index.html  -> 209.172.34.4
  • www.HosturlC.com/index.html  -> 209.172.34.5
  • www.HosturlD.com/index.html  -> 209.172.34.6
  • www.HosturlE.com/index.html  -> 209.172.34.7

 

이를 통해 공용 서버는 실제 목적지(호스트)를 파악하고 요청을 처리해 줍니다.

앞의 두 방법보다 훨씬 좋다고는 하지만 시스템에 연결할 수 있는 서버의 IP 개수에는 제한이 있기 때문에, 한 서버를 많은 사람들에게 호스팅 하기에는 어려움이 있습니다.

 

4. HOST 헤더를 통한 가상 호스팅

IP 주소 가상 호스팅에 대한 문제를 피하려면, 가상 사이트들이 같은 IP를 사용하더라도 각 사이트가 어디에 속해 있는지 알 수 있어야 합니다. (추가적인 IP 사용을 줄일 수 있습니다.) 하지만 앞서 설명했든 HTTP/1.0은 고질적인 경로 컴포넌트 문제 때문에 쉽지가 않습니다. 이 문제를 해결하기 위해, 원 호스트 명을 받아 볼 수 있게 HTTP를 확장해 모든 요청에 호스트명을 Host 확장 헤더에 기술해서 전달합니다.

 

안정적인 웹 사이트

웹 사이트 장애가 생기지 않게끔 하는 예측하고 대응하는 방법들을 설명합니다

 

1. 미러링 된 서버 팜

서버 팜은 서로 대신할 수 있고 식별할 수 있게 설정된 웹 서버들의 집합입니다. 이 기술 덕분에 한 서버에서 문제가 생기는 경우 다른 서버팜에서 대신 그 서버의 기능을 수행할 수 있게 됩니다.

보통 서버 팜은 원본 컨텐츠를 가지고 있는 마스터 원 서버사본을 받은 복제 원 서버 이렇게 두 가지로 계층화되어 있습니다. 이들을 네트워크 스위치를 이용해 사용자들의 요청을 분산시켜 서버에 보냄으로써 안정적으로 배포가 가능해집니다. 이때 호스팅 되고 있는 각 웹 사이트의 IP 주소는 스위치의 IP 주소가 됩니다.

 

그림4. 서버 팜

 

2. 컨텐츠 분산 네트워크(CDN)

컨텐츠 분산 네트워크는 특정 컨텐츠의 분산을 목적으로 하는 단순 네트워크입니다. 네트워크의 노드는 서버, 대리 서버, 프락시 서버가 될 수 있습니다.

 

노드가 대리 서버(캐시)인 경우

앞서 설명한 복제 원 서버의 역할을 합니다. 그리고 프록시편에서 설명한 대리 프록시같이 이들은 원 서버의 역할을 대신 수행해 처리 속도를 높이는 목적이지, 원 서버의 컨텐츠 전체를 복사하지는 않습니다.

 

노드가 프록시 서버(캐시)인 경우

한정적인 역할을 수행하는 대리 서버와 다르게 프록시 서버는 어떤 웹 서버 요청이든지 받을 수 있습니다.

웹 트래픽을 가로채 요청을 처리를 할 수도 있습니다.