AWS Load balancer(로드 밸런서)에 대해 조금 더 자세히 알아보자 (1)

 

들어가기 앞서..

로드 밸런싱이란?⚖️

Load Balancer는 서버로 트래픽을 백엔드 혹은 다운스트림 EC2 인스턴스 혹은 서버들로 고루 분산하여 전달하는 역할을 한다.

=> 한 가지 주요한 특징은 유저들은 로드밸런서에 연결되면 한 엔드포인트에 연결이 된다는 것만 알고 자신들이 백엔드 인스턴스 중 어떤 것에 연결되어 있는지 알 수 없다🤔💭

 

로드 밸런싱이 왜 필요할까🤷‍♀️

1. 부하를 다수의 다운스트림 인스턴스로 분산하기 위해서이다. 애플리케이션에 단일 액세스 지점(DNS)을 노출하게 되고 다운 스트림 인스턴스의 장애를 원활히 처리할수 있다.

=> 로드 밸런서가 상태 확인 매커니즘이라 어떤 인스턴스로 트래픽을 보낼 수 없는지 확인해준다.(=인스턴스 상태 확인)

2. 우리의 웹사이트의 SSL 종료도 제공해서 웹사이트의 암호화된 HTTPS 트래픽을 가질 수 있다.

3. 쿠키를 높게 강화할 수 있고 영역에 걸친 고가용성을 가질 수 있다.

4. 클라우드 내에서 개인 트래픽과 공공 트래픽을 분리할 수 있다.

 

#0 Elastic Load Balancer 🔀

일래스틱 로드 밸런서는 관리형 로드 밸런서이다.

AWS가 유지관리, 고가용성을 책임지고 관리하고 로드 밸런서의 작동 방식을 수정할 수 있게끔 일부 구성 놉(Knobs)을 제공해줘서 AWS 로드 밸런싱에는 일래스틱 로드 밸런서를 무조건 쓰는 것이 좋다.

(심지어 직접 관리하는 것보다 싸다)

그리고 로드밸런서는 다수의 AWS 서비스들(EC2, ECS, ACM, Cloudwatch, Route 53 등)과 통합이 가능하다.

상태확인도 할 수 있는데 일래스틱 로드 밸런서가 EC2 인스턴스의 작동이 올바르게 되어 있는지의 여부를 확인하기 위해 사용된다.

(만약 제대로 작동중이 아니면 해당 인스턴스로는 트래픽을 보낼 수가 없기 때문에 상태확인이 중요)

상태확인은 아래 그림과 같이 Port와 라우트에서 이루어진다.

만약 EC2 인스턴스가 괜찮다는 신호, 즉 HTTP 상태 코드로 200을 응답하지 않으면 인스턴스 상태가 좋지 않다고 기록된다.

 

<Load Balancer의 종류> - 아래로 내려갈수록 최신형

1. Classic Load Balancer(CLB - 클래식 로드 밸런서) :

기존 세대나 V1이라고도 하고 HTTP, HTTPS, TCP, SSL, secure TCP를 지원한다.

=> 그러나 너무 구형이라 이 로드 밸런서의 사용을 권장하지 않고 애초에 콘솔에서 더 이상 사용할 수 없는 걸로 나오긴 하지만 사용이 가능하긴 하다.

2. Application Load Balancer(ALB - 애플리케이션 로드 밸런서) :

HTTP, HTTPS, WebSocket 프로토콜을 지원한다.

3. Network Load Balancer(NLB - 네트워크 로드 밸런서) :

TCP, TLS, secure TCP, UDP 프로토콜을 지원한다.

4. Gateway Load Balancer(GWLB - 게이트웨이 로드 밸런서) :

네트워크층에서 작동하는 로드 밸런서인데 3Layers(3계층)과 IP프로토콜에서 작동

=> 결론적으로 더 많은 기능을 가지고 있는 신형 로드 밸런서를 사용하는 것이 권장된다!

+) 일부 로드 밸런서들은 내부에 설정될 수 있어서 네트워크에 개인적 접근이 가능하고 웹사이트와 공공 애플리케이션 모두에 사용이 가능한 외부 공공 로드 밸런서도 있다.

 

< 로드 밸런서를 통한 보안그룹에 대해 🛡️>

유저는 HTTP나 HTTPS를 사용해서 어디서든 로드 밸런서에 접근이 가능한데

위와같이 보안 그룹의 형태가 나올 것이다. 

위의 그림처럼 로드밸런서에 유저의 연결을 허용(어디서든 - 0.0.0/0)하는데

EC2까지는 로드 밸런서를 통해 곧장 들어오는 트래픽만 허용해야 하기 때문에

소스는 IP범위가 아니라 보안 그룹이 되어 보안이 더 강화된 매커니즘이 만들어지는 것이다.

 

#1 로드 밸런서 유형 1) Application Load Balancer(ALB) - HTTP전용

☑️ 7계층, 즉 HTTP전용 로드 밸런서로 머신 간 다수 HTTP 애플리케이션의 라우팅에 사용이 된다.

☑️ 이러한 머신들은 target group(대상 그룹)으로 묶이는데 동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산한다.

☑️ HTTP/2와 WebSocket, 리다이렉트도 지원한다. (HTTP나 HTTPS로 트래픽을 리다이렉트할 경우 로드 밸런서 레벨에서 가능하다는 의미)

☑️ target group(대상 그룹)에 따른 라우팅이 가능하다.

(예 : URL 대상 경로에 기반한 라우팅 - example.com/users랑 example.com/posts랑 경로가 다른데 target group에 리다이렉트할 수 있다는 말)

