CS) 웹 브라우저에 URL을 입력하면.(GSLB, CDN)

해당 내용은 이미 수많은 블로그와 유튜브에 많이 나와있는 내용이다. 이미 나 또한 이 내용을 알고 있었지만,

최근 같은 팀원분께서 위 내용을 질문했고 나는 어버버거리며 질문에 대한 답을 말하지 못하였다.

 

즉 머릿속으로는 알고 있지만 정리되지는 않아 입으로 말할 수 없는 것이다. 이는 결코 "알고있다"라고 말할 수가 없다.

 

때문에 다시 한 번 내용을 복습하려 한다.

 

 

IP주소

 

우선 국민 포털사이트 네이버로 접속하는 상황을 가정한다.(사용자의 OS는 Window이다)

 

 

브라우저는 네이버의 웹서버에 접속하기 위해 네이버의 IP주소를 알아야한다. 그렇기에 1차적으로 DNS서버에 네이버의 IP주소를 얻어온다.

 

 

브라우저는 라우터를 통해 DNS서버에 접속하며 네이버의 IP주소를 받아온다.

하지만  반드시 ISP의 DNS서버로 접속하는 경우는 아니다.

 

매 접속마다 DNS에 접속하여, 이미 여러 번 방문한 적이 있는 IP주소라도 DNS에 접속하여 새로 IP주소를 얻어오는 것은 낭비이지 않은가.

 

때문에 브라우저는 첫 번째로 도메인 네임(www.naver.com)을 확인한 후 브라우저 캐시를 확인한다.

이전에 방문한 사이트의 경우 브라우저는 캐싱을 진행하기 때문이다.

 

두 번째로 로컬DNS 캐시를 확인한다. 이 캐시는 이전에 다른 컴퓨터나 장치가 이미 접속한 도메인의 IP주소를 저장한다.

 

세 번째로 호스트 파일을 확인합니다. 호스트 파일은 도메인과 IP주소를 매핑하는 로컬 설정 파일입니다.

 

위 세가지 상황에서도 네이버의 IP주소를 찾지 못한다면 그제서야 DNS서버를 확인한다.

(ISP는 여러 DNS서버를 운영하기에 여러 DNS에 접속해 IP주소를 찾게된다)

 

이제 브라우저는 네이버의 IP주소를 얻었다.

 

 

HTTP통신

브라우저는 네이버의 IP주소를 이용해 네이버와 TCP연결을 진행한다.

이후 연결이 성공적으로 끝마치면 HTTP프로토콜을 이용해 네이버 서버에 HTTP요청을 보낸다.

이후 네이버 웹서버로부터 받은 HTML,CSS,JS등을 확인하여 웹페이지를 렌더링하고, 이를 사용자에게 보여준다.

 

---

여기까지가 매우 흔히 나와있는 내용이다.

나 또한 여기까지의 지식 밖에 없는 상황이었다. 그러나 이번에 다시 공부하게 되며 얻은 지식이 있기에 이 글을 작성하며 공유하고자 한다.

 

GSLB

Global Server Load Balancing의 약어로 전 세계 여러 지역에 분산된 서버들 간의 부하 분산을 관리하기 위한 기술이다.

주요 목표는 사용자들이 네트워크의 지리적 위치에 가까운 서버로 연결되어 빠른 응답 시간을 제공하고, 트래픽 부하를 분산하여 서버의 가용성을 향상시키는 것이다.

또한 GSBL는 사용자의 지리적 위치, 서버의 상태 및 부하, 네트워크 조건 등을 고려하여 최적의 서버로 연결한다.

 

 

 

 

CDN

Content Delivery Network의 약어로, 전 세계 여러 지역에 캐시 서버를 배치하여 사용자가 콘텐츠를 빠르게 제공받을 수 있도록하는 기술이다.

주로 정적인 컨텐츠(이미지, CSS, JS)를 더 빠르게 제공하기 위해 사용되며 DMS는 CDN의 일종으로 컨텐츠를 효율적으로 관리하고 배포하기 위한 시스템이다.

CDN과 DMS는 컨텐츠를 여러 지역의 서버에 캐시하여 웹 페이지 로드 시간을 단축하고 트래픽 부하를 줄이는데 사용된다.

 

 

즉 둘 모두 네트워크와 웹 서비스의 성능과 가용성을 향상시킨다.

