Skip to content

Latest commit

 

History

History
153 lines (118 loc) · 11.3 KB

로드밸런서.md

File metadata and controls

153 lines (118 loc) · 11.3 KB
Raw

부하 분산

  • 서비스 규모가 커질 때, 물리, 가상 서버 한 대로는 모든 서비스를 수용할 수 없게 된다.

  • 서비스 가용성을 높이기 위해서 보통 하나의 서비스를 두 대 이상의 서버로 구성하는데, 각 서버 IP 주소가 다르기 때문에 사용자가 서비스를 호출할 때는 어떤 IP 로 서비스를 요청할 지 결정해야 한다.

  • 이런 문제점 해결을 위해서, L4, L7 로드밸런서를 사용한다.

    image

  • 로드 밸런서는 부하를 다수의 장비에 분산시키기 위해 가상 IP 주소를 갖게 된다. 사용자가 VIP 로 서비스를 요청하게 되면, 해당 VIP에 연결된 실제 서버의 IP로 해당 요청을 전달한다.

헬스 체크

  • 로드 밸런서에서는 주기적으로 부하 분산을 하는 각 서버의 서비스를 주기적으로 헬스 체크해 정상적인 서비스로만 트래픽이 갈 수 있도록 체크한다.

  • 헬스 체크 방식

    • ICMP
      • 서버에 대해 ICMP(ping)로 헬스 체크를 수행하는 방법이다.
      • 서버가 살아 있는지 여부만 확인할 수 있다.
    • TCP 서비스 포트
      • 가장 기본적인 헬스 체크 방법은 로드 밸런서에 설정된 서버의 서비스 포트를 확인하는 것.
      • 실제 서비스 포트에 3 way handshake 후, FIN을 보내 헬스 체크를 종료한다.
    • TCP 서비스 포트 : Half Open
      • 일반 TCP 서비스 포트로 인한 부하를 줄이거나, 빨리 헬스 체크 세션을 끊기 위해서 사용하는 방식이다.
      • SYN 을 보내고, SYN,ACK 를 받은 후 ACK 대신 RST 를 보내 세션을 끊는다. → 3 way handshake 과정을 절반으로 줄임
    • HTTP 상태 코드
      • 웹서비스를 할 때, 서비스 포트까지는 TCP 로 정상적으로 열리지만, 웹 서비스에 대한 응답을 정상적으로 해주지 못하는 경우가 있다.
      • 이 때 로드 밸런서 헬스 체크 방식 중 HTTP 상태 코드를 확인하는 방식으로, 3 way handshake 를 거치고, HTTP 를 요청해 200번으로 응답하는지 체크할 수 있다.
    • 콘텐츠 확인(문자열 확인)
      • 로드 밸런서에서 서버로 콘텐츠를 요청하고 응답 받은 내용을 확인하여 지정된 콘텐츠가 정상적으로 응답했는지 여부를 확인하는 헬스 체크 방법.
      • 보통 특정 웹페이지를 호출해 사전에 지정한 문자열이 해당 웹페이지 내에 포함되어 있는 지를 체크하는 기능.

부하 분산 알고리즘

  • 라운드 로빈
    • 특별한 규칙 없이 현재 구성된 장비에 순차적으로 돌아가면서 트래픽을 분산한다.
  • 최소 접속 방식
    • 서버가 가진 세션 부하를 확인해 현재 세션이 가장 적게 연결된 장비로 서비스 요청을 보내는 방식
    • 로드 밸런서는 서비스 요청을 각 장비로 보낼 때 마다 저장하는 세션 테이블로 현재 세션 수를 알아낸다.
  • 해시
    • 서버 부하를 고려하지 않고 클라이언트가 같은 서버에 지속적으로 접속하도록 하기 위해서 사용하는 방식이다.
    • 알고리즘 계산에는 주로 출발지 IP, 목적지 IP, 출발지 포트, 목적지 포트가 사용된다.

