GSLB (Global Server Load Balancing) 완벽 가이드

Overview

글로벌 서비스를 운영하다 보면 필연적으로 마주하게 되는 질문이 있다. "서울의 사용자와 뉴욕의 사용자가 동시에 접속할 때, 어떻게 하면 둘 다 빠른 응답을 받을 수 있을까?" 이 질문에 대한 답이 바로 GSLB이다.

 

 

GSLB(Global Server Load Balancing)는 여러 지역에 분산된 데이터센터나 클라우드 리전 간의 트래픽을 지능적으로 분배하는 기술이다. 단순히 부하를 분산하는 것을 넘어, 사용자의 위치, 서버 상태, 네트워크 지연시간 등을 고려하여 최적의 엔드포인트로 트래픽을 라우팅한다.

 

DevOps 엔지니어로서 GSLB를 이해하는 것은 단순히 하나의 기술을 아는 것이 아니라, 글로벌 인프라 설계의 핵심 원리를 이해하는 것이다. 이 글에서는 GSLB의 개념부터 실제 구현 방법까지 단계적으로 살펴보겠다.

 

 

 

 

 

 

---

 

 

GSLB를 이해하기 위한 기초 개념

 

 

1. DNS (Domain Name System)

GSLB를 이해하려면 먼저 DNS의 동작 원리를 알아야 합니다. DNS는 인터넷의 전화번호부와 같은 역할을 한다.

 

 

DNS 기본 동작

사용자: "example.com이 어디있지?"
DNS 서버: "203.0.113.10 여기 있어요!"

 

 

DNS 레코드 타입

• A 레코드: 도메인 → IPv4 주소 매핑
• AAAA 레코드: 도메인 → IPv6 주소 매핑
• CNAME: 도메인 → 다른 도메인 별칭
• NS: 네임서버 지정
• TTL (Time To Live): DNS 응답이 캐시되는 시간

 

 

 

 

 

2. Load Balancing 기본 개념

 

 

일반 로드밸런서 (단일 데이터센터)

• L4 Load Balancer: TCP/UDP 레벨에서 분산
• L7 Load Balancer: HTTP/HTTPS 레벨에서 분산 (URL, Header 기반)
• 알고리즘: Round-robin, Least Connection, IP Hash 등

 

 

일반 로드밸런서의 한계

서울 사용자 → 서울 데이터센터 로드밸런서 → 서울 서버들 O
뉴욕 사용자 → 서울 데이터센터 로드밸런서 → 서울 서버들 X (지연시간 높음)

• 일반 로드밸런서는 단일 데이터센터 내에서만 작동하므로, 글로벌 트래픽 분산은 불가능하다.

 

 

3. Geo-Location과 Latency

 

 

Geo-Location (지리적 위치)

• 사용자의 IP 주소를 기반으로 위치 파악
• 대륙 → 국가 → 도시 단위까지 식별 가능

 

 

네트워크 지연시간 (Latency)

• 서울 ↔ 도쿄: ~30-50ms
• 서울 ↔ 미국 서부: ~150-180ms
• 서울 ↔ 유럽: ~250-300ms

 

 

지연시간이 100ms 증가하면 사용자 경험이 크게 저하된다. GSLB는 이를 최소화하는 것이 목표이다.

 

 

 

 

 

---

 

 

 

 

GSLB란 무엇인가?

 

 

핵심 개념

GSLB는 DNS 기반의 글로벌 트래픽 관리 시스템이다. 전통적인 DNS는 정적인 IP 주소만 반환하지만, GSLB는 다음 요소들을 실시간으로 고려하여 동적으로 최적의 IP를 반환한다.

1. 사용자의 지리적 위치
2. 각 데이터센터의 헬스 체크 상태
3. 네트워크 지연시간 (RTT)
4. 각 데이터센터의 부하 상태
5. 비즈니스 정책 (특정 지역을 우선 처리 등)

 

 

 

GSLB의 동작 원리

 

 

단계별 동작

1. DNS 쿼리: 사용자가 example.com에 접속 시도
2. 지능적 판단: GSLB는 다음을 확인
   • 사용자 IP → 서울 위치 파악
   • 각 데이터센터 헬스체크 상태
   • 서울 데이터센터가 가장 가까움 (10ms)
