서버 부하 분산과 로드 밸런싱 전략

서버 부하 분산과 로드 밸런싱 전략

1. 문제 상황: 서버 부하 증가로 인한 성능 저하

서비스 사용자가 증가하면서 웹 서버에 과부하가 발생하는 문제가 발생했다.

• 트래픽이 급증할 때 응답 속도가 느려짐
• 특정 시간대에 요청이 몰려 서버가 다운됨
• 단일 서버에서 모든 요청을 처리하느라 리소스 사용률이 100%에 도달
• 서버 장애 발생 시 전체 서비스가 중단됨

이러한 문제를 해결하기 위해 로드 밸런서를 도입하여 트래픽을 여러 서버로 분산할 필요가 있다.

2. 해결 과정: 로드 밸런싱 개념과 구현 방법

2.1 로드 밸런싱이란?

로드 밸런싱(Load Balancing)은 여러 서버에 요청을 분산하여 성능을 최적화하고, 서버 장애 발생 시에도 서비스가 지속적으로 운영될 수 있도록 하는 기술이다.

2.2 로드 밸런싱 방식

로드 밸런서는 다양한 방식으로 요청을 분산할 수 있다.

방식	설명
라운드 로빈(Round Robin)	각 요청을 순차적으로 서버에 분배
가중치 기반(Wighted Round Robin)	서버 성능에 따라 가중치를 부여하여 요청을 분배
최소 연결(Least Connections)	가장 적은 연결을 가진 서버로 요청을 분배
IP 해시(IP Hashing)	클라이언트 IP를 기반으로 특정 서버에 요청을 할당

3. Nginx를 활용한 로드 밸런싱 구현

가장 널리 사용되는 로드 밸런서 중 하나인 Nginx를 활용하여 트래픽을 분산할 수 있다.

3.1 Nginx 설치

sudo apt update
sudo apt install nginx -y

3.2 Nginx 로드 밸런싱 설정

다음과 같이 /etc/nginx/nginx.conf 파일을 수정하여 로드 밸런서를 설정할 수 있다.

http {
    upstream backend_servers {
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend_servers;
        }
    }
}

Nginx를 재시작하여 설정을 반영한다.

sudo systemctl restart nginx

3.3 가중치 기반 로드 밸런싱 적용

서버 성능에 따라 트래픽을 비율적으로 분산할 수 있다.

upstream backend_servers {
    server backend1.example.com weight=3;
    server backend2.example.com weight=1;
}

이렇게 설정하면 backend1 서버로 75%의 요청이 전달되고, backend2 서버로 25%의 요청이 전달된다.

4. 클라우드 로드 밸런서 활용

클라우드 환경에서는 AWS, GCP, Azure 등의 로드 밸런서를 활용할 수 있다.

4.1 AWS Elastic Load Balancer(ELB)

• ALB(Application Load Balancer): HTTP/HTTPS 트래픽을 분산
• NLB(Network Load Balancer): TCP/UDP 트래픽을 분산
• CLB(Classic Load Balancer): 레거시 시스템을 위한 로드 밸런서

AWS 콘솔에서 ELB를 생성하고, 대상 그룹(Target Group)을 설정한 후 EC2 인스턴스를 추가하면 자동으로 로드 밸런싱이 적용된다.

4.2 GCP Load Balancer

GCP에서는 다음과 같은 로드 밸런서를 제공한다.

• HTTP(S) Load Balancer
• TCP/UDP Load Balancer
• Internal Load Balancer

GCP 콘솔에서 네트워크 서비스 > 부하 분산을 선택하여 로드 밸런서를 설정할 수 있다.

5. 세션 유지(Session Persistence) 설정

일부 애플리케이션에서는 사용자의 요청이 항상 동일한 서버로 가야 하는 경우가 있다.

5.1 IP 해시 방식 적용

IP 해시 방식을 사용하면 동일한 IP에서 오는 요청을 동일한 서버로 보낼 수 있다.

upstream backend_servers {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

5.2 쿠키 기반 세션 유지

세션 쿠키를 설정하여 동일한 사용자의 요청이 같은 서버로 전달되도록 할 수도 있다.

proxy_pass http://backend_servers;
proxy_cookie_path / "/; HttpOnly; Secure";

6. 장애 감지 및 자동 복구

6.1 헬스 체크(Health Check) 설정

로드 밸런서는 헬스 체크를 수행하여 정상적인 서버로만 트래픽을 전달해야 한다.

upstream backend_servers {
    server backend1.example.com max_fails=3 fail_timeout=30s;
    server backend2.example.com max_fails=3 fail_timeout=30s;
}

이 설정을 적용하면, 특정 서버가 3번 연속 응답하지 않을 경우 해당 서버를 자동으로 제외한다.

6.2 자동 복구(Auto Scaling)

클라우드 환경에서는 자동 스케일링(Auto Scaling)을 통해 부하가 증가하면 서버를 추가하고, 부하가 줄어들면 서버를 줄일 수 있다.

• AWS Auto Scaling
• GCP Instance Groups
• Azure Scale Sets

7. 최종 정리

로드 밸런싱을 통해 트래픽을 효율적으로 분산하고, 서버 장애 시에도 안정적인 서비스를 유지할 수 있다.

핵심 요약:

• 로드 밸런싱을 통해 트래픽을 여러 서버로 분산
• Nginx를 활용한 기본 로드 밸런싱 구현
• 클라우드 로드 밸런서(AWS ELB, GCP Load Balancer) 활용
• IP 해시 또는 쿠키 기반 세션 유지
• 헬스 체크를 통한 장애 감지 및 Auto Scaling을 활용한 자동 복구

이러한 전략을 적용하면 트래픽 증가에도 안정적인 서비스를 제공할 수 있다.