티스토리 뷰

DEV

HAProxy 로드 밸런싱 마스터하기: 웹 서버 2대 구축부터 완벽 설정 가이드

Code Brewer 2026. 1. 28. 22:24
반응형

안녕하세요! 웹 서비스의 성능과 안정성에 관심 있는 여러분을 위해, 오늘은 필수적인 기술 중 하나인 '로드 밸런싱'과 이를 구현하는 강력한 도구인 'HAProxy'에 대해 이야기해보려 합니다. 아무리 좋은 웹 서비스라도 사용자가 몰려들 때 버벅거리거나 아예 접속조차 되지 않는다면 그 가치는 크게 떨어질 수밖에 없습니다. 마치 인기 식당에 손님이 너무 많이 몰려 주방이 혼란스러워지는 상황과 같습니다. 이 문제를 해결하고, 우리의 웹 서비스를 항상 빠르고 안정적으로 유지할 수 있도록 돕는 기술이 바로 로드 밸런싱입니다.

이번 가이드에서는 단일 HAProxy와 웹 서버 2대를 활용하여 로드 밸런싱을 설정하는 모든 과정을 처음부터 끝까지 상세하게 다룰 것입니다. 로드 밸런싱의 기본 개념부터 HAProxy 설치, 설정, 모니터링, 그리고 실제 서비스 동작 확인까지, 마치 옆에서 가르쳐주듯 차근차근 설명해 드릴게요. 웹 서비스 운영에 관심 있는 일반인부터 HAProxy를 직접 설정해보고 싶은 초급/중급 개발자 및 시스템 관리자까지, 이 글을 통해 여러분의 서비스가 한 단계 더 도약하는 데 필요한 실질적인 지식을 얻어가실 수 있을 것입니다.

자, 그럼 웹 서비스의 안정성과 확장성을 위한 여정을 함께 시작해볼까요?

1. 로드 밸런싱 개념과 필요성: 웹 서비스 안정성의 시작

웹 서비스가 성장하면 방문자 수가 폭발적으로 증가하게 됩니다. 초기에는 하나의 서버로도 충분했지만, 어느 순간부터 서버에 과부하가 걸리고, 서비스 응답 속도가 느려지거나 심지어 서비스가 중단되는 상황이 발생할 수 있습니다. 상상해보세요. 주말에 여러분이 즐겨 찾는 온라인 쇼핑몰이 접속이 안 되거나 결제 페이지에서 멈춘다면 어떠시겠어요? 답답함을 넘어 실망감까지 들 것입니다. 이러한 문제를 해결하기 위한 핵심 기술이 바로 로드 밸런싱(Load Balancing)입니다.

로드 밸런싱의 기본 개념

로드 밸런싱은 이름 그대로 '부하(Load)'를 '분산(Balancing)'시키는 기술입니다. 여러 대의 서버에 트래픽(사용자의 요청)을 균등하게 나누어 처리함으로써, 특정 서버에 부하가 집중되는 것을 방지합니다.

비유를 들어 설명해볼까요? 여러분이 매우 인기 있는 빵집을 운영한다고 가정해봅시다. 이 빵집은 매일 수백 명의 손님을 맞이합니다. 처음에는 베테랑 제빵사 한 명이 모든 빵을 만들었지만, 손님이 너무 많아지자 빵이 제때 나오지 않고, 손님들이 기다리다 지쳐 돌아가는 일이 생겼습니다. 이때 사장님은 똑같은 능력을 가진 제빵사 두 명을 더 고용했습니다. 이제 세 명의 제빵사가 동시에 빵을 만들 수 있게 되었죠.

하지만 여기서 문제가 생깁니다. 손님들이 어떤 제빵사에게 주문해야 할지 혼란스러워하고, 여전히 한 제빵사에게만 주문이 몰리는 상황이 발생할 수도 있습니다. 이때 사장님은 '매니저' 한 명을 고용합니다. 이 매니저는 손님들의 주문을 받아 가장 한가한 제빵사에게 주문을 전달하는 역할을 합니다. 이렇게 함으로써 모든 제빵사가 균등하게 일하고, 손님들은 빵을 더 빨리 받을 수 있게 됩니다.

여기서 매니저의 역할이 바로 로드 밸런서(Load Balancer)이고, 세 명의 제빵사가 웹 서버에 해당합니다. 로드 밸런서는 사용자들의 웹 서비스 요청을 받아 여러 대의 웹 서버 중 하나로 적절히 분배해주는 역할을 수행합니다.

로드 밸런싱이 필요한 이유와 주요 이점

로드 밸런싱은 단순히 트래픽을 분산하는 것을 넘어, 웹 서비스의 전반적인 품질과 안정성을 향상시키는 데 필수적인 역할을 합니다. 구체적인 이점은 다음과 같습니다.

  • 서비스 안정성(Availability) 향상:
    웹 서버가 한 대뿐이라면, 이 서버에 문제가 생겼을 경우 서비스 전체가 중단됩니다. 하지만 로드 밸런싱을 통해 여러 대의 서버로 트래픽을 분산하고 있다면, 그중 한두 대의 서버가 장애로 멈추더라도 로드 밸런서는 살아있는 다른 서버로 트래픽을 우회시켜 서비스가 계속 유지되도록 합니다. 마치 제빵사 한 명이 아파서 쉬더라도, 다른 제빵사들이 계속 빵을 만드는 것과 같습니다. 이는 사용자들이 끊김 없이 서비스를 이용할 수 있도록 보장하는 매우 중요한 요소입니다. 갑작스러운 트래픽 급증이나 예상치 못한 서버 오류로부터 서비스를 보호하는 든든한 방패막이가 됩니다.
  • 확장성(Scalability) 증대:
    웹 서비스 성장으로 트래픽이 예상보다 더 많이 증가한다면 어떻게 해야 할까요? 로드 밸런싱 아키텍처에서는 기존 서버의 성능을 높이는 대신(Scale-up), 서버 대수를 늘려(Scale-out) 전체 처리 용량을 손쉽게 확장할 수 있습니다. 새로운 웹 서버를 추가하고 로드 밸런서 설정만 업데이트해주면, 더 많은 트래픽을 안정적으로 처리할 수 있게 됩니다. 이는 서비스의 유연한 확장을 가능하게 하여, 예상치 못한 성공적인 캠페인이나 이벤트에도 안정적으로 대처할 수 있도록 돕습니다. 마치 빵집에 손님이 더 많아지면 제빵사를 추가로 고용하듯 말이죠.
  • 성능(Performance) 향상:
    트래픽을 여러 서버에 분산함으로써, 각 서버가 처리해야 할 부하가 줄어들고, 결과적으로 모든 사용자가 더 빠르고 쾌적한 응답 속도를 경험하게 됩니다. 각 서버는 자신의 능력 범위 내에서 최적의 성능을 발휘할 수 있게 되므로, 시스템 전체의 처리량(Throughput)이 향상되고, 지연 시간(Latency)이 감소합니다. 이는 사용자 경험을 직접적으로 개선하여 서비스 만족도를 높이는 데 기여합니다.
  • 효율적인 자원 활용:
    로드 밸런싱은 각 서버의 부하 상태를 모니터링하여 트래픽을 가장 효율적으로 분배할 수 있습니다. 예를 들어, 특정 서버의 CPU 사용률이 높다면, 로드 밸런서는 해당 서버로 가는 트래픽을 줄이고 비교적 한가한 서버로 트래픽을 돌릴 수 있습니다. 이를 통해 서버 자원을 최대한 활용하고, 불필요한 서버 증설 없이도 안정적인 운영이 가능해집니다.

이러한 이유들로 인해 현대의 대부분의 대규모 웹 서비스는 로드 밸런싱을 필수적으로 적용하고 있습니다. 이번 가이드에서는 이 HAProxy 로드 밸런싱 개념을 직접 구현해보는 과정을 상세히 다룰 것이므로, 이 모든 이점들을 여러분의 서비스에 직접 적용할 수 있는 첫걸음을 떼게 될 것입니다.

2. HAProxy란 무엇인가? 고성능 로드 밸런서 완벽 이해

로드 밸런싱의 중요성을 이해했다면, 이제 이를 실제로 구현할 도구에 대해 알아볼 차례입니다. 시중에는 다양한 로드 밸런서 솔루션이 존재하지만, 오늘 우리가 집중적으로 다룰 주인공은 바로 HAProxy입니다. HAProxy는 고성능과 뛰어난 안정성을 자랑하는 오픈 소스 로드 밸런서로, 특히 웹 애플리케이션 환경에서 많이 사용됩니다.

HAProxy는 어떤 역할을 하나요?

HAProxy (High Availability Proxy)는 TCP/HTTP 기반의 고가용성(High Availability) 및 로드 밸런싱 솔루션을 제공하는 무료 오픈 소스 소프트웨어입니다. 즉, 웹 애플리케이션, 데이터베이스 서버, 또는 다른 네트워크 서비스 앞에 위치하여 클라이언트의 요청을 받아 여러 백엔드 서버로 분산시켜주는 '프록시' 역할을 수행합니다.

비유하자면, HAProxy는 앞서 빵집 매니저 역할과 비슷하지만, 좀 더 전문적이고 똑똑한 매니저라고 볼 수 있습니다. 단순히 주문을 받는 것을 넘어, 각 제빵사의 현재 피로도(서버 부하)를 파악하고, 어떤 빵을 만들지(서비스 유형)에 따라 최적의 제빵사를 선택하며, 심지어 제빵사 중 한 명이 갑자기 아파서 쉬게 되면 그 사실을 즉시 파악하고 다른 제빵사들에게만 주문을 전달하는 능력을 갖추고 있습니다.

HAProxy는 주로 다음과 같은 핵심 역할을 수행합니다.

  • 트래픽 분산 (Load Balancing): 클라이언트의 요청을 여러 백엔드 서버에 효율적으로 분산하여, 각 서버의 부하를 균등하게 유지하고 전체적인 처리량을 극대화합니다.
  • 고가용성 확보 (High Availability): 백엔드 서버들의 상태를 지속적으로 모니터링(Health Check)하여, 문제가 발생한 서버는 트래픽 분배 대상에서 자동으로 제외하고, 정상적인 서버로만 트래픽을 전달합니다. 이는 서비스 중단을 최소화하고 안정적인 운영을 가능하게 합니다.
  • 세션 유지 (Session Persistence/Sticky Session): 특정 클라이언트의 요청이 항상 동일한 백엔드 서버로 전달되도록 하여, 로그인 상태 유지나 장바구니 정보와 같은 세션 기반 서비스의 일관성을 보장합니다.
  • SSL/TLS 오프로딩 (SSL Offloading): 암호화/복호화에 필요한 연산 부담을 백엔드 서버가 아닌 HAProxy에서 처리하여, 백엔드 서버의 자원 소모를 줄이고 웹 서버가 핵심 비즈니스 로직 처리에 집중할 수 있도록 돕습니다.
  • 콘텐츠 기반 라우팅: 요청의 URL, 헤더 등 특정 조건에 따라 다른 백엔드 서버 그룹으로 트래픽을 라우팅할 수 있습니다.

