L4/L7 로드 밸런싱

L4/L7 스위치가 Load Balancing 목적으로 지원하며 동일한 목적을 하는 서버에 부하를 일정하게 분산하기 위하여 사용합니다.
L4는 Transport 계층까지 확인할 수 있으며, L7는 Application 계층까지 확인 가능합니다.
Client는 실제 LoadBalancer IP 로 접속하게 되어 통신하며 뒷단의 Server IP를 알 수 없습니다.
"(Reverse Proxy) 역할."
LB는 뒷단의 Server Health Check를 하여 문제가 있다면 Load Balancing 대상에서 제외 시킵니다.
(하드웨어/소프트웨어 방식이 있으며 게시글은 하드웨어 기준이며 장비는 F5를 가장 많이 사용하고 그 다음으로는 알테온 장비를 많이 사용한다.)

2. L4/L7 로드 밸런서

L4 로드 밸런서 : Transport 계층 ~ Network 계층 정보를 가지고 Load Balancing - Client <-> LB, LB <-> Server 별도로 Session을 맺음.

인라인, One arm 구성의 경우 위와 같이 세션을 맺고 DSR 구성의 경우 Server-LB-Client로 응답.

L7 Load Balancer : Application 계층~ Network 계층의 정보를 가지고 Load Balancing - HTTP 헤더 (URL, 쿠키, 컨텐츠, 브라우저 정보 등)까지 볼 수 있기 때문에 클라이언트 더 많은 정보를 확인 가능하여 섬세한 Load Balancing 가능.

• 서버들의 상태를 더 섬세하게 체크할 수 있기 때문에 문제가 있는 서버가 있을 경우 빠르게 제외할 수 있음
• Client <-> LB, LB <-> Server(Client에서 요청이 있을 경우 세션 맺기 시작) 별도로 Session을 맺음
• 그 외 캐싱, 비정상적인 세션(DDoS 공격 등)을 체크하고 사전에 필터링, Qos 가능
  (물론 L7이 좋은 점만 있지만 가격이 비싸기 때문에 목적에 따라 L4 or L7 선택)
  
  (GET과 Response(Data)가 있다)

3. 구성

Inline

• 단순한 구성으로 모든 Server와 통신하기 위해서 LB를 거쳐야해서 LB 장애 시 통신이 불가능합니다.
• LB가 필요없는 불필요한 스위칭을 해줘야 합니다.
• LB가 Src NAT를 해주기 때문에 Server는 Client IP를 알 수 없어 LB가 별도 DB에 Client IP를 저장 or 헤더에 Client IP가 기록되도록 개발&운영해야합니다.
  

One Arm

• L4에 문제가 생겨도 BB <-> Server는 통신 가능합니다.
• LB 서비스를 사용하지 않는 Server는 LB를 거치지않고 Server와 통신할 수 있습니다.
• LB가 Src NAT를 해주기 때문에 Server는 Client IP를 알 수 없어 LB가 별도 DB에 Client IP를 저장 or 헤더에 Client IP가 기록되도록 개발&운영해야합니다.
• Server에 따라 트래픽 플로우가 달라 트러블슈팅시 고려해야합니다.
  

DSR(Direct Server Return)

• 트래픽이 들어올 때는 LB를 거치지만 나갈 때는 LB를 거치지않고 통신합니다.
• LB는 Src/Dst NAT 없이 Server로 트래픽을 전달하며 Server는 처리(Loopback IP와 LB IP가 동일하기 때문에 Server가 처리 가능) 후 LB를 거치지않고 Client로 트래픽을 보낼 수 있습니다.
• Server에는 Loopback IP에 LB IP를 넣고 GARP와 ARP Response를 비활성화하여 LB가 동일한 IP가 있음을 알지 못하게 합니다.
• LB는 SYN 받은 후 SYN+ACK 받은 기록 없이 ACK를 받게 되는데 LB 쪽에서 SYN+ACK 없이 세션이 맺어질 수 있도록 설정이 필요합니다.
• LB가 Src NAT를 해주지 않기 때문에 Server는 Client IP를 직접 알 수 있습니다.
  

4. Load Balancing 알고리즘
   라운드 로빈(Default, Round Robin)

• 요청을 순서대로 각 서버에 균등하게 분배하는 방식
• 서버 커넥션 수나 응답시간에 상관없이 현재 서버들에 돌아가며 트래픽을 분배
• 가장 빠름

IP 해시(IP Hash)

• 클라이언트의 IP 주소를 특정 서버로 매핑하여 분배하는 방식
• 사용자의 IP(+ Port 등 원하는대로 해싱 대상을 지정할 수 있음)를 해싱해 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장

최소 접속(Least Connection)

• 서버에 연결되어 있는 Connection 개수만 갖고 단순 비교하여 가장 적은곳에 분배하는 방식
• 신규 서버가 들어올 경우 가장 균등하게 분배할 수 있음

그 외 가중치 최소 접속(Weighted Least Connections), 응답 시간(Fastest Response Time) 등

5. Health Check
   ICMP

• Netwrok 계층에서 확인하며 IP를 통해 상태 체크할 수 있습니다.
  

TCP

• Transport 계층에서 확인하며 세션을 통해 상태 체크할 수 있습니다.
• LB는 Interval에 따라 Health Check를 계속 하기 때문에 Server가 해당 세션을 가지고 있지 않도록 LB가 RST로 세션을 종료해줘야 합니다.
  
  HTTP
• Application 계층에서 확인하며 웹 서비스를 통해 상태 체크할 수 있습니다.
• LB는 Interval에 따라 Health Check를 계속 하기 때문에 Server가 해당 세션을 가지고 있지 않도록 LB가 RST로 세션을 종료해줘야 합니다.
  

6. SSL Offload

• SSL은 Transport 계층 Security로 LB가 SSL 인증서를 가지고 TLS Handshaking을 대신해줄 수 있습니다.
• Client <-> LB는 HTTPS(Default 443 Port), LB <-> Server는 HTTP(Default 80 Port) 통신을 하기 때문에 LB는 Port NAT를 해줘야합니다.
• 하지만? 이렇게 외부에서 LB 통해 Client가 접속하는 Server는 DMZ이기 때문에 LB <-> Server가 HTTP 통신을 하는 건 보안 목적으로 허용하지 않을 수 있습니다.
  

출처
https://eunhyee.tistory.com/229#--%--Load%--Balancing%--%EC%--%-C%EA%B-%A-%EB%A-%AC%EC%A-%--