본문 바로가기

AWS

[AWS] ALB, NLB 기본 개념 정리하기

반응형

ELB : AWS의 로드밸런서 서비스

- Basic
    - 서버 부하 분산
    - EC2, ECS의 컨테이너, Lambda, ..
    - 타겟 그룹에 대한 헬스 체크
    - 고정 세션
    - SSL Offload (SSL 암복호화)
    - 헬스 체크를 통한 다운 서버 제외 ..
    - HTTP Header를 조작하여 전달 대상을 정하거나 고정 페이지를 반환, ACM의 SSL 인증서를 탑재하여 EC2의 부하

      를 줄이고, WAS를 앞에 내세워 보안 기능을 강화하거나, CF를 연결하여 반응 속도를 향상하며 최근에 나온 Global        Accelerator를 사용하여 Global Server Load Balancing (GSLB)의 기능을 활성화시키는 등 다양한 기능을 할 수 있다.
    - AutoScaling

# ELB 아키텍쳐

- AWS의 사용자 정의 네트워크인 VPC에 탑재되며, 사용자의 요청을 받고 이를 VPC 내의 리소스 (EC2 등..)에 적절히 부하를 분산한다.


- 외부의 요청을 받아들이는 Listener, 요청을 분산/전달할 리소스의 집합인 Target Group으로 구성되며 ELB는 다수의 리스너와 대상 그룹을 거느릴 수 있다. 부하 분산 대상인 대상 그룹 내 리소스들은 헬스 체크를 활용해 끊임없이 상태를 확인받는다.

 

1. Application Load Balancer

 

HTTP, HTTPS의 특성을 주로 다루는 로드밸런서


HTTP의 헤더 정보를 이용해 부하 분산을 실시하는 것이 ALB의 주요 특징이다.


- SSL 인증서를 탑재할 수 있어 대상 그룹의 EC2를 대신하여 SSL 암/복호화를 대신 진행할 수 있음


ALB는 라운드 로빈 방식으로 서버에 접속한다.


- ELB — WEB — ELB — WAS의 경우 세션에 관한 정보들은 Redis, Memcached 사용 권장


- 외부 방화벽에서 특정 IP만 허용이 필요할 때 ALB 앞단에 NLB를 두거나 AWS Global Accelerator를 설정한다. (NLB만 IP를 고정할 수 있다.)


ALB 세팅 시 보안그룹을 지정할 수 있다.


- ALB는 ALB 자신의 IP를 웹서버 혹은 Tomcat 서버 내부 access_log에 찍힌다. Client의 IP를 보내지 않으므로 Apache 기본 로그 설정에서 X-Forwarded-For를 추가하여 Client IP를 확인 가능


- 타겟 유형이 Instance나 ip, Lambda도 가능하다.


- Rule 편집을 통해 L7 구현이 가능하다.


Least Outstanding Requests (LOR) 알고리즘을 통해 미처리 요청이 가장 적은 대상으로 Client의 Request를 보낼 수 있다.


- 요청에 따라 대상그룹에 특정 서버로 가게 할 수 있다.

- Idle timeout (유휴 시간) : target EC2에 대해 connection을 맺어 놓고 HTTP 통신을 하게 되는데, Client에서 아무런 데이터를 보내지 않을 경우 idle timeout이 지난 후 connection을 close
    ⇒ EC2의 Timeout값을  ALB idle timeout보다 크게 잡도록 권장하며 keet-alive 옵션을 사용하여 ALB와 EC2

        Connection이 끊어지지 않도록 설정할 것을 권장

 

- HTTP/2


- Desync mitigation mode : Determines how the load balancer handles requests that might pose a security risk to your application.


- Drop invalid header fields : Indicates whether HTTP headers with invalid header fields are removed by the load balancer (true) or routed to targets (false).


- Access logs : Access Logs delivers detailed logs of all requests made to Elastic Load Balancing. The logs are stored in Amazon S3.


- WAF fail open : Allows requests through to backend target(s) when the application load balancer is unable to contact AWS Web Application Firewall (WAF).

 

- ACM (AWS Certificate Manager) 인증서 생성 가능

 

2. Network Load Balancer

- L4의 특성을 이용하는 로드밸런서이다. 즉, TCP와 UDP를 사용하는 요청을 받아들여 부하분산을 실시한다.


- HTTP가 아닌 하위 Layer인 TCP Layer에서 처리하므로 HTTP 헤더를 해석하지 못한다.


- 지연시간이 좀 짧다 → L4라서 빠름


- 대규모 트래픽 처리에 적합하다.


IP가 변하지 않는다.


- 보안 그룹 설정을 안한다. => Backend에서의 SG Rule을 따름


- NLB에서 대상을 인스턴스로 지정하면 Client IP 확인이 가능하다.
⇒ tcpdump로 서버에서 확인 가능

