Tagged: Load Balancer

Azure Load Balancer

Azure 를 하면서 여러가지 차이점을 느끼지만, 그 중 Azure Load Balancer 만큼 차이를 보여주는 것도 없어보인다. AWS 에서는 Network Load Balancer 에 대응되지만 기능이 몇가지 더 있음으로 해서 아키텍쳐에도 차이를 보인다.

SNAT

Azure LoadBalancer 는 SNAT 기능을 지원한다. Source NAT 라고 하는 것으로 내부 사설IP 를 외부 공인IP 로 변경해 주는 기능이다. 이 기능은 내부 사설망에서 외부 공인 인터넷망으로 통신을 가능하게 해주는 중요한 기능이다.

VM 기반 리소스를 생성할때에 보안상 대부분 사설 서브넷(Private Subnet) 에 위치시킨다. 그리고 서비스를 위해서 VM 앞단에 Load Balancer 를 위치킨다. 문제는 VM 자체적으로 인터넷 통신을 하려고할 때다. 공인IP 가 있다고 하더라도 사설 서브넷에 위치된 VM 은 라우팅으로 인해서 외부로 나갈 수 없어 인터넷 통신을 할 수 없다. AWS 의 경우 이 문제를 해결 하기 위해서 NAT Gateway 서비스를 이용해야 한다.

Azure 에서는 Load Balancer 를 이용하면 이러한 문제를 해결 할 수 있다. 물론 Azure 에서도 NAT Gateway 서비스가 존재하지만 Azure 아케텍쳐상 베스트 프렉티스(Best Practice) 가 아닌 것으로 보인다.

Azure VM 기준 아케텍쳐인데(Azure 공인문서), Frontend 와 Backend 에 위치한 VM들은 모두 사설 서브넷이며 인터넷 통신을 위해서 Load Balancer 를 이용하고 있다. NAT Gateway 를 이용하면 더 좋아 보이는데, 베스트 프렉티스로 되어 있지 않은 모양이다.

Load Balancer 생성

Azure 에 Load Balancer 는 L4 Layer 다. AWS 에 Network Load Balancer 에 대응되지만 SNAT 기능을 제공함으로써 인터넷 통신을 가능하게 해준다.

Load Balancer 생성화면에서 많은 절차가 필요하다는 것을 알수 있는데, Outbound rules 이 SNAT 기능을 사용하는 것이다. 물론 이 기능을 사용하기 위해서는 Inbound rules 설정에서 SNAT 기능을 사용하겠다고 활성화를 해줘야만 한다.

Port allocation

SNAT 설정할때에 문제가 되는 항목이 바로 Port allocation 이다. SNAT 자체가 VM 에서 출발하는 IP 를 변환해주는 것인데, 어쨋거나 Load Balancer 가 대신 공인 인터넷으로 접속을 하게 해주는 것임으로 결국에는 Load Balancer 가 출발지로 되고 결국에는 Client Port 가 있어야 한다.

문제는 VM 에서 인터넷 접속을 이것저것 하게 되면 단 하나의 Client Port 가지고는 되지 않는다. 브라우져를 통해 웹사이트 접속을 하더라도 동시에 몇십게의 Client Port 가 생성된다. 따라서 Load Balancer 입장에서는 뒷단에 있는 VM 들에게 무제한 접속을 허용, 다시 말해서 Client Port 를 할당해 줄수가 없게 된다.

이를 위해서 Azure 는 Port allocation 설정을 하도록 하고 있다. Load Balancer 의 Frontend IP 당 뒷단 VM 수를 조합해 VM 하나에 할당가능한 Port 의 개수를 정하도록 해 놨다.

Port allocation 의 방식을 Manually 로 하지 않고, Azure 에 위임할 경우에 Scale out 시에 뒷단 VM 의 연결이 안될 수도 있다. 위와같이 수동으로 하고 뒷단 인스턴스 개수를 지정해주는 것을 권장하고 있다.

이 설정을 하게되면 SNAT 설정이 완료된다. 이제 VM 에서 인터넷이 되는지 확인해보면 된다.

DNAT

Azure Load Balancer 는 DNAT 기능을 제공한다. 이 기능일 이용하면 Load Balancer 뒷단 VM 에 접속을 할 수 있다. 하지만 이 기능은 잘 사용하지 않는 것으로 보인다. 베스트 프렉티스 아키텍쳐에서는 Bastion 서버를 구성해서 사용하는 것으로 보이는데, 어쨌든 DNAT 기능을 제공한다.

