GSLB는 DNS 로드 밸런싱을 하면서 생기는 문제를 해결해주는 역할을 한다.
DNS는 동일한 레코드 이름으로 서로 다른 IP 주소를 동시에 설정할 수 있다.
그리고 도메인 질의에 따라서 응답 받는 IP 주소를 나누어 로드 밸런싱할 수 있다. → 이를 DNS 로드 밸런싱이라고 한다.
즉, DNS도 DNS 서버에 등록된 IP를 이용하여 적절히 로드 밸런싱을 할 수 있다는 뜻이다.
그런데 어떤 문제가 생기길래 GSLB라는 서비스가 생기게 된 것일까?
GSLB 탄생 이유
DNS는 설정된 서비스의 상태가 정상인지 비정상인지 확인하지 않고, 도메인에 대한 질의에 대해 설정된 값을 무조건 응답하게 되어있다.
1.1.1.1 서버와 2.2.2.2 서버가 있을 때 2.2.2.2의 서버에 장애가 생기더라도 DNS는 감지하지 못하기 때문에 장애 서버의 IP 주소를 응답하게 되고, 사용자는 서비스에 접근할 수 없게 된다.
서비스가 정상적인지 확인하는 과정을 헬스 체크(Health Check)라 하는데,
DNS는 이 과정을 거치지 않아 서비스 가용성이 떨어질 수 있다.
그래서 이를 해결하기 위해 GSLB가 탄생하게 되었고
GSLB는 등록된 도메인에 대해 헬스 체크를 수행하고 정상적인 레코드에 대해서만 응답하는 역할을 한다.
* 이러한 GSLB는 인텔리전스 DNS라고도 불린다!
| DNS | GSLB |
| 부하 분산 시 헬스 체크 X | 부하 분산 시 헬스 체크 O |
GSLB 동작 방식
GSLB를 사용한 도메인 질의 흐름은 다음과 같다.
* 서울과 대전에 있는 데이터 센터에서 동일한 서비스가 가동 중일 때의 상황을 기반으로 정리하였음
- 사용자가 example.net(이하 서비스)에 접속하기 위해 DNS에 질의
- LDNS(Local DNS)는 서비스를 관리하는 NS 서버를 찾기 위해 root 도메인부터 순차적으로 질의
- 해당 서비스를 관리하는 NS 서버로 질의
- DNS 서버는 GSLB로 서비스에 대해 위임했으므로 GSLB 서버가 NS 서버라고 LDNS에 응답
- LDNS가 다시 GSLB로 서비스에 대해 질의
- GSLB는 서비스에 대한 IP 주소 중 현재 설정된 분산 방식에 따라 IP 주소값을 LDNS에 응답(헬스 체크 후 정상적인 값만 응답)
- GSLB에게 응답받은 LDNS가 사용자에게 전달 받은 서비스 IP 주소값을 최종적으로 응답
위 예시에서 두 데이터 센터가 정상적이라면, 사전에 정의된 알고리즘을 통해 어느 데이터 센터의 IP 주소로 응답할지 결정하게 되고, 한 데이터 센터에 문제가 생긴다면 해당 IP를 응답하지 않고 다른 데이터 센터의 IP 주소만 응답하게 된다.
GSLB 구성 방식
GSLB를 사용한 도메인 설정 방법은 2가지가 존재한다.
1. 도메인 자체를 GSLB로 사용
모든 레코드 설정을 GSLB 장비에서 관리한다.
도메인에 대한 네임 서버를 GSLB로 지정하고, GSLB에서 도메인에 대한 모든 레코드를 등록해 처리하는 방식이다.
= GSLB가 네임 서버 역할을 한다는 뜻이다.
2. 도메인 내의 특정 레코드만 GSLB 사용
여러 레코드 중 GSLB 적용이 불필요한 경우가 생겨날 수 있다.
말 그대로 특정 레코드에 대해서만 GSLB로 처리를 이관하는데, 이관 방법은 2가지가 존재한다.
- 별칭(Alias) 사용 = CNAME 레코드 사용
실제 도메인과 다른 별도의 도메인 레코드로 GSLB에 등록된다.
사용 사례: 외부 CDN 사용, 회사 내부에 GSLB를 사용해야 할 도메인이 많은 경우 한꺼번에 관리하기 위함
DNS 서버에 CNAME 레코드로 외부 GSLB(ex. CDN)를 지정하게 되면 CNAME 레코드 값으로 등록된 FQDN을 GSLB로 재질의하여 서버를 찾아간다.
* FQDN이란? Fully Qualified Domain Name으로, 고유하게 식별할 수 있는 절대 도메인 이름으로,
Windows에서는 nslookup [호스트 이름], Linux/Unix에서는 hostname -f 명령을 이용하면 확인할 수 있다.
- 사용자가 example.net을 LDNS로 질의
- LDNS는 example.net을 관리하는 NS 서버를 찾기 위해 root부터 순차적으로 질의
- example.net을 관리하는 DNS에 서비스 주소 질의
- DNS는 example.net은 별칭으로 example.gslb.net이 관리하고 있다고 LDNS에게 응답 수신
- 다시 LDNS는 example.gslb.net을 관리하는 네임 서버를 root부터 순차적으로 질의
- example.gslb.net을 관리하고 있는 GSLB에게 질의
- GSLB가 LDNS에게 example.gslb.net의 IP 10.10.10.10 응답
- LDNS는 서비스 결과값 10.10.10.10을 사용자에게 최종적으로 응답
- 위임(Delegation) 사용 = NS 레코드 사용
실제 도메인과 동일한 도메인 레코드를 사용하며 도메인 전체를 위임한다.
DNS에서 특정 FQDN에 대한 설정을 NS로 설정하면 이 NS 레코드 값으로 설정된 네임 서버로 재질의한다.
이때 NS 레코드에 지정된 네임 서버 = GSLB가 된다.
- 사용자가 example.net을 LDNS로 질의
- LDNS는 example.net을 관리하는 NS 서버를 찾기 위해 root부터 순차적으로 질의
- example.net을 관리하는 DNS에 서비스 주소 질의
- DNS는 example.net은 3.3.3.3에서 관리하고 있다고 LDNS에게 응답 수신
- example.net을 관리하고 있는 NS 서버인 GSLB(3.3.3.3)에게 질의
- GSLB가 LDNS에게 example.net의 IP 10.10.10.10 응답
- LDNS는 서비스 결과값 10.10.10.10을 사용자에게 최종적으로 응답
++ 하나의 FQDN을 위임 처리할 경우 FQDN의 하위 도메인은 별도의 위임 처리 없이 상위 계층에서 위임 처리되기 때문에 특정 도메인 내에서 GSLB를 사용하여 하부 도메인을 계층화한다면 DNS 서버 설정을 최소화할 수 있다.
| CNAME을 사용하는 경우 | NS를 사용하는 경우 |
| CDN처럼 GSLB를 운영해주는 외부 사업자가 있는 경우 GSLB를 사용해야 하는 도메인이 매우 많은 경우 별도의 GSLB를 운영하기 위한 경우 |
DNS와 같은 도메인으로 GSLB를 운영하면서 계층적으로 GSLB를 이용한 FQDN을 관리할 때 사용 |
GSLB 분산 방식
GSLB는서로 다른 사이트로 부하를 분산하는 역할을 한다.
GSLB를 이용하여 서비스를 분산하면 다음과 같은 3가지 이점을 얻을 수 있다.
- 서비스 제공 가능 여부 체크 후 트래픽 분산
- 지리적으로 멀리 떨어진 다른 데이터 센터에 트래픽 분산
- 지역적으로 가까운 서비스에 접속하여 더 빠른 서비스 제공이 가능하도록 분산
또한 GSLB는 헬스 체크를 통해 서비스를 안정적으로 제공한다.
GSLB에서 지원되는 분산 방식은 2가지 헬스 체크 모니터링 요소를 지원한다.
- 서비스 응답 시간/지연(RTT/Latency): 서비스 요청에 대한 응답이 얼마나 빠른지 or 지연이 얼마나 없는지 확인
- IP에 대한 지리 정보: 서비스 제공이 가능한 각 사이트 IP 주소에 대한 Geo(지리)값을 확인해 가까운 사이트로 서비스 분산 ※ 단, Geo 값은 사용자 기준이 아닌, 바라보는 Local DNS와 GSLB 간의 값이므로 설정에 유의해야 한다.
'네트워크' 카테고리의 다른 글
| DNS(Domain Name System)란? 도메인부터 시작하는 DNS 정리 (0) | 2024.12.22 |
|---|---|
| NAT(Network Address Translation)와 PAT(Port Address Translation) (1) | 2024.12.10 |
| 4계층 장비를 최대로 활용하기 위한 방법 - 세션 관리 시 고려사항 + FTP Active 모드와 Passive 모드 (3) | 2024.12.06 |
| 방화벽::4계층 장비 (2) | 2024.12.04 |
| 로드 밸런서 2 - 구성 방식, 동작 방식 + DSR 모드 설정 방법 (0) | 2024.11.28 |