GSLB 는 LB 가 아니라 사실 DNS ver.2래..
들어가며
최근 회사 서버 구조를 보면서 낯선 이름을 듣게 되었다. 'GSLB ? 뭐.. 글로벌..로드...밸런싱...인가? 로드 밸런서 종류?' 라고 생각했고, 반쯤 맞았다. GSLB 는 Global Server Load Balancing 이고, 로드밸런서가 아니라 DNS 의 개선판이다. 🤔
뭐가 그리 다르길래 이걸 써? 그냥 익숙한 DNS 쓰지, 싶었는데 알고보니 GSLB 요 놈 아주 대단하다. GSLB 기능은 서비스 구성에 있어서 큰 도움이 되는 장점을 띄고 있다. 간략하게 DNS 를 설명한 뒤 GSLB 와 비교해보도록 하자!
DNS 가 뭐요
면접 질문의 단골 손님, 면접 질문계의 명가 DNS. '구글 / 네이버를 인터넷 브라우저에 쳤을 때 일어나는 일을 설명해보시오' 에서 DNS 언급이 없으면 안된다더라...
DNS 는 Domain Name System 의 약자로, 어려운 ip 주소와 그래도 사람이 읽을 수 있는 주소 체계(google.com) 등 을 매핑해주는 역할을 한다. 일반적으로 도메인 이름이 뭐에요~ 하면 google.com 등으로 표시되는 '읽을 수 있는' 문자열을 의미한다. TMI 로 2009년에 ICANN(인터넷 주소 정하는 대장기구) 에서 다국어 도메인 이름을 승인해서, .kr
대신 .한국
이라고 쓸 수도 있다고.
그래서 구글을 브라우저에 쳤을 때 DNS 는 무슨 일을 하냐구? 일단.. 자신의 기기 로컬에도 로컬 네임 서버가 있어서 그걸 가장 먼저본다. 손쉽게 볼 수 있는 방법으로, OS X 에서는 /etc/hosts
를 편집해서 특정 도메인 네임으로 접속할 때 연결해줄 ip를 정해줄 수 있다. 그러니까 내가 google.com
로 접속해도 실제로는 네이버 서버로 뜨도록 로컬에서 정해줄 수도 있다는 말이다.
이렇게 해서 저장한 뒤에 google.com 을 들어가면 네이버로 연결되는 걸 확인할 수 있다(ㅋㅋ)
그런데 당연히 이 로컬 네임 서버에 세상의 모든 주소를 연결해놓은 것은 아닐테니 없으면 물어서 간다. 가장 먼저 물으러 가는 곳은 루트(root) 네임 서버(.) 다. 우리는 google.com 을 찾아가고 있는데, 루트 네임서버는 .com
하위를 어디서 다루는지 주소를 알려준다.
그렇게 찾아간 곳은 .com
최상위 도메인 네임서버 (Top Level Name Server) 다. 여기서는 다시 google.com 의 ip 정보를 알고 있는 네임서버 위치를 알려준다. (authoritative name server).
그럼 정말 마지막으로, 우리는 authoritative 네임서버에 가서 물어본다. 그래서 google.com 의 주소가 뭔가요...?
이 과정을 다시 보자. 아래와 같은 과정이 순식간에 일어난다.
몇 가지 더!
root 네임 서버는 하나가 아니다. 전 세계에 13개로 퍼져있고, 이 정보를 알고 싶다면 IANA 사이트 에 가면 알 수 있다. 대부분 미국에 있네! 당연히 여러개로 퍼져있는 이유는 하나인 경우 root 네임서버가 공격 당했을 때 SPOF (Single Point of Failure) 가 될 수 있기 때문 ~.~
Authoritative 네임서버는 공인 서버로 해석해볼 수 있겠는데, 실제로 도메인과 IP 의 매핑을 갖고 있는 서버를 의미한다. 가끔 nslookup을 진행하면 non-authoritative 서버라고 나오는 경우도 있는데, 이는 캐시 등의 이유로 매핑 값을 갖고 있지만, 원본 매핑은 아니어서 값이 일치하지 않을 수도 있는 경우를 의미한다.
GSLB 는 뭐요
DNS 가 하나의 도메인 이름에 대해서 여러가지 ip를 넘겨줄 수 있어서, 가용성 구성과 로드밸런싱 기능을 약하게 할 수 도 있다. 하지만, 특정 서버로의 요청이 실패하는 상황 등에 대한 대처는 안되고 있다.
이런 부분을 개선해서 로드밸런싱과 가용성 구성을 가능하게 만든게 GSLB 다. 로드밸런싱을 하는 전략에는 여러가지가 있고, 이 중에는 지리적 위치를 고려해서 특정 서버로 보내주는 전략도 있기때문에 만약 서버가 글로벌하게 나가 있고, 글로벌 유저를 대상으로 한다면 아주 고려해봐야한다.
DNS와 GSLB 가 하나의 도메인에 대해서 여러 원본 서버 ip 를 매핑했을 때를 가정해서 비교해보자. 아래 상황에서는 juneyr.dev 에 대해서 1.1.1.1 / 2.2.2.2 / 3.3.3.3 이 모두 매핑되어있다.
첫번째 이슈 : 만약 서버 중 하나가 서비스가 불가능 하다면 🤔
이때 만약 중간의 2.2.2.2
서버가 모종의 이유로 서비스가 불가한 상태가 된다고 하면
DNS: 서비스 불가와 상관없이 계속 요청을 2.2.2.2
로 보내준다. 그러면 2.2.2.2
로 보내진 특정 사용자들은 서비스가 불가한 상태를 보게 될 것이다.
GSLB: GSLB 는 주기적인 원본서버의 health check 를 통해서 살아있는 서버로 요청을 우회해준다. 사용자들은 모두 서비스 가능한 1.1.1.1
/ 3.3.3.3
를 바라보게 될 것이다.
두번째 이슈: 만약 일부 서버만 너무 과중하게 부하를 받고 있다면 🤔
만약 중간의 2.2.2.2
서버가 가용량의 90%, 그리고 나머지가 상대적으로 널널한 편이더라도..
DNS: round-robin 을 채택해서, 서버에 모두 균일하게 요청을 보낸다. 그러면 2.2.2.2
로 보내진 특정 사용자들은 상대적으로 부하가 많이 가서 불안한 서비스를 경험하게될 수도 있다.
GSLB: GSLB 는 주기적으로 원본서버의 로드를 모니터링한다. 로드가 적은 서버의 IP 를 반환하는 방식을 채택해 전체 시스템적으로 쾌적한 서비스를 경험할 수 있다.
세번째 이슈 : 만약 특정 유저가 먼 서버랑 연결된다면
동아시아에 사는 유저가 있다고 하자. 각 서버는 미국 / 유럽 / 동아시아에 위치해 있는데, 당연히 가까운 서버가 상대적인 응답속도가 높다 (결국 네트워크는 물리적인 선으로 연결되어있다는 것을 기억하자 😅)
DNS: 응답속도에 상관없이 round-robin 을 통해서 원본 서버의 ip를 반환해준다. 동아시아 유저가 미국에 있는 서버랑 연결될 수도 있는 노릇이다.
GSLB: 두 가지를 통해서 가장 가까운 서버를 할당한다.
- RTT : round-trip-time, 즉 왕복시간! GSLB 는 각 원본서버에 요청이 왔던 local dns 의 ip 주소와의 왕복시간을 측정하게 하고, 이 값을 받아서 상대적으로 RTT 가 적은 (거리도 짧은) 곳에 할당한다.
- 지리적 거리: GSLB 는 요청이 왔던 local dns 의 ip 주소를 Geolocation DB 에서 검색하여 상대적으로 가까운 원본 서버를 할당해준다.
즉 GSLB 는 위와 같은 이슈를 전반적으로 해소하는 정책을 가진 DNS 라고 말할 수 있겠다.
위와 같은 문제를 해결하는 것 외에도 GSLB 는 우선순위를 가지고 어떤 ip를 반환할 것인지 선택한다. 서버(ip) 선택과정은 8가지로 진행되고, 설정에 따라서 각 단계를 건너뛸수도 있다. 만약 이 글을 보는 당신이 플랫폼에서 제공하는 GSLB 를 사용한다면, 해당 GSLB 를 관리하는 쪽에서 단계를 설정할 수 있을 것 같다. 기본적으로 각 단계를 통해 결정이 나지않으면 다음 단계로 진행되는 방식이다.
아래 내용은 여기 를 참조했다.
① Server Health - 살아있는 사이트 선택
② SLB Session & Network Capacity Threshold - 과부하 상태가 아닌 사이트 선택
③ Network Proximity - 응답 속도가 빠른(Low Latency) 사이트 선택
④ Geographic Proximity - 지리적으로 가까운 사이트 선택
⑤ SLB Connection Load - 새로운 연결 요청이 적은 사이트 선택
⑥ Site Preference - 운영자의 정책에 의해 특정 사이트 선택
⑦ Least Selected - 균등하게 사이트 선택
⑧ Static Load Balancing - 균등하게 사이트 선택
마치며
GSLB 는 발전된 형태의 DNS로, 고가용성과 로드밸런싱의 기능을 수행한다. 이 기능을 수행하는 제품을 여러 벤더에서 판매하고 있고 사용할 때는 잘 비교해서 (!!) 사용하면 될 것 같다.
참고
1일 1로그 100일 완성 IT 지식, 브라이언 W 커니핸
https://www.joinc.co.kr/w/man/12/GSLB https://www.netmanias.com/ko/?m=view&id=blog&no=5622