시스템 설계 기본 :로드 밸런서 101

인기 사이트가 엄청난 수의 요청을 처리하는 방법

Unsplash에 JOSHUA COLEMAN의 사진

시스템 설계는 소프트웨어 엔지니어링 의 가장 중요한 개념 중 하나입니다 . 어소시에이트 아키텍처 과정을 시작했을 때 시스템 설계 방법을 이해하기가 어려웠습니다. 주요 문제점 중 하나는 시스템 설계 리소스에서 사용되는 용어가 처음에는 이해하기 어렵다는 것입니다.

이 기사에서는 시스템 설계의 중요한 주제 인 Load Balancer를 검토합니다. 여기에서 서버 선택의 특성과 기술에 대해 알 수 있습니다. 시스템 설계의 기본 개념과 용어를 숙지하면 시스템 설계에 큰 도움이됩니다.

로드 밸런서

로드 밸런서는 모든 분산 시스템의 핵심 구성 요소입니다. 응용 프로그램 또는 웹 사이트의 응답 성과 가용성을 향상시키기 위해 서버 클러스터 내에서 클라이언트 요청을 배포하는 데 도움이됩니다.

Wikipedia에 따르면 " 부하 분산은 리소스 집합에 작업 집합을 배포하는 프로세스를 의미합니다.

작성자 별 이미지

예를 들어 한 서버가 동시에 많은 요청을 처리 할 수없는 경우로드 밸런서가 필요합니다. 주요 목적은 각 작업의 응답 시간을 최적화하는 것입니다. 이제 시스템에 클라이언트 요청으로 오버로드 된 서버가 하나 있다고 가정 해 보겠습니다. 서버에는 초당 요청 처리 제한이 있습니다. 따라서 대량의 요청을 처리하려면 더 많은 서버를 추가해야합니다. 그러나 서버 간의로드 균형을 맞추기 위해로드 밸런서가 필요할 수 있습니다.

로드 밸런서는 일반적으로 클라이언트 장치와 서버 세트 사이에 위치하며 서버간에 클라이언트 요청을 분배하는 서버입니다. 로드 밸런서는 시스템의 다양한 위치에 배치 할 수 있습니다. 서버의로드는 균형 잡힌 방식으로 분산되어야합니다. 이것이로드 밸런서라고 불리는 이유입니다.

그림 1 :로드 밸런서를 추가하여 클라이언트 요청을 여러 서버에 배포 (작성자 별 이미지)

따라서로드 밸런싱은 클라이언트 요청을 여러 리소스에 분산시키는 프로세스라고 말할 수 있습니다. 서버가 새 요청을 처리 할 수 ​​없거나 응답하지 않는 경우 LB는 해당 서버에 대한 요청 전송을 중지합니다.

이미 알고 있듯이로드 밸런서는 서버 과부하를 방지합니다. 로드 밸런서의 또 다른 필수 작업은 서버에서 요청을 처리 할 수 ​​있는지 확인하기 위해 지속적인 상태 확인을 수행하는 것입니다. 사용자 요청의 균형을 조정하여 시스템 리소스를 더 잘 사용할 수 있습니다. 시스템 설계에서 수평 확장은 사용자가 많은 경우 시스템을 확장하는 일반적인 전략입니다. 로드 밸런서는 수평 확장을위한 솔루션입니다. 시스템의 수신 트래픽 균형을 조정하여 LB는 서버가 과부하되는 것을 방지합니다. 또한 시스템의 전반적인 처리량을 향상시킵니다. 요청이 차단되지 않고 사용자가 요청이 처리 될 때까지 기다릴 필요가 없으므로 지연 시간이 더 적게 발생해야합니다.

로드 밸런서는 두 가지 유형의 하드웨어 LB와 소프트웨어 LB가 될 수 있습니다. 이 기사에서는 소프트웨어로드 밸런서에 중점을 둡니다.

로드 밸런서는 어디에서 사용합니까?

일반적으로 들어오는 네트워크 요청을 처리하기 위해 클라이언트와 서버 사이에로드 밸런서를 배치 할 수 있습니다. LB의 또 다른 매우 일반적인 용도는 네트워크 트래픽을 백엔드 서버에 분산하는 것입니다. 로드 밸런서는 개별 서버로드를 줄이는 데 사용됩니다. 또한 모든 서버에 대한 단일 장애 지점을 방지합니다. 따라서 시스템의 전반적인 가용성과 응답 성을 향상시킵니다. 시스템의 다양한 위치에 LB를 추가 할 수 있습니다. 특히 서버, 데이터베이스 또는 캐시와 같은 여러 리소스가있는 경우.

로드 밸런싱을 사용하는 이유 :

