AWS ELB를 사용한 로드 밸런싱

안녕하세요 여러분! 오늘부터 강좌가 시작됩니다 "개발자를 위한 AWS", 이와 관련하여 우리는 ELB 검토에 관한 해당 주제별 웹 세미나를 개최했습니다. 밸런서의 종류를 살펴보고 밸런서가 포함된 여러 EC2 인스턴스를 생성했습니다. 우리는 또한 다른 사용 사례도 연구했습니다.

웨비나를 들은 후, 당신은:

• AWS Load Balancing이 무엇인지 이해합니다.
• Elastic Load Balancer 및 해당 구성 요소의 유형을 알고 있습니다.
• 실무에 AWS ELB를 사용해보세요.

왜 이것을 알아야합니까?

• AWS 인증 시험에 응시할 계획이라면 유용합니다.
• 이는 서버 간에 로드를 분산시키는 간단한 방법입니다.
• 이는 서비스(ALB)에 Lambda를 추가하는 간단한 방법입니다.

공개강의를 진행했습니다 리샤트 테레굴로프, 웹사이트 개발 및 지원을 담당하는 마케팅 회사의 시스템 엔지니어입니다.

소개

Elastic Load Balancer가 무엇인지는 간단한 예를 보여주는 아래 다이어그램에서 확인할 수 있습니다.

Load Balancer는 요청을 수락하고 이를 인스턴스 전체에 배포합니다. 별도의 인스턴스가 하나 있고, Lambda 함수와 AutoScaling 그룹(서버 그룹)이 있습니다.

AWS ELB 유형

1. 주요 유형을 살펴 보겠습니다.:

클래식 로드 밸런서. AWS의 최초 로드 밸런서는 OSI 레이어 4와 레이어 7 모두에서 작동하며 HTTP, HTTPS, TCP 및 SSL을 지원합니다. 여러 Amazon EC2 인스턴스에 대한 기본 로드 밸런싱을 제공하며 요청 및 연결 수준 모두에서 작동합니다. 열어 보겠습니다(회색으로 강조 표시됨).

이 밸런서는 오래된 것으로 간주되므로 특정 경우에만 사용하는 것이 좋습니다. 예를 들어 EC2‑Classic 네트워크에 구축된 애플리케이션의 경우입니다. 원칙적으로 누구도 우리가 그것을 만드는 것을 막지 않습니다.

2. 네트워크 로드 밸런서. 과도한 워크로드에 적합하고 OSI 레이어 4(EKS 및 ECS에서 사용 가능)에서 작동하며 TCP, UDP 및 TLS가 지원됩니다.

Network Load Balancer는 트래픽을 Amazon VPC의 대상으로 라우팅하고 매우 짧은 지연 시간으로 초당 수백만 개의 요청을 처리할 수 있습니다. 또한 갑작스럽고 변화하는 부하가 있는 트래픽 패턴을 처리하도록 최적화되어 있습니다.

3. 애플리케이션 로드 밸런서. 레이어 7에서 작동하고, Lambda를 지원하며, 헤더 및 경로 수준 규칙을 지원하고, HTTP 및 HTTPS를 지원합니다.
마이크로서비스 및 컨테이너를 포함하여 최신 아키텍처를 기반으로 구축된 애플리케이션 제공에 초점을 맞춘 고급 요청 라우팅을 제공합니다. 요청 내용을 기반으로 Amazon VPC의 대상으로 트래픽을 전달합니다.

TCP가 HTTP만큼 일반적이지 않기 때문에 많은 사용자에게 Application Load Balancer는 Classic Load Balancer를 대체하는 첫 번째 선택이었습니다.

이를 생성해 보겠습니다. 그 결과 이미 두 개의 로드 밸런서가 있습니다.

로드 밸런싱 구성 요소

공통 로드 밸런싱 구성 요소 (모든 밸런서에 공통):

• 액세스 로깅 정책