로드 밸런서 구성 방식

  • 원암(One-Arm) 구성

    • 부하 분산을 수행하는 트래픽에 대해서만 로드 밸런서를 경유한다.

    • LACP이나 분리된 VLAN을 사용하는 경우처럼 같은 다수의 인터페이스로 연결되었더라도 스위치 옆에 있는 구성이라면 동일하게 원암 구성이라 부른다.

      image

  • 인라인(Inline) 구성

    • 모든 트래픽에 대해서 로드 밸런서를 경유한다.

      image

원암 구성과 인라인 구성을 구분하는 것은 물리적 구성 기준이 아니다. 원암 구성과 비슷하게 생겼더라도 모든 트래픽이 로드밸런서를 경유하게 설정되었다면 인라인 구성으로 구분한다.

로드 밸런서 동작 모드

Transparent Mode(L2 모드)

  • 로드 밸런서가 2계층 스위치처럼 동작하는 구성, 서비스하기 위해 사용하는 VIP 주소와 실제 서버가 동일한 네트워크를 사용한다.

  • VIP와 실제 서버가 동일한 네트워크를 사용하기 때문에, 로드 밸런서 도입으로 인한 IP 네트워크를 재설계하지 않아도 된다. (손쉽게 구성 가능)

  • 트래픽이 로드 밸런서를 거치더라도 부하 분산 서비스를 받는 트래픽에 대해서만 4계층 이상의 기능을 수행한다.

  • 원암 / 인라인 구조 모두에서 사용할 수 있다.

  • 동작 흐름

    image
    • 요청
      1. 사용자가 L4의 VIP로 요청을 전송한다.
      2. L4에서 Real Server로 전송 시, Destination IP를 VIP에서 Real Server IP로 NAT한다.
      3. 동일한 네트워크 대역이므로 Destination MAC 주소만 변경된다.
    • 응답
      1. Real Server에서 서비스 응답 시, Destination IP가 다른 대역의 IP이므로 Gateway (Router)로 전송한다.
      2. Real Server에서 L4를 거치면서 Source IP를 VIP로 NAT 수행한다.
      3. 동일한 네트워크 대역이므로 MAC 주소는 변경되지 않는다.

Router Mode

  • 로드 밸런서가 라우팅 역할을 수행하는 모드.

  • LB를 기준으로 Client Side와 Server Side가 서로 다른 네트워크로 분리된다.

  • 서버 네트워크를 사설로 구성해 서버에 접속하는 것을 막을 수 있어서 보안을 강화해준다.

  • 동작 흐름

    image
    • 요청
      1. 사용자가 L4의 VIP로 요청을 전송한다.
      2. L4에서 Real Server로 전송 시, Destination IP를 VIP에서 Real Server IP로 NAT한다.
      3. 네트워크 대역이 변경되었으므로, Source와 Destination MAC 주소 모두 변경된다.
    • 응답
      1. Real Server에서 서비스 응답 시, Destination IP가 다른 대역의 IP이므로 Gateway (L4)로 전송한다.
      2. L4에서 Source IP를 VIP로 NAT한다.

DSR(Direct Server Return) 모드

  • 요청이 로드 밸런서를 통해서 서버로 유입된 이후, 서버가 사용자에게 직접 응답하는 모드이다.

  • 로드 밸런서에서 실제 서버까지의 통신이 L2 / L3 인지에 따라서 두 종류로 구분된다.

    • L2 DRS : 실제 서버의 네트워크 대역을 로드 밸런서가 가진 경우
    • L3 DRS : 실제 서버의 네트워크 대역을 로드 밸런서가 가지지 않은 경우

  • DRS 모드는 요청 트래픽만 로드 밸런서를 통하기 때문에, 로드 밸런서 자체의 전체 트래픽은 감소한다. 반면, 응답이 로드 밸런서를 경유하지 않기 때문에 문제 발생 시 확인이 어렵다.

  • 로드밸런서의 VIP를 서버의 루프백 인터페이스에 설정해주어야 작동한다.

  • 동작 흐름

    image
    • 요청
      1. 로드 밸런서 VIP 주소로 서비스를 요청한다.
      2. 목적지 IP를 그대로 유지하고 목적지 MAC 주소만 실제 MAC 주소로 변경한다.
      3. 서버
    • 응답
      1. 출발지 IP를 서버의 인터페이스 주소가 아닌, 사용자가 요청했던 VIP 주소로 설정해 패킷을 전송한다. 응답 과정에 로드밸런서가 개입하지는 않는다.

