[AWS] AWS ELB

Scalability & High Availability

ELB에 들어가기 전에 먼저 정리해야 할 부분이다. 간단하게 짚고 넘어가자.

Scalability

확장성이다. 애플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있도록 하는 것이다.

• 수직 확장성
  • 인스턴스의 성능을 변경하는 것.
  • ex)
    • 콜센터를 생각해보자. 1분에 5건의 전화를 처리할 수 있는 신입 사원이 있지만, 더 많은 처리량을 필요로 하는 경우 1분에 20건의 전화를 처리할 수 있는 경력 사원으로 대체하는 것이다.
  • 데이터베이스와 같이 분산되지 않은 시스템에서 흔히 사용된다.
• 수평 확장성(탄력성)
  • 애플리케이션에서 인스턴스의 수를 늘리는 것
  • ex)
    • 콜센터를 생각해보자. 1분에 5건의 전화를 처리할 수 있는 신입 사원을 여러 명 더 뽑아서 문제를 해결할 수 있다.
  • 수평 확장을 했다는 것은 분배 시스템이 있다는 걸 의미한다.
  • 웹이나 현대적 애플리케이션은 대부분 분배 시스템으로 이루어져 있다.

High Availability

고가용성은 보통 수평 확장과 함께 사용되는 개념이긴 하지만 늘 그런 것은 아니다.

고가용성이란 애플리케이션 또는 시스템을 적어도 둘 이상의 AWS의 AZ나 데이터 센터에서 가동 중이라는 것을 의미한다.

고가용성의 목표는 데이터 센터의 손실에서 살아남는 것으로 센터 하나가 멈춰도 계속 작동이 가능하게끔 하는 것이다.

ex) 콜센터를 생각해보자. 뉴욕 지사와 한국 지사가 있다면 한국 지사의 전화 연결이 불가능해지더라도 뉴욕 지사를 통해 해결이 가능하다.

그래서 EC2에서는?

수직 확장성

• 인스턴스의 사이즈를 변경하는 것
• scale up ⬆️ / scale down ⬇️

수평 확장성

• 인스턴스의 개수를 변경하는 것
• scale out ⬆️ / scale in ⬇️

고가용성

• 하나의 애플리케이션의 인스턴스를 여러 개의 AZ에서 작동시키는 것
• Auto Scaling Group multi AZ
• Load Balancer multi AZ

---

AWS ALB

애플리케이션 로드 밸런서이다.

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

머신들을 target group로 묶어 사용하며, 동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산한다.

HTTP/2와 WebSocket도 지원하고, 리다이렉트도 지원하므로 HTTP → HTTPS 트래픽을 자동 리다이렉트하려는 경우에도 가능하다.

마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드밸런서이다.

(포트 매핑 기능이 있기 때문에 ECS 인스턴스의 동적 포트로의 리다이렉션을 가능하게 해 주기 때문.)

 

Cross-Zone Load Balancing가 자동 활성화되어있으며 AZ 간의 데이터 이동에 따른 비용이 발생하지 않는다.

경로 라우팅

경로 라우팅을 지원하며, 대상 그룹에 따라 라우팅 시켜준다.

• URL 대상 경로 기반 라우팅
  • example.com/users 와 example.com/posts 같이 구분시킬 수 있다.
  • 쿼리 문자열과 헤더에 기반한 라우팅도 가능하다.

ALB는 IP 주소들의 앞에 위치할 수 있다.

이 경우 꼭 사설 IP 주소여야만 한다.

ALB는 여러 대상 그룹으로 라우팅 할 수 있으며, 상태 확인은 대상 그룹 레벨에서 이루어진다.

---

AWS NLB

네트워크 로드 밸런서이다.

L4 로드 밸런서이므로, TCP와 UDP 트래픽을 다룰 수 있으며 HTTP를 다루는 L7보다 하위 계층이다.

네트워크 로드 밸런서의 성능은 매우 좋으며, 초당 수백만 건의 요청을 처리할 수 있고, 애플리케이션 로드 밸런서에 비해 지연 시간도 짧다.

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

탄력적 IP 주소를 각 AZ에 할당할 수 있고, 여러 개의 고정 IP를 가진 애플리케이션을 노출할 때 유용하다.

 

Cross-Zone Load Balancing가 자동 비활성화 되어있으며 활성화 시 AZ 간의 데이터 이동에 따른 비용이 발생한다.

작동 방식

애플리케이션 로드 밸런서의 작동 방식과 유사하다.

대상 그룹을 생성하면 네트워크 로드 밸런서가 대상 그룹을 리다이렉트한다.

IP 주소 등록

IP 주소를 등록할 수 있으며, 반드시 하드코딩 되어야 하고, 사설 IP여야 한다.

NLB와 ALB를 같이 사용하는 경우?

네트워크 로드 밸런서 덕분에 고정 IP 주소를 얻을 수 있고, 애플리케이션 로드 밸런서 덕분에 HTTP 유형의 트래픽을 처리하는 규칙을 얻을 수 있다.

상태 확인

세 가지 프로토콜을 지원한다.

• TCP 프로토콜
• HTTP 프로토콜
• HTTPS 프로토콜

---

AWS GWLB

가장 최근의 로드 밸런서인 게이트웨이 로드 밸런서이다.

IP 패킷의 네트워크 계층인 l3에서 실행된다.

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

 

모든 트래픽이 방화벽을 통과하게 하거나, 침입 탐지 및 방지 시스템에 사용된다.

따라서 IDPS나 심층 패킷 분석 시스템 또는 일부 페이로드를 수정할 수 있지만 네트워크 수준에서 사용 가능하다.

투명 네트워크 게이트웨이 기능을 갖는다.

→ VPC의 모든 트래픽이 GWLB가 되는 단일 엔트리와 출구를 통과하기 때문이다.

 

Cross-Zone Load Balancing가 자동 비활성화 되어있으며 활성화 시 AZ 간의 데이터 이동에 따른 비용이 발생한다.

Ex

애플리케이션에 액세스 하는 사용자가 있다고 하자.

사용자는 ALB를 사용해 애플리케이션에 바로 액세스 하고 트래픽은 사용자에서 ALB와 애플리케이션으로 바로 이동한다.

하지만 애플리케이션으로 이동하기 전에 모든 트래픽을 검사하려면 어떻게 해야 할까?

 

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

GWLB를 생성하면 이면에서는 VPC에서 라우팅 테이블이 업데이트된다.

라우팅 테이블이 수정되면 모든 사용자 트래픽은 GWLB를 통과한다.

GWLB는 가상 어플라이언스의 대상 그룹 전반으로 트래픽을 확산한다.

모든 트래픽은 어플라이언스에 도달하고 어플라이언스는 트래픽을 분석하고 처리한다.

이상이 없으면 다시 GWLB로 보내고, 이상이 있으면 트래픽을 드롭한다.

이후 애플리케이션으로 트래픽을 보낸다.

---

Cross-Zone Load Balancing

Cross-Zone Load Balancing란 다른 AZ 간의 로드밸런싱을 의미하는 것이다.

활성화되어 있다면 각 가용 영역으로 50씩 가더라도, 이른 다른 AZ와도 분배하여 갖는다.

→ 클라이언트가 아무리 나눠서 보내도 총 인스턴스의 개수에 따라 나눠 갖는다고 생각하면 쉽다.

비활성화되어 있다면 각 가용 영역의 인스턴스끼리 나눠 갖는다.

→ 클라이언트가 나눠서 보내면 그것을 다시 AZ의 인스턴스끼리 나눠서 갖는다.