Opensource(오픈 소스)/HAproxy

L4/L7 스위치의 대안, 오픈 소스 로드 밸런서 HAProxy란

hippo 데브옵스 2022. 7. 30. 14:37
  • HAProxy는 모바일 환경이 발달 → 모바일 환경에서는 빠르고 유연한 확장성이 필수 요소
  • 최초 서비스 구축 시 확장성을 고려해서 L4/L7 스위치 분산까지는 고려
  • 지역간 분산(GSLB 구성)을 고려해서 설계하는 것은 일부 업체를 제외하고는 비용 및 경험 부재로 어려움
  • 'DNS + HAProxy + 클라우드 서비스'를 조합하여 서비스를 진행하면 적은 비용으로 GSLB 구성과 동일한 수준으로 구축 가능
  • HAProxy를 이해하기 위해서 로드 밸런서의 기본 개념과 HAProxy의 동작 방식을 이해 필요


1. 오픈 소스 로드 밸런서 HAProxy

  • HAProxy는 기존의 하드웨어 스위치를 대체하는 소프트웨어 로드 밸런서
  • 네트워크 스위치에서 제공하는 L4, L7 기능 및 로드 밸런서 기능을 제공
  • HAProxy는 설치가 쉽고, 환경 설정도 어렵지 않음
  • 서비스 이중화를 빠르게 구성 가능

2. 로드 밸런싱이란

  • 로드 밸런싱이란 부하 분산을 위해서 가상(virtual) IP를 통해 여러 서버에 접속하도록 분배하는 기능
  • 로드 밸런싱에서 사용하는 주요 기술

2.1. NAT(Network Address Translation)

  • 사설 IP 주소를 공인 IP 주소로 바꾸는 데 사용하는 통신망의 주소 변조기

2.2. DSR(Dynamic Source Routing protocol)

  • 로드 밸런서 사용 시 서버에서 클라이언트로 되돌아가는 경우 목적지 주소를 스위치의 IP 주소가 아닌 클라이언트의 IP 주소로 전달해서 네트워크 스위치를 거치지 않고 바로 클라이언트를 전달

2.3. Tunneling

  • 인터넷상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념
  • 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제 가능


3. 로드 밸런서 동작 방식

  • 네트워크에서 IP 주소와 MAC 주소를 이용해 목적지(destination) IP 주소를 찾아가고 출발지로 되돌아오는 구조
  • 4가지의 로드 밸런서 동작 방식 설명

3.1. Bridge/Transparent Mode

  • 사용자(client)가 서비스(server)를 요청하면 L4로 전달된 목적지 IP 주소를 real server IP 주소로 변조하고, MAC 주소를 변조해서 목적지를 찾아가는 방식
    3.1.1. 요청 전달 시 변조

      사용자(client) → L4 → NAT(IP/MAC 주소 변조) → real server(server)

    3.1.2. 응답 전달 시 변조

      real server(server) → NAT → L4 → 사용자

3.2. Router Mode

  • Bridge/Transparent Mode와 유사하지만 출발지(source) MAC 주소도 변조

3.3. One Arm Mode

  • 사용자(client)가 real server(server)에 접근할 때 목적지 IP는 L4 스위치 IP를 설정
  • L4에 도달하면 L4가 클라이언트에게 받은 목적지 IP 주소를 L4 IP 주소에서 real server IP와 real server MAC 주소로 변조
  • 응답으로 되돌아가는 IP는 L4의 IP pool의 IP 주소로 변조

3.4. DSR (Direct Server Return) Mode

  • 사용자가 real server(server)에 접근할 때 출발지와 목적지의 IP 주소를 변조하지 않고, L4에서 관리하는 real server의 MAC 주소 테이블을 확인해서 MAC 주소만 변조


4. HAProxy 동작 방식

  • HAProxy는 기본적으로 reverse proxy 형태로 동작
  • 브라우저에서 사용하는 proxy는 클라이언트 앞에서 처리하는 기능 → forward proxy라 칭함
  • reverse proxy의 역할은 서비스 요청에 대해서 서버 앞 단에 존재하여, 서버로 들어오는 요청을 대신 받아서 서버에 전달하고 요청한 곳에 결과를 다시 전달하는 것
  • HAProxy의 동작 방식을 알면, HAProxy를 이용해서 어떤 구조로 확장 가능한지 알 수 있음
  • HAProxy의 동작 흐름
    1. 최초 접근 시 서버에 요청 전달
    2. 응답 시 쿠키(cookie)에 서버 정보 추가 후 반환
    3. 재요청 시 proxy에서 쿠키 정보 확인 → 최초 요청 서버로 전달
    4. 다시 접근 시 쿠키 추가 없이 전달 → 클라이언트에 쿠키 정보가 계속 존재함(쿠키 재사용)


