Haproxy(7layer) - 병목

YYY·2025년 5월 15일

lvs와 haproxy 분리하는 이유

haproxy에 fifo로 데이터가 들어온다면 cpu는 7계층까지 다 열어봐야함

사용자 공간(User space)에 있는 HAProxy 프로세스가 CPU를 사용해서 직접 까서 봄.

패킷 파싱(내용 까보기)을 "누가", "언제", "어떻게" 하는가?

핵심 주체: HAProxy 프로세스 (user-space 프로그램)

  • 커널이 TCP connection 수립까지 처리하면,
  • 그 이후로는 유입된 데이터(recv()로 꺼낸 것)를 HAProxy 프로세스가 직접 파싱
  • HTTP인지, URI가 뭔지, 쿠키가 뭔지 다 여기에 해당

흐름 요약: 실제로 패킷을 까는 과정

[NIC]
 → [커널 TCP/IP 처리]
   → [sk_receive_queue에 패킷 도착]
     → [HAProxy 프로세스가 recv()로 꺼냄]
       → [HAProxy 내부 코드에서 패킷 파싱 수행]
         → [요청 분기/라우팅 결정]

이 중 **"패킷을 까서 본다"**는 건 다음 시점입니다:

HAProxy 프로세스가 recv()로 소켓에서 데이터를 읽은 직후

→ 이 데이터를 parse_http_headers(), parse_url(), check_acl() 등의 함수가
CPU 연산으로 직접 문자열 검사 / 비교 / 파싱을 수행합니다.

📌 이때 CPU는 7계층 수준의 내용을 모두 "열어서 분석"합니다.


예시: HAProxy 내부에서 실제로 “패킷을 까는” 함수

// src/proto_http.c

int http_process_req_common(struct stream *s, struct channel *req, int an_bit, struct proxy *px) {
    ...
    ret = parse_http_headers(s, req);
    ...
}

이 함수는 다음을 수행합니다:

  • 요청 라인 파싱 (e.g., GET /index.html HTTP/1.1)
  • 헤더 추출 (Host, User-Agent, Authorization)
  • 정규표현식, prefix, 쿠키 검사 등

전부 HAProxy가 CPU를 써서 수행


왜 커널이 안 까보는가?

  • 커널은 TCP 레벨까지만 처리합니다 (3~4계층)
  • 7계층(HTTP 등)은 애플리케이션 로직이기 때문입니다
  • 커널이 HTTP 헤더를 해석하지는 않음 (그건 nginx, HAProxy, envoy 등 user-space가 담당)

모니터링 팁

항목명령어
HAProxy 프로세스 CPUtop, htop, pidstat -p <pid>
syscall 빈도strace -p <pid>
7계층 분석비용perf topparse_http_headers, strcmp

✅ 요약

실제로 패킷을 까서(7계층 파싱) 보는 주체는 커널이 아니라 HAProxy 프로세스입니다.

커널은 TCP까지만 다루고,
HAProxy가 CPU로 데이터를 읽고 해석하며 요청 경로, 헤더, 쿠키, 바디 등을 분석합니다.

profile
무지렁이 탈출기

0개의 댓글