3. 최적 IP 반환: 서울 데이터센터 IP 반환 (203.0.113.10)
4. 직접 연결: 사용자는 서울 데이터센터로 직접 연결

 

 

 

 

GSLB vs 일반 DNS

구분	일반 DNS	GSLB
IP 반환 방식	정적 (고정된 IP)	동적 (상황에 따라 변경)
헬스체크	없음	실시간 모니터링
지리적 고려	없음	사용자 위치 기반 라우팅
장애 대응	수동 변경 필요	자동 Failover
TTL 관리	긴 TTL (수시간~수일)	짧은 TTL (수초~수분)

 

 

 

 

GSLB의 주요 기능

 

 

1. Geographic Load Balancing (지리 기반 라우팅)

사용자의 물리적 위치에 따라 가장 가까운 데이터센터로 라우팅한다.

 

 

예시

서울 사용자 (IP: 121.x.x.x)
→ GSLB 판단: 아시아 태평양 지역
→ 반환 IP: 서울 데이터센터 (203.0.113.10)

뉴욕 사용자 (IP: 72.x.x.x)
→ GSLB 판단: 북미 지역
→ 반환 IP: 미국 동부 데이터센터 (203.0.113.40)

 

 

2. Health Check & Auto Failover

각 데이터센터의 상태를 지속적으로 모니터링하고, 장애 발생 시 자동으로 트래픽을 우회시킨다.

 

 

 

헬스체크 방식

• ICMP Ping: 네트워크 연결성 확인
• TCP Connect: 특정 포트 연결 가능 여부
• HTTP/HTTPS: 특정 URL에 대한 HTTP 상태 코드 확인
• Custom Script: 복잡한 헬스체크 로직

 

 

 

3. Performance-Based Routing (성능 기반 라우팅)

실시간 네트워크 지연시간(RTT)을 측정하여 가장 빠른 경로로 라우팅한다.

 

 

예시 시나리오

홍콩 사용자의 경우:
- 서울 DC: RTT 35ms, CPU 사용률 60%
- 도쿄 DC: RTT 45ms, CPU 사용률 30%
- 싱가포르 DC: RTT 25ms, CPU 사용률 85%

→ GSLB 판단: 서울 DC 선택 (최적의 RTT + 적절한 부하)

 

 

 

4. Load-Based Distribution (부하 기반 분산)

각 데이터센터의 현재 부하를 고려하여 트래픽을 분산한다.

 

 

 

 

5. Disaster Recovery (재해 복구)

특정 리전 전체가 다운되어도 서비스 연속성을 보장한다.

 

 

DR 시나리오

정상 상황:
서울 사용자 → 서울 DC (Primary)

서울 DC 완전 장애:
서울 사용자 → 도쿄 DC (Secondary)

도쿄 DC도 장애:
서울 사용자 → 싱가포르 DC (Tertiary)

 

 

 

 

 

---

 

 

 

 

 

 

GSLB 구현 방법

 

 

1. 클라우드 제공업체의 GSLB 서비스

 

 

AWS Route 53

# Route 53 Latency-Based Routing 예시
Type: AWS::Route53::RecordSet
Properties:
  Name: example.com
  Type: A
  SetIdentifier: Seoul-DC
  Region: ap-northeast-2
  TTL: 60
  ResourceRecords:
    - 203.0.113.10
  HealthCheckId: !Ref SeoulHealthCheck

---
Type: AWS::Route53::HealthCheck
Properties:
  HealthCheckConfig:
    Type: HTTPS
    ResourcePath: /health
    FullyQualifiedDomainName: seoul.example.com
    Port: 443
    RequestInterval: 30
    FailureThreshold: 3

 

 

Route 53 라우팅 정책

• Geolocation: 대륙/국가/주 단위 라우팅
• Geoproximity: 거리 기반 + Bias 설정 가능
• Latency: 실제 측정된 지연시간 기반
• Failover: Primary/Secondary 구성
• Weighted: 가중치 기반 분산

 

 

 

GCP Cloud DNS

# GCP Load Balancer + Cloud DNS 예시
gcloud compute forwarding-rules create global-lb \
  --global \
  --target-http-proxy=http-lb-proxy \
  --ports=80