5. HAProxy HA(High availability) 구성

  • HAProxy는 기본적으로 VRRP(Virtual Router Redundancy Protocol)를 지원
  • HAProxy는 초당 8만 건 정도의 연결을 처리 가능
  • HAProxy는 소프트웨어 기반의 솔루션이기 때문에 HAProxy가 설치된 서버에서 문제가 발생하면 하드웨어 L4보다는 불안정
  • HA 구성으로 master HAProxy에 문제가 생기는 경우에 slave HAProxy에서 서비스가 원활하게 제공되어야함

5.1. HAProxy HA(High availability) 기본 구성 설명 → HAProxy 무정지하기 위한 Active - Standby 구성

  • 가상 IP 주소를 공유하는 active HAProxy 서버와 standby HAProxy 서버가 heartbeat를 주고 받으면서 서로 정상적으로 동작하는지 여부를 확인
  • active 상태의 서버에 문제가 발생하면 standby HAProxy가 active 상태로 변경
  • 기존 active HAProxy의 가상 IP 주소를 standby HAProxy가 가져오면서 서비스가 무정지 상태를 유지
  • 1초 정도의 순단 현상은 발생


5.2. HAProxy HA(High availability) 기본 구성이 단일 HAPRoxy와 다른 점

  • 단일 HAProxy와 다른 점은 최초 접근 시 쿠키에 바로 서버 정보를 입력하지 않고 서버에서 jsessionid가 전달될 때 서버 정보를 합쳐서 전달
  • 쿠키에 정보 추가 없고 X-Forwarded-For에 정보 추가
  • 쿠키에 추가 없음
  • Jsessionid 추가
  • 서버 정보 + jsessionid를 쿠키에 추가
  • 쿠키에서 서버 판별 후 jsessionid만 전달




6. L4 + HAProxy HA 구성 및 Global 환경에서 구성

  • HAProxy와 기존 하드웨어 스위치를 이용해서 더 확장된 형태의 고가용성 구조를 설계 가능

6.1. 하드웨어 L4 + HAProxy

  • 클라이언트에서 연결되는 부분은 가상 IP 주소 + L4의 구성으로 하드웨어 이중화를 구축
  • L4에서 서버 앞 단에 HAProxy를 구축해서 HAProxy를 더 확장할 수 있는 구조로 설계 가능
  • L4 + HAProxy 구성


6.2. GSLB(Global Service Load Balancing) + HAProxy

  • global 서비스가 증가되면서 IDC 간 이중화 및 global 환경에서의 무정지 서비스를 위한 DR(Disaster Recovery, 재해 복구) 시스템 구축이 필수 요구사항
  • GSLB + HAProxy를 이용하면 global한 무정지 서비스 구축이 가능
  • GSLB 구축에 L4 스위치를 사용할 수도 있지만 GSLB 구성용 L4는 고가의 장비
  • L4를 이용한 GSLB 대신 DNS(BIND)를 이용한 구축 형태 → Global 환경에서 GSLB+HAProxy 구성
    1. 클라이언트에서 DNS로 도메인 조회
    2. 근거리 IDC 정보 전달




7. HAProxy Ncloud 적용 사례

  • 사내 Ncloud 시스템의 DNS RR을 HAProxy로 교체 → DNS를 HA 구성
  • DNS를 HA 구성함으로써 기존 DNS로 구성할 때보다 서버 증설 및 삭제에 있어 유연성이 증가, 서비스 안정성 증가
  • DNS를 HA로 구성함으로써 애플리케이션 서버에서 클라이언트 IP 주소를 찾아서 처리하는 로직에 문제가 발생
    • 문제 발생 이유 → 사용자의 요청이 HAProxy를 거치면서 클라이언트 IP 주소 정보가 HAProxy의 정보로 변조
    • 해결 방안 → 애플리케이션 서버가 HTTP 헤더에서 클라이언트 IP 주소를 조회하면 실제 클라이언트 IP 주소가 반환되도록 보완
      1. HAProxy에서 제공하는 X-Forwarded-For 옵션을 적용
      2. Apache에서 mod_rpaf 모듈을 설치




8. HAProxy 어드민 페이지

