haproxy

haproxy

줄곧 nginx를 사용해오다가 간과한점이 하나있었다.
nginx의 health check는 유료버전인 nginx plus에서만 가능하다는것.
물론 대중적으로 nginx를 많이쓰긴하지만, 필자에게 있어 health check 기능은 너무도 중요한 요소중 하나다.
그리하여 열심히 찾아보다가 .. haproxy라는 녀석을 만나게되었다.
haproxy를 처음 사용해봄으로서 간단하게 진행한 테스트를 글로 남기려한다.

setup haproxy

필자는 host os는 centos를 docker container에서 사용할 guest os는 주로 debian os를 사용한다.
설치는 haproxy 1.8 version과 debian jessie os 기준으로 설명한다.

1
2
3
4
5
6
7
8
9
$ echo deb http://httpredir.debian.org/debian jessie-backports main | \
    tee /etc/apt/sources.list.d/backports.list
$ curl https://haproxy.debian.net/bernat.debian.org.gpg | \
    apt-key add - 
$ echo deb http://haproxy.debian.net jessie-backports-1.8 main | \
    tee /etc/apt/sources.list.d/haproxy.list
$ apt-get update
$ apt-get install -y haproxy=1.8.\* -t jessie-backports
$ service haproxy start

필자가 만든 docker image를 사용하려면 다음과 같이 사용할수있다.
https://hub.docker.com/r/setyourmindpark/debian-haproxy/

1
2
3
4
5
6
$ docker pull setyourmindpark/debian-haproxy:1.8
$ docker run -d --name haproxy \
    -v /your/path:/etc/haproxy \
    -p default_port:80 \
    -p ssl-port:443 \
    setyourmindpark/debian-haproxy:1.8

config haproxy

이제 설치된 haproxy 설정을 시작한다.

1. url endpoint에 따른 redirect

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
$ vi /etc/haproxy.cfg
defaults
 mode http
 option httplog
 option dontlognull
 option redispatch
 option forwardfor
 option http-server-close
 retries 3
 maxconn 20480
 timeout connect 5s
 timeout server 50s
 timeout client 50s
 timeout http-keep-alive 3000
frontend http_in
 bind *:80
 reqadd X-Forwarded-Proto:\ http
 acl naver path_end -i /naver 
 redirect location http://www.naver.com if naver
 acl daum path_end -i /daum
 redirect location http://www.daum.net if daum
 acl google path_end -i /google
 redirect location http://www.google.com if google
$ service haproxy restart

2. load balancing

nginx 포스트 nginx load balancing 와 같이 haproxy에서도 load balancing을 진행한다. 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$ vi /etc/haproxy.cfg
defaults
 mode http
 option httplog
 option dontlognull
 option redispatch
 option forwardfor
 option http-server-close
 retries 3
 maxconn 20480
 timeout connect 5s
 timeout server 50s
 timeout client 50s
 timeout http-keep-alive 3000
frontend http_in
 bind *:80
 reqadd X-Forwarded-Proto:\ http
 default_backend server
backend server
 mode http
 balance roundrobin
 default-server inter 3s rise 3 fall 5
 # default-server       = health check 조건
 # inter                = interval 주기 ( 3초 ) 
 # rise                 = 요청횟수 ( 3번 )
 # fail                 = 실패횟수
 # = 3초 주기로 3번요청 성공시 healthy, 5번 실패시 dead로 판단 
 server s1 server1_ip:server1_port cookie check
 server s2 server2_ip:server2_port cookie check
 $ service haproxy restart

=> 3초 주기로 3번요청 성공시 정상작동간주, 트래픽을 연결한다.

log 확인

1
$ haproxy -d -f /etc/haproxy/

견해

필자가 health check를 중요하게 생각하는 이유는 무중단 서비스 배포시 client는 connection에 대한 영속성을 지녀야한다는 점이다.
client request에 대한 error가 아닌 실시간으로 반영될수있는 아주 중요한 요소중 하나이기 때문이다.
고객사의 서비스 개발시 항상 redeploy 에 관한 사항이 중요한 이슈중 하나였다.
‘언제 몇시에 서버 재기동합니다.’ 라는 말과함께 작업시 redeploy 하는 개발자 입장에서도 엄청난 부담이 될수밖에없다고 생각한다.
다음 포스트에서는 필자가 여러방면으로 테스트한 무중단 배포에 관한 글을 적어보려한다.