SNAT 기능은 Outbound rule 이라고 한다면 DNAT 는 Inbound NAT rule 이라고 한다.

테스트를 위해서 SSH(22 port) 를 활성해서 뒷단 VM 에 접속하도록 했다. 이렇게 되면 Load Balancer 의 공인IP 를 기반으로 VM 에 22 포트로 접속이 가능해 진다. Frontend Port 의 경우에는 잘 알려진 포트가 아닌 다른 포트를 이용하는 것이 좋다.

결론

Azure Load Balancer 는 L4 Layer 장비다. AWS 와 달리 SNAT, DNAT 기능을 모두 지원함으로써 뒷단 VM 에 특정한 기능을 제공한다.

Azure 기술 문서에는 사설 서브넷에 위치한 VM 의 인터넷 연결을 위해서 Load Balancer 를 이용하고 있다. VM 접속을 위해서는 Bastion 서비스를 이용하도록 구성하고 있어서 Inbound NAT Rule 은 임시적으로 긴급한 상황이 아니라면 크게 사용할 일은 없어보인다.

Apache Proxy Load Balancer 구성

Apache 웹 서버는 세계적으로 많이 사용되는 웹 서버이다. 많은 기능을 내장하고 있는데, 그 중에서 Proxy Load Balancer 구성에 대해서 설치부터 설정까지 기술 한다.

기술 환경은 다음과 같다.

  • 배포판: Ubuntu14.04 64bit
  • Apache: 2.4.25
  • 컴파일 설치.

운영환경도 아주 중요하다. 이 문서에서 기술한 운영 환경은 AWS 환경이며 External ELB 바로 뒤에 Apache 웹 서버가 있다. 이 Apache 웹 서버는 뒤에 WAS 서버가 존재하는 환경이다.

Apache Proxy Load Balancer 운영 환경

의존성 패키지 설치

컴파일 설치를 하기전에 의존성 패키지를 다음과 같이 설치해 줍니다.

 

설치

설치는 소스를 받아 직접 컴파일을 했다. 소스는 현재 최신버전인 2.4.25 버전으로 다운받아 압축 해제한다.

Apache 웹 서버의 확장 모듈을 설치하거나 별도의 유틸리티를 사용하기 위해서 apr, apr-utils 도 함께 설치해주어야 한다. 이 기능을 사용하기 위해서는 컴파일 시에 ‘–with-included-apr’ 옵션을 주어야 한다.

이제 다음과 같이 Configure 해줍니다.

아무런 오류 없이 끝나면 다음과 같이 컴파일, 설치 해줍니다.

설치 디렉토리로 이동해서 다음과 같이 심볼릭 링크를 생성해 줍니다.

 

httpd.conf 설정

Apache 웹 서버의 주요 설정은 httpd.conf 파일에서 이루어 집니다. 웹 서버이름, 실행할 데몬 소유자, 로깅, 사용할 모듈, 사용할 기능파일등에 대해서 설정할 수 있습니다.

사용할 모듈 설정

컴파일 설치를 했어도 사용할 모듈들을 최소화할 수 있습니다. 다음과 같이 해줍니다.

어떤 기능을 사용할 것인지에 따라서 위 설정은 달라지지만, 적어도 Proxy Load Balancer 를 운영하기 위해 필요한 것과 불필요한 것만 위에서 기술 했다.

현재 활성화된 모듈이 무엇인지는 다음의 명령어로 확인 가능하다.

 

데몬 사용자/그룹 지정

Apache 웹 서버는 실행 프로세스와 HTTP 를 처리하는 데몬의 사용자/그룹를 다르게 지정할 수 있다. mod_unixd 에서 제공하는 것으로 다음과 같이 지정할 수 있다.

RemoteIp 사용 설정

Apache 웹 서버 앞에 AWS ELB 가 있다. AWS 의 ELB 는 Client IP 를 ‘X-Forwarded-IP’ 헤더에 담아 뒤로 넘겨준다. 하지만 Apache 웹 서버는 이것이 Client IP 인지를 인식하지 못하는데, ‘X-Forwarded-IP’ 헤더 필드 값이 실제 IP 로 사용하도록 지정할 수 있는데 mod_remoteip 가 이를 담당 한다. 다음과 같이 설정해 준다.