gcloud dns record-sets create example.com \
  --type=A \
  --ttl=60 \
  --rrdatas="203.0.113.10,203.0.113.20,203.0.113.30" \
  --zone=my-zone

 

 

Azure Traffic Manager

{
  "name": "myTrafficManager",
  "type": "Microsoft.Network/trafficManagerProfiles",
  "location": "global",
  "properties": {
    "trafficRoutingMethod": "Performance",
    "dnsConfig": {
      "relativeName": "myapp",
      "ttl": 60
    },
    "monitorConfig": {
      "protocol": "HTTPS",
      "port": 443,
      "path": "/health",
      "intervalInSeconds": 30,
      "timeoutInSeconds": 10,
      "toleratedNumberOfFailures": 3
    },
    "endpoints": [
      {
        "name": "seoul-endpoint",
        "type": "Microsoft.Network/trafficManagerProfiles/azureEndpoints",
        "properties": {
          "targetResourceId": "/subscriptions/.../seoul-app",
          "endpointStatus": "Enabled",
          "weight": 100
        }
      }
    ]
  }
}

 

 

 

 

2. 오픈소스 솔루션

 

 

CoreDNS + 플러그인

# Corefile 예시
example.com {
    geoip {
        database /data/GeoLite2-Country.mmdb
    }
    
    # 한국 사용자
    route KR {
        forward . 203.0.113.10
    }
    
    # 일본 사용자
    route JP {
        forward . 203.0.113.20
    }
    
    # 기타
    route * {
        forward . 203.0.113.30
    }
    
    health :8080
    log
}

 

 

PowerDNS + GeoIP

-- PowerDNS Geographic Backend
INSERT INTO domains (name, type) VALUES ('example.com', 'NATIVE');

INSERT INTO records (domain_id, name, type, content, ttl, prio) 
VALUES 
  (1, 'example.com', 'A', '203.0.113.10', 60, 0),  -- Seoul
  (1, 'example.com', 'A', '203.0.113.20', 60, 0);  -- Tokyo

-- GeoIP 설정
INSERT INTO geoip_locations (country, content) 
VALUES 
  ('KR', '203.0.113.10'),
  ('JP', '203.0.113.20');

 

 

 

3. 엔터프라이즈 솔루션

 

 

F5 BIG-IP DNS (GTM)

# F5 GTM 설정 예시
gtm pool a pool_asia {
    members {
        seoul_dc:vs_http {
            member-order 0
        }
        tokyo_dc:vs_http {
            member-order 1
        }
    }
    load-balancing-mode round-robin
}

gtm wideip a example.com {
    pools {
        pool_asia { order 0 }
        pool_us { order 1 }
    }
    pool-lb-mode topology
}

 

 

Cloudflare Load Balancing

{
  "name": "example.com",
  "default_pools": ["seoul-pool", "tokyo-pool"],
  "fallback_pool": "us-pool",
  "ttl": 60,
  "steering_policy": "geo",
  "session_affinity": "cookie",
  "session_affinity_ttl": 3600,
  "proxied": true
}

 

 

 

 

 

---

 

 

 

 

 

 

실전 예시: 글로벌 게임 서비스

 

 

시나리오

모바일 게임 ProjectSomaz을 글로벌 출시한다고 가정하겠다.

 

 

요구사항

• 서울, 도쿄, 싱가포르, 미국 서부에 데이터센터 구축
• 각 지역 유저에게 최소 지연시간 보장
• 장애 시 자동 Failover
• 비용 효율적인 트래픽 분산

 

 

아키텍처

 

 

 

 

 

 

Terraform 구성 예시

# Route 53 GSLB 설정
resource "aws_route53_health_check" "seoul" {
  fqdn              = "seoul.projectm.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30

  tags = {
    Name = "Seoul-DC-Health"
  }
}

resource "aws_route53_record" "seoul" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "play.projectm.com"
  type    = "A"
  ttl     = 60

  set_identifier = "Seoul"
  latency_routing_policy {
    region = "ap-northeast-2"
  }

  alias {
    name                   = aws_lb.seoul.dns_name
    zone_id                = aws_lb.seoul.zone_id
    evaluate_target_health = true
  }

  health_check_id = aws_route53_health_check.seoul.id
}

