Tagged: Reverse Proxy

Nginx 이용한 로드 밸런싱(Load Balancing) 구현하기

Nginx 는 전세계적으로 인기있는 웹 서버 입니다. 기존 웹 서버들과 달리 고속이며 대량의 접속을 적은 자원으로 처리해줍니다. 또, Nginx 는 Reverse Proxy 기능도 아주 훌륭하게 수행하며 이에 더해서 로드밸런싱 기능도 제공하는듯 다양한 기능을 다른 웹서버들보다 훌륭하게 수행합니다.

아키텍쳐(Architecture)

먼저 다음과 같은 아키텍쳐를 생각해 봅시다.

Nginx 로드 밸런싱 아키텍쳐

AWS 에 흔히 볼수 있는 기본적인 아키텍쳐입니다. 외부 접속은 External ELB가 담당하고 이것을 뒤에 Nginx 서버가 ELB의 접속을 받아서 Nginx 뒤에 있는 Jboss EAP 서버에 분배 접속을 하도록 하는 것입니다.

Nginx 로드 밸런싱(Load Balancing)

Nginx 는 자체적으로 로드 밸런싱 기능을 제공합니다. 이는 Nginx 의 Upstream 모듈을 통해서 제공 합니다. 기본적인 설정 방법은 다음과 같습니다.

ELB 에서 Nginx 로 80 포트(port)로 접속을하면 proxy_pass 에 정의된 upstream 인 myapp1 으로 연결을 시켜주며 myapp1 upstream 에 정의된 서버 3대 중에 하나에 연결을 시켜줍니다.

upstream 에서 다양한 옵션을 제공 합니다. 대표적인 것이 Nginx 뒤에 서버의 연결 상태를 어떻게 체크할 것인가 하는 것입니다. 예를들면,

srv1.example.com 서버는 30초 동안 최대 3번 접속이 실패하면 30초 동안 접속이 불가한 것으로 판단 합니다. 30초가 지나면 또 최대 3번의 접속 실패가 발생하고 나서야 30초동안 접속을 하지 않습니다.

지속적인 서비스를 제공해야하는 상황에서 접속이 잘되는지 안되는지 실제로 접속을 해봐야만 한다면 고객들에게 불편을 제공할 것입니다.

AWS ELB 방식

AWS ELB 방식은 위 Nginx 의 max_fails 방법과는 다릅니다. ELB 는 뒤에 연결되는 인스턴스(Instance)가 살았는지 죽었는지를 판단하는 Health Check 기능을 제공합니다. 이것은 5초에 한번 Health Check 를 하고 10번이상 성공했다면 인스턴스가 살았다라고 판단해(InService 상태) 연결을 활성화 해줍니다. 만일 5초에 한번 Health Check 를 하는데 2번 실패를 했다면 인스턴스가 죽었다고 판단해(OutOfService 상태) 더 이상 연결을 시도하지 않습니다.

즉, 일정한 기준을 만족해야만 연결을 활성화 해준다는 겁니다. Nginx 에서도 이렇게 동작하면 얼마나 좋을까?

nginx_http_upstream_check_module

nginx_http_upstream_check_module 모듈은 Nginx.org 에서 배포하지 않고 개인 개발자가 개발한 Third Party 모듈 입니다. 이 모듈은 앞에서 언급했던 ELB 의 Health Check 기능을 제공해 줍니다. 특정한 기준을 통과하면 연결을 활성화 시켜주는 것입니다.

이를 활용하기 위해서는 Nginx 설치시에 같이 컴파일 설치를 해줘야 합니다.

Nginx 설치

이번 Nginx 설치는 Upstream Health Check Module 를 함께 설치하는 과정을 포함 합니다.

설치 환경은 다음과 같습니다.

  • Ubuntu 14.04 64bit
  • 컴파일을 위해서 설치한 패키지들: build-essential, automake, unzip, patch, libpcre++-dev, zlib1g-dev, geoip-bin, libgeoip-dev

Nginx 다운로드를 해줍니다.

nginx_http_upstream_check_module 는 git를 이용해서 다운(?) 받습니다.