HAProxy의 주요 특징과 장점

HAProxy가 수많은 기업과 개발자들에게 사랑받는 이유는 다음과 같은 특징과 장점들 때문입니다.

  1. 압도적인 성능: HAProxy는 C 언어로 개발되었으며, 매우 가볍고 효율적입니다. 적은 자원으로도 초당 수십만 개의 동시 연결과 요청을 처리할 수 있는 뛰어난 성능을 자랑합니다. 이는 특히 높은 트래픽을 처리해야 하는 환경에서 큰 강점입니다. 많은 트래픽을 받아야 하는 서비스에서는 HAProxy만큼 효율적인 로드 밸런서를 찾기 어렵습니다.
  2. 유연하고 강력한 설정: haproxy.cfg라는 단일 설정 파일을 통해 매우 세밀하고 복잡한 로드 밸런싱 규칙을 정의할 수 있습니다. 다양한 로드 밸런싱 알고리즘(라운드 로빈, 최소 연결 등), 조건부 라우팅, HTTP 헤더 조작 등 광범위한 기능을 지원하여 어떤 환경에도 유연하게 대처할 수 있습니다.
  3. 높은 안정성: 정교한 헬스 체크 기능을 통해 백엔드 서버의 상태를 실시간으로 감지하고, 문제가 있는 서버를 즉시 제외하여 서비스의 연속성을 보장합니다. 이는 시스템 관리자가 수동으로 개입하지 않아도 장애 상황에 자동으로 대응할 수 있게 해줍니다.
  4. 오픈 소스: 오픈 소스 라이선스로 제공되므로, 누구나 자유롭게 사용하고 수정할 수 있습니다. 이는 비용 절감뿐만 아니라, 활발한 커뮤니티 지원과 지속적인 기능 개선을 의미합니다.
  5. 쉬운 학습 곡선 (상대적): 처음 접하는 사람에게는 다소 복잡하게 느껴질 수 있지만, 기본적인 로드 밸런싱 설정은 비교적 직관적이며, 문서화가 잘 되어 있어 학습하기 용이합니다. 특히 이번 가이드에서는 HAProxy 초보 개발자 및 관리자분들도 쉽게 따라 할 수 있도록 상세하게 설명할 예정입니다.

이러한 장점들 덕분에 HAProxy는 금융, 통신, 전자상거래 등 고성능과 고가용성이 필수적인 다양한 산업 분야에서 핵심 인프라 구성 요소로 널리 활용되고 있습니다. 이제 HAProxy가 무엇인지, 왜 중요한지 충분히 이해하셨을 것입니다. 다음 섹션에서는 HAProxy와 웹 서버 2대로 구성되는 실제 아키텍처를 그림과 함께 살펴보겠습니다.

3. HAProxy 웹 서버 2대 아키텍처: 시스템 구조 및 트래픽 흐름

이제 로드 밸런싱의 개념과 HAProxy의 역할에 대해 충분히 이해했습니다. 그렇다면 실제로 '단일 HAProxy로 웹 서버 2대 로드 밸런싱'을 구현하면 어떤 모습이 될까요? 이 섹션에서는 우리가 구축할 시스템의 전체적인 구조와 트래픽 흐름을 다이어그램과 함께 상세히 설명하여, 아키텍처에 대한 명확한 그림을 제공하고자 합니다. 머릿속으로 그림을 그리며 이해하는 것은 실제 설정을 진행할 때 큰 도움이 될 것입니다.

아키텍처 개요: HAProxy와 두 웹 서버의 조화

우리가 구축할 아키텍처는 이름 그대로 매우 직관적입니다. 클라이언트(사용자)와 두 대의 웹 서버 사이에 하나의 HAProxy 서버가 위치하게 됩니다.

간단한 다이어그램을 통해 이 구조를 시각적으로 살펴보겠습니다.

graph LR
    A[클라이언트/사용자] --> B(인터넷)
    B --> C(HAProxy 서버)
    C -- 트래픽 분산 --> D[웹 서버 1]
    C -- 트래픽 분산 --> E[웹 서버 2]

    style C fill:#f9f,stroke:#333,stroke-width:2px
    style D fill:#ddf,stroke:#333,stroke-width:2px
    style E fill:#ddf,stroke:#333,stroke-width:2px
    style A fill:#cfc,stroke:#333,stroke-width:2px
    style B fill:#ddd,stroke:#333,stroke-width:2px

[ 이미지 삽입 가이드 ]
A clear, clean network diagram illustrating one HAProxy server acting as a load balancer for two distinct web servers. Arrows should depict traffic flow from a client through HAProxy to the web servers. Use simple, modern icons for servers and network components. The diagram should emphasize the concept of distributing load. The color palette should be professional and easy on the eyes.

위 다이어그램은 여러분이 HAProxy 서버 하나가 두 개의 웹 서버를 위한 로드 밸런서로 작동하는 모습을 시각적으로 보여주는, 명확하고 깔끔한 네트워크 다이어그램 이미지로 대체될 것입니다. 클라이언트에서 HAProxy를 거쳐 웹 서버로 흐르는 트래픽의 흐름을 화살표로 명확히 표현하며, 서버 및 네트워크 구성 요소에는 간단하고 현대적인 아이콘을 사용하여 부하 분산 개념을 강조할 것입니다. 색상 팔레트는 전문적이고 눈에 편안하도록 구성될 예정입니다.

이 다이어그램에서 각 구성 요소의 역할은 다음과 같습니다.

  • 클라이언트/사용자: 웹 브라우저나 모바일 앱을 통해 웹 서비스에 접속하려는 주체입니다. 이들은 웹 서비스의 실제 IP 주소를 알 필요 없이, HAProxy 서버의 공인 IP 주소 또는 도메인으로 접속을 시도합니다.
  • 인터넷: 클라이언트와 HAProxy 서버 사이의 통신 경로입니다.
  • HAProxy 서버: 클라이언트의 모든 요청을 가장 먼저 받는 관문(Gateway) 역할을 합니다. 이 서버는 웹 서비스의 '공인 IP 주소'를 가지고 있으며, 클라이언트는 이 주소로 접속하게 됩니다. HAProxy는 받은 요청을 미리 설정된 규칙(로드 밸런싱 알고리즘)에 따라 백엔드 웹 서버 중 하나로 전달합니다. 또한, 각 웹 서버의 건강 상태(Health Check)를 지속적으로 확인하여, 문제가 있는 서버로는 트래픽을 보내지 않습니다. 이것이 바로 우리가 구성할 단일 HAProxy 구성의 핵심입니다.
  • 웹 서버 1 & 웹 서버 2: 실제 웹 애플리케이션(HTML, CSS, JavaScript, 이미지 등)을 호스팅하고 클라이언트의 요청을 처리하는 서버들입니다. 이 서버들은 HAProxy의 뒤에 숨겨져 있으므로, 외부에서 직접 접근할 수 없습니다. HAProxy만이 이 서버들과 통신할 수 있으며, 이들은 HAProxy로부터 전달받은 요청을 처리한 후, 그 결과를 다시 HAProxy를 통해 클라이언트에게 전달합니다. HAProxy 웹 서버 2대 구성은 가장 기본적인 형태의 로드 밸런싱 환경으로, 학습 및 소규모 서비스에 매우 적합합니다.
반응형

트래픽 흐름 심층 분석

이제 클라이언트의 요청이 어떻게 흐르는지 단계별로 자세히 살펴보겠습니다.

  1. 클라이언트 요청 발생: 사용자가 웹 브라우저에 http://서비스도메인.com과 같은 URL을 입력하거나, 모바일 앱에서 특정 기능을 실행하면, 해당 요청은 인터넷을 통해 HAProxy 서버의 공인 IP 주소로 전달됩니다. 사용자는 웹 서버들의 존재나 IP 주소를 전혀 알지 못합니다. 모든 요청은 HAProxy로 향합니다.
  2. HAProxy 서버의 요청 수신: HAProxy 서버는 80번 포트(HTTP)나 443번 포트(HTTPS) 등 미리 설정된 포트로 들어오는 클라이언트의 요청을 수신합니다. 이 시점에서 HAProxy는 여러 가지 작업을 수행할 수 있습니다. 예를 들어, 요청 헤더를 검사하거나, 특정 URL 패턴을 분석하는 등의 사전 처리를 할 수 있습니다.
  3. 백엔드 서버 선택 및 트래픽 분배 (로드 밸런싱): HAProxy는 설정된 로드 밸런싱 알고리즘(예: Round Robin, Least Connection 등)에 따라 백엔드 웹 서버 그룹 (backend) 내에서 가장 적합한 서버를 선택합니다. 이 과정에서 각 서버의 현재 부하 상태, 활성화 여부(Health Check 결과) 등을 고려하여 결정합니다. 이것이 바로 HAProxy 로드 밸런싱의 핵심 단계입니다.
  4. 백엔드 서버로 요청 전달: 선택된 웹 서버(예: 웹 서버 1)로 클라이언트의 요청을 전달합니다. 이때 HAProxy는 클라이언트와 웹 서버 사이에서 프록시 역할을 수행하므로, 웹 서버는 요청이 HAProxy로부터 온 것으로 인식합니다. (실제 클라이언트 IP를 백엔드에 전달하는 설정도 가능합니다.)
  5. 백엔드 서버의 요청 처리: 선택된 웹 서버는 HAProxy로부터 받은 요청을 처리합니다. 예를 들어, 동적인 웹 페이지를 생성하거나 데이터베이스에서 정보를 조회하는 등의 작업을 수행합니다.
  6. 처리 결과 HAProxy로 반환: 웹 서버는 처리된 결과(HTML 페이지, 이미지 등)를 다시 HAProxy 서버로 반환합니다.
  7. HAProxy의 결과 수신 및 클라이언트로 전달: HAProxy는 웹 서버로부터 받은 처리 결과를 클라이언트에게 다시 전달합니다. 이로써 클라이언트는 마치 HAProxy가 직접 요청을 처리한 것처럼 응답을 받게 됩니다.