resource "aws_route53_record" "tokyo" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "play.projectm.com"
  type    = "A"
  ttl     = 60

  set_identifier = "Tokyo"
  latency_routing_policy {
    region = "ap-northeast-1"
  }

  alias {
    name                   = aws_lb.tokyo.dns_name
    zone_id                = aws_lb.tokyo.zone_id
    evaluate_target_health = true
  }

  health_check_id = aws_route53_health_check.tokyo.id
}

# 헬스체크 알림
resource "aws_cloudwatch_metric_alarm" "seoul_health" {
  alarm_name          = "seoul-dc-unhealthy"
  comparison_operator = "LessThanThreshold"
  evaluation_periods  = "2"
  metric_name         = "HealthCheckStatus"
  namespace           = "AWS/Route53"
  period              = "60"
  statistic           = "Minimum"
  threshold           = "1"
  alarm_description   = "Seoul DC is unhealthy"
  alarm_actions       = [aws_sns_topic.alerts.arn]

  dimensions = {
    HealthCheckId = aws_route53_health_check.seoul.id
  }
}

 

 

 

 

장애 시나리오 및 대응

 

 

 

 

 

모니터링 대시보드

# Prometheus + Grafana 메트릭
- name: gslb_metrics
  interval: 30s
  metrics:
    - dns_query_count_by_region
    - dns_response_time_by_dc
    - health_check_status_by_dc
    - traffic_distribution_percentage
    - failover_events_count

# Grafana 쿼리 예시
sum(rate(dns_queries_total[5m])) by (region)
avg(dns_response_time_seconds) by (datacenter)
health_check_status{dc="seoul"} == 0  # Alert condition

 

 

 

 

 

 

 

GSLB 설계 시 고려사항

 

 

1. TTL 설정

 

 

짧은 TTL (30-60초)

• 장점: 빠른 Failover, 실시간 트래픽 제어
• 단점: DNS 쿼리 증가, DNS 서버 부하

 

긴 TTL (5-10분)

• 장점: DNS 부하 감소, 캐싱 효율
• 단점: 장애 대응 지연

 

 

권장사항

프로덕션 환경: TTL 60초 (1분)
DR 환경: TTL 30초 (긴급 전환 대비)
개발 환경: TTL 300초 (5분)

 

 

2. Health Check 설정

 

 

체크 주기 vs 민감도

# 보수적 설정 (False Positive 방지)
interval: 30s
timeout: 10s
failure_threshold: 5  # 5회 연속 실패 시 Down

# 공격적 설정 (빠른 감지)
interval: 10s
timeout: 5s
failure_threshold: 2  # 2회 연속 실패 시 Down

 

 

3. 세션 유지 (Session Affinity)

 

사용자가 한 번 연결된 데이터센터에 계속 연결되도록 보장

방법 1: Cookie 기반
- GSLB가 쿠키 발행
- TTL 내에 같은 DC로 라우팅

방법 2: IP Hash
- 사용자 IP를 해싱하여 일관된 DC 선택

방법 3: Application-Level
- 앱에서 토큰 기반 라우팅 처리

 

 

4. 비용 최적화

트래픽 분산 전략:
- Primary: 저렴한 리전 (가중치 70%)
- Secondary: 비싼 리전 (가중치 30%)

예시:
서울 DC (저렴): Weight 60
도쿄 DC (중간): Weight 30
싱가포르 DC (비쌈): Weight 10

 

 

5. 보안 고려사항

 

 

DDoS 대응

- Anycast 방식의 GSLB 사용
- Rate Limiting on DNS level
- Cloudflare, AWS Shield 같은 DDoS 방어 서비스 연동

 

 

DNS Spoofing 방어

- DNSSEC 활성화
- DNS over HTTPS (DoH) 지원

 

 

 

 

GSLB vs CDN

 

많은 분들이 GSLB와 CDN을 혼동하는데, 역할이 다르다.

구분	GSLB	CDN
주 목적	애플리케이션 서버 트래픽 분산	정적 컨텐츠 캐싱 및 배포
작동 레벨	DNS (L3/L4)	HTTP (L7)
캐싱	없음	적극적 캐싱
동적 컨텐츠	가능 (API, 게임 서버 등)	제한적
세션 유지	가능	어려움
예시	Route 53, F5 GTM	CloudFront, Cloudflare

 

 