1) 호스트 이름에 기반한 라우팅이 가능하다. 

(예 : one.example.com 혹은 other.example.com에 접근이 가능하다치면 두 개의 다른 target group에 라우팅될 수 있다는 말)

2) 쿼리 문자열과 헤더에 기반한 라우팅이 가능하다.

(예 : example.com/users?id=123&order=false가 다른 target group에 라우팅될 수 있다는 말)

 

=> 결국 ALB는 마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드 밸런서로 Docker와 Amazon ECS의 경우에 ALB가 가장 적합한 로드 밸런서가 될 거다.

(왜냐면 port mapping 기능이 있어 EC2인스턴스의 동적 port로의 리다이렉션을 가능하게 해주기 때문)

 

#2 로드 밸런서 유형 2) Network Load Balancer(NLB) - Layer4 TCP, UDP 트래픽 다루기

Layer4(L4) 로드 밸런서라 TCP나 UDP 트래픽을 다룰 수 있다.

HTTP를 다루는 L7보다 하위 계층인데 L4는 TCP나 UDP 트래픽을 다룬다.

 

✅ <NLB의 특징>

- 초당 수백만 건의 요청을 처리할 정도로 성능이 매우 높다.

- 가용 영역별로 하나의 Static(고정) IP를 갖는다.

(Elastic(탄력적인) IP 주소를 각 AZ에 할당할 수 있고 여러 개의 Static IP를 가진 애플리케이션을 노출할 때 유용)

- Elastic IP를 사용할 수도 있다. (예 : 1~3개의 IP로만 액세스할 수 있는 애플리케이션을 만들 때)

 

✅ <NLB 동작 방식>

ALB와 동작방식이 유사하긴한데 target group을 생성하면 NLB가 target group을 리다이렉트한다. 백엔드, 프론트엔드 모두 TCP 트래픽을 사용하거나 백엔드에서는 HTTP, 프론트엔드에서는 TCP를 사용할 수 있다.

 

✅ <NLB Target group의 유형>

1) EC2 인스턴스는 Target group이 될 수 있다.

(NLB가 TCP나 UDP트래픽을 EC2 인스턴스로 리다이렉트할 수 있다는 뜻)

2) IP 주소가 Target group이 될 수 있다.

(IP주소는 반드시 하드코딩되어야 하고 private IP여야 한다 -> 자체 EC2 인스턴스의 private IP를 보낼 수도 있지만 자체 데이터 센터 서버의 private IP를 사용할 수도 있기 때문)

3) Appliacation Load Balancer(ALB) 앞에 Network Load Balancer(NLB)를 사용할 수 있다.

NLB 덕분에 static IP도 얻을 수 있고 ALB 덕분에 HTTP유형의 트래픽을 처리하는 role을 얻을 수 있기 때문에 유효한 설정 조합이다.

 

#3 로드 밸런서 유형 3) Gateway Load Balancer(GWLB)

✅ <GWLB 의 특징>

GWLB는 배포 및 확장과 AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용된다.

GWLB는 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용한다.

=> 그래서 IDPS나 심층 패킷 분석 시스템 혹은 일부 payload를 수정할 수 있지만 '네트워크 수준'에서 가능

 

✅ <GWLB 동작 방식>

원래는 트래픽이 애플리케이션에 도달하기 전에 EC2 인스턴스와 같은 타사 가상 어플라이언스를 배포했고 트래픽의 애플리케이션에 도달 전에 트래픽을 통과하려면 원래는 많이 복잡했지만 GWLB를 사용하면 아주 간단하다.

GWLB를 생성하면 이면에서는 VPC에서 Route Table이 업데이트된다. Route Table이 수정되면 먼저, 모든 사용자 트래픽은 GWLB를 통과하고 GWLB는 가상 어플라이언스의 Target group 전반으로 트래픽을 확산한다. 그래서 모든 트래픽은 어플라이언스에 도달하고 어플라이언스는 트래픽을 분석하고 처리한다. (예 : 방화벽, 침입 탐지)

이상이 있으면 트래픽을 드롭하고 허용되면 GWLB를 통과해서 애플리케이션으로 보낸다.

=> 이렇게 하면 애플리케이션에서는 명료하게 모든 트래픽이 GWLB와 타사 가상 어플라이언스를 통과해 모든 네트워크 트래픽을 분석하고 드롭시킬 수 있다

...

GWLB는 L3(Layer3)으로 모든 로드 밸런서보다 낮은 수준에서 실행되는데 2가지 기능을 갖게 된다.

1. Transparent Network Gateway(투명 네트워크 게이트웨이) -> VCP의 모든 트래픽이 GWLB가 되는 단일 엔트리와 출구를 통과하기 때문이다. 2. 그리고 Target group의 가상 어플라이언스 집합에 전반적으로 그 트래픽을 분산해 로드 밸런서가 된다.

 

✅ <GWLB Target group의 유형>

1) EC2 인스턴스는 Target Group이 될 수 있다.

2) IP 주소는 Target Group이 될 수 있다. (이 경우에는 private IP여야 함)

-> 예를 들어 자체 네트워크나 자체 데이터 센터에서 이런 가상 어플라이언스를 실행하면 IP로 수동 등록할 수 있다.

 

+)

로드 밸런서에 대해 자세한 내용이 많아 다음 글에 더 정리하려고 합니다.

로드 밸런서에 대해 더 많이 알고 싶으면 다음 글을 참고하길 바랍니다😀