이러한 과정을 통해 클라이언트는 여러 대의 웹 서버가 존재한다는 사실을 인지하지 못한 채, 안정적이고 빠른 서비스를 이용하게 됩니다. HAProxy는 이 모든 과정의 중앙에서 트래픽의 흐름을 제어하고, 서비스의 안정성과 확장성을 책임지는 중요한 역할을 수행합니다.

이 아키텍처는 단일 HAProxy 구성이지만, 두 대의 웹 서버를 통해 기본적인 웹 서버 이중화 효과와 부하 분산 효과를 얻을 수 있습니다. 물론 HAProxy 자체에 장애가 발생하면 전체 서비스가 중단되는 '단일 실패 지점(Single Point of Failure)'이 될 수 있다는 한계점도 있지만, 이는 HAProxy 이중화(HA 구성)를 통해 보완할 수 있습니다. 이번 가이드에서는 가장 기본적인 형태를 먼저 이해하고 구축하는 데 집중할 것입니다.

이제 머릿속에 HAProxy와 웹 서버 2대의 전체적인 그림이 그려지셨기를 바랍니다. 다음 섹션부터는 실제로 서버를 준비하고 HAProxy를 설치 및 설정하는 단계로 넘어가겠습니다.

4. HAProxy 설치 및 기본 환경 설정 (Ubuntu/CentOS)

이제 이론적인 배경과 아키텍처를 이해했으니, 실질적인 단계로 넘어가 HAProxy를 설치하고 초기 환경을 설정해봅시다. 이 섹션에서는 실제 서버 환경(Ubuntu 또는 CentOS)에서 HAProxy 설치 단계별 가이드와 함께 기본적인 설정 파일(haproxy.cfg)의 구조를 설명합니다.

HAProxy는 비교적 설치가 간단하며, 리눅스 시스템의 패키지 관리자를 통해 쉽게 설치할 수 있습니다. 여러분의 운영체제에 맞춰 다음 단계를 따라주세요.

4.1. 서버 준비 (HAProxy 서버)

HAProxy를 설치할 서버 한 대가 필요합니다. 이 서버는 클라이언트로부터의 모든 웹 요청을 받을 서버이므로, 공인 IP 주소가 할당되어 있어야 합니다.

  • 운영체제: Ubuntu 20.04+ 또는 CentOS 7/8+ (여기서는 일반적인 명령어를 사용하므로 큰 차이는 없습니다.)
  • 최소 사양: CPU 1코어, RAM 1GB (실습용으로 충분하며, 실제 운영 환경에서는 트래픽 규모에 따라 증설이 필요합니다.)
  • 방화벽 설정: HAProxy가 사용할 포트(기본적으로 HTTP는 80번, HTTPS는 443번)를 외부에서 접근할 수 있도록 방화벽을 열어두어야 합니다.

4.2. HAProxy 설치 가이드

아래는 Ubuntu와 CentOS 환경에서 HAProxy를 설치하는 방법입니다. SSH를 통해 서버에 접속한 후 다음 명령어를 실행하세요.

4.2.1. Ubuntu/Debian 기반 시스템 (예: Ubuntu 20.04/22.04)

  1. 패키지 목록 업데이트:
    시스템의 패키지 목록을 최신 상태로 업데이트하여, 최신 버전의 HAProxy를 설치할 수 있도록 합니다.
  2. sudo apt update
  3. HAProxy 설치:
    apt 패키지 관리자를 사용하여 HAProxy를 설치합니다.-y 옵션은 설치 중 확인 메시지에 자동으로 '예(yes)'라고 응답하여 설치를 자동화합니다.
  4. sudo apt install haproxy -y
  5. HAProxy 서비스 상태 확인 (선택 사항):
    설치 후 HAProxy 서비스가 정상적으로 실행되고 있는지 확인합니다. 초기에는 설정 파일이 없거나 잘못되어 에러 상태일 수 있습니다.출력 결과에서 Active: active (running)을 확인하면 정상입니다. 만약 Active: inactive (dead) 또는 Active: failed가 보인다면, 아직 설정 파일이 없거나 문제가 있을 수 있습니다.
  6. sudo systemctl status haproxy
  7. HAProxy 서비스 자동 시작 활성화:
    서버 재부팅 시 HAProxy가 자동으로 시작되도록 설정합니다.
  8. sudo systemctl enable haproxy

4.2.2. CentOS/RHEL 기반 시스템 (예: CentOS 7/8, AlmaLinux, Rocky Linux)

  1. EPEL 저장소 설치 (CentOS 7):
    HAProxy는 기본 EPEL (Extra Packages for Enterprise Linux) 저장소에 포함되어 있을 수 있습니다. 만약 HAProxy 패키지를 찾을 수 없다면, 먼저 EPEL 저장소를 설치해야 합니다. CentOS 8 이상 버전에서는 일반적으로 필요하지 않거나 다른 저장소에 포함되어 있습니다.
  2. sudo yum install epel-release -y # 또는 CentOS 8 이상: # sudo dnf install epel-release -y
  3. 패키지 목록 업데이트 (선택 사항):
    패키지 목록을 업데이트합니다.
  4. sudo yum update -y # 또는 CentOS 8 이상: # sudo dnf update -y
  5. HAProxy 설치:
    yum 또는 dnf 패키지 관리자를 사용하여 HAProxy를 설치합니다.
  6. sudo yum install haproxy -y # 또는 CentOS 8 이상: # sudo dnf install haproxy -y
  7. HAProxy 서비스 상태 확인 (선택 사항):
    설치 후 HAProxy 서비스가 정상적으로 실행되고 있는지 확인합니다.
  8. sudo systemctl status haproxy
  9. HAProxy 서비스 자동 시작 활성화:
    서버 재부팅 시 HAProxy가 자동으로 시작되도록 설정합니다.
  10. sudo systemctl enable haproxy

4.3. 방화벽 설정

HAProxy 서버에 방화벽이 활성화되어 있다면, 클라이언트의 요청이 HAProxy에 도달할 수 있도록 필요한 포트를 열어주어야 합니다. 기본적으로 HTTP 트래픽을 위한 80번 포트를 열어줍니다.

4.3.1. Ubuntu (UFW 사용)

sudo ufw allow 80/tcp
sudo ufw reload
sudo ufw status # 80번 포트가 허용되었는지 확인

4.3.2. CentOS (firewalld 사용)

sudo firewall-cmd --permanent --add-service=http
# 또는 특정 포트 번호로:
# sudo firewall-cmd --permanent --add-port=80/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-all # 80번 포트가 허용되었는지 확인

4.4. HAProxy 초기 설정 파일 (haproxy.cfg) 구조 이해

HAProxy의 모든 설정은 /etc/haproxy/haproxy.cfg 파일에 기록됩니다. 이 파일을 수정하여 HAProxy의 동작 방식을 정의하게 됩니다. 처음에는 이 파일이 다소 복잡하게 느껴질 수 있지만, 주요 섹션만 이해하면 쉽게 다룰 수 있습니다.

HAProxy 설정 파일은 크게 다음과 같은 섹션으로 구성됩니다.

  1. global 섹션:
    HAProxy 프로세스 전역에 적용되는 설정들을 정의합니다. 예를 들어, 로그 설정, 최대 연결 수, 사용자 및 그룹 설정 등이 포함됩니다.
  2. global log /dev/log local0 notice # 로그 설정 chroot /var/lib/haproxy # 보안 강화를 위한 chroot 경로 pidfile /var/run/haproxy.pid # PID 파일 경로 maxconn 4000 # 최대 동시 연결 수 user haproxy # HAProxy 실행 사용자 group haproxy # HAProxy 실행 그룹 daemon # 데몬으로 실행 stats socket /var/run/haproxy.sock user haproxy group haproxy mode 660 level admin # 통계 소켓 # 기타 CPU 코어 활용, SSL 관련 설정 등
  3. defaults 섹션:
    listen, frontend, backend 섹션에 공통적으로 적용될 기본 설정을 정의합니다. 이 섹션에서 정의된 값들은 각 개별 섹션에서 재정의될 수 있습니다. 일반적으로 타임아웃, 로그 형식, 모드(HTTP/TCP) 등을 설정합니다.특히 mode http는 HAProxy가 HTTP 프로토콜 수준에서 트래픽을 처리하도록 지시하는 중요한 설정입니다. 이는 HAProxy가 HTTP 헤더를 분석하고, URL 기반 라우팅, 쿠키 기반 세션 유지 등 HTTP 프로토콜의 고급 기능을 활용할 수 있게 합니다.
  4. defaults mode http # 기본 통신 모드: HTTP (layer 7) log global # global 섹션의 로그 설정 상속 option httplog # HTTP 요청/응답 로그 활성화 option dontlognull # 비어있는 로그 항목 기록 안 함 timeout connect 5000ms # 서버 연결 대기 시간 timeout client 50000ms # 클라이언트 유휴 시간 timeout server 50000ms # 서버 유휴 시간 errorfile 400 /etc/haproxy/errors/400.http # 오류 페이지 설정 errorfile 403 /etc/haproxy/errors/403.http errorfile 408 /etc/haproxy/errors/408.http errorfile 500 /etc/haproxy/errors/500.http errorfile 502 /etc/haproxy/errors/502.http errorfile 503 /etc/haproxy/errors/503.http errorfile 504 /etc/haproxy/errors/504.http
  5. frontend 섹션:
    HAProxy가 클라이언트로부터 요청을 수신하는 지점을 정의합니다. 어떤 IP 주소와 포트에서 요청을 들을 것인지(bind), 그리고 어떤 backend로 요청을 전달할 것인지(default_backend) 등을 설정합니다. 이 섹션은 클라이언트가 HAProxy와 통신하는 방법을 정의합니다. HAProxy frontend backend 키워드와 밀접하게 관련됩니다.
  6. frontend my_web_frontend # 프론트엔드 이름 (임의 지정) bind *:80 # 모든 IP의 80번 포트에서 요청 수신 default_backend web_servers # 이 프론트엔드로 들어온 요청을 web_servers 백엔드로 전달
  7. backend 섹션:
    HAProxy가 클라이언트로부터 받은 요청을 실제로 전달할 웹 서버(백엔드 서버) 그룹을 정의합니다. 어떤 로드 밸런싱 알고리즘(balance)을 사용할지, 어떤 서버들이 백엔드 그룹에 포함되는지(server) 등을 설정합니다.
  8. backend web_servers # 백엔드 이름 (임의 지정) balance roundrobin # 로드 밸런싱 알고리즘: roundrobin server web1 192.168.1.101:80 check # 백엔드 서버 1 (IP:포트), 헬스 체크 server web2 192.168.1.102:80 check # 백엔드 서버 2 (IP:포트), 헬스 체크
  9. listen 섹션 (선택 사항):
    frontend와 backend를 하나의 섹션에서 동시에 정의할 때 사용합니다. 간단한 설정에서는 유용하지만, 복잡한 구성에서는 frontend와 backend를 분리하는 것이 더 가독성이 높습니다. HAProxy 모니터링 페이지와 같은 특정 목적에 주로 사용됩니다.

