드디어 ~! 람쥐썬더 책의 60% 이상을 읽었다.
이상부터는 실무와 관련된 내용들이 많이 나와서 재밌게 읽고 있다.
웹 호스팅
인터넷을 통해 페이지를 클라이언트에게 제공하는 서비스는
내가 만든 리소스들을 공용 웹 서버에 올려두고 서버와 인터넷을 통해 이뤄진다.
리소스를 만드는 것도 중요 하지만 만든 리소스를 효과적으로 배포하는 것도 중요하다.
리소스를 저장 , 중개, 관리하는 일을 통틀어 웹 호스팅이라고 한다.
호스팅 서비스
월드 와이드 웹 초기에는 각 회사가 자체 컴퓨터 하드웨어를 구매하고
해당 컴퓨터 하나를 웹 서버 하나로 설정하여 서버 소프트 웨어를 관리했다.
웹이 대중화 되면서 트래픽이 늘어날 수록 서버가 갖춰야 하는 조건들이 늘어났다.
예를 들어 공간, 냉난방, 연결 등과 같은 물리적 장비 관리부터 서버를 관리하는 소프트웨어적 관리까지 말이다.
웹을 이용해 가치를 창출하려는 사람이 늘어날 수록 웹은 더더욱 늘어났으며
늘어나는 웹을 적절히 호스팅 하기 위한 서버의 수요들도 늘어났다.
하지만 서버를 관리하는데 필요한 조건들이 어려워져 개인이 관리하기 힘들어졌고
이로인해 웹 호스팅을 해주는 사업들도 같이 부상하였다.
이러한 서비스를 제공하는 사람들을 ISP (Internet Service Provider) 라고 한다.
전용 호스팅
ISP 에서 웹 호스팅을 실시하는 가장 직관적인 방법으로
웹 호스팅 하나당 하나의 서버를 가지고 있는 것이다.
www.example.com , www.blahblah.com 두 개의 웹을 호스팅 하기 위해선
각 웹을 호스팅 할 서버 2개가 필요하다.
각 웹에서 리소스를 요청하면 1:1 대응 되는 서버에서 리소스를 찾아 반환한다.
가상 호스팅
전용 호스팅은 가장 직관적인 방법이지만 단점이 존재한다.
-
서버의 성능이 올라감에 따라 하나의 서버가 하나의 웹만을 호스팅 하는 것은 공간적으로나 비용적으로 낭비이다.
-
웹의 공급은 늘어났지만 모든 웹이 하나의 서버를 통째로 필요로 할만큼 트래픽이 높지 않다. (모든 웹이 항상 성공하는 것만은 아니다)
이에 하나의 서버에서 여러 개의 웹을 호스팅하는 가상 호스팅 기법을 사용하는 ISP들이 차츰 늘어났다.
한 서버에서 호스팅 되는 웹 서버들은 각자의 도메인 주소를 가지지만
모든 리소스 요청은 호스팅 하고 있는 하나의 서버에서 처리 된다.
가상 호스팅을 하기 위해서 서버는 두 가지 문제에 직면한다.
-
어떻게 한 서버에서 각기 다른 웹에서 오는 리소스 요청들을 적절하게 처리 할 수 있을까 ?
-
호스팅 하는 서버들이 늘어날 수록 서버의 부하가 늘어나는데 이런 부하들을 어떻게 처리 할 수 있을까 ?
이 두가지 문제들에 대해서는 추후 기술하도록 하자
그 이유는 저 두 문제를 처리하기 전에 더 큰 문제에 직면했기 때문이다.
HTTP 1.0 에서 호스팅 정보가 없는 가상 서버 요청
HTTP 명세서가 기술된지 얼마 안됐을 때에는 가상 호스팅에 대한 점을 염두해두지 않았기 때문에
모든 리소스 요청에서는 호스팅 정보 없이 필요로 하는 리소스의 주소만 기술하곤 했다.
GET /path/to/resource HTTP/1.0
User-Agent: Your-User-Agent이런식의 GET 요청은 전용 호스팅을 할 경우엔 문제가 없지만
가상 호스팅을 할 경우에는 도대체 어떤 웹에서 요청하는 리소스인지 알 수가 없다.
그래서 4가지 방법을 통해 가상 호스팅을 가능하게 했다.
URL 경로를 통한 가상 호스팅
리소스 별로 호스팅 정보를 표현 할 수 있도록 URL 자체에 호스팅 정보를 집어넣는 것이다.
예를 들어 abong 이라는 고객의 웹 서버를 호스팅할 때
도메인 주소자체를
www.abongsCloth.com/abong/index.html 자체로 해두는 것이다.
이를 통해 GET /abong/index.html 이라는 리소스에 대한 경로만 오더라도
가상 호스팅을 하는 서버 입장에서는 리소스 경로만으로 어떤 웹에서 온 요청인지 확인 할 수 있다.
하지만 이는 불필요한 접두어인 abong 이 붙어있기도 하고 www.abongsCloth.com 이라는 기본 주소에 대해서는 어떠한 요청도 받아들일 수 없다.
오로지
www.abongsCloth.com/abong이나www.abongsCloth.com/abong/index.html로 접속해야 한다.
이러한 이유로 거의 사용하지 않는다.
포트번호를 통한 가상 호스팅
그렇다면 가상 호스팅 하는 웹마다 각기 다른 포트 번호를 적용하는 방법은 어떨까 ?
그렇게 되면 리소스 요청에 적힌 포트 번호를 통해 어떤 웹인지 판단 할 수 있을 것이다.
하지만 이는 비표준 포트 번호를 사용함으로서 문제가 발생한다.
클라이언트는 해당 웹에 접근하기 위해 서버에서 설정한 포트번호까지 작성해야 하기 때문이다.
http://www.abongsCloth.com으로 포트번호를 기술하지 않으면 자동으로 표준 포트 번호로 연결된다. (http는 80 ,https는 443)
IP 주소를 통한 가상 호스팅
그렇다면 이번에는 웹마다 각기 다른 IP 주소를 할당하고 각 IP 주소는 가상 호스팅을 하고 있는 서버와 연결해두면 어떨까 ?
리소스 요청에 적힌 IP 주소를 통해 어떤 웹에서 요청한 리소스인지 아는 것이다.
하지만 이는 규모가 큰 호스팅 업자에게 있어서는 어려운 문제를 안겨준다 .
그 이유는 IP 주소가 유한하기 때문에 많은 웹을 호스팅 할 수록 더 많은 IP 주소를 필요로 하기 때문이다.
구세주 HTTP 1.1 Host 헤더와 함께 등장
가상 호스팅에서 어려움을 겪었던 이유는 리소스 요청 헤더에서
호스팅과 관련된 정보가 없었기 때문이다.
어떤 웹에서 요청하였는지에 대한 헤더가 존재하기만 한다면 가상 호스팅시에서는 리소스 경로와 조합하여 가상 호스팅을 할 수 있다.
그 때 ~!
이런 점을 고려한 HTTP 1.1 이 Host 헤더와 함께 등장했다.
GET /path/to/resource HTTP/1.1
Host: www.abongsCloth.com
User-Agent: Your-User-Agent리소스 정보만 띡 하고 떨어져도 서버 입장에서는 Host 헤더를 통해 호스팅하고 있는 어떤 웹의 요청인지 알 수 있다.
다음과 같은 HTTP1.1 에서는 다음과 같은 조건으로 Host 헤더를 이용한다.
Host헤더에 포트가 기술되어 있지 않으면 스킴의 기본 포트를 사용한다.URL에IP주소가 있으면Host헤더는 같은 주소를 포함해야 한다.URL에IP주소가 없다면Host헤더에서는IP주소를 사용하면 안된다.여러개의 가상 사이트들이 하나의
IP주소를 가지고 있을 수 있기 때문이다.
IP주소가 기술되어있지 않다면Host에는 호스팅 정보만 적도록 하자URL에 호스트명이 존재할 경우Host헤더는URL과 같은 호스트 명을 포함해야 한다.예를 들어 요청 자체가
GET http://www.abongsCloth.com/index.html이라면
Host헤더도 동일한http://www.abongsCloth.com여야 한다.- 클라이언트가 특정 프록시 서버를 이용한다하더라도
Host는 프록시 서버의 주소를 가리키지 말고 원 서버의 주소를 기술해야 한다. - 웹 클라이언트는 항상
Host헤더를 기술해야 한다. HTTP1.1웹 서버는Host헤더가 없다면400상태 코드로 응답해야 한다.
서버 입장에서는 들어온 요청에 대해서
URL 이 기술되어 있다면 해당 URL 을 우선적으로 사용하고, 없다면 차선책으로 Host 헤더를 해석, 둘 다 존재하지 않는다면 에러 상태코드 응답을 반환해야 한다.
안정적인 웹 사이트 만들기
우리는 구세주 HTTP1.1 과 함께 가상 호스팅이 가능해졌다.
그럼 이제 안정화를 해보자
웹 서버는 다음과 같은 이유들로 장애가 생기곤 한다.
- 서버 다운
- 트래픽 폭증으로 인한 웹 서버의 부하 증가
- 네트워크의 장애나 손실
안정적인 웹 사이트는 다음 이유들을 예방하거나 문제가 발생했을 시 해결 할 수 있는 방법을 준비해야 한다.
미러링 된 서버 팜
서버 팜은 서로를 대신 할 수 있고 식별 할 수 있게 설정된 웹 서버들의 집합이다.
어떤 서버에 장애가 생기면 서버 팜에 있는 다른 서버에서 장애가 생긴 서버의 요청들을
처리하도록 한다.
미러링 된 서버팜은 계층적인 관계에 있으며
원 서버 역할을 하는 서버를 마스터 원 서버 , 마스터원 서버로부터 콘텐츠를 받은 미러링 된 서버는 복제 원 서버 라고 부른다.
서버 팜은 스위치 를 통해 요청들을 분배하여 서버 간 부하를 줄인다.
로드 밸런싱 (
Load Balancing)로드 밸런싱은 네트워크 트래픽이나 작업 부하를 여러 서버 또는 리소스에 분산시키는데 사용되는 기술이다.
중개자 역할을 하는 로드밸런서를 통해 부하를 분산하고 서버 상태, 응답 시간, 현재 서버 로드와 같은 요소를 기반으로 부하를 분산시킨다.
이를 통해 리소스 활용도를 최적화 하고 부하 감소, 성능 향상 , 장애 해결 등의 기능을 제공한다.
로드밸런서는 세션 지속성 유지가 필요한 경우 클라이언트를 한 서버와 연결을 지속 시킨다.
이 때 호스팅 되고 있는 사이트들의 IP 주소는 여러 서버들이 아닌 스위치를 가리키도록 하여
모든 요청은 스위치까지 도착하며 스위치에서 설정된 값에 따라 복제 원 서버들에게 리소스를 요청 한다.
스위치가 중개 서버 역할을 하는 것이다.
이 때 각 복제 원서버들은 마스터원 서버와 동일한 리소스들을 가지고 있어야 하는 의무가 존재한다.
그렇기 때문에 마스터 원 서버는 복제 원 서버들에게 동일한 리소스들을 퍼뜨리는 역할을 한다.
스위치에서 설정된 알고리즘에 따라 분배하는 방식 외에도
마스터원 서버로부터 온 요청을 복제 원 서버에게 리다이렉션 시키는 방법이나 호스팅되는 웹 별로 각기 다른 복제 원 서버의 IP 주소를 소유하는 방법도 존재한다.
어떤 방법이든 서버 팜을 이용하면 원 서버에 과한 부하를 줄여줄 뿐 아니라 특정 서버가 다운되었을 때에도 다른 복제 서버를 통해 리소스를 제공함으로서 예기치 못한 장애에 대응 할 수 있다.
콘텐츠 분산 네트워크
콘텐츠 분산 네트워크 , CDN (Content Delivery Network) 는 여러 콘텐츠를 분산시켜두는 방법을 의미한다.
서버팜과 유사한 이 방법은 지리적인 특징에 따라 동일한 리소스들을 가진 서버들을 분산시켜둠으로서 더욱 빠르게 리소스를 제공하는 특징이 있다.
예를 들어 원서버가 미국에 있는 페이지가 존재한다고 해보자
그리고 CDN 을 구성하면서 서버를 한국 , 일본 , 미국 세 국가에 서버를 세워뒀을 경우
한국에서 해당 페이지에 접속하면 리소스를 미국까지 가서 요청하는 것이 아닌
한국에 존재하는 서버에 요청하여 더욱 빠르게 리소스를 제공 받을 수 있다.
본질적으로 서버팜 방법과 유사하기 때문에 서버팜이 갖는 장점을 그대로 가질 수 있다.
한국 서버가 만약 부하가 심하거나 장애가 발생했다면 한국 다음으로 가까운 일본 서버에서 리소스를 요청받도록 리다이렉트 될 것이다.
이와 관련된 내용은 유튜브 널널한 개발자님의 영상에서 잘 설명해준다 !!