둘의 차이점을 간략하게 설명하자면 CDN은 서버와 클라이언트의 지리적 거리를 줄여 서버가 클라이언트와 통신하는 데 필요한 시간을 단축시킨다.

GSLB는 서버 클러스터 전체에 네트워크 트래픽을 자동으로 분산시키는 장치이다. 일부 로드 밸런서는 여러 데이터 센터에 걸쳐 트래픽 균형을 조정하지만, 일반적으로 모두 동일한 데이터 센터에 위치한다.

로드벨런서는 다음 중 하나일 수도 있다.

1. 실제 독립형 하드웨어 장치

2. 다른 네트워크 하드웨어에서 실행되는 소프트웨어 애플리케이션

 

그러나 로드 밸런서는 필요하지만 CDN은 필요하지 않은 상황이 있을 수 있다.

예를들어, 사용자 기반 서버 클러스터와 로드 밸런서를 요구할 만큼 충분히 크지만 대부분의 사용자가 동일한 지리적 위치에 있는 도시 기간을 위한 애플리케이션을 호스팅하는 경우이다.

 

또 반대로 CDN은 필요하지만 로드 밸런서는 필요하지 않는 상황이 있을 수 있다.

예를들어, 사용자 기반이 지리적으로 분산되어 있지만 한 위치에 서버 클러스터가 필요할 만큼 사용자가 충분하지 않은 경우이다.

 

로드 밸런서와 CDN은 모두 최신 애플리케이션 제공 및 호스팅을 위한 도구이며 둘 다 서버와 클라이언트간에 상호작용을 최적화하는데 도움이 된다. 하지만 둘은 서로 다른 유형의 도구이므로, 하나가 있으면 다른 하나는 없어도 된다는 가정을 해서는 안된다.

 

한가지 예를 들어보자

네이버의 서버가 CDN 그룹을 사용하고 네이버의 IP주소가 만약 222.222.222.222라고 생각하자.

초당 5명 내외의 접속이 발생한다 했을 때, 최악의 상황은 아닐 것이다.

하지만 월드컵 결승, 게다가 한일전이라면 또한 네이버가 이를 단독 중계한다면 동시 접속자 수는 기하급수적으로 증가할 것이다.

수많은 사용자가 222.222.222.222에 접속할 것이고 이는 곧 트래픽의 증가로 네트워크의 가용성을 뛰어넘어 웹 서버의 응답이 느려지는 등의 수많은 문제가 발생할 것이다.

 

때문에 GSLB 또는 CDN 기술을 이용해 가까운 N개의 네이버 웹 서버 중 사용자에게 IP주소를 알려주게 된다.

하지만 무조건적으로 가까운 웹서버의 IP주소를 알려주는 것은 또 아니다.

 

만약 네이버의 웹서버가 서울, 도쿄, 그리고 캘리포니아에 있다 가정해보자. 대한민국의 유저들은 제일 가까운 서울에 설치되어있는 네이버 웹서버에 접속하게 될 것이다.(웹 서버의 가용성이 충분하다는 전제에)

하지만 최악의 상황에서는 서울에 있는 서버가 꺼져버리거나 혹은 제 3자의 공격을 받아 먹통이 되어버릴 수가 있다.

그런 상황에서 대한민국의 사용자들은 여전히 다운된 서울 서버에 접속을 시도할 것이다.

 

Health Check

 "health check"라는 기능을 제공하고 있다. 이는 서버의 상태를 주기적으로 확인하여 사용자에게 최상의 성능과 가용성을 제공하기 위해 사용된다.

 

일반적으로 다음과 같은 단계를 따른다.

1. 주기적인 상태 확인

2. 서버 응답 확인

3. 응답 확인 및 판단

4. 트래픽 조정

(health check에 대한 것은 깊히 들어가지는 않았다.)

 

끝으로 네이버는 CDN기술을 사용하는 것 같다. (구글에 검색하면 다 나온다.)

 

마지막으로 재밌는 걸 발견했다.

명령 프롬프트 창에 (본인은 Mac OS 사용중)

nslookup www.naver.com

 

을 입력하면 ip 주소가 나오는데, 이 ip주소들을 https://xn--c79as89aj0e29b77z.xn--3e0b707e/eng/main.jsp에 검색하면 다음과 같이 나온다.

첫 번째로 본인이 사용중인 ISP가 나온다.(본인의 경우 SK)

두 번째로 네이버 웹서버의 IP주소가 나오는데 이는 분당구 판교에 위치해있다.

 

 

---