— 귀하의 ELB 액세스 로그. 설정하려면 설명으로 이동하여 "속성 편집" 버튼을 선택하세요.

그런 다음 S3Bucket - Amazon 객체 스토리지를 지정합니다.

• 계획

— 내부 또는 외부 밸런서. 요점은 LoadBalancer가 외부에서 액세스할 수 있도록 외부 주소를 받아야 하는지, 아니면 내부 로드 밸런서가 될 수 있는지 여부입니다.

• 보안 그룹

— 밸런서에 대한 접근 제어. 본질적으로 이것은 높은 수준의 방화벽입니다.

• 서브넷

— VPC 내부의 서브넷(및 그에 따른 가용성 영역). 서브넷은 생성 중에 지정됩니다. VPC가 지역별로 제한되는 경우 서브넷은 가용성 영역으로 제한됩니다. 로드 밸런서를 생성할 때 최소 XNUMX개의 서브넷에 생성하는 것이 좋습니다(가용 영역 하나에서 문제가 발생하는 경우 도움이 됨).

• 청취자

— 밸런서 프로토콜. 앞서 언급했듯이 Classic Load Balancer의 경우 HTTP, HTTPS, TCP 및 SSL이 될 수 있고, Network Load Balancer의 경우 TCP, UDP 및 TLS, Application Load Balancer의 경우 HTTP 및 HTTPS가 될 수 있습니다.

Classic Load Balancer의 예:

그러나 Application Load Balancer에서는 약간 다른 인터페이스와 일반적으로 다른 논리를 볼 수 있습니다.

Load Balancer v2 구성요소(ALB 및 NLB)

이제 버전 2 밸런서인 Application Load Balancer와 Network Load Balancer를 자세히 살펴보겠습니다. 이러한 밸런서는 고유한 구성 요소 기능을 가지고 있습니다. 예를 들어 대상 그룹, 즉 인스턴스(및 기능)와 같은 개념이 나타났습니다. 이 구성 요소 덕분에 트래픽을 전달할 대상 그룹을 지정할 수 있습니다.

간단히 말해서 대상 그룹에서는 트래픽이 발생할 인스턴스를 지정합니다. 동일한 Classic Load Balancer에서 강도를 밸런서에 즉시 연결한 다음 Application Load Balancer에서 먼저 다음을 수행합니다.

• 로드 밸런서를 생성합니다.
• 대상 그룹을 생성합니다.
• 필수 포트 또는 로드 밸런서 규칙을 통해 필수 대상 그룹으로 직접 연결합니다.
• 대상 그룹에서 인스턴스를 할당합니다.

이 조작 로직은 더 복잡해 보일 수도 있지만 실제로는 더 편리합니다.

다음 구성품은 리스너 규칙 (라우팅 규칙). 이는 Application Load Balancer에만 적용됩니다. Network Load Balancer에서 리스너를 생성하고 특정 대상 그룹으로 트래픽을 보내는 경우 Application Load Balancer에서는 모든 것이 더 재미있고 편리하게.

이제 다음 구성 요소에 대해 몇 마디 말해 보겠습니다. 탄력적 IP (NLB의 고정 주소). 리스너 규칙 라우팅 규칙이 Application Load Balancer에만 영향을 미친 경우 탄력적 IP는 Network Load Balancer에만 영향을 미쳤습니다.

Network Load Balancer를 생성해 보겠습니다.

그리고 생성 프로세스 중에 탄력적 IP를 선택할 수 있는 기회가 제공되는 것을 볼 수 있습니다.

탄력적 IP는 시간이 지나면서 다양한 EC2 인스턴스와 연결될 수 있는 단일 IP 주소를 제공합니다. EC2 인스턴스에 탄력적 IP 주소가 있고 해당 인스턴스가 종료되거나 중지된 경우 새 EC2 인스턴스를 탄력적 IP 주소와 즉시 연결할 수 있습니다. 그러나 실제 EC2가 변경된 경우에도 애플리케이션은 여전히 ​​동일한 IP 주소를 볼 수 있으므로 현재 애플리케이션의 작동이 중지되지 않습니다.

