[Network] Extra. 로드 밸런싱

KYJ의 Tech Velog·2023년 4월 28일
0

Network

목록 보기
19/21
post-thumbnail

Load Balancing

로드 밸런싱(Load Balancing)은 컴퓨터 네트워크 기술의 일종으로 컴퓨터 자원들에게 작업을 나누는 것을 의미합니다. 즉, 여러 서버가 분산 처리 하는 것을 로드 밸런싱이라고 합니다.

로드 밸런서는 로드 밸런싱 기술을 제공하는 서비스 또는 장치입니다.

L4 Load Balancer

전송 계층에서의 로드 밸런서는 IP 주소, 포트 번호, MAC 주소, 전송 프로토콜 등에 따라 부하를 분산합니다. 클라이언트에서 로드 밸런서로 요청을 보냈을 때 최적의 서버로 요청을 전송하고 결과를 클라이언트에게 전해줍니다.

L7 Load Balancer

응용 계층에서의 로드 밸런서는 L4 로드 밸런서의 기능을 포함하고 응용 계층의 프로토콜에 따라 부하를 분삽합니다.

L4 로드 밸런서는 단지 부하를 분산시키는 것입니다. L7 로드 밸런서는 요청의 세부적인 사항을 두고 여러 서버로 분리해서 가볍고 작은 단위로 여러 개의 서비스를 운영하고 요청을 각각의 서버에 분산할 수 있습니다.

L7 로드 밸런서는 L4 로드 밸런서와 다르게 데이터를 분석해서 처리가 가능하기 때문에 악의적이거나 비정상적인 콘텐츠를 감지해 보안 지점을 구축할 수 있다는 장점이 있습니다. 다만, 자원 소모가 크다는 단점이 있습니다.

Load Balancing Algorithm

Round Robin

클라이언트로부터 받은 요청을 로드밸런싱 대상 서버에 순서대로 할당받는 방식입니다. 첫 번째 요청은 첫 번째 서버, 두 번째 요청은 두 번째 서버에 할당합니다. 서버의 성능이 동일하고 처리 시간이 짧은 애플리케이션의 경우, 균등하게 분산이 이루어지기 때문에 이 방식을 사용합니다.

Weighted Round Robin

서버에 서로 다른 처리 용량을 지정할 수 있습니다. 각 서버에 가중치를 부여할 수 있으며, 지정한 정수값을 통해 처리 용량을 정합니다.

IP Hash

클라이언트 IP 주소를 숫자로 변환한 다음 개별 서버에 매핑하는 방식입니다.

최소 연결

클라이언트는 서버에 첫 번째 요청을 전송할 때 서로 연결을 인증하고 설정합니다. 로드 밸런서는 연결이 가장 적은 서버를 확인하고 해당 서버로 트래픽을 전송합니다. 이 방식은 모든 연결에 대해 모든 서버가 동일한 처리 능력이 필요하다고 가정합니다.

가중치 기반 최소 연결

일부 서버가 다른 서버보다 더 많은 연결을 처리할 수 있다고 가정합니다. 각 서버에 다른 가중치 또는 용량을 할당할 수 있으며, 로드 밸런서는 용량별 연결이 가장 적은 서버로 새 클라이언트 요청을 전송합니다.

최소 응답 시간

서버 응답 시간과 연결을 결합하여 최상의 서버를 결정합니다.

리소스 기반

서버 부하를 분석하여 트래픽을 배포합니다. 에이전트라고 하는 특수 소프트웨어는 각 서버에서 실행되며 컴퓨팅 용량 및 메모리와 같은 서버 리소스의 사용량을 계산합니다. 그런 다음 로드 밸런서는 해당 서버에 트래픽을 배포하기 전에 에이전트에 충반한 여유 리소스가 있는지 확인합니다.

DNS

별도의 소프트웨어 혹은 로드밸런서를 사용하지 DNS를 사용하여 로드 밸런싱이 가능합니다. 바로 Round Robin DNS 입니다.

웹 서버로 예시를 들어서 설명드리겠습니다. 웹 서비스를 담당할 여러 서버는 각각 자신의 공인 IP를 가지고 있습니다. 웹 사이트에 접속을 원하는 사용자가 해당 도메인 주소를 브라우저에 입력하면 DNS는 도메인의 정보를 조회합니다. 이 때 IP 주소를 여러 서버 IP 리스트 중에서 라운드 로빈 형태로 랜덤하게 하나 혹은 여러 개를 선택하여 사용자에게 알려줍니다.

결과적으로 웹 사이트 접속하는 다수의 사용자는 실제로는 복수의 웹 서버에 나뉘어 접속하게 되면서 서버의 부하가 분산됩니다.

단점은 서버의 상태를 확인하는 과정이 없습니다. 따라서 특정 서버에 문제가 생겨 서비스가 불가한 상태더라도 DNS는 이를 알 방법이 없고 해당 서버의 공인 IP를 도메인 조회 결과에 포함시킨다는 단점이 있습니다.

캐싱에 관련된 단점도 있습니다. 조회된 IP 주소들은 DNS Resolver나 클라이언트 애플리케이션에 캐싱이 될 수 있습니다. 캐싱 주기(TTL) 동안에는 동일한 도메인에 대해서는 캐싱된 IP 주소를 활용합니다. 따라서, 도메인 설정 작업을 할 때엔 캐시 주기 설정을 고려해야 합니다. 캐싱 주기를 무조건 길게 하면 관리자가 급하게 DNS 정보를 바꿔도 인터넷 상에서 적용되려면 해당 시간 이상으로 기다려야 합니다. 바뀐 DNS 정보가 인터넷 상의 네임 서버에 전파되는데 오랜 시간이 걸리기 때문입니다. 반대로 캐싱 주기를 짧게 하면 빠른 업데이트 반영은 가능하지만, 도메인 조회가 빈번해지면서 사용자가 웹 사이트에 접속하는 데 필요한 시간 증가합니다.

0개의 댓글