부하분산 Load Balancing

시작하기 전에

해당 블로그에 작성되는 글은 주인장의 지극히 주관적인 생각이 다수이며, 대부분의 지식은 구글링을 통해 얻고 있기 때문에 옳지않은 정보가 있습니다. 

잘못된 부분이나 수정해야 하는 부분이 있다면 과감히 덧글을 남겨주세요! 모르는게 많은 새싹입니다

오늘의 주제

오늘의 주제는 로드밸런싱! AWS를 이용할 계기가 생겨서 로드밸런서와 로드밸런싱에 대해 알아보던 도중 글을 작성하게 되었습니다. 간단한 내용이지만 재밋게 읽어주세요.

부하분산, 로드밸런싱(Load Balancing)이란?

컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋이상의 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미합니다. 부하를 여러대의 서버 컴퓨터가 나누어 갖기 때문에 가용성 및 응답시간을 최소화 시킬 수 있습니다. 로드 밸런싱은 트래픽의 과부하를 막기위해 가상의 아이피(Virtual IP)를 통해 여러대의 서버로 접속을 분배하는 기능을 합니다.

인터넷 서비스에서는 소프트웨어를 이용한 부하분산이 적용되며, 소프트웨어는 중간에 위치해 실제 서비스하는 서버와 클라이언트 포트를 이용해 중개한다. 내부의 네트워크 구조를 공개하지 않기 때문에 크래킹을 막을 수 있습니다.

각 계층에서 사용하는 스위치의 역할과 무엇을 기준으로 스위치 기능을 하는지는 다음과 같습니다.

L2(DataLink Layer)에서는 MAC address를 이용한 스위칭을 합니다. 외부 호스트에 접근할 수 있는 방법이 없습니다. 또한 상위 계층으로의 프로토콜 기반 스위칭이 불가능 합니다.

L3(Network Layer)에서는 IP address를 이용한 진행하며, L2 + Routing의 기능을 합니다. IP주소를 이용하기 때문에 외부망에 있는 호스트에게도 스위칭이 가능한 구조를 갖추고 있습니다.

L4(Transport Layer)는 TCP / UDP 프로토콜을 이용합니다. IP와 Port를 기반으로 한 스위칭이 발생합니다.

L7(Application Layer)에서는 IP와 Port 그리고 패킷의 내용을 통해 스위칭을 합니다.

보통 상위 계층에 있는 스위치는 하위 계층에 있는 스위칭을 지원합니다. 하지만 각 계층에는 고유의 문제점들이 존재합니다. L2, L3 장비는 요즘에는 많이 사용하는 추세는 아닌것 같아. L4와 L7 스위치에 대해서만 좀 더 상세하게 정리하였습니다. 

L4 스위치

L4 스위치의 로드 밸런서는  위와 같은 형태를 갖추고 있습니다. 중간의 스위치를 통해 각각의 서버에 접속을 분산시켜 보내주는 역할을 합니다. 트랜스포트 레이어에서 작동합니다. IP, PORT, SESSION 을 기반으로한 로드밸런싱을 담당합니다. TCP/UDP 프로토콜을 이용하며 프로토콜의 헤더를 보고 로드 밸런싱을 수행 한다고 합니다. 주로 Round Robin 방식을 이용하여 부하를 분산합니다.

눈 크게 뜨고, 그림을 봅시다. (O_O)

DSR(Direct Server Return) 모드

L4가 양방향 프록시라면 모든 웹서버가 받는 트래픽을 L4가 다 받야아 합니다. DSR 기능은 응답시 L4 스위치를 거치지 않고 출발지 IP로 다이렉트하게 응답하여 줍니다. L4 스위치에서 제공하는 DSR 기능을 통해서 스위치는 양방향에서 발생하는 모든 트래픽을 받는게 아닌 클라이언트에서 발생한 트래픽만 처리해주게 됩니다.

NAT(Network Access Traslation)

- TCP/UDP 포트 숫자와 소스 및 목적지 IP주소등을 재기록하여 라우터를 통해 네트워크 트래픽을 주고 받는 기술입니다.

- 사설 네트워크에 속한 여러개의 호스트가 하나의 공개 IP를 통해 접속하는 것을 목적으로 합니다.

L4 스위치의 사용이 적절한 경우와 적절하지 않은 경우입니다.

적절한 경우는 다음과 같아요

- 요청 패킷이 적은 경우

- 일반적인 웹 요청의 경우

- 파일 다운로드의 경우

다음 경우는 적절하지 못합니다.

- 요청 패킷이 많은 경우

- 파일 업로드와 같은 웹 요청의 경우

- SMTP

L7 스위치

어플리케이션 레이어에서 동작하는 스위치 입니다. 이메일의 제목이나, HTTP의 URI, FTP의 파일명,

쿠키정보, 플레이로드 정보 등을 분석(패킷의 정보를 이용하여 원하는 장비나 서버로전송을 합니다) 좀 더 정교한 로드밸런싱이 가능 합니다.

L7 스위치는 L4 스위치보다 보안적으로 우수합니다. 데이터 분석을 통해 DDoS 공격 방어가 가능하고, 감염 패킷의 필터링이 가능합니다.

주요기능

- 전송제어 : IP 헤더 및 페이로드 등 패킷을 분석

- 로드밸런싱 : HTTP, URL 등 컨텐츠 내용 기반 부하분산

- Qos : 세션별, 유저별, 애플리케이션별 대역 관리

- 모니터링: 응용 프로그램 수준의 트래픽 감시 및 통제

L4와 L7 스위치 차이점

L4 스위치의 세션 유지 방식은 다음과 같습니다.

L4 스위치에서의 세션관리는 스위치가 담당합니다. 패킷을 확인하고 연결될 서버와 세션을 생성합니다. 그렇다면 "서버가 여러 대인 경우에는 어떻게 세션을 유지하지?" 예를들어, 서버가 총 3대가 있는 상황이라면 처음 연결시 1번 서버와 연결되고 그 다음 요청시 또 다시 1번 서버와 연결 될 확률은 33.33% 입니다. 같은 서버에 지속적으로 연결되지 않기 때문에 세션의 유지가 이루어 지지 않는다. 이런 경우엔 어떻게 해야할까? L4 스위치에서는 "sticky session" 이라는 기능을 제공합니다. 해당 기능을 사용하면 "A사용자가 처음 1번 세션을 생성한 경우 일정시간의 timeout 동안 해당 서버에 추가적인 연결을 시켜 줍니다." 

잠깐! 

여기에도 문제점이 발생합니다. 프록시 서버가 있는 경우에는 외부망으로 통신이 이루어질 때 프록시 서버의 IP를 가지고 통신이 이루어지기 때문에  같은 내부망에 있는 여러사람이 같은 외부 망에 지속적으로 요청을 할 경우 한 서버에 트래픽이 몰릴 수 있다. 모두 같은 프록시의 IP를 통해 요청이 외부로 날아가기 때문이다. 하지만 여기서 Cookie를 사용하면 문제를 적절하게 해결 가능하다.

L7 스위치의 세션 관리 방식은 다음과 같습니다.

L7 스위치는 Client - Switch의 세션과 Switch - Server의 세션을 각각 맺어 두 세션을 연결시켜 관리합니다. 

L7 스위치는 "URL 스위칭 방식"과 "Cookie 스위칭 방식"을 사용하여 부하를 분산합니다.

"URL 스위칭"은 URL 주소를 확인하여 설정에 알맞은 서버로 부하를 분산하는 방식입니다.

저의 경우는 음... 일반 API를 처리하는 서버와 이미지를 처리하는 서버를 따로 분리해 두었었는데,

1. base-url/image

2. base-url/api 

위의 두가지 경우를 로드 밸런서가 스위칭 해주는 방식으로 이용했던 경험이 있습니다.

"Cookie 스위칭"은 HTTP Header의 cookie값 설정에 따라 스위칭할 서버를 결정합니다. 

그리고 마지막으로 새로 추가된 "L7 Content 스위칭"도 있다고 합니다.

이름 처럼 Content의 내용을 기반으로 스위칭이 발생하는 구조인데요, HTTP의 Header와 XML content를 기반으로 스위칭의 타겟이 결정된다고 합니다. 또한 Cookie와 HTTP header의 insertion과 delete를 포함한 contents-rewrite도 지원하며, 도메인의 redirecting request 또한 지원합니다.

L4/L7 스위치의 성능 지표
- 초당연결수(connections per second) : (3 Way Handshake를 통한) TCP 세션 open의 시간당 처리 개수
- 동시연결수(concurrent connections) : 동시 세션 유지 개수
- 처리용량(throughput) : (패킷 자체에 대해 연결이 성립되는) UDP 프로토콜에 대한 로드밸런싱 성능 지표. FWLB에서 중요. 단위는 bps(bit per second) 또는 pps(packet per second)를 사용.

이렇게 로드밸런서가 무엇인지 알아보고, 많이 쓰이는 L4와 L7 로드밸런서에 대해서 알아 보았습니다. 예전에 작성했던 포스팅을 수정하여 다시 작성했는데 생각보다 양이 많아서 오래걸리기도 되게 오래 걸렸네요. 포스팅을 읽고 같이 공부하도록 합시다! ( _ _ )