9. HAProxy 성능

  • HAProxy가 설치되는 서버의 사양에 따라 어느 정도 성능이 제공되는지 확인하기 위해 성능을 측정
  • nGrinder(http://www.nhnopensource.org/ngrinder/) 테스트 결과와 해외 사례를 공유

1. 해외 운영 사례

  • 서버 사양(저사양) : Dell PowerEdge 2850, Intel PCI3 4x Gigabit Fiber card (CPU 1.6GHz dual core x 1)
  • 제공 서비스: 영화 다운로드 서비스
  • 결과: 일별 2.47TB 전송 + 81일 동안 운영

2. nGrinder 테스트

  • 환경: HAProxy (1core), apache 서버 2대
  • 결과: 6,603 TPS


3. 해외 성능 사례

  • 듀얼 CPU 환경에서 초당 2만 세션까지 연결 가능 → CPU 성능이 높아지면 연결 가능 세션 수 증가
  • 초당 1만 건 세션 연결 시 응답에 100밀리초(ms) 소요 → 최대 연결 개수는 하드웨어의 RAM과 file descriptor에 의해 결정됨 → 세션당 16KB 사용 시 6만 세션당 1G RAM 필요




HAProxy 설치 및 옵션 → HAProxy의 중요 옵션 설명

1. HAProxy 운영 시 필요한 옵션

  • HAProxy의 경우 튜닝 옵션을 비롯하여 매우 많은 옵션을 지원 → 실제 구축 시 필요한 옵션만 설명
  • 옵션을 변경하려면 haproxy.cfg 파일을 수정 필요
  • HAProxy 설정 매뉴얼 → https://runebook.dev/ko/docs/haproxy/-index-

2. HAProxy 옵션

  • 전역 옵션(global) 섹션과 기본 옵션(defaults) 섹션, 프록시 옵션 섹션(listen)의 주요 옵션에 관한 설명
  • global # 전역 옵션 섹션
    1. daemon → 백그라운드 모드(background mode)로 실행
    2. log → syslog 설정
    3. log-send-hostname → hostname 설정
    4. uid → 프로세스의 userid를 number로 변경
    5. user → 프로세스의 userid를 name으로 변경
    6. node → 두 개 이상의 프로세스나 서버가 같은 IP 주소를 공유할 때 name 설정(HA 설정)
    7. maxconn → 프로세스당 최대 연결 개수
  • Defaults # 기본 옵션 섹션
    1. log → syslog 설정
    2. maxconn → 프로세스당 최대 연결 개수
  • listen
    1. listen webfarm 10.101.22.76:80→ listen haproxy name ip:port
    2. mode http → 연결 프로토콜
    3. option httpchk → health check
    4. option log-health-checks → health 로그 남김 여부
    5. option forwardfor → 클라이언트 정보 전달
    6. option httpclose → keep-alive 문제 발생 시 off 옵션
    7. cookie SERVERID rewrite → 쿠키로 서버 구별 시 사용 여부
    8. cookie JSESSIONID prefix → HA 구성 시 prefix 이후에 서버 정보 주입 여부
    9. balance roundrobin → 순환 분배 방식
    10. stats enable → 서버 상태 보기 가능 여부
    11. stats uri /admin → 서버 상태 보기 uri
    12. server xvadm01.ncli 10.101.22.18:80 cookie admin_portal_1 check inter 1000 rise 2 fall 5 → real server 정보(server [host명] [ip]:[port] cookie [서버쿠키명] check inter [주기(m/s)] rise [서버구동여부점검횟수], fall [서비스중단여부점검횟수])

3. balance 옵션

  • 로드 밸런싱의 경우 round robin 방식을 일반적으로 사용하지만 다른 여러 방식이 있음 → 옵션에 적용할 수 있는 로드 밸런싱 알고리즘
    1. roundrobin → 순차적으로 분배(최대 연결 가능 서버 4128개)
    2. static-rr → 서버에 부여된 가중치에 따라서 분배
    3. leastconn → 접속 수가 가장 적은 서버로 분배
    4. source → 운영 중인 서버의 가중치를 나눠서 접속자 IP를 해싱(hashing)해서 분배
    5. uri → 접속하는 URI를 해싱해서 운영 중인 서버의 가중치를 나눠서 분배(URI의 길이 또는 depth로 해싱)
    6. url_param → HTTP GET 요청에 대해서 특정 패턴이 있는지 여부 확인 후 조건에 맞는 서버로 분배(조건 없는 경우 round robin으로 처리)
    7. hdr → HTTP 헤더 에서 hdr()으로 지정된 조건이 있는 경우에 대해서만 분배(조건 없는 경우 round robin으로 처리)
    8. rdp-cookie → TCP 요청에 대한 RDP 쿠키에 따른 분배

참고 URL : https://d2.naver.com/helloworld/284659


저작자표시 비영리 변경금지