GSLB, L4, L7의 차이와 실무 로드밸런싱 아키텍처

Об этом предложении

GSLB, L4, L7의 차이와 실무 로드밸런싱 아키텍처 서비스를 여러 서버에 배포하면 어느 서버로 요청을 보낼지, 서버 한 대가 장애를 일으켰을 때 어떻게 정상 서버로 전환할지 고민하게 된다. 이 과정에서 GSLB, L4, L7, Nginx 같은 용어를 접한다. 이들을 이해할 때 가장 중요한 기준은 대상을 선택하는 시점과 실제 트래픽이 통과하는 경로 다. 이 글에서는 각 개념을 정리하고, 대표적인 구성에서 장애가 발생했을 때 어떻게 동작하는지 살펴본다. 아래 구성은 이해를 위한 예시다. 특정 기업의 실제 운영 구성을 나타내지는 않는다. GSLB는 구현 방식이 다양하므로, 여기서는 DNS 기반 GSLB를 중심으로 설명한다. 1. GSLB와 L4·L7은 분류 기준부터 다르다 L4와 L7의 L은 Layer를 뜻한다. OSI 7계층 중 어떤 계층의 정보를 이용해 트래픽을 처리하는지를 나타낸다. 반면 GSLB는 Global Server Load Balancing의 약자다. 여러 거점이나 서버 그룹에 걸쳐 서비스 접속 대상을 선택하는 기능을 의미한다. GSLB를 L4나 L7의 다음 단계로 이해하면 혼동하기 쉽다. 구분 GSLB L4 로드밸런싱 L7 로드밸런싱 핵심 역할 접속할 주소·거점 선택 전송 계층 정보로 트래픽 분산 응용 계층 정보로 요청 분산 대표 방식 DNS 응답으로 대상 선택 TCP·UDP 처리 HTTP·HTTPS 처리 판단 정보 정상 여부, 위치, 가중치, 우선순위 IP, 포트, 프로토콜, 연결 수 도메인, URL, 헤더, 쿠키 선택 시점 DNS 조회 시 TCP에서는 주로 새 연결 생성 시 HTTP 요청 처리 시 실제 서비스 트래픽 DNS 기반 방식에서는 통과하지 않음 로드밸런서가 전달에 관여 프록시가 요청·응답 처리에 관여 세 기능은 함께 사용할 수 있다. GSLB가 어느 데이터센터로 접속할지 선택하고, 해당 센터의 L4·L7이 실제 서버로 트래픽을 분산하는 구성이 그 예다.[1][2][3] 2. GSLB: 어떤 IP를 알려줄 것인가 DNS 기반 GSLB는 도메인 조회에 응답할 IP를 정책에 따라 선택한다. 도메인 대상 그룹 api-a.example.com 서버 1, 서버 2 api-b.example.com 서버 3, 서버 4 A 도메인을 조회해 서버 1의 IP를 받았다면, 호출 시스템은 서버 1로 직접 접속한다. GSLB가 API 요청을 받아 전달하는 과정은 없다. 제품과 정책에 따라 주소 하나 또는 여러 주소를 응답할 수 있다.[1] sequenceDiagram participant C as 호출 시스템 participant R as DNS 리졸버 participant G as GSLB participant S as 선택된 서버 C->>R: 도메인 조회 R->>G: 캐시가 없거나 만료되면 질의 G-->>R: 대상 IP 응답 R-->>C: IP 전달 C->>S: API 요청 S-->>C: API 응답 그림에서는 DNS 위임 과정과 다른 캐시 계층을 생략했다. 핵심은 DNS 조회와 API 통신의 경로가 분리된다는 점이다. GSLB의 대상 IP는 실제 WAS 주소일 수도 있고, Nginx 서버 주소나 L4의 VIP일 수도 있다. 내부 DNS와 사설 주소를 대상으로 구축하는 방식도 있으므로, Global이라는 이름이 반드시 해외나 인터넷 서비스만을 뜻하지는 않는다. 사설망 지원 방식은 사용하는 제품과 구성에 따라 확인해야 한다. GSLB로 정확히 반씩 분산할 수 있을까 DNS 응답을 번갈아 제공하더라도 API 요청 100건이 서버마다 50건씩 전달되는 것은 아니다. 호출 시스템이나 DNS 리졸버가 주소를 캐시하면 같은 주소를 계속 사용할 수 있다. HTTP 클라이언트가 기존 TCP 연결을 재사용하는 경우도 마찬가지다. 특히 호출 시스템이 몇 대 없는 내부 API 환경에서는 특정 서버로 요청이 몰릴 수 있다. GSLB를 설계할 때는 응답 정책뿐 아니라 호출 측의 DNS 캐시와 연결 재사용도 확인해야 한다.[4] 3. L4: 들어온 연결을 어느 서버로 보낼 것인가 L4는 OSI 4계층인 전송 계층을 뜻한다. L4 로드밸런서는 IP와 TCP·UDP 포트 등의 정보를 이용해 트래픽을 분산한다. IP 자체는 3계층 정보이므로 실제로는 3·4계층 정보를 함께 사용한다.[2] 예를 들어 서비스 대표 주소로 들어온 새 TCP 연결을 서버 1 또는 서버 2에 배정한다. TCP 연결 하나의 패킷을 두 서버에 번갈아 보내는 방식은 아니다. 따라서 연결 수가 균등하더라도 요청 수나 서버 부하까지 균등하다고 볼 수는 없다. 연결 하나가 많은 요청을 처리하거나 오래 유지될 수 있기 때문이다. UDP는 연결을 맺지 않으므로 TCP의 연결 설명을 그대로 적용하지 않고, 제품의 흐름 관리와 분산 동작을 확인해야 한다. VIP와 L4는 어떤 관계인가 VIP는 Virtual IP, 즉 가상 IP다. 로드밸런싱 구성에서는 여러 서버 앞에서 서비스를 대표하는 접속 주소로 사용된다. 호출 시스템은 개별 서버 IP 대신 VIP에 접속한다. 로드밸런서는 등록된 서버 중 대상을 선택한다. 뒷단 서버가 추가되거나 제외되어도 VIP가 유지되면 호출 측의 접속 주소를 바꿀 필요가 없다. VIP는 주소이고 L4는 처리 방식이다. VIP가 있다는 사실만으로 전용 L4 장비가 있다고 판단할 수는 없다. 소프트웨어 이중화에서도 VIP를 사용할 수 있다.[9] L4의 구현에도 여러 방식이 있다. NAT, 프록시, DSR 등 구성에 따라 주소 변환과 응답 경로가 달라지므로, 모든 환경에서 요청과 응답이 반드시 같은 장비를 통과한다고 가정해서는 안 된다. 4. L7: HTTP 요청을 보고 어디로 보낼 것인가 L7은 OSI 7계층인 응용 계층을 뜻한다. 웹·API 환경에서는 HTTP 도메인, 경로, 헤더, 쿠키 등을 이용해 전달할 대상 그룹을 선택할 수 있다.[3] 요청 조건 전달 대상 예시 api.example.com API Gateway 그룹 portal.example.com 관리 포털 그룹 /orders/ 경로 주문 서비스 그룹 /images/ 경로 이미지 서비스 그룹 선택한 그룹 안에서 서버 1·2로 요청을 분산하는 것도 가능하다. 경로별로 서비스를 나누지 않더라도 같은 서비스를 제공하는 여러 서버에 HTTP 요청을 분산하는 데 사용할 수 있다.[5] HTTPS의 HTTP 경로나 헤더를 확인하려면 해당 지점에서 TLS를 종료해 요청을 읽을 수 있어야 한다. 뒷단 구간도 암호화해야 한다면 서버와 다시 TLS 연결을 맺는다. TLS 종료 위치는 인증서 관리 위치와 구간별 암호화 정책을 결정한다.[6] L4·L7이라는 이름만으로 실제 성능을 단정할 수는 없다. L7은 HTTP와 TLS 처리가 추가될 수 있지만, 실제 처리량과 지연은 제품 구현, 서버 자원, 연결 재사용, 요청 크기와 정책에 따라 달라진다. 5. Nginx가 있으면 전용 L4 장비가 없어도 될까 필요한 기능과 가용성 요구를 충족한다면 가능하다. Nginx는 웹 서버뿐 아니라 리버스 프록시와 로드밸런서로 사용할 수 있다. Nginx 구성 트래픽 역할 http 의 upstream · proxy_pass HTTP·HTTPS L7 프록시와 로드밸런싱 stream 의 upstream · proxy_pass TCP·UDP L4 프록시와 로드밸런싱 stream 을 사용하려면 설치된 Nginx에 해당 모듈이 포함되거나 로드되어 있어야 한다.[5][7] 즉, Nginx는 제품이고 L4·L7은 처리 방식이다. 현장에서 “L4를 쓴다”는 말은 보통 전용 로드밸런서 장비를 뜻하지만, L4 기능은 소프트웨어로도 구현할 수 있다. 전용 장비를 선택하는 이유에는 요구 처리량, 동시 연결 수, 검증된 이중화 기능, 기존 네트워크와의 연동, 기술지원과 운영 책임 등이 있다. 일부 장비는 특정 처리를 하드웨어로 가속한다. 다만 이를 “모든 전용 장비가 모든 Nginx 구성보다 압도적으로 빠르다”로 일반화하기보다, 필요한 처리량과 제품별 사양·측정 결과를 비교해야 한다. 소프트웨어를 선택하면 장비 구매 비용을 줄일 수 있지만 서버, OS, 패치, 모니터링과 이중화 운영은 필요하다. 6. 실무에서 고려하는 대표 아키텍처 다음은 요구사항에 따라 선택하거나 조합할 수 있는 대표 패턴이다. 보안 장비와 방화벽은 로드밸런싱의 역할에 집중하기 위해 생략했다. 6-1. GSLB → 실제 서버 직접 접속 GSLB에 실제 서버 IP를 등록하고 호출 시스템이 선택된 서버로 직접 접속한다. 장점 은 별도의 트래픽 중계 계층을 줄일 수 있다는 것이다. 여러 거점의 주소를 하나의 도메인으로 제공하는 데도 활용할 수 있다. 한계 는 장애 전환이 DNS 캐시와 호출 프로그램의 동작에 영향을 받는다는 것이다. 호출마다 세밀하게 분산하기 어렵고, URL 경로에 따른 라우팅도 DNS 계층에서 처리하지 않는다. 이 구성에서는 “서버 두 대를 등록했는가”와 함께 “호출 측이 주소를 얼마나 오래 사용하고, 실패하면 어떻게 재연결하는가”를 봐야 한다.[4] 6-2. L4 → Nginx WEB → WAS L4가 WEB 서버로 연결을 분산하고, 각 WEB의 Nginx가 WAS로 요청을 분산한다. flowchart TD C[호출 시스템] --> V["L4 서비스 VIP"] V --> W1["WEB 1 · Nginx"] V --> W2["WEB 2 · Nginx"] W1 --> A1[WAS 1] W1 --> A2[WAS 2] W2 --> A1 W2 --> A2 그림의 L4는 논리적인 서비스 진입점이다. 실제 운영에서는 로드밸런서 계층 자체의 이중화도 필요하다. WEB 1이 장애라면 L4가 정상 WEB으로 새 연결을 보내고, WAS 1이 장애라면 Nginx가 정상 WAS를 선택하도록 구성할 수 있다. VIP가 유지되는 한 해당 뒷단 서버 장애 때문에 호출 시스템의 DNS 주소를 바꿀 필요는 없다. 장점 은 연결 분산과 HTTP 라우팅의 역할을 분리할 수 있다는 것이다. 단점 은 계층과 운영 지점이 늘어난다는 것이다. 타임아웃, 원본 클라이언트 주소 전달 방식과 로그 추적을 맞추어야 한다. 또한 각 WEB이 두 WAS 모두에 접근한다는 전제가 중요하다. WEB 1은 WAS 1만, WEB 2는 WAS 2만 바라보도록 묶으면 장애 대응 범위가 달라진다. 6-3. GSLB → Nginx WEB → Gateway 전용 L4 장비 없이 GSLB가 WEB 주소를 선택하고, 각 WEB의 Nginx가 Gateway 두 대에 요청을 분산하도록 구성할 수 있다. flowchart TD G[GSLB] -. DNS 응답 .-> C[호출 시스템] C --> W1["WEB 1 · Nginx"] C --> W2["WEB 2 · Nginx"] W1 --> A1[Gateway 1] W1 --> A2[Gateway 2] W2 --> A1 W2 --> A2 점선은 주소 선택, 실선은 가능한 API 통신 경로다. 호출 시스템이 매 요청마다 두 WEB을 번갈아 사용한다는 뜻은 아니다. 이 구성에서는 Gateway 장애와 WEB 장애를 구분해야 한다. 장애 위치 대응 방식 호출 측 DNS 캐시의 영향 Gateway 1 장애 접속 중인 Nginx가 정상 Gateway 선택 WEB 주소를 바꿀 필요가 없음 WEB 1 장애 GSLB와 호출 시스템이 WEB 2로 전환 캐시된 WEB 1 주소가 남아 있으면 영향 발생 장점 은 Nginx의 HTTP 기능을 활용하면서 별도 L4 계층을 줄일 수 있다는 것이다. 한계 는 WEB 장애의 전환이 여전히 DNS 기반이라는 것이다. Gateway 장애 대응이 잘 동작하더라도 WEB 장애에 같은 복구 시간을 기대할 수는 없다. GSLB의 점검도 WEB 포트가 열렸는지만 볼지, 진입점이 실제 서비스를 제공할 수 있는지까지 볼지 결정해야 한다. 6-4. Nginx 두 대 + Keepalived VIP 호출 시스템은 고정된 VIP에 접속한다. 활성 Nginx 노드에 장애가 발생하면 대기 노드가 VIP를 인계받는다. Keepalived의 VRRP를 활용한 Active–Standby 구성이 대표적인 예다.[9][10] 장점 은 활성 노드가 바뀌어도 접속 IP를 유지할 수 있다는 것이다. 운영 부담 은 주소 인계가 가능한 네트워크와 상태 점검을 직접 갖추어야 한다는 것이다. Nginx 프로세스 장애도 확인하도록 구성하고 설정 파일과 인증서를 일관되게 배포해야 한다. VIP 인계만으로 기존 TCP 연결이나 애플리케이션 세션까지 자동 복원되지는 않는다. 모든 망에서 VIP 이동이 가능한 것은 아니다. VRRP 통신, 네트워크 정책과 주소 소유권 변경 지원을 확인해야 한다. 단일 VIP의 기본 Active–Standby 구성에서는 평상시 두 노드가 동시에 부하를 나누어 처리하지 않는다. 6-5. 여러 센터에 GSLB + 로컬 로드밸런서 GSLB가 접속할 센터를 선택하고, 각 센터의 L4·L7이 내부 서버로 트래픽을 분산한다.[1] 계층 책임 예시 GSLB 센터 A 또는 B의 서비스 진입점 선택 센터 내부 L4·L7 정상 서버로 연결·요청 분산 애플리케이션·DB 전환 후 필요한 상태와 데이터 제공 장점 은 서버 장애와 센터 전체 장애를 서로 다른 범위에서 대응할 수 있다는 것이다. 어려운 점 은 트래픽 전환과 데이터 복구를 함께 설계해야 한다는 것이다. 센터 B로 정상 접속되더라도 주문 데이터가 없거나 세션을 복원할 수 없으면 사용자는 서비스를 정상적으로 이용하지 못한다. DNS 전환과 함께 데이터 복제 지연, 손실 허용 범위와 복구 목표를 검토해야 한다. 7. 헬스체크가 있어도 장애가 보이는 이유 장애 감지, 대상 제외, 사용자 요청 복구는 서로 다른 단계다. GSLB가 서버 1을 장애로 판정해 이후 응답에서 제외해도 호출 시스템이 이미 받은 IP는 캐시에 남아 있을 수 있다. 단계 발생할 수 있는 일 장애 감지 전 GSLB가 장애 서버 IP를 정상 대상으로 응답 감지 후, 캐시 만료 전 GSLB는 제외했지만 호출 측은 이전 IP 사용 주소 갱신 후 정상 서버로 새로 접속하면 호출 복구 TTL은 DNS 응답을 캐시에 보관할 수 있는 시간을 뜻한다. TTL 30초가 장애 발생 후 30초 이내 복구를 보장하지는 않는다. 장애 감지 시점, 캐시 저장 시점, 재조회와 다음 요청 시점이 다르기 때문이다.[4] Java처럼 런타임 자체에 주소 캐시 정책이 있는 경우도 있다. 따라서 DNS 레코드와 함께 실제 호출 애플리케이션의 캐시 설정을 확인해야 한다.[11] L4·L7은 뒷단 서버 장애에 대해 DNS 캐시 만료를 기다리지 않고 다른 서버를 선택할 수 있다. 하지만 감지 전에 들어온 연결이나 처리 중인 요청까지 항상 복구해 주는 것은 아니다. 기존 TCP 연결을 다른 서버에서 그대로 이어받는 것도 별개의 문제다.[12] 8. 헬스체크와 재시도도 함께 설계해야 한다 능동 점검과 수동 점검 능동 헬스체크는 사용자 요청과 별도로 점검 요청을 보내 상태를 확인한다. 수동 헬스체크는 실제 요청에서 발생한 실패를 보고 대상을 제외한다. 오픈소스 Nginx의 기본 upstream 장애 판정은 수동 방식이다. max_fails 와 fail_timeout 등의 설정이 관련된다. 주기적인 HTTP 능동 헬스체크는 공식 Nginx Plus 기능으로 제공된다. 별도 모듈이나 외부 점검 체계를 쓰는 경우는 구분해야 한다.[8] 트래픽 분산 계층과 헬스체크 방식도 별개다. L4로 트래픽을 분산하면서 서버 상태는 HTTP 점검 URL로 확인하도록 구성하는 제품도 있다. 점검 범위는 실제 트래픽을 받을 준비가 되었는지 판단할 수 있어야 한다. 너무 얕은 점검은 서비스 장애를 놓치고, 모든 공통 의존성까지 검사하면 전체 서버를 동시에 제외할 수도 있다. 다른 서버로 재시도하면 모든 오류를 숨길 수 있을까 Nginx의 proxy_next_upstream 처럼 실패한 요청을 다른 서버로 전달하는 기능은 오류를 줄이는 데 도움이 된다. 하지만 조건, 횟수와 허용 시간을 제한해야 한다. 이미 클라이언트로 응답 일부를 보냈다면 다른 서버의 응답으로 처음부터 바꾸어 줄 수도 없다.[13] 주문 서버가 DB 저장을 끝낸 뒤 응답만 유실된 상황을 생각해 보자. 호출 측에는 실패처럼 보이지만 주문은 이미 생성되었다. 같은 요청을 다시 보내면 중복 주문이 생길 수 있다. 따라서 상태를 변경하는 API에는 멱등성 키나 중복 방지 설계가 필요하다. 호출 프로그램과 여러 프록시가 각각 재시도한다면 전체 시도 횟수와 장애 시 부하도 확인해야 한다.[14] 9. 어떤 구성이 적합한지 판단하는 기준 요구사항 검토할 방향 여러 센터·리전의 접속 대상을 선택 GSLB와 각 거점의 가용성 구성 TCP·UDP 트래픽 분산 전용·관리형·소프트웨어 L4 도메인·URL에 따른 API 분산 Nginx 등 L7 프록시·로드밸런서 전용 장비 없이 HTTP 분산 구현 Nginx와 Nginx 계층 자체의 이중화 뒷단 서버 장애 시 DNS 캐시 대기 회피 고정 진입점 뒤에서 정상 서버를 선택하는 구성 주문·결제의 중복 처리 방지 애플리케이션 멱등성과 재시도 정책 L7이 필요하다고 항상 L4를 앞에 추가해야 하는 것은 아니다. L7 로드밸런서가 진입점과 분산을 직접 담당할 수 있다. 기존 인프라의 L4가 WEB 이중화를 담당한다면 Nginx와 함께 사용하는 구성이 자연스러울 수도 있다. 구성을 결정한 뒤에는 실제 호출 경로로 검증해야 한다. 시험 상황 확인할 내용 Gateway 프로세스 종료 정상 Gateway 전환 시간과 실패 요청 수 WEB 서버 중단 진입점 전환 시간과 DNS 캐시 영향 포트는 열렸지만 응답이 멈춘 상태 점검·호출 타임아웃의 장애 감지 기존 연결 유지 중 서버 장애 실제 커넥션풀의 재연결 동작 서버 복구 재편입 시점과 복구 직후 부하 등록 요청의 응답 유실 재시도 시 중복 데이터 발생 여부 결과는 장애 감지 시간, 정상 호출 재개 시간, 실패율과 지연 분포로 남긴다. 단순한 curl 반복 호출과 운영 프로그램은 캐시와 연결 재사용 방식이 다를 수 있다. 최종 판단에는 실제 호출 방식이 반영되어야 한다. 참고 자료 개념과 제품 기능은 아래 공식 문서를 참고했다. 구성별 장단점과 장애 시나리오는 이를 적용해 설명한 예시다. 세부 기능과 기본값은 사용하는 버전·에디션의 문서를 확인한다. Cloudflare — Load Balancing Reference Architecture F5 — Layer 4 Load Balancing F5 — Layer 7 Load Balancing Cloudflare — DNS-only Load Balancing NGINX — HTTP Load Balancing NGINX — Securing HTTP Traffic to Upstream Servers NGINX — TCP and UDP Load Balancing NGINX — HTTP Health Checks Keepalived — Quick Start NGINX — High Availability with Keepalived Oracle — Java Networking Properties F5 — Pools and Action on Service Down NGINX — proxy_next_upstream AWS — Timeouts, Retries, and Backoff with Jitter