로드 밸런서 유의사항

  • 사용자가 서비스 IP(로드 밸런서 VIP)로 요청하면 로드 밸런서에서는 실제 서버의 IP 주소로 Destination NAT 한 후 서버로 전달한다.
  • 서버는 다시 사용자에게 응답할 때 게이트웨이 장비인 L3 스위치를 통해 응답하는데 인라인 구성에서는 로드 밸런서를 통과하지만 원암 구성에서는 로드 밸런서를 거치지 않고 바로 응답한다.
  • 요청 IP와 응답 IP가 매칭되지 않아서 클라이언트 입장에서는 패킷을 폐기하게 된다.
  • 이 문제는 로드 밸런서를 거치면서 변경된 IP 가 재응답할 때, 로드 밸런서를 경유하면서 원래의 IP 바꾸어 응답해야 하지만 원암 구조에서는 응답 트래픽이 로드 밸런서를 경유하지 않아서 발생한다.
  • 해결방법
    • 게이트웨이를 로드 밸런서로 설정
      • 서버가 동일 네트워크가 아닌 다른 네트워크의 목적지로 가려면 게이트웨이를 통과해야 한다
      • 때문에, 게이트웨이를 로드 밸런서로 설정하게 되면, 외부 사용자의 호출에 대한 응답이 항상 로드 밸런서를 통하므로 정상적으로 응답할 수 있게 된다.
      • 물론 부하 분산을 사용하지 않는 서버는 기존과 동일하게 게이트웨이를 L3 스위치로 설정하면 로드 밸런서를 경유하지 않으므로 여전히 로드 밸런서의 부하 감소효과를 가져올 수 있다.
    • Source NAT 사용
      • 사용자의 서비스 요청에 대해 로드 밸런서가 실제 서버로 가기 위해 수행하는 Destination NAT 뿐만 아니라, 출발지 IP 주소를 로드 밸런서가 가진 IP 로 함께 변경한다. (Source NAT)
      • 이 경우 서비스를 호출할 때와 응답할 때 모두 Source/Destination NAT 을 함께 수행하게 된다.
    • DSR 모드
      • DSR 모드는 사용자의 서비스 요청 트래픽에 대해 별도의 Destination NAT 을 수행 하지 않고, 실제 서버로 서비스 응답 패킷을 전송한다.
      • 각 서버에는 서비스 IP 정보가 루프백(클라이언트가 목적지로 설정한 VIP) 인터페이스에 설정되어 있으며 서비스에 응답할 때 루프백에 설정된 서비스 IP 주소를 출발지로 응답한다.

동일 네트워크 내에서 서비스 IP(VIP) 호출

  • 로드 밸런서를 통해 동일 네트워크에 있는 서버1, 서버2 가 있다고 가정해보자.

  • 문제 상황

    • 서버2에서 서버1의 서비스 IP 호출을 위해서 로드 밸런서로 서비스 요청을 한다.
    • 로드 밸런서는 목적지 IP 인 서비스 IP 주소를 서버1의 IP 주소로 변환해 서버1로 전달한다.
    • 서비스 요청을 받은 서버1은 서비스를 호출한 출발지 IP 를 확인하는데, 이 때 출발지 IP 가 동일 네트워크인 것을 확인하고 로드 밸런서를 통해서가 아닌 직접 응답한다.
    • 서버2에서는 요청한 IP 가 아닌 다른 IP 주소로 응답이 오기 때문에, 해당 패킷은 폐기되고, 정상적인 서비스가 이루어지지 않는다.
    • ⇒ 원암 / 인라인 모두에서 발생할 수 있는 문제이다.

  • 해결 방안

    • Source NAT 사용
    • DSR 모드

참고