Docker + Nginx 로드밸런싱 구성과 SPOF 검증

목차

1.왜 로드벨런싱이 필요 했는가?

2.로드벨런싱 테스트

3.마치며

 

1.왜 로드벨런싱이 필요 했는가?

기존의 프로젝트 배포 환경은 단일 인스턴스였습니다. 비용 문제로 서버를 무한정 늘릴 수 없는 상황에서, 제한된 자원으로 최대한 안정적으로 운영할 수 있는 구조를 고민하면서 진행을 했습니다. 하지만 서버가 죽는 상황 자체를 막을 수는 없었습니다. 그래서 서버가 죽더라도 데이터가 유실되지 않도록 Outbox 패턴과 Kafka 오프셋 커밋 설정 등 여러 장치를 미리 심어두었지만  마음 한편에 걸리는 게 있었습니다.

 

"장치를 아무리 잘 만들어도, 서버 자체가 죽으면 요청을 받을 곳이 없다."

 

기존의 배포에서는 Nginx를 리버스 프록시와 HTTPS 인증 용도로만 사용하고 있었습니다. 그런데 Nginx의 로드밸런서를 활용 해서 새로운 서버를 추가하지 않고도 기존 구성을 확장하는 방향으로 접근할 수 있겠다는 생각이 들었습니다.

 

단일 인스턴스 구조는 SPOF(Single Point of Failure), 즉 단일 장애점을 가집니다. 서버 재배포, 메모리 초과, 예상치 못한 프로세스 종료 중 어느 하나만 발생해도 사용자는 서비스를 이용할 수 없게 됩니다. 그래서 다음 두 가지를 목표로 구성을 시작했습니다.

• 트래픽을 여러 서버에 분산해 특정 서버에 부하가 몰리지 않도록 한다
• 서버 하나가 죽어도 서비스가 중단되지 않는 구조를 만든다

이번 글에서는 Docker + Nginx를 활용해 로컬 환경에서 로드밸런싱을 구성하고, 실제로 SPOF 상황을 재현해 검증한 과정을 정리합니다.

2.로드벨런싱 테스트

로드벨런싱을 사용하기 위해서 기존의 단일 인스턴스에서 아래와 같이 변경을 했습니다. 우선은 배포를 하기 전에 로컬에서 아래와 같은 구조로 진행을 해보겠습니다.

로컬에서의 환경은 다음과 같습니다.

• OS: Windows 11
• Docker Desktop
• Nginx 1.29.8
• 요청 도구: PowerShell curl

이번 테스트에서 확인하고자 한 것은 두 가지입니다.

• Nginx가 요청을 backend-1, backend-2에 실제로 분산하는가
• backend-1을 강제 종료했을 때 서비스가 중단 없이 유지되는가

Nginx 설정

upstream backend-cluster {
    server schedule-backend-1:8082;
    server schedule-backend-2:8082;
}

location /api/ {
    proxy_pass http://backend-cluster/api/;
}

 

Docker Compose 변경사항

nginx:
  image: nginx:latest
  ports:
    - "80:80"
  volumes:
    - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
  depends_on:
    - backend-1
    - backend-2

 

로드밸런싱 동작 확인

 

curl로 10회 요청을 보냈을 때 backend-1, backend-2 에 각각 5개씩 요청이 간 것을 확인을 할 수 있습니다. 

 

위의 사진을 보면 backend-1과 backend-2에 5개씩 요청이 들어간 부분을 볼 수가 있습니다. 

 

SPOF 테스트

 

다음으로는 서비스 서버2개중 한개를 정지시킨뒤에 한쪽으로 요청을 받는지를 확인을 해보겠습니다. 

위의 사진처럼 backend-1을 강제로 종료한 뒤 동일하게 요청을 보냈습니다.

backend-1이 종료된 상황에서도 StatusCode 200 응답이 정상적으로 반환됐습니다. backend-2가 요청을 이어받아 서비스 중단 없이 처리한 것을 확인했습니다.

3.마치며

이번 테스트를 통해 두 가지를 확인했습니다.

• Nginx upstream 설정만으로 별도의 서버 추가 없이 로드밸런싱 구성이 가능하다
• backend-1이 종료된 상황에서도 backend-2가 요청을 이어받아 서비스 중단이 발생하지 않았다

기존에 Outbox 패턴, Kafka 오프셋 커밋 설정 등으로 데이터 유실을 막는 장치는 이미 마련되어 있었습니다. 여기에 로드밸런싱 구성을 추가함으로써 데이터 유실 방지와 서비스 가용성 확보 두 가지를 함께 갖춘 구조가 됐습니다.

 

다만 이번 테스트는 로컬 환경에서 진행한 것으로, 실제 배포 환경에서는 결과가 달라질 수 있습니다. 다음 편에서는 기존 Lightsail이 아닌 EC2 환경에 새롭게 배포해 동일한 구성을 적용하고, JMeter를 활용해 100VU 부하 상황에서도 트래픽이 정상적으로 분산되는지 검증해보겠습니다.