여기에 또 다른 사용 사례 Elastic IP가 필요한 이유에 대한 주제입니다. 보세요, 3개의 IP 주소가 표시되지만 여기에 영원히 머물지는 않습니다.

Amazon에서는 시간이 지남에 따라 60초마다 변경합니다(그러나 실제로는 빈도가 낮습니다). 이는 IP 주소가 변경될 수 있음을 의미합니다. Network Load Balancer의 경우 IP 주소를 바인딩하고 이를 규칙, 정책 ​​등에 표시하면 됩니다.

결론 도출

ELB는 여러 대상(컨테이너, Amazon EC2 인스턴스, IP 주소 및 Lambda 함수)에 수신 트래픽을 자동으로 배포합니다. ELB는 단일 가용 영역 내와 여러 가용 영역에 걸쳐 다양한 로드로 트래픽을 분산할 수 있습니다. 사용자는 고가용성, 자동 확장 및 우수한 보호 기능을 제공하는 세 가지 유형의 밸런서 중에서 선택할 수 있습니다. 이 모든 것은 애플리케이션의 내결함성을 보장하는 데 중요합니다.

주요 장점 :

• 고가용성. 서비스 계약은 로드 밸런서의 가용성을 99,99%로 가정합니다. 예를 들어 여러 가용 영역을 사용하면 정상 객체에 의해서만 트래픽이 처리됩니다. 실제로 전체 지역에 걸쳐 로드 밸런싱을 수행하여 다양한 가용성 영역의 정상 대상으로 트래픽을 리디렉션할 수 있습니다.
• 보안. ELB는 Amazon VPC와 연동하여 통합 인증서 관리, 사용자 인증, SSL/TLS 복호화 등 다양한 보안 기능을 제공합니다. 모두 함께 TLS 설정을 중앙 집중식으로 유연하게 관리할 수 있습니다.
• 탄력. ELB는 네트워크 트래픽의 갑작스러운 변화를 처리할 수 있습니다. 또한 Auto Scaling과의 긴밀한 통합은 로드가 변경되는 경우 수동 개입 없이도 애플리케이션에 충분한 리소스를 제공합니다.
• 유연성. IP 주소를 사용하여 요청을 애플리케이션 대상으로 라우팅할 수 있습니다. 이는 대상 애플리케이션을 가상화할 때 유연성을 제공하므로 단일 인스턴스에서 여러 애플리케이션을 호스팅할 수 있는 기능을 제공합니다. 애플리케이션은 단일 네트워크 포트를 사용하고 별도의 보안 그룹을 가질 수 있으므로 마이크로서비스 기반 아키텍처가 있으면 애플리케이션 간의 통신이 단순화됩니다.
• 모니터링 및 감사. Amazon CloudWatch 기능을 사용하여 실시간으로 애플리케이션을 모니터링할 수 있습니다. 지표, 로그, 요청 추적에 대해 이야기하고 있습니다. 간단히 말해서 문제를 식별하고 성능 병목 현상을 아주 정확하게 찾아낼 수 있습니다.
• 하이브리드 로드 밸런싱. 동일한 로드 밸런서를 사용하여 온프레미스 리소스와 AWS 간의 로드 밸런싱 기능을 사용하면 온프레미스 애플리케이션을 클라우드로 쉽게 마이그레이션하거나 확장할 수 있습니다. 클라우드를 사용하면 오류 처리도 단순화됩니다.

자세한 내용이 궁금하신 경우 공식 Amazon 웹사이트에서 제공하는 몇 가지 유용한 링크를 참조하세요.

1. 탄력적로드 밸런싱.
2. Elastic Load Balancing 기능.

출처 : habr.com