함께 사용하는 구조

사용자
  ↓
CDN (정적 컨텐츠: JS, CSS, 이미지)
  ↓
GSLB (동적 API 요청)
  ↓
가장 가까운 데이터센터

 

 

 

 

 

---

 

 

 

 

트러블슈팅 가이드

 

 

문제 1: 특정 지역에서 잘못된 DC로 라우팅

 

 

증상

한국 사용자가 미국 DC로 연결됨
Latency: 180ms (정상: 10ms)

 

 

원인 및 해결

# 1. GeoIP 데이터베이스 업데이트 확인
dig @8.8.8.8 play.projectm.com +short
# 반환된 IP가 예상과 다르면 GeoIP 문제

# 2. GSLB 정책 확인
aws route53 get-health-check-status --health-check-id xxx

# 3. 사용자 IP의 GeoIP 결과 확인
curl "https://ipinfo.io/121.x.x.x/json"

# 해결: GeoIP 규칙 수정 또는 예외 추가

 

 

문제 2: Failover가 동작하지 않음

 

 

증상

서울 DC가 다운되었는데도 계속 서울로 라우팅
Health Check는 실패로 표시됨

 

 

원인 및 해결

# TTL이 너무 길어서 캐시가 남아있음
dig play.projectm.com
# TTL: 3600 (1시간) ← 문제!

# 해결:
# 1. TTL을 60초로 단축
# 2. DNS 캐시 플러시 (사용자측)
sudo dscacheutil -flushcache  # macOS
ipconfig /flushdns            # Windows

# 3. Health Check 실패 임계값 확인
aws route53 get-health-check --health-check-id xxx
# FailureThreshold가 너무 높을 수 있음

 

 

문제 3: DNS 쿼리 폭증

 

 

증상

DNS 쿼리 수: 100,000/sec → 500,000/sec
Route 53 비용 급증

 

 

원인 및 해결

# 원인: TTL이 너무 짧음 (10초 이하)

# 해결:
# 1. TTL을 60초로 조정
aws route53 change-resource-record-sets \
  --hosted-zone-id Z123 \
  --change-batch file://change-ttl.json

# 2. DNS 쿼리 로그 분석
aws route53 get-query-logging-config --id xxx
# 비정상적인 쿼리 패턴 확인

# 3. Resolver 캐시 레이어 추가 (예: Unbound)

 

 

 

 

---

 

 

 

 

마무리

GSLB는 글로벌 서비스 운영에 있어 선택이 아닌 필수이다.

 

단순히 트래픽을 분산하는 것을 넘어, 사용자 경험을 극대화하고 장애 상황에서도 서비스 연속성을 보장하는 핵심 인프라이다.

 

 

GSLB 도입 시 체크리스트

• 여러 리전에 인프라가 구축되어 있는가?
• 글로벌 사용자층이 존재하는가?
• 지연시간이 서비스 품질에 중요한가?
• 고가용성과 재해 복구가 필요한가?
• 트래픽 분산을 통한 비용 최적화가 가능한가?

 

위 질문 중 2개 이상이 "예"라면 GSLB 도입을 진지하게 고려해야 한다.

 

 

 

DevOps 엔지니어로서의 접근

GSLB는 단순한 설정이 아니다. DNS, 네트워킹, 모니터링, 자동화가 모두 어우러져야 하는 복합적인 시스템이다.

 

처음에는 클라우드 제공업체의 관리형 서비스(Route 53, Traffic Manager 등)로 시작하되, 점차 커스터마이징과 최적화를 통해 자사 서비스에 맞는 GSLB 전략을 구축해나가는 것이 현명하다.

 

 

최종적으로 GSLB의 목표는 명확하다.

전 세계 어디서든, 가장 빠르고 안정적인 서비스 제공.

 

이를 위해 지속적인 모니터링, 튜닝, 그리고 장애 대응 훈련이 필수이다.

 

 

 

 

 

 

 

 

---

Reference

 

• AWS Route 53 Developer Guide
• Google Cloud Load Balancing
• Azure Traffic Manager Documentation
• F5 BIG-IP DNS (GTM) Configuration Guide
• RFC 1034/1035 - Domain Names Implementation

 

 

 

Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist