개인이든 직업이든, 그리고 앱이 비즈니스일 때 단순한 커뮤니케이션 이상의 용도로 앱을 사용할 때 오늘날처럼 애플리케이션의 가용성이 심각하게 고려된 적이 없습니다.
지속적으로 온라인 상태가 아니거나 불안정한 응용 프로그램은 사용자와 관련성을 잃고 결국 쓸모 없게 됩니다. 그것은 순식간에 일어났다. 인터넷은 잠을 자지 않고 하루 24시간 작동하기 때문에 앱에도 동일한 아이디어가 적용되어야 합니다.
확장성은 이를 수행하고 애플리케이션 가용성을 보장하는 데 중요합니다. 로드 밸런싱은 가용성을 보장하는 가장 중요한 구성 요소 중 하나입니다. 많은 사람들은 여전히 간단한 스크립트로 로드 밸런싱을 수행할 수 있다고 믿습니다.
그러나 이것은 사실이 아닙니다. 언제 어디서나 모든 장치에서 전 세계의 프로그램에 액세스할 수 있습니다.
이 게시물에서는 로드 밸런싱, 그 알고리즘, 그리고 무엇보다도 이것이 마이크로서비스와 어떻게 관련되는지 자세히 살펴볼 것입니다. 의 시작하자!
로드 밸런싱이란 무엇입니까?
웹사이트 또는 비즈니스 애플리케이션에 대한 수요가 증가함에 따라 단일 서버는 곧 전체 로드를 처리할 수 없게 됩니다. 조직은 수요를 충족시키기 위해 워크로드를 수많은 서버에 분산합니다. "로드 밸런싱"이라고 하는 이 방법은 단일 서버에 과부하가 걸리는 것을 방지하여 속도를 늦추거나 요청을 중단하거나 충돌을 일으킬 수 있습니다.
로드 밸런싱은 리소스 과부하로 인한 장애를 피하기 위해 네트워크 트래픽을 균등하게 분배합니다. 이 방법을 사용하면 응용 프로그램, 웹 사이트, 데이터베이스 및 기타 컴퓨터 리소스가 더 잘 수행되고 더 많이 사용할 수 있습니다. 또한 사용자 요청을 적절하고 시기 적절하게 처리하는 데 도움이 됩니다.
사용자의 관점에서 로드 밸런싱은 클라이언트와 서버 모음 사이에서 보이지 않는 중개자 역할을 하여 연결 요청이 삭제되지 않도록 합니다. 로드 밸런싱 없이 수요가 너무 많아지면 애플리케이션, 웹 사이트, 데이터베이스 및 온라인 서비스가 붕괴될 가능성이 높습니다.
수십만 개의 사용자 요청을 동시에 트래픽이 많은 단일 웹 사이트로 보낼 수 있습니다. 텍스트, 이미지, 비디오 및 오디오 스트리밍과 같은 요청된 콘텐츠로 웹 페이지를 올바르게 채우려면 여러 서버가 필요합니다. 부하 분산은 일반적으로 트래픽이 많은 웹 사이트 서버 팜과 DNS 서버, 데이터베이스 및 FTP(파일 전송 프로토콜) 사이트에서 사용됩니다.
단일 서버에 과부하가 걸리면 제대로 작동하지 않거나 충돌할 수도 있습니다. 로드 밸런서는 사용자 요청을 여러 서버에 고르게 분산시켜 가동 중지 시간을 줄입니다. 그룹의 서버 중 하나에 장애가 발생하면 트래픽이 그룹의 다른 서버로 다시 라우팅됩니다. 로드 밸런서는 서버 풀에 추가될 때 트래픽 분산 프로세스에서 새 서버를 자동으로 추가합니다.
로드 밸런싱은 어떻게 작동합니까?
다음과 같이 작동합니다.
- 클라이언트는 브라우저나 애플리케이션을 통해 요청을 받으면 서버에 연결을 시도합니다.
- 로드 밸런서는 요청을 받으면 알고리즘(또는 팜)에 의해 설정된 패턴을 기반으로 서버 그룹의 서버 중 하나로 라우팅합니다.
- 서버는 연결 요청을 수신하고 로드 밸런서를 통해 클라이언트에 응답합니다.
- 로드 밸런서는 응답을 받으면 클라이언트의 IP 주소를 선택한 서버의 IP 주소와 일치시킵니다. 그런 다음 패킷과 함께 응답이 전송됩니다.
- SSL 오프로드는 보안 소켓 레이어 암호화 프로토콜을 사용하여 서버에서 필요하지 않도록 데이터를 해독하는 프로세스입니다.
- 세션이 끝날 때까지 프로세스가 반복됩니다.
부하 분산 방법
서버 팜의 서버 중 다음 요청을 수신할 서버를 선택하기 위해 각 부하 분산 기술은 일련의 기준을 사용합니다. 로드 밸런싱에는 다섯 가지 일반적인 접근 방식이 있습니다.
- 원형으로 서명한 청원서: 이것이 기본 접근 방식이며 들리는 대로 작동합니다. 로드 밸런서는 그룹의 첫 번째 서버에서 시작하여 맨 아래로 진행하여 다시 호출될 때까지 대기하는 순환 패턴으로 요청을 분산합니다. 이 방법을 사용하면 각 서버가 거의 동일한 수의 연결을 처리할 수 있습니다.
- 가중 라운드 로빈: 이 접근 방식은 일반적으로 용량에 비례하는 가중치(또는 기본 설정)를 각 서버에 할당합니다. 서버가 수신하는 요청이 많을수록 가중치가 높아집니다. 예를 들어 가중치 값이 XNUMX인 서버는 가중치 값이 XNUMX인 서버보다 두 배 많은 요청을 받습니다.
- 고정 세션: 세션 지속성이라고도 하는 이 접근 방식은 세션 기간 동안 특정 클라이언트와 서버를 연결합니다. 링크를 설정하기 위해 로드 밸런서는 쿠키 또는 사용자의 IP 주소를 사용하여 사용자 속성을 식별합니다. 연결이 설정되면 세션이 종료될 때까지 사용자의 요청이 동일한 서버로 전달됩니다. 이는 네트워크 리소스를 최적화하는 동시에 사용자 경험을 개선합니다.
- 최소 연결: 이 전략은 모든 요청이 동일한 서버 부담을 초래한다고 가정합니다. 결과적으로 요청 수가 가장 적은 서버가 다음 요청을 받습니다.
- IP 해시: 이 알고리즘은 클라이언트와 서버의 소스 및 대상 IP 주소를 기반으로 고유한 해시 키를 생성합니다. 키는 요청을 라우팅하는 데 사용되며 동일한 서버와의 끊긴 연결을 재개할 수 있습니다.
하드웨어 대 소프트웨어 로드 밸런서
하드웨어 로드 밸런서
어플라이언스와 같은 물리적 하드웨어는 하드웨어 로드 밸런서를 구성합니다. 이는 기존 연결 수, 프로세서 사용량 및 서버 성능과 같은 요인에 따라 트래픽을 서버로 라우팅합니다. 하드웨어 로드 밸런서에는 새 버전 및 보안 수정 사항이 제공될 때 유지 관리하고 업데이트해야 하는 독점 펌웨어가 있습니다.
하드웨어 로드 밸런서는 종종 Kerberos 인증 및 SSL 하드웨어 가속과 같은 광범위한 기능뿐만 아니라 더 높은 성능과 제어를 제공하지만 일정 수준의 관리 및 유지 관리 전문 지식이 필요합니다. 하드웨어 로드 밸런서는 소프트웨어 로드 밸런서보다 유연성과 확장성이 떨어지므로 하드웨어 로드 밸런서를 과도하게 프로비저닝하는 경향이 있습니다.
소프트웨어 로드 밸런서
소프트웨어 로드 밸런서는 일반적으로 하드웨어 로드 밸런서보다 설정하기 쉽습니다. 또한 비용 효율적이고 적응력이 뛰어나며 소프트웨어 개발 환경과도 잘 작동합니다. 소프트웨어 방법을 사용하면 환경의 정확한 요구 사항에 맞게 로드 밸런서를 사용자 지정할 수 있습니다. 유연성이 향상되면 로드 밸런서를 설정하는 데 추가 시간이 소요될 수 있습니다.
소프트웨어 밸런서는 더 폐쇄적인 접근 방식을 사용하는 하드웨어보다 수정 및 업데이트를 수행할 수 있는 더 큰 유연성을 제공합니다. 사전 패키징된 가상 머신은 소프트웨어 부하 분산 장치(VM)로 사용할 수 있습니다. 가상 머신을 사용하면 설정 시간을 절약할 수 있지만 해당 하드웨어에서 사용할 수 있는 모든 기능이 없을 수도 있습니다.
간단한 로드 밸런싱 구현
Spring Cloud 라이브러리를 사용하여 앱 빌드 부하 분산 방식으로 다른 앱에 연결합니다. 원격 서비스 요청을 처리하는 동안 원하는 기술을 사용하여 로드 밸런싱을 쉽게 구성할 수 있습니다. 다음 코드를 예로 들어 보겠습니다. 기본적인 서버 애플리케이션부터 시작하겠습니다.
서버에는 HTTP 엔드포인트가 하나만 있으며 여러 인스턴스에서 작동됩니다. 그런 다음 Load Balancer를 사용하여 여러 서버 인스턴스에 요청을 분산하는 클라이언트 앱을 빌드합니다.
서버
우리는 기본으로 시작합니다 봄 부팅 예제 서버용 애플리케이션:
시작하려면 instance_ID라는 사용자 지정 가능한 변수를 삽입합니다. 이것은 작동 중인 수많은 인스턴스를 구별하는 데 도움이 됩니다. 그런 다음 메시지와 인스턴스 ID를 반환하는 단일 HTTP GET 끝점을 만듭니다.
ID가 1인 기본 인스턴스는 포트 8080에서 작동합니다. 두 번째 인스턴스를 시작하려면 몇 가지 프로그램 매개변수만 추가하면 됩니다.
Client
이제 클라이언트 코드를 살펴보겠습니다. 여기에서 Load Balancer가 필요하므로 애플리케이션에 통합하여 시작하겠습니다.
그런 다음 ServiceInstanceListSupplier의 구현을 개발합니다. 이것은 Load Balancer에서 가장 중요한 인터페이스 중 하나입니다. 액세스 가능한 서비스 인스턴스를 찾는 방법을 지정합니다.
샘플 애플리케이션에서 예제 서버의 두 개의 개별 인스턴스를 하드 코딩할 것입니다. 동일한 시스템에서 실행되지만 별도의 포트를 사용합니다.
지금 LoadBalancerConfiguration 클래스를 만듭니다.
이 클래스는 단 하나의 목적을 가지고 있습니다. 원격 요청을 만들기 위한 로드 밸런싱된 WebClient 빌더를 생성합니다. 우리의 주석은 서비스에 가상의 이름을 사용합니다.
이는 인스턴스를 실행하기 위한 정확한 호스트 이름과 포트를 미리 알지 못할 가능성이 높기 때문입니다. 결과적으로 가상의 이름을 자리 표시자로 활용하고 프레임워크는 실행 중인 인스턴스를 선택할 때 실제 정보를 대체합니다.
다음으로 서비스 인스턴스 공급을 인스턴스화하는 데 사용할 구성 클래스를 만들어 보겠습니다. 이전과 동일한 별칭을 사용합니다.
이제 실제 클라이언트 애플리케이션을 빌드할 수 있습니다. 이전의 WebClient 빈을 사용하여 샘플 서버에 10개의 쿼리를 보내보겠습니다.
출력에서 두 개의 개별 인스턴스 간에 로드 밸런싱을 수행하고 있음을 알 수 있습니다.
마이크로서비스의 부하 분산
마이크로서비스 아키텍처는 Netflix 및 Amazon과 같은 여러 회사에서 비즈니스 애플리케이션을 느슨하게 연결된 서비스 세트로 개발하는 데 사용하고 있습니다. 복잡한 애플리케이션을 위한 하이퍼스케일 및 지속적 제공은 이 분산되고 느슨하게 연결된 아키텍처로 이동하는 두 가지 이유일 뿐입니다.
이러한 기업의 팀은 기존 방법보다 더 빠르고 낮은 실패율로 앱을 생성하기 위해 Agile 및 DevOps 전략을 구현했습니다. 그러나 분산 아키텍처의 복잡성과 응용 프로그램의 요구 사항, 확장 요구 사항 및 출시 시간 제한 간에 균형을 유지해야 합니다.
수년 동안 ADC(애플리케이션 제공 컨트롤러)는 온프레미스 또는 클라우드에서 호스팅되는 기업 애플리케이션에 대한 서비스 수준 요구 사항을 충족하는 데 중요했습니다. 마이크로서비스 기반 애플리케이션에 참여하는 클라이언트는 클라이언트와 마이크로서비스를 독립적으로 성장시키기 위해 이를 제공하는 인스턴스에 대해 알 필요가 없습니다.
이것은 정확히 역방향 프록시 또는 로드 밸런서에서 제공하는 디커플링입니다. 다시 말하지만, 로드 밸런싱은 마이크로서비스가 수요, 보안 및 가용성을 처리할 수 있도록 하는 솔루션입니다.
수평적 확장성을 위해 클라이언트와 마이크로서비스 기반 앱 간의 기존 남북 로드 밸런싱을 동서 배포와 결합하면 상당한 향상을 얻을 수 있습니다. 목표는 개발 민첩성 또는 DevOps 자동화 요구 사항.
장점
로드 밸런싱은 트래픽이 많은 웹사이트와 앱, 쿼리를 많이 받는 데이터베이스에 대한 리소스 활용도, 데이터 전달, 응답 시간을 개선하여 다양한 이점을 제공합니다. 로드 밸런싱은 트래픽이 많은 시나리오에서 사용자 요청이 빠르고 정확하게 이행되도록 합니다.
사용자가 느린 프로그램과 리소스를 처리하는 번거로움을 덜어줍니다. 로드 밸런싱은 또한 다운타임을 방지하고 보안을 단순화하여 회사의 생산성 및 수익 손실 위험을 낮추는 데 도움이 됩니다.
- 로드 밸런싱은 트래픽을 최적의 효율성으로 관리하는 것 외에도 수요에 따라 서버를 추가 및 제거할 수 있는 유연성을 제공합니다. 유지 보수 중에는 트래픽이 다른 서버로 우회되기 때문에 사용자에게 방해가 되지 않고 서버 유지 보수를 수행하는 것도 가능합니다.
- 로드 밸런싱은 서버 세트 간에 트래픽을 분할하여 기본 제공 중복성을 제공합니다. 한 서버에 장애가 발생하면 즉시 부하를 다른 서버로 전환하여 사용자에 대한 영향을 최소화할 수 있습니다.
- 응용 프로그램이나 웹 사이트의 사용이 증가하면 트래픽이 증가하여 효과적으로 처리되지 않으면 성능이 저하될 수 있습니다. 로드 밸런싱을 사용하면 서비스를 중단하지 않고 수요를 충족하기 위해 실제 또는 가상 서버를 추가할 수 있습니다. 로드 밸런서는 새 서버가 온라인 상태가 될 때 이를 식별하고 이를 작업에 손쉽게 통합합니다. 이 방법은 과부하가 걸린 서버에서 다운타임이 자주 발생하는 새 서버로 웹사이트를 마이그레이션하는 것보다 선호됩니다.
결론
로드 밸런싱은 최신 내결함성 시스템의 중요한 구성 요소입니다. 다양한 로드 밸런싱 접근 방식을 사용하여 여러 서비스 인스턴스에 요청을 배포하는 앱을 간단히 구성할 수 있습니다. 기업은 애플리케이션을 안전하게 제공하기 위해 복잡한 IT 시스템을 지원해야 합니다.
도메인 간 마이크로서비스 구성, 배포 및 유지 관리는 오류가 발생하기 쉽고 비용이 많이 들고 시간이 많이 소요될 수 있습니다. IT는 애자일 및 DevOps 프로세스와 호환되는 자동화, 가시성, 분석, 오케스트레이션 모범 사례 및 기술을 사용하여 이러한 마이크로서비스의 설정 및 유지 관리를 더 쉽게 만들어야 합니다.
댓글을 남겨주세요.