이러한 global, defaults, frontend, backend 섹션들이 모여 하나의 haproxy.cfg 파일을 구성하며, HAProxy의 모든 동작을 제어합니다.

이제 HAProxy 설치와 설정 파일의 기본 구조에 대한 이해가 끝났습니다. 다음 섹션에서는 HAProxy의 로드 밸런싱 대상이 될 웹 서버 두 대를 준비하는 방법을 다루겠습니다. HAProxy 설치 및 초기 환경 설정은 로드 밸런싱 구현의 첫 단추이므로, 이 과정을 꼼꼼히 따라 해주시기 바랍니다.

5. 로드 밸런싱 대상 웹 서버 준비: Nginx 설치 및 테스트

HAProxy 서버를 준비하고 설치했으니, 이제 HAProxy가 트래픽을 분산해줄 실제 웹 서버들을 준비할 차례입니다. 우리는 두 대의 웹 서버를 구축하고, 각각의 웹 서버가 정상적으로 동작하는지 간단한 테스트 페이지를 통해 확인하는 방법을 안내할 것입니다. 이 두 웹 서버는 HAProxy의 '백엔드(backend)' 역할을 수행하게 됩니다.

5.1. 웹 서버 환경 준비 (웹 서버 1 & 웹 서버 2)

HAProxy 웹 서버 2대 로드 밸런싱을 위해 최소 두 대의 웹 서버가 필요합니다. 이 서버들은 HAProxy와 동일한 네트워크 대역에 있거나, HAProxy가 접근할 수 있는 네트워크 경로를 가지고 있어야 합니다.

  • 운영체제: HAProxy 서버와 동일하게 Ubuntu 20.04+ 또는 CentOS 7/8+
  • 최소 사양: CPU 1코어, RAM 512MB (실습용으로 충분)
  • 네트워크: 각 웹 서버에는 고유한 사설 IP 주소(예: 192.168.1.101 및 192.168.1.102)가 할당되어 있어야 합니다. HAProxy 서버는 이 사설 IP 주소를 통해 웹 서버에 접근하게 됩니다.
  • 방화벽 설정: 웹 서버들은 HAProxy로부터만 요청을 받을 것이므로, HAProxy 서버의 IP 주소(또는 서브넷)에서 80번 포트(HTTP)로의 접근을 허용하도록 방화벽을 설정해야 합니다. 외부로부터의 직접적인 접근은 차단하는 것이 보안상 좋습니다.

이번 가이드에서는 가볍고 널리 사용되는 웹 서버인 Nginx를 사용하여 웹 서버를 구성하겠습니다.

5.2. Nginx 설치 및 기본 페이지 설정 (각 웹 서버에서 반복)

두 대의 웹 서버(웹 서버 1, 웹 서버 2) 각각에서 아래 단계를 반복하여 수행해야 합니다.

5.2.1. Nginx 설치

  1. 패키지 목록 업데이트:
  2. sudo apt update # Ubuntu/Debian # sudo yum update -y # CentOS/RHEL
  3. Nginx 설치:
  4. sudo apt install nginx -y # Ubuntu/Debian # sudo yum install nginx -y # CentOS/RHEL
  5. Nginx 서비스 시작 및 자동 시작 활성화:
  6. sudo systemctl start nginx sudo systemctl enable nginx sudo systemctl status nginx # Nginx 서비스 상태 확인

5.2.2. 간단한 테스트 페이지 생성

