이 문서는 의문을 가지고 있던 지점을 AI 에이전트와 대화하며 정리한 메모입니다. L4와 L7 로드밸런싱의 차이, TLS 종료와 라우팅 기준, Logstash와 Elasticsearch 앞단에서의 선택 포인트를 정리합니다.

L4 vs L7 로드밸런싱 완전 정리

#

1. L4 vs L7 로드밸런싱 기본 개념

#

L4 로드밸런싱 (Transport Layer)

#

L4 로드밸런싱은 TCP/UDP 같은 전송 계층 기준으로 연결을 분산한다. 대표적으로 IP, Port, 프로토콜, 연결 단위 정보를 바탕으로 대상 서버를 고른다.

장점

• 애플리케이션 요청 내용을 직접 해석하지 않아 처리 경로가 단순하다
• TCP/UDP 기반 다양한 트래픽에 적용하기 쉽다
• 단순 분산, 정적 IP, 대량 연결 처리 같은 요구사항에 잘 맞는다

단점

• URL, 헤더, 쿠키, gRPC 메서드 같은 애플리케이션 정보 기반 라우팅은 불가하다
• 세밀한 요청 단위 정책은 L7보다 제한적이다

참고: TLS 종료는 L7에서 흔하지만, AWS NLB처럼 L4 계열에서도 TLS listener로 지원하는 제품이 있다. 따라서 “L4면 무조건 TLS 종료 불가"라고 단정하면 틀릴 수 있다.

L7 로드밸런싱 (Application Layer)

#

L7 로드밸런싱은 애플리케이션 계층 요청을 해석해서 분산한다. 웹 트래픽 기준으로는 URL, 헤더, 쿠키, 메서드, 쿼리 문자열 등을 기준으로 라우팅할 수 있다.

장점

• URL 경로, 호스트, 헤더, 쿼리 문자열 기반 라우팅 가능
• 쿠키 기반 sticky session 구현 가능
• TLS 종료와 HTTP/gRPC 수준 정책 적용이 쉽다
• 카나리 배포, A/B 테스트, 인증, 리다이렉트 같은 고급 제어에 유리하다

단점

• 요청을 해석해야 하므로 L4보다 일반적으로 처리 경로가 복잡하다
• 제품이 이해하는 애플리케이션 프로토콜에 의존한다
• 기능이 많아질수록 설정과 장애 포인트가 늘어난다

참고: 많은 L7 제품은 HTTP/HTTPS 중심이지만, 제품에 따라 HTTP/2, gRPC, WebSocket도 지원한다. 따라서 “L7 = 오직 일반 HTTP만"이라고 보는 것도 과한 단순화다.

한눈에 비교

#

2. 언제 L4를, 언제 L7을 써야 하는가?

#

핵심 원칙

#

L4는 연결을 어디로 보낼지 결정하는 데 강하고, L7은 요청 내용을 보고 어떻게 나눌지 결정하는 데 강하다.

L7도 여러 서버에 트래픽을 분산할 수 있다. 차이는 요청 내용을 읽는 기능이 실제로 필요한가 에 있다.

단순 분산 → L4가 자연스러운 이유

#

상황: 동일한 Spring 서버 3대에 트래픽 분산

#

클라이언트 → [로드밸런서] → Server A
                           → Server B
                           → Server C

세 서버가 완전히 동일한 역할을 하고, 요청마다 별도 정책이 필요 없다면 굳이 URL이나 헤더를 읽을 이유가 없다.

• L4: 연결 단위로 분산 → 보통 더 단순하고 가볍다
• L7: HTTP 요청을 해석한 뒤 분산 → 기능은 많지만 필요 없는 경우도 많다

즉, 이 경우에는 “L7이 불가능해서"가 아니라 “L4로 충분해서” L4가 더 자연스러운 선택이 된다.

MSA 환경 → L7이 필요한 이유

#

상황: 쇼핑몰 MSA

#

/api/users     → User Service (포트 8081)
/api/orders    → Order Service (포트 8082)
/api/products  → Product Service (포트 8083)

하나의 진입점에서 경로별로 다른 서비스로 보내려면 요청 내용을 읽어야 한다.

클라이언트가 GET /api/orders 요청

L4: 연결 정보만 보므로 URL 경로 자체는 판단 근거가 아님 ❌
L7: /api/orders 경로를 읽고 Order Service로 라우팅 ✅