이제 Nginx 에 nginx_http_upstream_check_module 다음과 패치를 해줍니다.

그리고 다음과 같이 서버 Signiture 를 바꿔 줍니다.

이렇게하면 서버가 PowerServer/1.0 이라고 나와서 Nginx 를 쓴다는것을 숨길 수가 있습니다.

마지막으로 openssl 최신 소스를 다운받아 nginx 디렉토리에 놓습니다.

 

Nginx 설정하기

설치가 끝났다면 이제 설정을 해야 합니다. 설정에 앞서서 현재 Nginx 의 아키텍쳐를 상기시켜봅시다.

  • Nginx 앞에는 AWS ELB 에 있다. AWS ELB 는 실제 접속자인 Client IP 를 ‘X-Forewarded-For’ 헤더값에 저장해 넘겨준다.
  • Nginx 뒤에는 두대의 WAS 서버가 존재한다.
  • Nginx 는 뒤에 두대의 WAS 에 대해서 Health Check 하고 특정값 기준으로 Alive/Down 을 결정하도록 한다.

위 내용을 설정에 반영하면 다음과 같습니다.

먼저 7번째 줄에 Nginx 에서 실제 IP를 ‘X-Forewarded-For’ 헤더 값이라고 알려 주도록 설정한 것입니다. 8번째 줄은 AWS ELB 의 주소 범위를 말합니다. Nginx 는 AWS ELB 로부터 접속을 받기 때문에 그것을 지정해줄 필요가 있는데 그것이 바로 8줄 설정입니다. 12줄 ~ 14줄은 뒤에 WAS 서버에 넘겨줄 헤더값을 지정해주고 있습니다. WAS 서버도 실제 Client IP가 필요하기 때문에 이것을 ‘X-Forewarded-For’ 에 지정해 줍니다. 그외에 ‘X-Forewarded-Server’, ‘X-Forewarded-Host’ 도 지정해 줍니다.

18번째 줄부터는 이제 upstream 설정하는 부분인데, 24줄이 Health Checker 를 해주는 부분으로 nginx_http_upstream_check_module 기능 입니다. 3초에 한번 체크를 하는데 그 방법은 TCP를 이용하고 5번 연속으로 실패할 경우에 뒤에 서버는 다운된것으로 하고 2번 연속 성공하면 뒤에 서버가 살아있는것으로 해서 연결을 시켜줍니다. 마치 AWS ELB 처럼 동작하는 것입니다.

/status URL 을 호출하면 다음과 같이 나옵니다.

Nginx Upstream Health Status
Rise Counts, Fall counts 는 3초마다 체크해서 그 수를 센 것입니다. 현재 뒤에 WAS 서버들이 하나는 살아 있고, 하나는 죽은것으로 되어 있고 Down 된 서버는 빨강색으로 표시됩니다.

체크하난 프로토콜을 변경할 수 있는데, http 를 이용할 경우에 보내는 url 과 기대되는 리턴되는 http 의 상태값(status)를 지정해주면 됩니다.

Proxy 서버 개념

Forward Proxy

forward proxy
Forward proxy

포워드 프락시(Forward Proxy)는 클라이언트가 타켓서버(목표서버)의 주소를 받아서 타켓서버로 연결을 시켜준다. 클라이언트는 타켓서버의 주소를 요청하면 프락시 서버는 뒷단에 타켓서버의 주소를 가진 서버에 연결을 포워딩 한다. 프락시 서버는 타켓서버의 주소를 가지고 있지 않다.

Reverse Proxy

Reverse Proxy
Reverse Proxy

리버스 프락시(Reverse Proxy)는 타켓서버의 주소가 아닌 프락시 서버가 타켓서버의 주소를 가지고 있고 프락시 서버가 이를 받아서 뒷단에 실제 타켓 서버로 연결을 시켜준다. 그러니까 타켓서버의 주소를 프락시서버가 가지고 있어야 하며 클라이언트는 타켓서버의 주소로 요청을 하면 프락시 서버가 응답을 하게 된다.