HAProxy가 트래픽을 제대로 분산하고 있는지 시각적으로 확인하기 위해, 각 웹 서버에 해당 서버의 IP 주소나 이름을 표시하는 간단한 index.html 파일을 생성할 것입니다.

  1. 기존 index.html 백업 (선택 사항):
  2. sudo mv /var/www/html/index.nginx-debian.html /var/www/html/index.nginx-debian.html.bak # Ubuntu # sudo mv /usr/share/nginx/html/index.html /usr/share/nginx/html/index.html.bak # CentOS
  3. 새 index.html 파일 생성 및 내용 입력:
    • 웹 서버 1 (192.168.1.101)에서:파일 내용에 다음을 추가합니다.
    • <!DOCTYPE html> <html> <head> <title>Web Server 1</title> <style> body { font-family: Arial, sans-serif; text-align: center; margin-top: 50px; background-color: #e0f2f7; } h1 { color: #2196f3; } p { font-size: 1.2em; } </style> </head> <body> <h1>Hello from Web Server 1!</h1> <p>This page is served by: <strong>192.168.1.101</strong></p> <p>You have successfully connected to the first web server.</p> </body> </html>
    • sudo vi /var/www/html/index.html # Ubuntu # sudo vi /usr/share/nginx/html/index.html # CentOS
    • 웹 서버 2 (192.168.1.102)에서:파일 내용에 다음을 추가합니다.vi 에디터 사용법: i를 눌러 입력 모드 진입 -> 내용 붙여넣기 -> Esc 키 누르기 -> :wq 입력 후 Enter (저장 후 종료).
    • <!DOCTYPE html> <html> <head> <title>Web Server 2</title> <style> body { font-family: Arial, sans-serif; text-align: center; margin-top: 50px; background-color: #fffde7; } h1 { color: #ffc107; } p { font-size: 1.2em; } </style> </head> <body> <h1>Hello from Web Server 2!</h1> <p>This page is served by: <strong>192.168.1.102</strong></p> <p>You have successfully connected to the second web server.</p> </body> </html>
    • sudo vi /var/www/html/index.html # Ubuntu # sudo vi /usr/share/nginx/html/index.html # CentOS

5.2.3. Nginx 설정 파일 수정 (옵션)

기본 Nginx 설정은 /etc/nginx/nginx.conf 또는 /etc/nginx/sites-available/default (Ubuntu)에 있습니다. 특별히 변경할 필요는 없지만, server 블록 내 root 지시자가 /var/www/html을 가리키는지 확인하고, listen 80으로 80번 포트를 리스닝하는지 확인합니다.

예시 (/etc/nginx/sites-available/default 또는 /etc/nginx/conf.d/default.conf):

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    root /var/www/html; # 또는 /usr/share/nginx/html (CentOS)

    # Add index.php to the list if you are using PHP
    index index.html index.htm index.nginx-debian.html;

    server_name _;

    location / {
        try_files $uri $uri/ =404;
    }
    # ... (생략)
}

변경 사항이 있다면 Nginx를 재시작합니다.

sudo systemctl restart nginx

5.2.4. 웹 서버 방화벽 설정

각 웹 서버에서 HAProxy 서버의 IP 주소(예: 192.168.1.100)만 80번 포트에 접근할 수 있도록 방화벽을 설정합니다.

  • Ubuntu (UFW 사용):(만약 HAProxy 서버 IP가 192.168.1.0/24와 같은 대역이라면, sudo ufw allow from 192.168.1.0/24 to any port 80 proto tcp로 설정할 수 있습니다.)
  • sudo ufw allow from 192.168.1.100 to any port 80 proto tcp sudo ufw reload sudo ufw status
  • CentOS (firewalld 사용):your_admin_ip 부분에는 여러분이 접속할 클라이언트(관리 PC)의 실제 공인 IP 주소를 입력해야 합니다.
  • sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port port="80" protocol="tcp" accept' sudo firewall-cmd --reload sudo firewall-cmd --list-all

5.3. 웹 서버 개별 동작 테스트

HAProxy를 설정하기 전에, 각 웹 서버가 개별적으로 정상 동작하는지 HAProxy 서버에서 확인해야 합니다. HAProxy 서버에 SSH로 접속한 후 curl 명령어를 사용하여 각 웹 서버의 사설 IP로 직접 접근해봅니다.

  • HAProxy 서버에서 웹 서버 1 테스트:출력 결과: Hello from Web Server 1!과 같은 index.html 내용이 보여야 합니다.
  • curl http://192.168.1.101
  • HAProxy 서버에서 웹 서버 2 테스트:출력 결과: Hello from Web Server 2!과 같은 index.html 내용이 보여야 합니다.
  • curl http://192.168.1.102

만약 curl 명령어가 동작하지 않거나 웹 페이지 내용이 예상과 다르다면, 해당 웹 서버의 Nginx 서비스 상태, 방화벽 설정, 또는 index.html 파일 내용을 다시 확인해야 합니다. 이 테스트가 성공해야 HAProxy가 웹 서버로 트래픽을 정상적으로 전달할 수 있습니다.

이제 HAProxy가 로드 밸런싱할 두 대의 웹 서버 준비가 완료되었습니다. 다음 섹션에서는 HAProxy의 핵심 설정 파일인 haproxy.cfg를 수정하여 frontend와 backend를 정의하는 방법에 대해 자세히 알아보겠습니다. HAProxy 웹 서버 2대 환경 구축의 핵심 단계이니, 주의 깊게 따라와 주세요.

6. HAProxy 로드 밸런싱 설정 핵심: Frontend, Backend 구성

이제 HAProxy 서버와 두 대의 웹 서버가 모두 준비되었습니다. HAProxy가 클라이언트의 요청을 받아 웹 서버로 분산시켜주는 핵심적인 역할을 수행하도록 설정해야 합니다. 이 작업은 /etc/haproxy/haproxy.cfg 파일을 수정함으로써 이루어집니다. 이 섹션에서는 HAProxy 로드 밸런싱의 핵심인 frontend와 backend 섹션을 설정하는 방법을 심층적으로 다루고, 다양한 로드 밸런싱 알고리즘의 개념과 적용 예시를 제공합니다.

6.1. haproxy.cfg 파일 수정

HAProxy 서버에 SSH로 접속하여 /etc/haproxy/haproxy.cfg 파일을 편집합니다.

sudo vi /etc/haproxy/haproxy.cfg

기존 파일 내용은 주석 처리하거나 백업해두고, 아래의 예시를 참고하여 필요한 설정을 추가 또는 수정합니다.

6.1.1. global 및 defaults 섹션 설정 (재확인)

이전 섹션에서 설명한 대로 global 및 defaults 섹션을 설정합니다. 특히 defaults 섹션의 mode http 설정이 중요합니다.

global
    log         /dev/log    local0 notice
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/run/haproxy.sock user haproxy group haproxy mode 660 level admin

defaults
    mode                    http              # HTTP 모드 설정
    log                     global
    option                  httplog           # HTTP 로그 활성화
    option                  dontlognull
    timeout connect         5000ms            # 백엔드 서버 연결 대기 시간
    timeout client          50000ms           # 클라이언트 유휴 시간
    timeout server          50000ms           # 백엔드 서버 유휴 시간
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

6.1.2. frontend 섹션 설정

frontend는 HAProxy가 클라이언트의 요청을 수신하는 진입점을 정의합니다. 우리는 클라이언트가 HAProxy 서버의 80번 포트(HTTP)로 접속하도록 설정할 것입니다.

frontend my_web_frontend
    bind *:80                     # 모든 IP의 80번 포트에서 요청 수신 (HAProxy 서버의 공인 IP:80)
    option http-server-close      # HTTP 연결 닫기 옵션으로 효율성 증대
    default_backend web_servers   # 이 프론트엔드로 들어온 모든 요청을 'web_servers' 백엔드로 전달
  • frontend my_web_frontend: 이 프론트엔드의 이름을 my_web_frontend로 지정합니다. 이름은 사용자 정의입니다.
  • bind *:80: HAProxy 서버의 모든 네트워크 인터페이스(IP)의 80번 포트에서 클라이언트의 연결을 기다립니다. 만약 특정 IP만 사용하고 싶다면 bind 123.123.123.123:80과 같이 지정할 수 있습니다.
  • option http-server-close: HAProxy가 클라이언트와 웹 서버 간의 HTTP 연결을 좀 더 효율적으로 관리하도록 돕는 옵션입니다.
  • default_backend web_servers: 이 frontend로 들어오는 모든 트래픽을 web_servers라는 이름의 backend 섹션으로 전달하도록 지시합니다.

6.1.3. backend 섹션 설정

backend는 HAProxy가 클라이언트로부터 받은 요청을 실제 웹 서버(백엔드 서버)들로 분산시키는 방법을 정의합니다. 여기서는 두 대의 Nginx 웹 서버를 백엔드로 등록하고, 로드 밸런싱 알고리즘을 지정합니다.

backend web_servers
    balance roundrobin      # 로드 밸런싱 알고리즘: roundrobin
    # option httpchk GET /  # HTTP 헬스 체크 경로 (루트 경로로 GET 요청)
    # option forwardfor     # X-Forwarded-For 헤더 추가하여 클라이언트 IP 전달

    server web1 192.168.1.101:80 check # 웹 서버 1: IP 192.168.1.101의 80번 포트
    server web2 192.168.1.102:80 check # 웹 서버 2: IP 192.168.1.102의 80번 포트
  • backend web_servers: 이 백엔드의 이름을 web_servers로 지정합니다. 이 이름은 frontend 섹션에서 default_backend 지시자로 참조됩니다.
  • balance roundrobin: 로드 밸런싱 알고리즘으로 roundrobin을 사용하도록 지정합니다. 이는 들어오는 요청을 백엔드 서버들에게 순서대로(돌아가면서) 분배하는 가장 기본적인 방식입니다.
  • server web1 192.168.1.101:80 check: web1이라는 이름으로 첫 번째 백엔드 서버를 정의합니다. IP 주소는 192.168.1.101, 포트는 80번입니다. check 옵션은 HAProxy가 이 서버의 상태를 주기적으로 확인하여, 서버가 응답하지 않을 경우 트래픽 분배 대상에서 자동으로 제외하도록 지시합니다.
  • server web2 192.168.1.102:80 check: 동일한 방식으로 두 번째 백엔드 서버를 정의합니다.

HAProxy 설정 가이드 요약본 (haproxy.cfg)

모든 내용을 합치면 다음과 같은 haproxy.cfg 파일이 됩니다.

global
    log         /dev/log    local0 notice
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/run/haproxy.sock user haproxy group haproxy mode 660 level admin

defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    timeout connect         5000ms
    timeout client          50000ms
    timeout server          50000ms
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

frontend my_web_frontend
    bind *:80
    option http-server-close
    default_backend web_servers

backend web_servers
    balance roundrobin
    server web1 192.168.1.101:80 check
    server web2 192.168.1.102:80 check

파일을 저장하고 종료합니다. (:wq for vi)

6.2. HAProxy 로드 밸런싱 알고리즘

backend 섹션의 balance 지시자를 통해 HAProxy가 트래픽을 분산하는 방식을 설정할 수 있습니다. HAProxy는 다양한 로드 밸런싱 알고리즘을 지원하며, 서비스의 특성에 맞춰 적절한 알고리즘을 선택하는 것이 중요합니다.

주요 로드 밸런싱 알고리즘은 다음과 같습니다.

  1. roundrobin (라운드 로빈):
    • 가장 간단하고 널리 사용되는 알고리즘입니다. 요청을 백엔드 서버들에게 순서대로(돌아가면서) 분배합니다. 마치 시계 방향으로 돌아가면서 음식을 나눠주는 것과 같습니다.
    • 장점: 구현이 간단하고 설정하기 쉽습니다. 모든 서버에 균등하게 트래픽을 분산하므로, 서버들의 성능이 유사할 때 효율적입니다.
    • 단점: 각 서버의 실제 부하 상태를 고려하지 않고 단순히 요청 수를 기준으로 분배하므로, 처리 시간이 긴 요청이 많은 서버가 생기면 전체적인 응답 속도가 느려질 수 있습니다.
    • 적용 예시: 모든 웹 서버의 처리 능력이 동일하고, 요청 처리 시간이 비슷한 환경에 적합합니다.
  2. leastconn (최소 연결):
    • 현재 활성화된 연결 수가 가장 적은 서버로 새로운 요청을 분배합니다.
    • 장점: 서버들의 부하 상태를 실시간으로 반영하여 트래픽을 분산하므로, roundrobin보다 효율적일 수 있습니다. 특정 서버에 부하가 몰리는 것을 방지하는 데 효과적입니다.
    • 단점: 연결이 오래 지속되는 서비스(예: 웹 소켓)에서는 다른 서버에 비해 연결 수가 압도적으로 많아질 수 있습니다.
    • 적용 예시: 각 서버의 처리 능력이 약간 다르거나, 요청 처리 시간이 가변적인 환경에서 유용합니다.
  3. source (소스 IP 해시):
    • 클라이언트의 IP 주소를 해싱하여, 동일한 클라이언트의 요청은 항상 동일한 백엔드 서버로 전달합니다. 이를 통해 세션을 유지(Sticky Session)할 수 있습니다.
    • 장점: 세션 유지가 필요한 서비스(로그인, 장바구니 등)에 적합합니다.
    • 단점: 특정 IP 대역에서 많은 요청이 발생할 경우, 해당 백엔드 서버에 부하가 집중될 수 있습니다. 로드 밸런싱 효과가 불균등할 수 있습니다.
    • 적용 예시: 세션 데이터가 서버에 저장되는(Stateful) 애플리케이션에 필수적입니다.
  4. uri (URI 해시) / url_param (URL 파라미터 해시):
    • 요청의 URI(Uniform Resource Identifier) 또는 특정 URL 파라미터 값을 해싱하여 로드 밸런싱합니다.
    • 장점: 특정 리소스에 대한 요청을 특정 서버로 보낼 때 유용합니다.
    • 단점: URL 패턴에 따라 부하가 불균등해질 수 있습니다.
    • 적용 예시: 캐시 서버나 특정 종류의 콘텐츠를 처리하는 서버 그룹에 유용합니다.

이 외에도 header, rdp-cookie, random 등 다양한 알고리즘이 있지만, 위 네 가지가 가장 흔하게 사용됩니다. 이번 실습에서는 가장 기본적이고 이해하기 쉬운 roundrobin을 사용했습니다.

6.3. HAProxy 설정 파일 문법 검사 및 서비스 재시작

설정 파일 (haproxy.cfg)을 수정한 후에는 반드시 문법 오류가 없는지 확인하고, HAProxy 서비스를 재시작해야 변경 사항이 적용됩니다.

  1. HAProxy 설정 파일 문법 검사:
    다음 명령어를 사용하여 설정 파일에 오류가 없는지 확인합니다. 오류가 있다면 메시지가 출력됩니다.Configuration file is valid 메시지가 출력되면 정상입니다.
  2. sudo haproxy -c -f /etc/haproxy/haproxy.cfg
  3. HAProxy 서비스 재시작:
    설정 파일에 문제가 없다면, HAProxy 서비스를 재시작합니다.
  4. sudo systemctl restart haproxy
  5. HAProxy 서비스 상태 확인:
    서비스가 정상적으로 실행 중인지 확인합니다.Active: active (running)을 확인하면 성공입니다. 만약 failed 상태라면, 로그를 확인하여 문제를 해결해야 합니다. (sudo journalctl -u haproxy)
  6. sudo systemctl status haproxy

이제 HAProxy frontend backend 설정이 완료되었습니다. 클라이언트의 요청이 HAProxy를 통해 웹 서버로 성공적으로 전달될 준비가 된 것입니다. 다음 섹션에서는 HAProxy가 제공하는 모니터링 대시보드를 활성화하고 활용하는 방법을 알아보겠습니다. 이를 통해 로드 밸런싱이 실제로 어떻게 동작하는지 시각적으로 확인할 수 있습니다.

7. HAProxy 모니터링 대시보드 활용: 실시간 성능 확인

HAProxy를 성공적으로 설정했다면, 이제 로드 밸런서가 제대로 작동하고 있는지, 그리고 백엔드 서버들의 상태는 어떤지 실시간으로 확인하고 싶을 것입니다. HAProxy는 이러한 요구를 충족시키기 위해 강력한 통계 및 모니터링 대시보드를 내장하고 있습니다. 이 섹션에서는 HAProxy에서 제공하는 통계 및 모니터링 페이지를 활성화하고, 이를 통해 로드 밸런싱 상태와 서버의 부하를 실시간으로 확인하는 방법을 설명합니다. 이는 HAProxy 모니터링의 핵심 기능입니다.

7.1. HAProxy 모니터링 대시보드 활성화 (listen 섹션 추가)

HAProxy 모니터링 대시보드는 일반적으로 웹 서버의 트래픽을 처리하는 포트와는 다른 별도의 포트에서 동작하도록 설정합니다. 이는 보안상의 이유와 관리 편의성을 위함입니다. haproxy.cfg 파일에 listen 섹션을 추가하여 모니터링 페이지를 활성화할 수 있습니다.

HAProxy 서버에 SSH로 접속하여 /etc/haproxy/haproxy.cfg 파일을 다시 편집합니다.

sudo vi /etc/haproxy/haproxy.cfg

파일의 가장 마지막 부분, 또는 backend 섹션 다음에 다음과 같은 listen 섹션을 추가합니다.

# ... (기존 frontend, backend 섹션 아래에 추가) ...

listen stats
    bind *:8080                         # HAProxy 서버의 8080 포트에서 통계 페이지 리스닝
    stats enable                        # 통계 페이지 활성화
    stats uri /haproxy_stats            # 통계 페이지 접속 URI (예: http://HAProxy_IP:8080/haproxy_stats)
    stats realm Haproxy\ Statistics     # 로그인 창에 표시될 영역 이름
    stats auth admin:password           # 통계 페이지 접속 인증 (ID:비밀번호)
    stats hide-version                  # HAProxy 버전 정보 숨기기 (보안 권장)
    stats admin if LOCALHOST            # 로컬 호스트에서만 관리자 기능 활성화 (선택 사항)
  • listen stats: 이 섹션의 이름을 stats로 지정합니다. listen 섹션은 frontend와 backend의 조합과 같다고 보시면 됩니다.
  • bind *:8080: HAProxy 서버의 모든 IP 주소에 대해 8080번 포트에서 요청을 기다립니다. 이 포트를 통해 모니터링 페이지에 접근하게 됩니다. 실제 운영 환경에서는 bind 123.123.123.123:8080과 같이 특정 IP에 바인딩하거나, 방화벽을 통해 특정 관리자 IP에서만 접근 가능하도록 제한하는 것이 좋습니다.
  • stats enable: 통계 페이지 기능을 활성화합니다.
  • stats uri /haproxy_stats: 통계 페이지에 접근할 URI 경로를 지정합니다. 이 예시에서는 http://HAProxy_IP:8080/haproxy_stats로 접속하게 됩니다.
  • stats realm Haproxy\ Statistics: 통계 페이지에 접속할 때 표시되는 인증 팝업의 제목입니다. \은 공백 문자를 나타냅니다.
  • stats auth admin:password: 통계 페이지에 접속하기 위한 사용자 이름과 비밀번호를 설정합니다. 여기서는 admin과 password를 사용했지만, 실제 운영 환경에서는 훨씬 복잡하고 안전한 비밀번호를 사용해야 합니다.
  • stats hide-version: HAProxy의 버전 정보를 숨겨 보안을 강화합니다.
  • stats admin if LOCALHOST: (선택 사항) if LOCALHOST 조건을 추가하면, HAProxy 서버 자체에서 접속할 경우에만 관리자 기능(예: 서버 비활성화)이 활성화됩니다. 외부 접속 시에는 모니터링만 가능하게 하여 보안을 높일 수 있습니다.

파일을 저장하고 종료한 후, HAProxy 설정 파일 문법을 검사하고 서비스를 재시작합니다.

sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl restart haproxy
sudo systemctl status haproxy

7.2. HAProxy 서버 방화벽 설정

모니터링 대시보드에 외부에서 접근하려면, HAProxy 서버의 방화벽에서 8080번 포트를 열어주어야 합니다. 보안을 위해 특정 관리자 IP 주소에서만 접근을 허용하는 것을 강력히 권장합니다.

  • Ubuntu (UFW 사용):
  • sudo ufw allow 8080/tcp # 모든 IP에서 허용 (보안 취약) # 또는 특정 IP에서만 허용 (권장): # sudo ufw allow from your_admin_ip to any port 8080 proto tcp sudo ufw reload sudo ufw status
  • CentOS (firewalld 사용):your_admin_ip 부분에는 여러분이 접속할 클라이언트(관리 PC)의 실제 공인 IP 주소를 입력해야 합니다.
  • sudo firewall-cmd --permanent --add-port=8080/tcp # 모든 IP에서 허용 (보안 취약) # 또는 특정 IP에서만 허용 (권장): # sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="your_admin_ip" port port="8080" protocol="tcp" accept' sudo firewall-cmd --reload sudo firewall-cmd --list-all

7.3. 모니터링 대시보드 활용

이제 웹 브라우저를 열고 HAProxy 서버의 IP 주소와 설정한 포트, URI로 접속합니다.

  • 접속 URL: http://HAProxy_SERVER_IP:8080/haproxy_stats
    (예: http://192.168.1.100:8080/haproxy_stats)

접속하면 사용자 이름과 비밀번호를 묻는 팝업창이 나타날 것입니다. admin / password를 입력하여 로그인하면 HAProxy 통계 페이지를 볼 수 있습니다.

모니터링 대시보드 주요 항목 설명:

모니터링 대시보드는 여러 테이블로 구성되어 있으며, 각 섹션별로 다양한 통계 정보를 제공합니다.

  • my_web_frontend (프론트엔드 섹션):
    • Sessions: 현재 활성화된 세션 수, 최대 세션 수, 총 세션 수 등 클라이언트 연결과 관련된 통계를 보여줍니다. Cur (현재), Max (최대), Lbt (세션 유지 시간) 등의 정보를 통해 프론트엔드에 걸리는 부하를 파악할 수 있습니다.
    • Bytes: 송수신된 총 데이터량을 보여줍니다.
  • web_servers (백엔드 섹션):
    • 이 섹션 아래에는 각 백엔드 서버(web1, web2)에 대한 상세 통계가 표시됩니다.
    • Status: 현재 서버의 상태를 나타냅니다. UP은 정상 작동, DOWN은 장애, MAINT는 유지보수 모드 등을 의미합니다.
    • Sessions: 각 서버로 분배된 현재 세션 수, 최대 세션 수, 총 세션 수를 보여줍니다. 이 수치를 통해 로드 밸런싱이 얼마나 균등하게 이루어지고 있는지 확인할 수 있습니다.
    • QCur / QMax: 현재 대기열에 있는 요청 수 / 최대 대기열 요청 수입니다. 요청이 대기열에 많이 쌓인다면 해당 서버에 과부하가 걸리고 있음을 의미합니다.
    • Bps(in/out): 초당 입/출력 바이트 수입니다. 서버의 네트워크 트래픽을 파악할 수 있습니다.
    • Chk: 헬스 체크 상태를 나타냅니다. OK는 정상, fail은 헬스 체크 실패를 의미합니다. LastChk는 마지막 헬스 체크 결과를 보여줍니다.
    • Downtime: 서버가 DOWN 상태였던 총 시간입니다.
    • Weight: 해당 서버에 할당된 가중치입니다. 기본값은 1이며, 가중치가 높을수록 더 많은 트래픽을 받습니다.

이 대시보드를 통해 우리는 HAProxy가 클라이언트 요청을 두 웹 서버에 roundrobin 방식으로 어떻게 분배하고 있는지, 각 서버의 현재 상태는 어떤지 등을 실시간으로 파악할 수 있습니다. 예를 들어, web1과 web2의 Sessions 값이 비슷하게 증가하는 것을 보면 로드 밸런싱이 잘 되고 있다는 것을 알 수 있습니다. 만약 한 서버의 Status가 DOWN으로 변경된다면, HAProxy가 자동으로 해당 서버로는 트래픽을 보내지 않는 것을 확인할 수 있을 것입니다.

단일 HAProxy 구성에서 모니터링은 특히 중요합니다. HAProxy 자체에 문제가 생기면 전체 서비스가 마비될 수 있기 때문에, HAProxy의 상태를 주의 깊게 지켜볼 필요가 있습니다. 다음 섹션에서는 실제로 HAProxy를 통해 웹 서비스에 접속하고, 간단한 부하 테스트를 통해 로드 밸런싱의 동작을 검증하는 방법을 알아보겠습니다.

8. HAProxy 로드 밸런싱 동작 확인: 실제 서비스 및 부하 테스트

모든 설정이 완료되었습니다! HAProxy 설치부터 웹 서버 준비, 그리고 haproxy.cfg 설정까지, 모든 단계를 성공적으로 마쳤습니다. 이제 실제로 클라이언트 입장에서 웹 서비스에 접속하여 로드 밸런싱이 정상적으로 작동하는지 확인하고, 더 나아가 간단한 부하 테스트를 통해 HAProxy의 동작을 검증해볼 차례입니다. 이 과정은 HAProxy 로드 밸런싱이 제대로 구현되었는지 최종적으로 확인하는 중요한 단계입니다.

8.1. 웹 브라우저를 통한 서비스 동작 확인

가장 먼저, 웹 브라우저를 통해 HAProxy 서버의 공인 IP 주소(또는 도메인)로 접속하여 웹 서비스가 정상적으로 뜨는지 확인합니다.

  1. HAProxy 서버의 공인 IP 주소 확인:
    HAProxy 서버의 공인 IP 주소를 알고 있어야 합니다. 예를 들어, 123.123.123.123이라고 가정합니다.
  2. 웹 브라우저 접속:
    웹 브라우저를 열고 다음 URL로 접속합니다: http://HAProxy_SERVER_IP (예: http://123.123.123.123).
  3. 결과 확인:
    • 처음 접속하면 "Hello from Web Server 1!"이라는 메시지와 함께 192.168.1.101 서버 페이지가 보일 것입니다.
    • 웹 브라우저의 캐시를 지우거나 (Ctrl+Shift+R 또는 Shift+F5로 강제 새로고침), 시크릿 모드/다른 브라우저로 다시 접속하거나, 단순히 새로고침을 여러 번 반복해 보세요.
    • roundrobin 로드 밸런싱 알고리즘 덕분에, 새로고침할 때마다 "Hello from Web Server 2!" (192.168.1.102) 페이지와 "Hello from Web Server 1!" (192.168.1.101) 페이지가 번갈아 나타나는 것을 확인할 수 있을 것입니다.

만약 한 서버의 페이지만 계속 보이거나, 웹 페이지가 뜨지 않는다면 다음 사항들을 다시 확인해야 합니다.

  • HAProxy 서비스가 active (running) 상태인지
  • HAProxy 서버의 80번 포트 방화벽이 열려 있는지
  • HAProxy의 haproxy.cfg 파일에 frontend와 backend 설정이 올바른지 (특히 백엔드 서버 IP 주소와 포트)
  • 각 웹 서버의 Nginx 서비스가 active (running) 상태인지
  • 각 웹 서버의 80번 포트 방화벽이 HAProxy 서버로부터의 접근을 허용하고 있는지
  • HAProxy 서버에서 curl http://192.168.1.101 및 curl http://192.168.1.102 명령어가 정상 작동하는지

8.2. HAProxy 모니터링 대시보드를 통한 확인

웹 브라우저를 통해 동작을 확인하는 동시에, HAProxy 모니터링 대시보드(http://HAProxy_SERVER_IP:8080/haproxy_stats)를 열어두면 더욱 확실하게 로드 밸런싱 상황을 파악할 수 있습니다.

  • 웹 브라우저에서 서비스 페이지를 새로고침할 때마다, 대시보드의 backend web_servers 섹션 아래에 있는 web1과 web2 서버의 Sessions (특히 Cur와 Tot) 값이 번갈아 증가하는 것을 볼 수 있습니다. 이는 HAProxy가 요청을 각 서버에 잘 분산하고 있다는 증거입니다.
  • 만약 특정 웹 서버의 Nginx 서비스를 잠시 중지시켜보세요 (예: sudo systemctl stop nginx on Web Server 1). 그러면 HAProxy 모니터링 대시보드에서 해당 서버의 Status가 DOWN으로 바뀌고, HAProxy가 자동으로 해당 서버로의 트래픽 전송을 중단하는 것을 확인할 수 있습니다. 이제 서비스 페이지를 새로고침해도 다른 정상적인 웹 서버 페이지만 계속 보이게 될 것입니다. 다시 Nginx 서비스를 시작하면 (sudo systemctl start nginx), 잠시 후 서버 상태가 UP으로 돌아오고 다시 로드 밸런싱에 참여하게 됩니다.

8.3. 간단한 부하 테스트 (Load Testing)

웹 브라우저를 통한 수동 확인은 기본적인 동작을 검증하기에 충분하지만, 실제 부하 상황에서 HAProxy가 얼마나 효율적으로 트래픽을 분산하는지 확인하기 위해서는 부하 테스트 도구를 사용하는 것이 좋습니다. 여기서는 ApacheBench (ab)나 hey와 같은 간단한 도구를 사용하여 부하 테스트를 수행하는 방법을 설명합니다.

8.3.1. ApacheBench (ab) 사용 (Ubuntu/CentOS)

ab는 Apache HTTP 서버의 성능 벤치마킹 도구이지만, HAProxy를 포함한 다른 웹 서버나 로드 밸런서의 성능 테스트에도 널리 사용됩니다.

  1. ab 설치 (테스트를 실행할 클라이언트 PC 또는 별도의 서버에 설치):
    • Ubuntu/Debian: 
      sudo apt install apache2-utils -y
    • CentOS/RHEL: 
      sudo yum install httpd-tools -y
# 또는 sudo dnf install httpd-tools -y (CentOS 8 이상)
  2. 부하 테스트 실행:
    다음 명령어를 사용하여 HAProxy 서버의 공인 IP로 1000개의 요청을 100개의 동시 연결로 전송합니다.
    • -n 1000: 총 1000개의 요청을 보냅니다.
    • -c 100: 동시에 100개의 요청을 처리합니다 (동시성).
    • http://HAProxy_SERVER_IP/: HAProxy 서버의 공인 IP 주소 또는 도메인입니다.
  3. ab -n 1000 -c 100 http://HAProxy_SERVER_IP/
  4. 결과 확인:
    ab 명령어가 실행되는 동안 HAProxy 모니터링 대시보드를 주시하세요. web1과 web2 서버의 Sessions 값이 빠르게 증가하며, 거의 유사한 수준으로 분배되는 것을 확인할 수 있을 것입니다. roundrobin 알고리즘 덕분에 요청이 두 서버에 거의 절반씩 나뉘어 처리되는 것을 볼 수 있습니다.
  5. ab 명령어의 출력 결과에서는 Requests per second, Time per request, Transfer rate 등 다양한 성능 지표를 확인할 수 있습니다.

8.3.2. hey 사용 (Go 기반 경량 부하 테스트 도구)

hey는 Go 언어로 작성된 경량 부하 테스트 도구로, ab보다 더 현대적이고 사용하기 쉽습니다.

  1. hey 설치 (테스트를 실행할 클라이언트 PC 또는 별도의 서버에 설치):
    • GitHub 릴리즈 페이지에서 바이너리를 다운로드하여 /usr/local/bin 등에 옮겨 실행 권한을 부여하거나, Go 환경이 있다면 go install로 설치합니다. 
      # 예시: Linux 64비트 시스템
wget https://github.com/rakyll/hey/releases/download/v0.1.4/hey_linux_amd64 -O hey
chmod +x hey
sudo mv hey /usr/local/bin/
  2. 부하 테스트 실행:
    ab와 유사하게 1000개의 요청을 100개의 동시 연결로 전송합니다.
    • -n 1000: 총 요청 수
    • -c 100: 동시 사용자 수
  3. hey -n 1000 -c 100 http://HAProxy_SERVER_IP/
  4. 결과 확인:
    hey 역시 HAProxy 모니터링 대시보드를 통해 로드 밸런싱 분배를 확인하고, hey 자체의 출력에서 Requests/sec, Latency, Throughput 등의 지표를 확인할 수 있습니다.

부하 테스트를 통해 HAProxy가 트래픽을 안정적으로 분산하고 각 웹 서버가 요청을 처리하는 모습을 확인했다면, 여러분의 단일 HAProxy 구성은 성공적으로 작동하고 있는 것입니다. 이로써 HAProxy 설정 가이드의 핵심적인 배포 및 검증 과정이 완료되었습니다. 다음 섹션에서는 HAProxy의 고급 기능과 실제 운영 시 고려해야 할 사항들을 간략하게 소개하며, 더 나은 서비스를 위한 다음 단계로 나아갈 준비를 하겠습니다.

9. HAProxy 고급 기능 및 운영 팁: 헬스 체크, 세션 유지, 보안

지금까지 우리는 단일 HAProxy로 웹 서버 2대 로드 밸런싱의 기본 개념부터 실제 설정, 그리고 동작 확인까지 마쳤습니다. 이제 HAProxy가 제공하는 강력한 고급 기능들을 간략하게 소개하고, 실제 운영 환경에서 서비스를 더욱 안정적이고 효율적으로 만들기 위해 고려해야 할 사항들을 다루겠습니다. 이 섹션은 HAProxy 초보를 넘어 중급 이상으로 나아가기 위한 중요한 지식입니다.

9.1. HAProxy 고급 기능

9.1.1. 헬스 체크 (Health Check) 심화

우리는 backend 섹션의 server 지시자 뒤에 check 옵션을 추가하여 기본적인 헬스 체크를 활성화했습니다. 이는 HAProxy가 백엔드 서버의 80번 포트에 TCP 연결을 시도하여 서버가 살아있는지 확인하는 가장 기본적인 방식입니다. 하지만 실제 웹 서비스에서는 단순히 서버가 살아있는지 여부뿐만 아니라, 웹 애플리케이션 자체의 로직이 정상적으로 동작하는지도 확인해야 할 때가 많습니다.

  • HTTP 헬스 체크:
    check 옵션과 함께 option httpchk GET /health와 같은 설정을 추가하여 특정 URL 경로(GET /health)로 HTTP 요청을 보내 서버의 응답을 확인하도록 할 수 있습니다. 예를 들어, /health 경로로 접속했을 때 "OK"라는 텍스트나 특정 HTTP 상태 코드(예: 200 OK)를 반환하도록 웹 애플리케이션을 구현하면, HAProxy는 이를 통해 서비스의 정상 여부를 더욱 정확하게 판단할 수 있습니다.
    • inter 2s: 2초마다 헬스 체크를 수행합니다.
    • fall 3: 헬스 체크 3회 연속 실패 시 서버를 DOWN 상태로 전환합니다.
    • rise 2: 서버가 DOWN 상태였다가 헬스 체크 2회 연속 성공 시 UP 상태로 전환합니다.
    정교한 헬스 체크는 장애 발생 시 사용자에게 미치는 영향을 최소화하고 서비스의 가용성을 극대화하는 데 필수적입니다.
  • backend web_servers balance roundrobin option httpchk GET /health # /health 경로로 HTTP GET 요청 보내 응답 확인 server web1 192.168.1.101:80 check inter 2s fall 3 rise 2 server web2 192.68.1.102:80 check inter 2s fall 3 rise 2

9.1.2. 세션 유지 (Session Persistence / Sticky Session)

특정 클라이언트의 요청이 항상 동일한 백엔드 서버로 전달되도록 하는 기능입니다. 이는 사용자 로그인 세션, 장바구니 정보 등 서버에 상태 정보가 저장되는(Stateful) 애플리케이션에 매우 중요합니다.

  • cookie 기반 세션 유지:
    HAProxy가 클라이언트에게 특정 쿠키를 발급하고, 이 쿠키 값에 따라 항상 동일한 서버로 요청을 전달하는 방식입니다.클라이언트가 처음 접속하면 HAProxy는 SERVERID라는 쿠키를 발행하고, 그 값으로 web1_id 또는 web2_id 중 하나를 할당합니다. 이후 동일 클라이언트의 요청은 이 쿠키 값을 보고 항상 같은 서버로 보내지게 됩니다.
  • backend web_servers balance roundrobin cookie SERVERID insert indirect nocache # SERVERID라는 쿠키를 삽입하고, # 각 서버에 고유한 ID 부여 server web1 192.168.1.101:80 check cookie web1_id server web2 192.168.1.102:80 check cookie web2_id
  • source 기반 세션 유지:
    클라이언트의 IP 주소를 해싱하여 해당 IP의 모든 요청을 항상 동일한 서버로 보내는 방식입니다. balance source 지시자를 사용합니다. 설정은 간단하지만, 네트워크 환경(NAT)에 따라 여러 클라이언트가 동일한 공인 IP를 사용할 경우 특정 서버에 부하가 집중될 수 있습니다.

9.1.3. SSL/TLS 오프로딩 (SSL Offloading)

HTTPS 트래픽의 암호화 및 복호화 작업은 CPU 자원을 많이 소모합니다. HAProxy에서 이 작업을 대신 처리하도록 설정하면(SSL Offloading), 백엔드 웹 서버들은 암호화 부담 없이 HTTP 트래픽만 처리하여 핵심 비즈니스 로직에 집중할 수 있게 됩니다.

frontend my_secure_frontend
    bind *:443 ssl crt /etc/ssl/certs/your_domain.pem # 443 포트에서 SSL/TLS 처리
    default_backend web_servers
  • ssl crt /etc/ssl/certs/your_domain.pem: HAProxy에 SSL 인증서(도메인에 대한 공인 인증서 또는 자체 서명 인증서) 경로를 지정합니다. 이 파일은 PEM 형식이어야 하며, 개인 키와 인증서가 함께 포함되어야 합니다.
  • 백엔드 서버들은 이제 80번 포트(HTTP)로 요청을 받게 되므로, 백엔드 설정은 그대로 유지할 수 있습니다.

9.2. 실제 운영 시 고려사항

HAProxy 설정 가이드를 따라 기본적인 로드 밸런싱을 구축했지만, 실제 서비스 운영에서는 더 많은 부분을 고려해야 합니다.

  1. HAProxy 이중화 (High Availability for HAProxy):
    현재 단일 HAProxy 구성은 HAProxy 서버 자체에 장애가 발생하면 전체 서비스가 중단되는 '단일 실패 지점(Single Point of Failure, SPOF)'을 가집니다. 이를 해결하기 위해 두 대 이상의 HAProxy 서버를 두고, Keepalived와 같은 솔루션을 사용하여 가상 IP(VIP)를 공유하며 액티브-스탠바이(Active-Standby) 또는 액티브-액티브(Active-Active) 클러스터로 구성하여 HAProxy의 고가용성을 확보해야 합니다. 이는 웹 서버 이중화를 넘어 로드 밸런서 자체의 이중화를 의미합니다.
  2. 로그 관리 및 모니터링 강화:
    HAProxy의 로그는 서비스 운영에 매우 중요한 정보를 제공합니다. 적절한 로깅 설정과 함께, ELK Stack(Elasticsearch, Logstash, Kibana)이나 Prometheus/Grafana 같은 전문 모니터링 도구를 연동하여 HAProxy의 통계 및 백엔드 서버들의 상태를 더욱 심층적으로 분석하고 시각화하는 것이 필요합니다. 경고 시스템을 구축하여 장애 발생 시 즉각적으로 알림을 받을 수 있도록 준비해야 합니다.
  3. 성능 튜닝:
    HAProxy는 기본적으로 고성능을 제공하지만, 대규모 트래픽 환경에서는 OS 커널 파라미터 튜닝(TCP 버퍼, 파일 디스크립터 수 등), HAProxy 설정 파일 내의 nbproc (HAProxy 프로세스 개수), maxconn (최대 연결 수), 타임아웃 값 등을 세밀하게 조정하여 성능을 최적화할 필요가 있습니다.
  4. 보안 강화:
    HAProxy는 외부와 내부 네트워크의 경계에 있으므로, 보안에 각별히 신경 써야 합니다. 불필요한 포트 개방 최소화, 강력한 인증 정보 사용, SSL/TLS 적용, DDoS 공격 방어를 위한 설정 등을 검토해야 합니다. HAProxy는 요청 헤더, URL 등을 기반으로 악성 트래픽을 필터링하는 데도 활용될 수 있습니다.
  5. 백엔드 서버의 무상태성(Stateless) 유지:
    세션 유지가 반드시 필요한 경우가 아니라면, 백엔드 웹 서버를 무상태(Stateless)로 설계하는 것이 좋습니다. 즉, 사용자 세션 정보나 데이터를 각 웹 서버 자체에 저장하는 대신, 별도의 분산 캐시(Redis, Memcached)나 데이터베이스에 저장하여, 어떤 웹 서버로 요청이 가더라도 동일한 사용자 경험을 제공할 수 있도록 합니다. 이는 로드 밸런싱의 효율성을 극대화하고 서버 확장을 용이하게 합니다.

이러한 고급 기능과 운영 시 고려사항들을 충분히 이해하고 적용한다면, 여러분의 웹 서비스는 더욱 강력하고 안정적으로 거듭날 수 있을 것입니다. 이번 가이드는 HAProxy 초보를 위한 첫걸음이지만, 이 지식들이 더 나아가 고성능, 고가용성 아키텍처를 구축하는 데 튼튼한 기반이 되기를 바랍니다.

10. 결론: HAProxy 로드 밸런싱, 다음 단계는?

이번 가이드에서는 단일 HAProxy로 웹 서버 2대 로드 밸런싱을 완벽하게 구현하는 여정을 함께했습니다. 로드 밸런싱의 기본 개념부터 HAProxy 소개, 아키텍처 분석, 실제 설치 및 설정, 모니터링, 그리고 동작 확인까지, 모든 과정을 자세히 살펴보았습니다. 이 과정을 통해 여러분은 웹 서비스의 안정성과 확장성을 위한 중요한 기술적 기반을 다지게 되었습니다.

10.1. 단일 HAProxy 구성의 장점

우리가 구축한 단일 HAProxy 구성은 다음과 같은 명확한 장점을 제공합니다.

  • 설정 및 관리의 용이성: 하나의 HAProxy 서버와 두 대의 웹 서버라는 비교적 간단한 구조 덕분에, 설정과 관리가 복잡하지 않아 HAProxy 초보 사용자도 쉽게 접근하고 운영할 수 있습니다.
  • 비용 효율성: 고가의 상용 로드 밸런서 솔루션이나 클라우드 서비스의 로드 밸런싱 기능을 사용하지 않고도, 오픈 소스인 HAProxy를 통해 기본적인 로드 밸런싱 기능을 구현할 수 있어 비용을 절감할 수 있습니다.
  • 성능 및 안정성 향상: 두 대의 웹 서버로 트래픽을 분산함으로써, 단일 서버 구성에 비해 서비스의 응답 속도가 향상되고, 한 서버에 장애가 발생해도 다른 서버가 요청을 처리하여 서비스 중단을 방지할 수 있습니다. 이는 기본적인 웹 서버 이중화 효과를 제공합니다.
  • 학습 및 실습에 최적: 실제 로드 밸런싱 환경을 직접 구축하고 원리를 이해하는 데 있어, 가장 직관적이고 효율적인 시작점이 됩니다.

10.2. 단일 HAProxy 구성의 한계

하지만 우리가 구축한 단일 HAProxy 구성은 실제 운영 환경에서 다음과 같은 잠재적인 한계점을 가집니다.

  • 단일 실패 지점 (Single Point of Failure, SPOF):
    가장 큰 한계점은 HAProxy 서버 자체에 장애가 발생할 경우, 모든 웹 서버로의 트래픽이 차단되어 서비스 전체가 중단된다는 것입니다. HAProxy가 아무리 안정적이라 할지라도 하드웨어 고장, 네트워크 문제, 설정 오류 등으로 인해 언제든 다운될 수 있습니다. 이 단일 지점이 무너지면 웹 서비스 역시 마비됩니다.
  • 트래픽 처리량의 제약:
    하나의 HAProxy 서버가 처리할 수 있는 최대 트래픽 양에는 물리적인 한계가 있습니다. 서비스 규모가 매우 커져 HAProxy 서버 하나로는 감당하기 어려운 수준의 트래픽이 발생하면 병목 현상이 일어날 수 있습니다.
  • 단순한 확장성:
    웹 서버 대수는 쉽게 늘릴 수 있지만, HAProxy 서버 자체의 확장성(스케일 아웃)은 단일 구성에서는 불가능하며, HAProxy를 여러 대 사용하는 추가적인 고가용성 아키텍처가 필요합니다.

10.3. 다음 단계: 더 나은 서비스를 위한 확장

이러한 한계점을 극복하고 더욱 견고하며 확장 가능한 웹 서비스를 구축하기 위해서는 다음 단계로 나아가야 합니다.

  1. HAProxy 이중화 (HAProxy High Availability):
    단일 실패 지점 문제를 해결하기 위한 가장 중요한 다음 단계는 HAProxy 이중화입니다. 두 대 이상의 HAProxy 서버를 구성하고, Keepalived와 같은 솔루션을 활용하여 가상 IP(VIP)를 공유함으로써, 한 HAProxy 서버가 다운되더라도 다른 HAProxy 서버가 자동으로 트래픽을 이어받아 서비스 중단 없이 로드 밸런싱을 지속할 수 있도록 하는 것입니다. 이는 서비스의 진정한 고가용성을 보장하는 핵심 요소입니다.
  2. 로드 밸런싱 계층 확장:
    서비스 규모가 더욱 커지면 HAProxy 앞에 클라우드 로드 밸런서(AWS ELB, GCP L7 LB)나 하드웨어 로드 밸런서를 두어 1차 로드 밸런싱을 수행하고, HAProxy는 더 세부적인 백엔드 트래픽 분배를 담당하는 다계층 로드 밸런싱 아키텍처를 고려할 수 있습니다.
  3. 컨테이너 및 오케스트레이션 도입:
    Docker와 Kubernetes와 같은 컨테이너 기술과 오케스트레이션 도구를 도입하여 웹 서버 및 HAProxy 배포를 자동화하고, 서비스의 확장성과 유연성을 극대화할 수 있습니다. HAProxy를 컨테이너로 실행하고 Kubernetes Ingress Controller와 연동하여 동적인 환경에서도 로드 밸런싱을 효율적으로 관리할 수 있습니다.

이번 가이드는 여러분이 웹 서비스의 안정성을 한 단계 끌어올리는 데 필요한 기본적인 지식과 실질적인 경험을 제공했을 것입니다. HAProxy 설치부터 HAProxy 로드 밸런싱의 원리, 그리고 HAProxy 웹 서버 2대 구성까지, 여러분은 이제 복잡한 웹 시스템의 한 축을 이해하고 직접 구축할 수 있는 능력을 갖추게 되었습니다. 이 지식들을 발판 삼아, 더 복잡하고 강력한 아키텍처 구축에 도전해 보시길 바랍니다.

여러분의 서비스가 항상 안정적이고 빠르게 작동하기를 기원합니다! 다음번에는 HAProxy 이중화 구성이나 더 심화된 주제로 다시 찾아뵙겠습니다. 감사합니다.

 

반응형

'DEV' 카테고리의 다른 글

디지털 보안의 핵심: OTP(일회용 비밀번호) 인증 원리, 비전공자도 완벽 이해하기  (0) 2026.01.28
유튜브 수익 추정, 2024년 최신 완벽 가이드: 조회수와 구독자만으로 실제 수익을 예측할 수 있을까?  (0) 2026.01.28
로또 1등 당첨 확률: '쌀 한 톨' 비유부터 실제 계산까지 통계학적 분석  (0) 2026.01.28
macOS Cron Job 마스터 가이드: 반복 작업 자동화부터 고급 설정까지  (0) 2026.01.28
SSD 핵심 기술 완전 정복: SLC, MLC, TLC, QLC 셀 타입 완벽 분석 및 구매 가이드  (0) 2026.01.28
공유하기 링크
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG more
«   2026/02   »
일 월 화 수 목 금 토
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
글 보관함
반응형