이 구조에서는 L7 프록시, API Gateway, Ingress Controller 같은 요청 인식형(L7) 구성이 필요하다.

카나리 배포도 구분해서 봐야 한다

#

/api/orders 요청 중
  → 특정 헤더가 있으면 v2로
  → 나머지는 v1로

이처럼 헤더, 쿠키, 경로, 메서드 기준으로 트래픽을 나누는 카나리/A-B 라우팅은 L7이 필요하다.

반면 단순 가중치 기반 분산은 일부 L4 제품도 지원한다. 예를 들어 AWS Network Load Balancer는 여러 target group에 weight를 줄 수 있다.
그래서 정확히 말하면, “정교한 요청 기반 카나리"는 L7의 영역이고, “단순 비율 분할"은 제품에 따라 L4에서도 가능할 수 있다.

정리

#

3. ELK 스택에서 왜 L4 로드밸런싱을 쓰는가?

#

ELK 데이터 흐름

#

애플리케이션 서버들
    ↓ (로그 전송)
[Logstash 클러스터 - 3대]  ← 여기 앞에 LB를 둘 수 있음
    ↓
Elasticsearch
    ↓
Kibana

Logstash 앞에 로드밸런서를 두는 이유는, 입력 트래픽을 여러 Logstash 인스턴스로 분산하기 위해서다.

핵심은 “Logstash 입력 프로토콜"이다

#

Logstash 자체는 HTTP 전용 제품이 아니다. 어떤 input plugin 을 쓰느냐에 따라 앞단에서 다뤄야 하는 프로토콜이 달라진다.

• Beats input: Logstash가 Beats framework의 연결을 받는다
• Filebeat의 Logstash output: lumberjack protocol을 사용하며 TCP 위에서 동작한다
• UDP input: UDP로 이벤트를 받는다
• HTTP input: HTTP(S) 요청을 이벤트로 받는다

즉, “Logstash 앞은 무조건 L4” 도 아니고 “무조건 L7” 도 아니다.
실제로 쓰는 입력이 Beats/TCP/UDP 계열이면 L4가 자연스럽고, HTTP input을 쓰면 L7도 가능하다.

왜 L4가 자주 어울리는가?

#

로그 수집 경로에서 다음 조건이 많기 때문이다.

• 입력이 Beats, TCP, UDP, syslog처럼 HTTP가 아닌 경우가 많다
• 여러 Logstash 인스턴스가 동일한 역할을 하므로 경로 기반 라우팅이 필요 없는 경우가 많다
• 단순 분산이 목적이라면 요청 내용을 굳이 해석할 이유가 적다

Filebeat → LB → Logstash A
              → Logstash B
              → Logstash C

이 구조에서는 “어느 Logstash가 이 로그를 처리해도 되는가?” 가 핵심이고, 대부분은 그렇다.
그래서 HTTP 기능보다 TCP/UDP 수준 분산이 더 중요한 경우가 많다.

L7으로 하면 안 되나?

#

안 되는 것은 아니다. Logstash에는 http input plugin 이 있으므로, HTTP로 이벤트를 받는 구성이라면 L7도 사용할 수 있다.

다만 이 경우에도 확인할 질문은 단순하다.

• 입력이 정말 HTTP인가?
• URL/헤더 기반 라우팅이 필요한가?
• 여러 Logstash 인스턴스가 동일 역할이라면 L7 기능이 실질적으로 필요한가?

결론: Logstash 앞단 선택은 “ELK라서"가 아니라 “입력 프로토콜과 라우팅 요구사항이 무엇인가"로 결정하는 게 맞다.

4. Elasticsearch 샤드 구성과 로드밸런싱

#

중요한 개념 구분

#

샤드 라우팅과 외부 로드밸런서는 다른 레이어의 이야기다.

외부 로드밸런서가 샤드를 직접 분산시키는 게 아니다.
Elasticsearch 클러스터는 각 노드가 클러스터 상태를 공유하고, 적절한 노드로 요청을 전달할 수 있다.

ES 내부 샤드 라우팅 메커니즘

#

클라이언트
    ↓ HTTP 요청
[Node 1] ← coordinating 역할
    ↓
  ┌─────────────────┐
  ↓                 ↓
[Node 2]          [Node 3]
Shard 0, 1        Shard 2, 3