이렇게 설정을 해주면 이제부터 Apache 내부에서 사용하던 Client IP 관련 환경변수들이 ‘X-Forwarded-For’ 값으로 대체(override)된다. 바꿔말해서 Client IP 관련 환경 변수들을 하나하나 찾아서 ‘X-Forwarded-For’ 값으로 대체하지 않아도 된다.

log 설정

mod_remoteip 를 사용할 경우에 Apache 웹 서버의 로그에 Client IP 가 기록되도록 다음과 같이 추가해 준다.

기준의 combined 로그 포맷을 이용해 ‘%h’ -> ‘%a’, ‘%b’->’%O’ 로 교체해주고 ‘proxy_combined’ 이름의 로그 포맷을 정의했다.

추가 설정

Apache 웹 서버는 기능별로 설정들을 따로 모아서 conf/extra 디렉토리에 모아 뒀다. 필요한 기능과 설정을 하고 싶다면 이 파일들을 수정하고 httpd.conf 파일에서 Include 명령어로 포함시켜주면 동작한다.

주요하게 포함되어지는 파일들은 다음과 같다.

 

httpd-mpm.conf

Apache 웹 서버의 프로세스 모델을 설정하는 파일이다. Apache 2.4 에서는 주요하게 세가지를 제공 한다.

  • event (2.4 기본)
  • profork
  • worker

event 프로세스 모델은 ‘mpm_event_module’ 을 이용해서 설정 가능하며 httpd-mpm.conf 파일 중간쯤에 있다.

모델별로 동작 방법은 다르지만 설정하는 내용은 비슷하다. 대부분이 초기 프로세스 개수, 최소, 최대 쓰레드(Thread) 개수, 한 쓰레드당 최대 worker 등을 지정하는 식이다.

이 값은 얼마만큼 Apache 웹 서버가 일하는지에 따라서 달리 설정되어 진다. 이 값은 서비스 오픈전 부하 테스트를 거쳐서 확정된다.

httpd-default.conf

이 설정은 매우 중요하다. 특히나 AWS ELB 뒤에 Apache 웹 서버를 운영중이라면 아주 중요하다.

여기에서 reqtimeout_module 부분을 수정하지 않으면 아마도 로그에  ‘ELB-HealthChecker/1.0’ 요청에 대해서 408 을 리턴하는 것을 볼 수 있다.

이는 httpd-default.conf 파일에서 다음을 수정해줘야 한다.

이렇게 해야 하는 이유는 AWS ELB 의 Health Checker 가 Apache 웹 서버의 Alive 를 알아내기 위해서 패킷을 보내는데, AWS ELB 의 기본 Idle 값(60)보다 크게 잡아야 하기 때문이다.

위와같이 설정하면 408 오류는 보이지 않게 된다.

httpd-vhosts.conf 

Proxy Load Balancer 설정

Proxy Load Balancer 설정을 위해서는 Proxy 설정을 먼저 알아야 한다. Apache 웹 서버의 Proxy 설정은 다음과 같다.

Proxy 는 ReverseProxy 로 동작하게 하면서 Load Balancer 를 지정하고 있다. URL 이 /adm 으로 들어올 경우에 위 설정을 따르게 되고 Load Balancer 로 연결이 된다.

Load Balancer 설정에서는 Balancer 를 위한 서버의 Member 를 등록한다. route 는 Sticky Session 부분과 관련이 있으며 Tomcat의 jvmRoute 파라메터에서 사용되어지기도 해서 WAS 서버 설정과 관련이 있다.

그러나 WAS 서버에서 Session Cluster 설정을 했다면 route 는 그냥 WAS 서버의 호출 주소를 적어줘도 된다.

CustomLog 설정

CustomLog 설정에서 rotatelogs 시에 파일명을 날짜별로 되도록 다음과 같이 수정한다.

 

지금까지 Apache 2.4 에서 기초적인 Reverse Proxy 설정을 기술했다. 기본적인 설정일뿐이며 이를 기반으로 다양한 기능들을 추가하면 된다. 추가적인 기능으로는 CustomLog 에서 파일형태(그림파일), URI 별로 쪼개서 로깅하기 혹은 IP 를 기반으로 차단하기, 이미지 파일 캐싱하기 등등이 있다.