NLB에서 대상을 IP로 등록시 NLB 내부 IP를 찍는다 !! ( 위와 차이점 )
⇒ 클라이언트 IP로 확인이 안됨 ( NLB는 L4라 안된다. )
⇒ Proxy Protocol 활성화해서 사용해야 한다.
⇒ 웹서버에서 Proxy Protocol 활성화 설정해 확인이 가능

 

타겟 그룹

- 타겟 : Instance, IP, Lambda
- Protocol : IP와 Instance는 HTTP/HTTPS가 있다.
- Port는 임의로 지정할 수 있음
- Health Check
    - 프로토콜과 Path를 지정할 수 있음
    - Avdanced H.C Settings에서
        - traffic port
        - override : 재정의가 설정된 경우 지정된 포트가 태스크 호스트 포트와 일치하는지 확인한다. ( 원 override는 부모로부터 물려받은 것을 다르게 만든다는 개념 ... )

### cross-zone
disalbe 되어 있다면 각 Zone 별로만 Load Balancer의 요청을 균등하게 배분한다.
enable 되어 있다면 각 Instance 별로 요청을 균등하게 배분한다.


Example
a zone에 2대 / b zone에 5개가 있다.

**disable이 되어 있다면**, a zone에 50%, b zone에 50%가 요청이 들어간다.

즉, a zone 2대의 Instance들에는 25%의 요청들만 가고, b zone의 5대의 instance들에는 10%의 요청들만 간다.

**enable이 되어 있다면,** a zone 의 각 instance 들에 14.28..%의 요청들이 가고, b zone의 각 instance 들에도 14.28...%의 요청들이 들어가게 된다.

- ALB에는 교차 영역 로드 밸런싱이 항상 활성화되어 있다.
- NLB에는 교차 영역이 활성화되어 있지 않으므로 사용하고 싶다면 Attributes에서 Enable 해주어야 한다.
- CLB에는 교차 영역이 활성화되어 있으며 체크할 수 있음

### Web, Proxy Protocol, ..


- AWS NLB에서 Target Group Type으로 IP를 사용하는 경우에도 Proxy Protocol을 이용해서 사용자 IP를 확인하는 방법 !

⇒ Target Group의 Type이 Instance일 시에는 크게 신경쓰지 않아도 되는 부분이다.

 

1. apache에서 mod_remoteip 모듈이 있는지 확인
2. httpd.conf에서 해당 Module이 로드되어 있지 않다면 Load하고 LogFormat을 수정해준다.

1. Target Grop에서 Proxy protocol v2을 활성화해주면 된다.
- 설정 이후
    Target Group IP Type인 경우에도 Access log에서 출발지 IP 확인 가능

 

 

### ALB의 리스너 : 규칙 작업, 규칙 조건

- 조건에 따라 행동 규칙을 정할 수 있음
규칙 : 리스너는 정의한 규칙에 따라 로드밸런서가 하나 이상의 대상 그룹에서 대상으로 요청을 라우팅한다. 각 리스너는 기본 규칙을 가지며, 선택적으로 추가 규칙 정의 가능


    - 기본 규칙은 삭제가 불가능하고 조건을 가질 수 없으며 다수의 규칙이 존재할 때 가장 마지막에 적용된다.

    - 각 규칙은 우선 순위와 하나 이상의 조건, 하나 이상의 작업으로 구성된다.


규칙 작업 : 작업을 수행하는 데필요한 유형, 순서 및 정보
    - Forward : 요청을 지정한 '대상 그룹'으로 전달
    - Redirect : URL의 요청을 다른 URL로 변경하여 전달, 즈 요청된 URL이 아닌 다른 URL을 요청하는 것으로 바뀜
    - Fixed-response : 사용자가 지정한 HTTP Response를 반환, 즉 200을 포함하여 2XX, 4XX, 5XX 응답 코드와 메시지 반환 가능


규칙 조건 : 작업을 수행할 규칙에 대한 조건 충족
    - Host-Header : 도메인 이름을 기반으로 라우팅
    - HTTP-Header : 각 요청의 HTTP Header를 기반으로 라우팅
    - Source-ip : 각 요청의 source ip 주소를 기반으로 라우팅

 

### ALB의 Host, Path 조건


Host 조건 : 도메인 이름을 기반으로 로드밸런싱 ( example.com, cafe.example.com, ..)
Path 조건 : 도메인의 경로를 이용한 로드밸런싱 ( /test/, /login/, .. )

Connection Draining : 종료될 인스턴스에 요청 전달을 중단하고 수행중인 요청을 방해 없이 완료한 후 인스턴스 종료
    - 1초 ~ 3600초까지 설정 가능
    - AutoScaling은 인스턴스를 종료시키기 전에 Connection Draining을 기다림
    - ALB, CLB 지원

- Client IP를 보존해주는 기능인 ELB X-Forwarded-For를 ALB, CLB가 지원
- 기본활성이기 때문에 활성화시킬 필요 X

 

 

 

Ref

 

 

 

 

 

 

 

반응형