Network

[NGINX 쿡북] 2. 고성능 부하분산

noahkim_ 2025. 4. 1. 02:35

데릭 디용기 님의 "NGINX 쿡북" 책을 정리한 글입니다.


0. 소개

인터넷 서비스에서의 성능과 가용성

  • 현대의 인터넷 서비스의 사용자 경험은 높은 성능과 가용성이 필요함
  • 이를 위해 일반적으로 같은 시스템을 여러 대 운영하고 부하를 각 시스템으로 분산함

 

부하 분산

개념 설명
Scale Out
동일한 시스템을 여러 대 운영하여 부하를 분산시키는 방식
부하에 따라 서버 수를 동적으로 조절함
Stateless 아키텍처
서버 간에 상태 정보를 공유 메모리에 저장하여 서버 간 독립성을 유지하는 아키텍처
서비스의 효율성을 높아짐
세션 관리
상태 유지가 필요한 경우, 사용자가 같은 서버로 연결되도록 함
쿠키값이나 라우팅을 추적하는 등의 방식으로 문제를 해결

 

서버 상태 감지

방식 설명
패시브 방식
사용자의 요청을 로드 밸런서가 받은 시점에 서버와의 연결이나 응답을 확인하는 방식 (실시간으로 서버 상태 감지)
부하가 적음
액티브 방식 로드 밸런서가 주기적으로 업스트림 서버와 연결을 시도하고 요청을 보내 서버 상태를 확인 (서버 상태를 능동적으로 점검)
  • 엔진엑스는 서비스 품질을 위해 업스트림 서버의 문제를 감지하는 능력 및 트래픽 전송을 중지할 수 있어야 함

 

1. HTTP 부하분산

upstream backend {
    server 10.10.12.45:80        weight=1;
    server app.example.com:80    weight=2;    
    server spare.example.com:80  backup;
}

server {
    location / {
        proxy_pass http://backend;
    }
}
upstream 모듈
  • 문제 발생 시 backup으로 지정한 서버를 사용함
  • 부하 분산: 지정한 weight 매개변숫값에 따라 두 번쨰 서버는 첫 번째 서버보다 많은 요청을 받음

 

server 지시자
  • 각 업스트림 대상 지정
  • proxy_pass를 통해 프록시 역할을 수행함

 

2 .TCP 부하분산

stream {
    upstream mysql_read {
        server read1.example.com:3306   weight=5;
        server read2.example.com:3306;
        server spare.example.com:3306   backup;
    }
    
    server {
        listen 3306;
        proxy_pass mysql_read;
    }
}
stream 모듈
  • TCP 트래픽을 처리하는 지시자

 

3. UDP 부하분산

stream {
    upstream ntp {
        server ntp1.example.com:3306   weight=5;
        server ntp2.example.com:3306;
    }
    
    server {
        listen 123 udp;
        proxy_pass ntp;
    }
}

 

4. 부하분산 알고리즘

알고리즘 설명
round robin (기본값) 지정된 서버의 순서에 따라 요청을 분산 (가중치 설정 가능)
least_conn 현재 열린 커넥션이 가장 적은 서버로 연결
least_time 응답 시간이 가장 빠른 서버로 연결
- header: 응답 헤더 시간을 활용하여 응답 시간 추정
- last_byte: 응답 전체 시간을 활용하여 응답 시간 추정
hash
특정 문자열을 해싱하여 동일한 요청을 같은 서버로 연결
- consistent: 서버 재구성으로 인한 재분배 시, 영향을 최소화 함
iphash 클라이언트의 IP 주소를 해싱하여 같은 서버로 연결 (세션 유지에 유용)
random 무작위로 서버를 선택하여 연결 (가중치 설정 가능)
- two [method]: 두대를 후보자로 선정하고, method에 따라 분배할 서버를 선정

 

9. 수동적인 헬스 체크

upstream backend {
    server backend1.example.com:1234 max_fails=3 fail_timeout=3s;
    server backend2.example.com:1234 max_fails=3 fail_timeout=3s;    
}
  • 동작에 문제가 없는 업스트림 서버만 사용하려면 헬스 체크 변수를 추가해야 함
  • 사용자 요청에 대한 업스트림 서버의 응답을 모니터링해 서버의 상태를 확인함
매개변수 설명
max_fails
최대 허용 실패 횟수 (이 횟수를 초과하면 서버를 일시적으로 제외)
fail_timeout
서버가 비활성화되는 시간 (이 시간이 지나면 다시 요청을 보냄)

 

5. 스티키 쿠키(엔진엑스 플러스)

6. 스티키 런(엔진엑스 플러스)

7. 스티키 라우팅(엔진엑스 플러스)

8 커넥션 드레이닝(엔진엑스 플러스)

10. 능동적인 헬스 체크(엔진엑스 플러스)

11. 슬로 스타트(엔진엑스 플러스)