2024-02-17

docs/sk-lim19f/2024-02-17.md

@@ -0,0 +1,67 @@
+## 7.3 GSLB
+
+-   DNS 로드밸런싱
+    -   DNS에서 동일한 레코드 이름으로 서로 다른 IP 주소를 동시에 설정할 수 있음
+    -   도메인 질의에 따라 응답받는 IP 주소를 나누어 로드밸런싱 가능
+-   DNS는 설정된 서버스 상태의 정상 여부를 확인하지 않고 도메인에 대한 질의에 대해 설정된 값을 무조건 응답
+-   특정 서비스에 문제가 있을 때 DNS 서버는 이것을 감지하지 못해 사용자의 도메인 질의 요청에 비정상 상태인 서비스 IP 주소를 응답한 경우, 사용자는 해당 서비스에 접근할 수 없음
+-   즉 DNS 서버는 서비스 가용성 향상 방법으로는 부적합
+-   GSLB는 DNS와 동일하게 도메인 질의에 응답해주는 역할과 동시에 로드 밸런서처럼 등록된 도메인에 연결된 서비스가 정상적인지 헬스 체크를 수행
+-   즉, 등록된 도메인에 대한 서비스가 정상인지 상태를 체크해 정산인 레코드에 대해서만 사용
+-   이런 이유로 GSLB를 '인텔리전스 DNS'라고도 부름
+
+### 7.3.1 GSLB 동작 방식
+
+1. 사용자가 web.zigispace.net에 접속하기 위해 DNS에 질의
+2. LDNS는 web.zigispace.net을 관리하는 NS 서버를 찾기 위해 root부터 순차 질의
+3. zigispace.net을 관리하는 NS 서버로 web.zigispace.net
+4. DNS 서버는 GSLB로 web.zigispace.net에 대해 위임했으므로 GSLB 서버가 NS 서버라고 LDNS에 응답
+5. LDNS는 다시 GSLB로 web.zigispace.net에 대해 질의
+6. GLSB는 web.zigispace.net에 대한 IP 주솟값 중 현재 설정된 분산 방식에 따라 서울 또는 부산 데이터 센터의 IP 주솟값을 DNS에 응답
+   서울과 부산 데이터 센토로 헬스 체크해 정상적인 값만 응답
+7. GSLB에서 결괏값을 응답받은 LDNS는 사용자에게 web.zigispace.net이 1.1.1.1로 서비스하고 있다고 최종 응답
+
+-   GSLB는 zigispace.net이라는 FQDN에 대한 IP 주소 정보를 단순히 갖고 있다가 응답해주는 것이 아니라 헬스 체크를 통해 해당 IP가 정상적인 서비스가 가능한 상태인지 확인
+-   정리하면 GSLB는 앞의 동작 방식처럼 일반 DNS를 사용하는 것과 거의 동일하게 동작
+-   다만 GSLB에서 서비스 IP 정보에 대한 헬스 체크와 사전에 지정한 다양한 분산 방법을 이용한 부하 분산이 일반 DNS와 큰 차이점이라고 볼 수 있음
+
+### 7.3.2 GSLB 구성 방식
+
+-   GSLB를 사용한 도메인 설정방법은 두가지가 있음
+-   도메인 자체를 GSLB로 사용
+    -   도메인 자체를 GSLB로 사용하면 해당 도메인에 속하는 모든 레코드 설정을 GSLB 장비에서 관리
+    -   즉, 도메인에 대한 모든 레코드를 GSLB에서 설정
+    -   도메인 자체를 GSLB로 사용하는 것은 도메인에 대한 네임 서버를 GSLB로 지정하고 GSLB에서 도메인에 대한 모든 레코드를 등록해 처리하는 방식
+    -   즉, GSLB 자체가 도메인의 네임 서버 역할을 하는 경우
+-   도메인 내의 특정 레코드만 GSLB로 사용
+    -   DNS에서 도메인 설정 시 GSLB를 사용하려는 레코드에 대해서만 GSLB로 처리하도록 설정
+    -   회사 대표 도메인에 속한 레코드 중 GSLB 적용이 불필요한 경우가 많아 도메인 내의 특정 레코드에 대해서만 GSLB로 처리를 이관하는 방식을 사용
+    -   특정 레코드에 대해서만 GSLB로 처리를 이관하는 방법은 두 가지가 있음
+        -   별칭(Alias) 사용(CNAME 레코드 사용)
+            -   일반적으로 외부 CDN을 사용하거나 회사 내부에 GSLB를 사용해야 할 도메인이 많은 경우 한꺼번에 관리하기 위해 사용
+            -   DNS 서버에 CNAME 레코드로 CDN과 같은 외부 GSLB를 지정하면 CNAME 레코드의 값으로 등록된 FQDN을 GSLB로 재질의해 서버를 찾아가게 됨
+            -   즉, CNAME 값으로 등록되는 FQDN이 GSLB가 네임 서버로 등록된 도메인을 사용해 GSLB로 재질의하게 만드는 것
+        -   위임(Delegation) 사용(NS 레코드 사용)
+            -   실제 도메인과 동일한 도메인 레코드를 사용하며 도메인 전체를 위임하는 것이 대표적
+            -   DNS에서 특정 FQDN에 대한 설정을 NS 레코드로 설정하면 해당 FQDN에 대한 값을 NS 레코드의 값으로 설정된 네임 서버로 재질의
+            -   이때 NS 레코드에 지정된 네임 서버가 GSLB
+            -   이렇게 NS 레코드를 이용한 위임으로 재질의하는 경우, 최초 요청한 FQDN을 그대로 재질의하므로 GSLB에서 관리되는 도메인은 사용자가 최초 호출하는 동일한 FQDN이 됨
+-   정리하면 별칭을 이용해 GSLB를 사용하는 경우, CDN처럼 GSLB를 운영해주는 외부 사업자가 있거나 GSLB를 사용해야 하는 도메인이 매우 많은 경우, 별도의 GSLB를 운영하기 위해 사용
+-   위임의 경우에는 DNS와 같은 도메인으로 GSLB를 운영하면서 계층적으로 GSLB를 이용한 FQDN을 관리할 때 사용
+-   많은 환경에서 다양한 서비스가 혼재되어 있으므로 NS와 CNAME 방식을 혼용하여 사용하기도 함
+
+### 7.3.3 GSLB 분산 방식
+
+-   GSLB를 이용해 서비스를 분산하면 다음과 같은 주요 목적을 달성할 수 있음
+    -   서비스 제공의 가능 여부를 체크해 트래픽 분산
+    -   지리적으로 멀리 떨어진 다른 데이터 센터에 트래픽 분산
+    -   지역적으로 가까운 서비스에 접속해 더 빠른 서비스 제공이 가능하도록 분산
+-   서비스 헬스 체크를 통해 서비스를 안정적으로 제공하는 것 외에 서로 다른 사이트로 서비스를 분산시키는 것이 GSLB의 중요한 역할
+-   이를 위해 GSLB는 라운드 로빈(Round Robin)이나 최소 접속(Least Connection), 해싱(Hashing) 방식 외에 추가적인 분산 방식을 제공
+-   대부분 다음 두가지 헬스 체크 모니터링 요소를 지원
+    -   서비스 응답 시간/지연(RTT/Latency)
+        -   서비스 요청에 대한 응답이 얼마나 빠른지 또는 지연이 얼마나 없는지를 확인하고 이것을 이용해 서비스를 분산 처리
+    -   IP에 대한 지리 정보
+        -   서비스 제공이 가능한 각 사이트의 IP 주소에 대한 Geo 값을 확인해 가까운 사이트로 서비스 분산을 처리
+-   위의 두가지 요소에 따른 분산 방법은 다르겠지만 기본적으로 추구하는 목표는 다음과 같음
+-   서비스가 가능한 사이트로 트래픽을 분산하는 것은 물론 더 신속히 서비스를 제공할 수 있는 사이트로 접속할 수 있도록 유도하는 것이 궁극적인 목표