AWS ELB 정리 (2)

Network Load Balancer (NLB)

Network Load balancer는 4계층의 TCP, UDP의 트래픽을 처리할 수 있다. 초당 수백 만건의 요청을 처리할 수 있다. ALB에 비해서 지연시간도 더 짧다.

대신 가용영역(AZ) 당 하나의 고정 IP를 가질 수 있고, Elastic IP를 인스턴스에 배정할 수 있다. 시험에서 애플리케이션이 1개 혹은 서로 다른 2~3개의 IP로만 액새스 가능하다고 하면 NLB가 적절하다. 예를 들어 3개의 AZ에 사용하면 3개의 고정 IP를 사용할 수 있다.

따라서 고도의 성능, TCP, UDP 트래픽 , 그리고 IP 고정인 경우 NLB가 적절하다.

NLB 작동 원리

작동원리는 TCP나 UDP 트래픽을 ALB와 비슷하게 대상 그룹에 라우딩할 수 있다.

대상 그룹 종류

EC2 인스턴스들
IP 주소 : 무조건 프라이빗 IPs EC2 인스턴스의 IP나 개인 소유의 데이터 센터의 IP도 좋다.
ALB : 이 경우 NLB가 ALB 앞에 있는 거다.

대상 그룹의 Health Check는 ALB와 달리 TCP, HTTP, 그리고 HTTPS 프로토콜을 지원한다. 백엔드 애플리케이션이 HTTP를 지원하면 확인할 수 있다.

NLB와 EC2를 사용할 때 주의할 점

NLB는 TCP 트래픽을 라우팅하지 HTTP 트래픽을 라우팅하지 않늗다. 그래서 HTTP 라우팅하는 ALB와 달리 NLB는 EC2에 외부 연결을 직접 라우팅한다. 그래서 EC2에 보안그룹(SG)에 외부 연결(HTTP, CIDR 0.0.0.0/0)을 허용해야한다. 이 경우 보안에 문제가 있을 것 같다. 그래서 NLB의 대상그룹으로 ALB를 둬서 보안을 강화시킬 수 있을 것 같다. 그리고 AWS 프리티어는 NLB를 지원하지 않는다.

Gateway Load balancer GWLB

GWLB는 네트워크의 보안을 관리하는데 특화했다. 네트워크로 들어오는 모든 트래픽에 침입 탐지, 방화벽, 심층 패킷 분석 시스템 등등 네트워크 수준에서 작업할 수 있다.

예를 들어 유저가 애플리케이션 인스턴스에 접속하려고 했을 때, 보통 ALB를 통해 라우팅하게된다. 그러나 트래픽 분석을 위해 서드 파티 가상 애플리케이션 인스턴스로 트래픽을 GWLB로 쉽게 통과시킬 수 있다. GWLB를 설정하면 유저의 모든 트래픽이 GWLB로 들어가고 GWLB는 대상 그룹으로 트패픽을 라우팅한다. 이때 대상그룹은 방화벽이나 트래픽 분석하는 서드 파티 애플리케이션이다. 그럼 다시 GWLB로 트래픽이 돌아가고 GWLB는 애플리케이션으로 트래픽을 다시 보내다.

위와 같은 작업이 가능한 이유는 모든 로드 밸런서 보다 낮은 수준에서 GWLB가 실행되기 때문이다. 즉 IP 패킷을 다루는 3계증!

GWLB의 역할

투명 네트워크 게이트 웨이 : VCP의 모든 트래픽은 GWLB 단일 출입구를 사용한다.
로드 밸런서 : 대상 그룹으로 트래픽 분산
GWLB를 위해 6081번 포트의 GENEVE 프로토콜을 사용한다.

GWLB의 대상 그룹

EC2 인스턴스들
IP 주소들 : 프라이빗 IP만 가능!!

ELB Sticky Session

고정 세션이란 두가지 요청하는 클라이언트의 응답을 동일한 백엔드 인스턴스가 수행하도록 하는 것. 한 유저의 요청은 한 인스턴스가 수행하지만, 다른 유저가 요청하면 다른 인스턴스에 트래픽을 라우팅해서 인스턴스의 부하를 적절하게 관리한다. 세션 고정은 쿠키를 이용해서 구현되기 때문에 CLB와 ALB가 지원할 수 있다.

사용 사례

유저 세션 정보 관리 : 한 인스턴스에서 한 유저의 세션 정보를 관리할 수 있게한다. 요청할 때마다 인스턴스가 바뀌면 세션 정보가 없어서 문제가 생길 수 있다.
고정성을 활성화하면 일부 EC2에 불균형을 초래할 수 있다. (두 인스턴스에 동일한 수의 유저가 처음에 요청했는데 한 인스턴스에 접속한 유저만 계속 요청하는 경우)

쿠키 생성

쿠키는 애플리케이션 기반과 기간 기반 쿠키가 있다. AWS에서 로드밸런서의 고정성을 선택하는 옵션에는 application-based cookie와 Load balancer generated cookie (기간 기반 쿠키) 중에서 선택할 수 있다.

애플리케이션 기반 쿠키를 대상 그룹의 인스턴스가 생성할 수 있는데 여기에는 유저 정보 같은 애플리케이션에서 필요한 속성을 추가할 수 있다. 또한 쿠키 이름은 대상 그룹 마다 개별적으로 정해야하고, AWSALB, AWSALBAPP, AWSALBTG 같은 이름은 쓰면 안된다. 왜냐하면 ALB는 대상 그룹마다 라우팅할 수 있기 때문에 어느 대상 그룹에서 온 쿠키인지 확신할 수 있어야하고, AL B 자체적으로 생성하는 쿠키와도 구분될 수 있어야한다.

대상 그룹이 만든 쿠키 뿐만 아니라 ALB가 만드는 쿠키도 있다. 그 쿠키 이름은 AWSALBAPP이다.

그리고 기간 기반 쿠키도 ALB가 만드는데 이름은 AWSALB for ALB, AWSELB for CLB이고, 쿠키의 기간은 로드밸런서 자체에서 결정한다.

Cross-Zone Load Balancing

만약 AZ1에 2개의 인스턴스가 있는 대상그룹과 로드 밸런서가 있고, AZ2에 8개의 인스턴스가 있는 대상그룹과 로드 밸런서가 있다면, 원래 유저는 다른 IP로 각각의 로드 밸런서에 접속하고 각 AZ의 로드 밸런서는 AZ 안에 있는 인스턴스에만 라우팅할 수 있다. 그러나 Cross Zone Load Balancing이 적용되면 유저는 각 AZ로 50%씩 트래픽을 보내지만 각 로드밸런서는 모든 인스턴스에 10%씩 균등하게 트래픽을 라우팅한다. 즉 인스턴스의 AZ가 달라도 균등하게 쓸 수 있다.

Cross Zone Load Balancing이 없다면, 각 AZ에 로드밸런서에 50%씩 트래픽이 보내진다면, 로드밸런선는 자신이 속한 AZ 안에 있는 인스턴스로만 트래픽을 라우팅한다. 만약 AZ마다 인스턴스 개수가 불균형하다면, 특정 가용 영역에 인스턴스는 부하를 많이 받을 것이다.

적용 방법

ALB : 기본적으로 Cross Zone Load Balancing이 적용됐다. 다만, 대상 그룹 단위로 옵션을 바꿀 수 있다.
NLB, GWLB : 기본적으로 꺼저있고, 다른 AZ로 데이터가 넘어가기 때문에 사용하면 요금이 부과된다.

목차