클라이언트 요청을 받은 노드는 클러스터 상태를 바탕으로 적절한 샤드가 있는 노드로 요청을 전달하고, 응답을 모아 반환할 수 있다.
Elastic 문서에서도 coordinating-only node를 smart load balancer 처럼 동작한다고 설명한다.

즉, 외부 LB가 하는 일은 보통 “첫 진입 노드를 고르는 것” 이지, “샤드를 직접 나누는 것” 이 아니다.

그럼 ES 앞에 두는 로드밸런서는 뭘 하는가?

#

노드 레벨 분산이다.

클라이언트들
    ↓
[외부 LB] → Node 1
          → Node 2
          → Node 3
              ↓
        (이후 샤드 단위 조정은 ES 내부에서 처리)

어느 노드로 먼저 들어가든, 그 다음의 샤드 단위 분산과 reduce는 Elasticsearch 클러스터가 처리한다.

ES 앞단에서 왜 L4가 자주 거론되는가?

#

이유 1: 외부 LB와 내부 transport 포트는 구분해야 한다

#

Elasticsearch는 HTTP 인터페이스와 transport 인터페이스를 따로 둔다.

9200대 → HTTP client communication
9300대 → node-to-node transport TCP

여기서 중요한 점은, 9300대 transport 포트가 존재한다고 해서 외부 클라이언트용 LB가 반드시 9300도 다뤄야 한다는 뜻은 아니라는 것이다.
보통 클라이언트 진입점은 HTTP(9200대)이고, 9300대는 클러스터 내부 통신용으로 본다.

즉, “9300 때문에 외부 ES 앞단은 무조건 L4” 라고 말하면 과하다.

이유 2: URL 기반 라우팅이 보통 필요 없다

#

GET /my-index/_search
POST /my-index/_doc

Elasticsearch API는 경로가 다르더라도, 일반적인 다중 노드 클러스터 앞단에서는 특정 URL을 특정 노드로 보내야 하는 경우가 흔하지 않다.

즉, 외부 LB 입장에서는 보통:

• 어느 healthy node로 먼저 보낼지만 결정하면 되고
• 이후의 샤드 배치와 내부 전달은 Elasticsearch가 처리한다

이 때문에 요청 내용을 읽는 L7 기능이 꼭 필요하지 않은 경우가 많다.

이유 3: 단순 노드 분산만 원하면 L4가 충분하다

#

외부에서 필요한 것이:

• 정적 진입점
• 여러 ES 노드로의 기본 분산
• TCP/TLS 수준의 단순 전달

정도라면 L4가 자연스러운 선택이 된다.

ES에서 L7을 쓰면 안 되나?

#

가능하다. 9200대 HTTP API 앞단에는 L7을 둘 수 있고, 실제로 AWS ALB처럼 HTTP/HTTPS 기반 L7 로드밸런서로 구성할 수도 있다.

다만 이 경우에도 질문은 같다.

• path/header 기반 정책이 필요한가?
• 인증/리다이렉트/WAF 같은 HTTP 기능이 필요한가?
• 단순 노드 분산 이상의 요구사항이 있는가?

없다면 L4가 충분할 수 있고, 있다면 L7이 의미가 생긴다.

5. 최종 요약

#

선택 기준 한 문장 정리

#

L7이 더 많은 요청 정보를 이해하지만, 그 정보가 필요 없으면 L4가 더 단순한 선택이 된다.

전체 케이스 정리

#

참고 자료

#

• AWS - Application Load Balancer
• AWS Docs - Listeners for your Application Load Balancers
• AWS Docs - Condition types for listener rules
• AWS Docs - Action types for listener rules
• AWS Docs - Target groups for your Application Load Balancers
• AWS Docs - What is a Network Load Balancer?
• AWS Docs - Listeners for your Network Load Balancers
• AWS Docs - Health checks for Network Load Balancer target groups
• AWS Docs - Target groups for your Network Load Balancers
• Elastic Docs - Beats input plugin
• Elastic Docs - Udp input plugin
• Elastic Docs - Http input plugin
• Elastic Docs - Configure the Logstash output (Filebeat)
• Elastic Docs - Networking settings
• Elastic Docs - Node roles
• Elastic Docs - Search shard routing
• NGINX Docs - HTTP Load Balancing
• NGINX Docs - TCP and UDP Load Balancing