시스템 설계 구성 요소의 경우 구성 요소를 사용하는 이유와시기를 아는 것이 가장 중요합니다. 로드 밸런싱은 시스템의 가용성 및 전체 처리량의 경우 중요한 구성 요소입니다. 다음은로드 밸런싱 사용의 몇 가지 예입니다.

  • 시스템을 설계 할 때 주요 관심사 중 하나는 더 빠른 사용자 경험과 중단없는 서비스를 만듭니다. 사용자 요청은 이전 작업을 완료하지 않은 단일 서버를 기다리지 않아야합니다. 이 경우 클라이언트 요청은 즉시 응답 가능한 사용 가능한 서버로 배포됩니다. 이때로드 밸런서를 사용해야합니다. 여러 리소스 간의 작업 균형을 맞 춥니 다. 그림 1은 이러한 예입니다.
  • 가용성은 분산 시스템의 핵심 특성입니다. 전체 서버 오류 시나리오의 경우로드 밸런서가 클라이언트 요청을 정상적인 서버로 전송하기 때문에 사용자 경험에 영향을 미치지 않습니다.
  • 로드 밸런서에서 예측 분석을 사용하여 트래픽 병목 현상이 발생하기 전에 파악할 수 있습니다. 비즈니스 결정을 내리는 데 도움이 될 수 있습니다.
  • 단일 리소스가 많은 작업을 수행하는 대신로드 밸런싱은 여러 장치가 견딜 수있는 양의 작업을 수행하도록합니다.
  • 로드 밸런서의 또 다른 작업은 분산 서비스 거부 (DDoS) 공격으로부터 시스템을 보호하는 것입니다. 소프트웨어로드 밸런서는 DoS 공격으로부터 효율적이고 비용 효율적인 보호를 제공 할 수 있습니다.

로드 밸런서가 여러 서버 중에서 백엔드 서버를 선택한다는 것을 알고 있습니다. 서버를 어떻게 선택합니까? 클라이언트 요청을 서버로 전달하기 전에로드 밸런서가 고려하는 두 가지 주요 요소가 있습니다.

  1. 첫째,로드 밸런서는 선택한 서버가 응답하는지 확인해야합니다. 요청에 응답하고 있음을 의미합니다.
  2. 둘째, LB는 사전 구성된 알고리즘을 사용하여 응답 성이 좋은 정상 서버 세트에서 하나를 선택합니다.
그림 :로드 밸런서에 의한 상태 확인 (작성자 별 이미지)

로드 밸런싱 기술 :

다양한 유형의 부하 분산 방법이 있습니다. 모든 유형은 다른 목적을 위해 다른 알고리즘을 사용합니다. 이러한 기술은 실제로 서버 선택을위한 다른 유형의 전략입니다. 다음은 부하 분산 기술 목록입니다.

  • 무작위 선택 : 이 방법에서는 서버가 무작위로 선택됩니다. 서버 선택시 계산 된 다른 요소는 없습니다. 유휴 상태에있는 일부 서버에 문제가있을 수 있으며 일부는이 기술의 요청으로 오버로드됩니다.
  • 라운드 로빈 : 이것은 가장 일반적인로드 밸런싱 방법 중 하나입니다. LB가 서버 집합간에 들어오는 트래픽을 특정 순서로 리디렉션하는 방법입니다. 그림 2를 확인하십시오. 5 개의 서버 목록이 있습니다. 첫 번째 요청은 서버 1로 이동하고 두 번째 요청은 서버 2로 이동하는 식입니다. LB가 목록 끝에 도달하면 서버 번호 1부터 처음부터 다시 시작됩니다. 서버 간의 트래픽 균형을 거의 균등하게 유지합니다. 그러나이 방법에서는 서버 사양을 고려하지 않습니다. 이 방법이 유용하려면 서버의 사양이 동일해야합니다. 그렇지 않으면 처리 능력이 낮은 서버가 높은 처리 용량 서버와 동일한 부하를 가질 수 있습니다.
그림 2 :로드 밸런싱을위한 라운드 로빈 방법 (작성자 별 이미지)
가중 라운드 로빈 방법 : 이전에 설명한 라운드 로빈 방법의 업데이트 된 버전입니다. 이전보다 조금 더 복잡합니다. 이 방법은 일반적인 라운드 로빈에서 문제였던 다른 특성을 가진 서버를 처리하도록 설계되었습니다. 가중치는 각 서버에 할당됩니다. 이 가중치는 서버의 처리 능력에 따라 달라지는 정수 값일 수 있습니다. 더 높은 처리 서버는 더 강력한 리소스를 활용하기 위해 더 많은 연결을 얻습니다. 따라서 여기서 트래픽 리디렉션은 서버의 처리 능력에 따라 달라집니다. 최소 연결 : 여기서로드 밸런서는 클라이언트 요청이 수신 될 때 활성 연결이 가장 적은 서버로 트래픽을 보냅니다. 서버가 긴 계산으로 바쁘고 클라이언트와 서버 간의 연결이 더 오랜 기간 동안 활성 상태 인 경우이 방법이 유용합니다. 최소 응답 시간 : 이 알고리즘은 최소 활성 연결과 최소 응답 시간 (평균)을 가진 서버로 클라이언트 요청을 보냅니다. 가장 빠르게 응답하는 백엔드 서버는 다음 요청을받습니다. Source IP Hashing : 이 방법에서는 클라이언트의 서버를 선택하는 데 사용되는 클라이언트 IP 주소의 해시가 생성됩니다. 연결이 끊어져도 클라이언트의 다음 요청은 여전히 ​​동일한 서버로 이동합니다. 따라서이 방법은 연결이 끊긴 후에도 여전히 활성 상태 인 세션에 클라이언트를 연결해야하는 상황에서 사용할 수 있습니다. 캐시 적중을 최대화하고 성능을 향상시킬 수 있습니다.

