맞으면서 배우는 HAProxy

Image: HAProxy Logo from Wikimedia Commons, CC BY-SA 4.0

인프라 팀의 가장 큰 목표는 서비스의 장애를 최소화하는 것입니다. 이 과정에서 물론 기술을 고도화하는 것도 중요하지만, 당장 놓인 환경에서 급한 문제를 해결해야 할 때도 있습니다. 이를 위해 제가 처음으로 비중 있게 참여하게 된 업무가 HAProxy 도입이었습니다.

HAProxy를 사용했던 경험은 없었고 이제 막 회사에 적응 중이었기 때문에, 많은 문제가 있었습니다. 그 과정을 돌아보고 정리해 보려고 합니다.

왜 HAProxy를 사용했나요?

현재 회사에서는 Docker Compose를 통해 서비스를 배포하고 있습니다.
아주 간단하게 나타내면 앞에 NGINX가 있고, 여러 개의 컨테이너로 부하를 분산하는 형태입니다.

하지만 큰 문제가 하나 있었는데, NGINX는 최초 시작 또는 재시작 때만 도메인의 IP를 갱신하기 때문에 컨테이너를 재시작해도 IP 동기화가 이루어지지 않고, 따라서 배포 때마다 순단이 발생하고 있었습니다.

이를 해결하기 위해 중간에 HAProxy를 두어 동적으로 컨테이너의 IP를 갱신하는 방법을 생각하게 되었습니다.
(추가로 조사했을 때 현재 구조에서 해결할 수도 있었을 것 같은데, 공식적인 방법은 아니었습니다.)

도입하며 겪은 문제들

HAProxy를 중간에 놓는 것 자체는 큰 문제가 없었습니다.
NGINX에서 요청을 받아 웹 컨테이너로 전달하도록 설정 파일을 작성하고, 그 파일만 덮어씌워 Docker 이미지를 빌드하면 되기 때문입니다. 실제로 설정 파일을 제외하면 수정할 부분이 많지 않았습니다.

하지만 설정 과정에서 신경 쓸 부분이 많았습니다. 주로 설정했던 부분은 다음과 같습니다.

1. Resolvers
   Docker Compose 환경에서 DNS 매핑을 위해 다음과 같은 설정을 추가했습니다.
   이렇게 하면 /etc/resolv.conf 파일에 정의된 네임서버를 가져옵니다.

   # ...
   
   resolvers custom-dns
       parse-resolv-conf
   
   # ...

2. Timeout
   다른 구성 요소들을 참고해서 알맞은 값을 설정해야 합니다.
   HAProxy에서만 설정이 다를 경우 예기치 않은 장애가 발생할 수 있기 때문입니다.

3. 로드 밸런싱 방법
   부하 분산을 위한 알고리즘을 정할 수 있습니다.
   저희는 특별한 알고리즘이 필요하지 않았기 때문에 roundrobin을 사용했습니다.

4. 서버 상태 확인
   HAProxy를 도입한 이유입니다. 컨테이너 상태를 확인 가능한 URL을 설정하고, 주기와 재연결 ◦ 연결 해제 조건도 정할 수 있습니다.

   하지만 한 가지 더 고려해야 할 부분이 있었는데, 환경별로 연결해야 하는 컨테이너 수가 달라 이에 대한 대응이 필요했습니다. 이를 위해 server-template을 사용했는데, 해당 옵션을 사용하면 특정 어구로 시작하는 서버들을 모두 감지해 연결하고, 설정한 수보다 컨테이너 수가 적어도 연결에 문제가 생기지 않습니다.

그 외

• HAProxy에는 상태 확인을 위한 간단한 대시보드가 있고, 메트릭 수집과 모니터링 관련 기능도 지원합니다.
  Datadog이나 Grafana 등과 연동도 가능합니다. 다만 이것이 HAProxy를 도입한 이유는 아니었기 때문에, 최소한의 기능만 설정했습니다.
• 설정 파일을 마운트 하는 방식이라면, Graceful reload 기능을 사용할 수 있습니다. (링크)
• 최대 연결 수도 설정할 수 있는데, 따로 제한을 두지는 않았습니다.

마치며

이번 주에 작업이 마무리되었고, 실제로 동적 DNS 문제를 해결할 수 있었습니다.
다만 이 과정에서 챙기지 못한 부분이 있어 장애 상황이 발생하기도 했고, 저도 테스트 과정에서 미숙한 부분이 있었습니다. 처음으로 큰 작업을 진행한 것임을 고려해도 아쉬운 점이 많았습니다.

아직 인프라 팀에는 해결해야 할 과제가 많습니다. 하나씩 문제를 해결하면서 더 나은 환경을 만들고, 저 또한 더 성장할 수 있도록 노력해야 할 것 같네요.