트래픽이 갑자기 몰리는 시간대에는 웹 서버가 멀쩡해 보여도 응답 속도가 급격히 느려지는 일이 자주 생깁니다. 이때 많은 운영자가 가장 먼저 묻는 질문은 “pf만으로 충분한가, 아니면 HAProxy까지 써야 하나”입니다. 이 글에서는 FreeBSD 환경에서 pf + relayd, HAProxy + pf, 그리고 CARP 기반 이중화까지 실제 운영 기준으로 어디까지 필요한지 정리합니다.
로드밸런싱은 단순히 요청을 나누는 기능이 아닙니다. 장애 서버를 자동으로 제외하고, 특정 서버에만 트래픽이 몰리지 않도록 조정하며, 서비스 중단 없이 유지하는 구조를 만드는 작업에 가깝습니다.
겉으로는 설정 파일 몇 줄처럼 보이지만, 실제로는 헬스체크 방식, 세션 유지 여부, 장애 시 우회 방식에서 운영 안정성이 크게 갈립니다.
1. FreeBSD 로드밸런싱 방식과 선택 기준
처음 구축할 때 가장 많이 막히는 부분은 “무엇부터 써야 하는가”입니다. pf, relayd, HAProxy, CARP가 모두 언급되다 보니 처음에는 전부 한 번에 구성해야 할 것처럼 느껴집니다.
실제로는 목적에 따라 선택이 달라집니다. 단순한 L4 분산과 기본적인 헬스체크가 필요하다면 pf + relayd 조합이 충분할 수 있습니다. 반대로 SSL 종료, 상세한 라우팅 정책, 세션 유지, 고성능 HTTP 프록시가 필요하다면 HAProxy가 더 적합합니다.
| 구성 방식 | 추천 상황 |
|---|---|
| pf + relayd | 간단한 웹 서비스, 기본 장애 대응, FreeBSD 기본 구성 선호 |
| HAProxy + pf | 대규모 트래픽, 세밀한 정책 제어, SSL 종료 필요 |
| CARP + pf | 로드밸런서 자체의 이중화가 필요한 경우 |
많은 경우 서버 수보다 “장애를 어디까지 허용할 것인가”가 더 중요합니다. 백엔드 서버가 2대여도 로드밸런서가 1대면 그 장비가 단일 장애 지점(SPOF)이 됩니다. 여기서 갈리는 핵심은 서버 수가 아니라 장애 허용 설계입니다.
2. pf + relayd 기본 구성 방법
설정 직전 가장 자주 생기는 실수는 pf만 활성화하고 relayd를 별도로 생각하지 않는 것입니다. pf는 필터링과 NAT에 강하지만, 실제 헬스체크 기반 로드밸런싱은 relayd가 담당합니다.
기본 흐름은 이렇습니다. 외부 요청은 VIP(Virtual IP)로 들어오고, relayd가 백엔드 서버 상태를 확인한 뒤 정상 서버로 전달합니다. pf는 해당 트래픽을 허용하고 필요한 리디렉션을 처리합니다.
실무에서는 VIP를 먼저 정하고 backend 서버 IP를 나중에 넣는 경우가 많습니다. 반대로 하면 테스트 단계에서 라우팅이 꼬여 원인 파악이 어려워집니다.
헬스체크는 단순 ping보다 HTTP 응답 확인이 더 현실적입니다. 서버는 살아 있지만 웹 서비스만 죽어 있는 상황이 실제로 더 자주 발생하기 때문입니다.
대부분 조건 자체보다 헬스체크 기준을 더 많이 놓칩니다. “서버가 살아있다”와 “서비스가 정상이다”는 다른 이야기입니다. 놓치기 쉬운 포인트는 여기입니다.
3. HAProxy를 사용하는 이유와 설정 포인트
조회는 잘 되는데 실제 운영에서 불안정한 경우가 있습니다. 이럴 때는 relayd보다 HAProxy가 필요한 상황일 가능성이 높습니다.
HAProxy는 단순 분산보다 정책 제어에 강합니다. 예를 들어 특정 URL만 다른 서버로 보내거나, 로그인 세션은 같은 서버로 유지하거나, SSL 종료를 프록시 앞단에서 처리하는 방식이 가능합니다.
특히 HTTPS 서비스에서는 SSL 종료 위치가 중요합니다. 백엔드 서버마다 인증서를 관리하는 구조는 운영 피로도가 매우 높아집니다. 프록시에서 종료하면 인증서 관리가 훨씬 단순해집니다.
다만 SSL 종료를 앞단에서 처리하면 원본 클라이언트 IP 전달 설정(X-Forwarded-For)을 반드시 확인해야 합니다. 로그 분석이 꼬이는 가장 흔한 이유가 여기입니다.
겉으로는 설정이 간단해 보여도 실제로는 로그 확인 단계에서 가장 오래 걸립니다. 대부분 성능보다 추적 가능성에서 운영 품질이 갈립니다. 헷갈리기 쉬운 부분은 “잘 된다”가 아니라 “문제 발생 시 원인을 찾을 수 있는가”입니다.
4. CARP 기반 이중화가 필요한 상황
백엔드 서버를 여러 대 두었는데도 서비스가 멈추는 경우가 있습니다. 원인은 종종 로드밸런서 자체가 한 대뿐이라는 점입니다.
이때 사용하는 것이 CARP(Common Address Redundancy Protocol)입니다. 두 대 이상의 FreeBSD 노드가 하나의 가상 IP를 공유하고, Active 장비 장애 시 Standby 장비가 자동으로 승계합니다.
많은 운영자가 백엔드만 이중화하고 앞단은 단일 구성으로 끝냅니다. 하지만 실제 장애는 앞단 네트워크 장비에서 더 체감되기 쉽습니다. 사용자는 backend 장애보다 “사이트가 아예 안 열린다”는 상황을 더 크게 느낍니다.
CARP는 설정 자체보다 동기화 범위가 중요합니다. pf 상태 정보, 세션 유지, 방화벽 정책이 함께 맞지 않으면 전환은 되지만 접속이 끊기는 상황이 생깁니다. 여기서 갈리는 핵심은 전환 성공이 아니라 무중단 전환입니다.
5. 운영 중 자주 발생하는 실수와 대응 방법
실제 운영에서는 설정 오류보다 “변경 후 검증 부족”이 더 자주 문제를 만듭니다. 특히 야간 배포 직후 장애가 나는 경우 대부분 이 단계에서 발생합니다.
헬스체크가 너무 느린 경우
체크 간격이 길면 장애 감지가 늦어집니다. 반대로 너무 짧으면 오탐지가 늘어납니다. 서비스 특성에 따라 현실적인 간격을 잡아야 합니다.
세션 유지가 필요한 서비스
쇼핑몰, 관리자 페이지, 로그인 기반 서비스는 세션 유지가 중요합니다. 라운드로빈만 적용하면 로그인 풀림 문제가 발생할 수 있습니다.
로그를 남기지 않은 경우
문제는 항상 “어제는 됐는데 오늘 안 된다”는 형태로 옵니다. 그때 로그가 없으면 원인 추적이 거의 불가능합니다.
대부분 튜닝보다 기록이 먼저입니다. 성능 최적화는 나중에도 가능하지만 장애 원인 복구는 당시 로그가 없으면 어렵습니다. 놓치기 쉬운 포인트는 설정 파일보다 운영 기록입니다.
FAQ
Q1. pf만으로 로드밸런싱이 가능한가요?
기본적인 트래픽 제어는 가능하지만, 헬스체크 기반 분산과 장애 서버 자동 제외까지 생각하면 relayd 또는 HAProxy가 함께 필요합니다. 실무에서는 pf 단독보다는 조합 방식이 일반적입니다.
Q2. relayd와 HAProxy 중 무엇이 더 좋은가요?
규모와 목적에 따라 다릅니다. 단순하고 안정적인 FreeBSD 기본 구성을 원하면 relayd가 편하고, 세밀한 정책 제어와 대규모 트래픽 대응이 필요하면 HAProxy가 유리합니다.
Q3. CARP는 꼭 필요한가요?
서비스 중단 허용 범위에 따라 다릅니다. 로드밸런서 한 대 장애도 허용하기 어렵다면 CARP 구성을 검토하는 편이 좋습니다.
Q4. SSL 종료는 어디에서 하는 것이 좋나요?
운영 편의성만 보면 프록시 앞단에서 처리하는 경우가 많습니다. 다만 보안 정책과 내부 네트워크 구조에 따라 판단이 달라질 수 있습니다.
Q5. 가장 먼저 테스트해야 할 것은 무엇인가요?
헬스체크와 장애 전환입니다. 평상시 동작보다 실제 장애 발생 시 자동 우회가 되는지 먼저 확인해야 운영 중 당황하지 않습니다.
마무리
FreeBSD 로드밸런싱은 설정 파일 몇 줄로 끝나는 작업이 아닙니다. 어떤 도구를 쓰느냐보다 “어떤 장애를 막고 싶은가”를 먼저 정하는 것이 훨씬 중요합니다.
작은 서비스라면 pf + relayd부터 시작해도 충분합니다. 트래픽이 커지고 정책이 복잡해지면 HAProxy를 검토하고, 서비스 중단 자체를 최소화해야 한다면 CARP까지 고려하는 흐름이 현실적입니다.
처음부터 완벽한 구성을 만들기보다, 장애가 났을 때 어디서 막히는지 확인할 수 있는 구조를 만드는 것이 더 중요합니다. 그 기준으로 설계하면 훨씬 덜 헤매게 됩니다.
서버 환경, 트래픽 규모, 서비스 구조에 따라 최적의 로드밸런싱 방식은 달라질 수 있습니다. 특히 네트워크, 보안, 인증서, 세션 정책은 운영 환경마다 차이가 크므로 실제 적용 전 테스트 환경에서 충분한 검증이 필요합니다.