회사에서 L4 스위치 관련해 이슈가 있었는데 관련 지식이 부족해 찾아보던 중 잘 정리된 포스팅이 있어 읽고 간단하게 정리해보았다.
L4 스위치란?
- L4 스위치는 서버 부하 분산=로드빌런싱 을 처리하는 장치다
- 뿐만 아니라 프로토콜(TCP, UDP, HTTP 등)의 헤더를 분석한 정보를 토대로 부하 분산을 실시하고, source ip, destination ip를 NAT 해서 보낼 수 있다.
관련 용어
- L4 스위치는 외부 접속용 공인 IP와 서버와 통신하기 위한 사설 IP를 갖게된다
- 모든 요청은 L4스위치를 통해 서버로 들어오므로, 서버는 공인 ip가 필요없고 사설 ip만 갖는다.
- 외부에서 서버 ip를 알 수 없고 악의적 공격이 제한된다.
- Virtual Server
- L4 스위치의 Virtual Server : 외부에서 접속하기 위한 공인 IP와 포트번호
- Virtual Server의 ip : VIP
- L4 스위치는 다수의 Virtual Server를 가질 수 있다.
- virtual server는 type이 Layer 4 또는 Layer 7이다
- layer 4 : forwarding(전달)에 초점, 사용자가 전달한 요청 그대로 서버에 전달
- L7에 굳이 접근할 필요 없이 L4에서의 성능에 집중
- layer 7 : layer7 (application layer : http, dns)의 프로토콜의 헤더 제어 + layer 4 (tcp, udp) 제어
- L7도 제어함으로써 HTTP 헤더 정보에 따라 처리하는 등 L4스위치를 적극적으로 사용 가능
- layer 4 : forwarding(전달)에 초점, 사용자가 전달한 요청 그대로 서버에 전달
- Pool
- ip와 port가 명시된 서버들의 집합, virtual server로 온 요청을 L4가 여기로 보낸다
- pool에 속한 각 서버를 pool member라 한다. (ip + port# 로 식별)
NAT
- Network Address Translation으로 IP 패킷이 네트워크 망을 이동하면서 라우터와 같은 IP를 변형시킬 수 있는 네트워크 장비에 의해 출발지 또는 목적지 IP가 변화하는 것이다.
NAT가 필요한 이유
- 클라이언트 → L4 요청 시 L4에서 NAT로 목적지 IP를 실제 서버 IP로 변경해줘야 서버에서 패킷을 무시하지 않고 처리한다. 목적지 IP가 L4 IP라면 서버가 자신한테 온 패킷이 아니므로 해당 패킷을 무시한다.
- Source IP NAT가 필요한 이유
- Destination IP NAT (목적지 IP NAT) 뿐만 아니라 출발지 IP NAT도 필요하다.
- 서버의 gateway가(서버의 트래픽이 외부로 나가는 관문 역할) L4가 아닌 다른 스위치 (backbone switch)로 되어 있는 경우, 3 way handshake 시 클라이언트 → L4 → 서버로 syn을 보내고 syn/ack는 서버 → backbone switch → 클라이언트로 보내진다. 클라이언트가 다시 L4로 ack를 보내면 L4는 syn/ack를 받은 적이 없기 때문에 ack를 drop하게 되고 클라이언트 ↔ 서버 통신에 실패한다.
- 또는 L4가 backbone과 서버 사이에 위치하더라도 packet의 목적지 정보(IP or MAC)이 L4를 가리키는게 아닌 이상 L4는 패킷을 처리하지 않고 전달만 할 뿐이다. 따라서 L4는 마찬가지로 syn/ack를 받지 못했는데 ack를 받은걸로 인지해 ack를 drop하고 3 way handshake에 실패한다.
- 이러한 문제를 해결하기 위해 클라이언트→L4→서버로 syn을 보낼 때 L4에서 NAT을 통해 source ip와 destionation ip를 바꿔준다.
- 변경 전 { src ip : 클라이언트, dest ip : L4 } → 변경 후 { src ip : L4, dest ip : 서버}
- 서버는 syn/ack를 보낼 때 dest ip : L4이므로 굳이 backbone switch가 아닌 L4로 직접 보내게 되고, syn/ack가 L4를 거쳐가므로 L4는 이후 ack를 drop하지 않게 되고 통신에 성공한다. (L4가 backbone과 서버 사이에 위치하는 경우도 마찬가지다)
- 원래라면 L4에 도달하지 못하는 패킷을 NAT를 통해 L4에 도달하게 해 문제를 해결한다.
NAT의 단점
- 서버의 입장에서 원래의 source ip를 알 수 없다.
- http의 x-forwarded-for 같은 헤더에 원래 source ip를 넣어서 해결한다.
port translation
- L4 virtual server의 port#가 서버의 port# 와 달라서 요청이 L4 → server로 향할 때 port#가 변경되는 것
- L4 port와 같은 port#를 서버에서 사용할 수 없을 때, 서버에서 사용하는 port#를 공개하고 싶지 않을 때
- port translation이 꼭 필요한 상황이 ssl offload이다.
ssl offload
- https 통신 시 L4가 ssl 암호화/복호화를 대신해 서버의 부하를 줄여주는 것
- L4 스위치에 SSL 인증서를 위치시킨다. 클라이언트 ↔ L4 스위치가 SSL Handshake를 하고 L4 스위치 ↔ 서버는 평문으로 통신한다.
- L4스위치는 https를 위해 443 포트를, 서버는 평문이므로 80 포트를 사용한다.
L4의 핵심 기능 3가지
health check
- 부하 분산 대상인 서버의 상태를 체크하는 것
- 헬스 체크에 실패한 서버에게는 요청을 전달하지 않는다.
- interval 마다 헬스체크를 반복적으로 시도하며 timeout이 지날 때 까지 계속 실패하면 실패로 간주한다
- {interval : 5초, timeout : 16초} → 5초마다 헬스체크, 3번 실패하고 1초 지나면 실패로 간주
- interval : 너무 짧으면 서버가 잠시 응답을 못해도 실패로 판단해서 로드밸런싱에 방해, 너무 길면 실제로 다운되었음에도 헬스체크에 오래 결려 장애 발생
- 헬스 체크 방법
- TCP : L4 스위치가 서버와 3way handshake 시도 ( 성공 시 바로 fin을 날려 연결 해제함)
- HTTP : 3 way handshake 시도 + http request 전송해 응답 요구
connection & connection timeout
- Connection은 클라이언트 ↔ 서버의 논리적인 연결이다.
- L4 스위치를 통해 로드밸런싱된 경우 L4 스위치도 커넥션에 참여한다.
- 네트워크 상에 커넥션이 있는 것이 아닌 L4, 클라이언트, 서버가 각각 커넥션을 가지고 있음을 기억하는 것이다.
- L4 스위치는 부하 분산 뿐만 아니라 커넥션을 관리한다. 사용되지 않는 커넥션은 제거해 부하를 줄인다.
- 커넥션이 사용되지 않는다고 판단되면 카운트다운을 시작하고, 카운트다운이 끝나면 제거한다. 이 시점을 커넥션 타임아웃이라 한다.
persistence(sticky)
- 위 2가지와 다르게 선택 사항에 해당하는 기능이다.
- 클라이언트 ↔ 서버 커넥션이 생성되면 동시에 sticky session이 생성된다.
- 커넥션 타임아웃이 발생해 커넥션이 소멸되어도 L4는 sticky session을 유지해 클라이언트가 접속했던 서버를 기억한다. 클라이언트가 다시 접속 시도하면 과거 접속 이력이 있던 서버로 로드밸런싱 시킨다.
- sticky session이 필요한 이유
- sticky session이 없는 상황
- 클라이언트가 서버1에 접속해 요청하고 요청 처리동안 잠시 자리를 비워 L4에 의해 커넥션이 제거된다.
- 사용자가 돌아와 다시 접속했는데 L4가 서버2로 로드밸런싱 시켜서 서버1이 처리하던 정보가 없어 정상 처리가 불가하다.
- sticky session이 있는 상황
- L4가 클라이언트가 서버1에 접속했던 이력을 기억해 재접속시 서버1로 로드밸런싱 시킨다.
- sticky session이 없는 상황
- 정해진 timeout (ex : 300초) 동안 sticky session 유지
L4 사용 시 네트워크 구성
IN-LINE
- backbone switch - L4 switch - L2 switch -server 일렬로 구성
- L4 스위치 기준 대역이 분리되는 경우
- 클라이언트, 서버 모두 L4를 목적지로 해야 하며 모든 요청이 L4를 거친다
- L4가 Proxy Server로서 트래픽 이동을 제어한다.
- 모든 트래픽이 L4를 거치므로 장애 , 이슈 파악이 비교적 쉽다
- 모든 트래픽이 L4를 거치므로 L4의 부하가 크고, L4 장애시 서비스 마비 (이중화를 통한 해결 가능)
- L4 스위치 중심으로 대역이 동일한 경우
- 서버가 굳이 gateway를 L4로 잡을 필요가 없어서 패킷이 꼭 L4를 거친다는 보장이 없다
- L4가 proxy server로서의 역할을 하기 힘들다
ONE-ARM
- L4가 backbone의 옆에 위치한다.
- 요청 : 클라이언트 → backbone → L4 → backbone → 서버
- 응답 : 서버 → backbone → L4 → backbone → 클라이언트
- 인라인과 비슷하게 L4 기준 ip 대역이 나뉘게 구성할 수도, 동일하게 구성할 수도 있다.
- 인라인과 달리 L4에 장애가 발생해도 대처 가능(라우팅 설정을 바꿔서 서버와 직접통신하도록)
- backone 스위치와 l4 스위치는 각각 다른 인터페이스를 사용해 다른 IP 대역을 부여하거나 Trunk 설정으로 인터페이스 1개를 나눠 사용한다.
- 서버는 L4 혹은 backbone을 게이트웨이로 잡는다. backbone을 게이트웨이로 잡을 경우 L4에서 source ip NAT을 실시한다.
- 모든 패킷이 L4를 지나가지 않아서 ( backbone이 gateway일 경우를 말하는 것 같음) 이슈 발생 시 파악이 어렵다
DSR (Direct Server Return)
- 요청은 L4를 거치지만, 서버가 L4가 아닌 사용자에게 직접 응답하는 것을 말한다.
- response에 비해 request가 매우 적을 경우 (몇 번의 request 이후 response만 계속적으로 존재하는 경우) → response가 굳이 L4를 지나갈 필요가 없다
- response 경로가 짧아지며, L4의 부하를 줄인다.
- 인터넷 방송 등에 많이 사용 (트래픽 비중 : 사용자의 조작 << 방송 송출)
- 사용자는 L4 스위치와 커넥션을 맺었기 때문에 응답 패킷의 src ip가 L4여야 받아들인다.
- 클라이언트 → L4 → 서버로 요청을 보낼 때 L4 → 서버의 과정에서 src ip nat, src port nat을 하지 않고 L4 virtual server의 ip와 port를 destination으로 그대로 사용하며, destination mac address만을 서버의 것으로 변경하여 서버에게 전달한다.
- 패킷의 dest ip가 서버가 아니므로 서버는 이 패킷을 처리할 수 없다. 이를 해결하기 위해 서버의 Loopback Ip(자기 자신을 참조하기 위해 사용하는 ip)를 L4의 VIP와 같은 IP로 설정한다.
- 이 때, 서버에는 L4 virtual server와 충돌을 피하기 위해 2가지 설정을 해준다.
- GARP(자신의 새 ip를 broadcasting 하는 것) : 미실시
- 다른 단말이 ARP reqeust를 보냈을 때 이에 대해 ARP response를 보내지 않도록 설정합니다. (ip 주소만 알고 mac 주소를 모를 때 arp request를 보내고 , arp response로 mac 주소를 알려준다)
- 또, L4의 규칙인 L4를 통한 3-way-handshake 시 모든 과정(syn, syn/ack, ack)은 L4를 거쳐야 한다 는 규칙도 이 경우는 무시해야 한다. 그래야 L4가 ack 를 통과시켜 3 way handshake에 성공한다.
- 이 때, 서버에는 L4 virtual server와 충돌을 피하기 위해 2가지 설정을 해준다.
- 요청 ex) 동영상 재생 요청 : 클라이언트 → L4 스위치 → 서버
- 응답 ex) 동영상 송츨 : 서버 → 클라이언트
- 응답을 받을 때마다 ack : 클라이언트 → L4 스위치 → 서버
- 관련 설정 방법은 https://aws-hyoh.tistory.com/144 참고
이중화
- 고가용성 : 가용성이 높다는 뜻으로 “절대 고장나지 않음”을 의미한다.
- 이중화 : 고가용성을 위한 방법 중 하나로, 장애 후에도 기능을 유지할 수 있게 예비 장비를 운용(active-stanby) 하거나 다수의 장비를 활성화시켜 운용(active-active)한다.
- Failover : active device가 다운되면 stanby device가 이어받아 active device로 역할을 수행하는 것
- HA VLAN (고가용성 VLAN) : L4가 이중화를 맺기 위해 이중화 구성과 정보 공유만을 위해 사용하는 VLAN으로 다른 통신은 허용되지 않는다.
- Virtual IP : 2개의 L4 가 같은 VIP를 갖지만 active 상태인 L4만 VIP를 사용(GARP, ICMP Response)한다.
- VIP가 없는 상황 : 서버가 active L4로 gateway 를 설정했다가 L4에 장애가 발생해 다른 L4가 active가 된다면 서버는 gateway를 새로운 L4로 수동 설정해야 한다.
- VIP가 있는 상황 : L4의 VIP로 서버의 gateway르 설정하면 active L4가 변경되어도 서버는 할 일이 없다.
- Virtual Server IP : L4의 Virtual Server 이중화를 위해 필요하다. active, stanby server 모두 virtual server ip를 갖지만 virtual ip와 마찬가지로 active 스위치만이 GARP, ICMP Response를 한다.
출처
https://aws-hyoh.tistory.com/65
해당 시리즈 1편부터 마지막 편 까지 참고해 짧게 요약했다.
'infra' 카테고리의 다른 글
aws ec2로 spring 프로젝트 배포하기 (2) | 2024.08.18 |
---|