로드 밸런서의 임무는 들어오는 클라이언트 트래픽을 여러 백엔드 서버에 분산시키는 것입니다. 부하 분산은 사용자의 대기 시간을 줄입니다. 시스템을 확장 할 때 수평 확장의 경우 중요한 구성 요소입니다. 추가하거나 제거하는 서버가 많을수록로드 밸런서가 있으면 변경 사항을 유지하는 데 도움이됩니다. 새 서버가 추가되거나 서버 풀에서 서버가 제거되면로드 밸런서를 업데이트해야합니다. 그렇지 않으면 자원 낭비이거나 일부 요청이 처리되지 않을 수 있습니다. 시스템을 설계 할 때 시스템의 필요에 따라 서버 선택 전략을 선택해야합니다.

리소스 : Grokking the System Design Interview, 부하 분산 기술

이 기사는 초보자를위한 일련의 시스템 설계의 일부입니다. 다음은 기사 목록입니다.

시스템 설계 기사

Suggested posts

데이터 포인트가 얼마나 극단적입니까?

특이 치 및 모델 선택

데이터 포인트가 얼마나 극단적입니까?

이상치 및 모델 선택 회귀를 실행할 수있는 것은 하나이지만 올바른 모델과 올바른 데이터를 선택할 수 있다는 것은 또 다른 문제입니다. 곡선의 맨 끝에있는 데이터 포인트가 실수로 여분의 제로 (인간 오류)를 기록한 사람 또는 블랙 스완 이벤트 (드물지만 중요한 이벤트)에서 가져온 것임을 어떻게 알 수 있습니까? 회귀 모델에 유지하면서 여전히 작동하는 예측을 가질 수 있습니까? 이 기사에서 알아 보자.

Express.js 시작하기

Express.js 시작하기

Express는 웹 및 모바일 앱을 만드는 경험을 즐겁게 만드는 기능 세트가 포함 된 Node.js 프레임 워크입니다.

Related posts

백엔드 개발을 배우기위한 10 가지 최고의 튜토리얼

프로그래밍은 당신이 아는 것에 관한 것이 아닙니다. 그것은 당신이 알아낼 수있는 것에 관한 것입니다.

백엔드 개발을 배우기위한 10 가지 최고의 튜토리얼

"더 나은 오류 메시지를 작성하지 말고 필요하지 않은 코드를 작성하십시오." — Jason McDonald Backend Development — 대부분 웹, 소프트웨어 또는 앱에서 모든 것이 작동하는 방식에 관한 것입니다. 대부분은 애플리케이션 작동 방식의 중추입니다.

엔트리 레벨 소프트웨어 엔지니어로서 배운 5 가지

엔트리 레벨 소프트웨어 엔지니어로서 배운 5 가지

코딩과 기술력뿐만 아니라 3 년 전, 저는 사물이 어떻게 생겼을 지에 대한 수많은 가정과 기대를 가지고 기업 세계에 처음 발을 들여 놓았습니다. 내가 얼마나 잘못이 증명 될지 거의 알지 못했습니다.

소프트웨어 개발에서“단순한 것”이 빠르게 복잡 해지는 방법

소프트웨어 개발에서“단순한 것”이 빠르게 복잡 해지는 방법

"자동화되기를 바라는이 사소한 것이 있습니다."— 사소한 일이 아닐 것임을 알고 이것을 얼마나 자주 듣지 못했습니까? 아니면 당신이 더 잘 알면서도 직접 말 했나요? 왜 단순한 것들은 소프트웨어 개발에서 결코 단순하지 않고, 여기저기서 몇 가지 작은 것들이 빠진 것과 당신이 만들어야했던 몇 가지 지름길을 아는 것에 대한 좌절없이 우리가 기능을 "적절하게"구현하는 것을 방해하지 않는가? 프로젝트의 다음 기한을 잡을 수있을만큼 모든 것이 제대로 작동하도록하려면? Europe Elects의 다른 사람들과 함께 여러 유럽 국가의 여론 조사에서 주요 데이터를 수집하는 약간의 취미 프로젝트가 있습니다. 이 프로젝트에서는 모든 정보를 수집 할 수있는 인프라를 설정해야합니다.

해독 : 얻을 수없는 테스트 안정성 (아니면?)

해독 : 얻을 수없는 테스트 안정성 (아니면?)

Detox는 모바일 앱용 그레이 박스 테스트 솔루션으로, 테스트 코드와 앱 간의 동기화를 관리하므로 사용자가 수동으로 수행 할 필요가 없습니다. 사용자의 필요와 풍부한 문서 및 가이드가 없어도 개발자와 테스터는 여전히 사용 패턴, 잘못된 구성, 열악한 테스트 안정성으로 어려움을 겪을 수 있습니다.