[NCP] - Load Balancer 정리 & 분기처리 테스트

*로드밸런서 생성 전

>먼저 Target Group을 생성 후 해당 타겟그룹에 대해서 로드밸런싱

>타겟 그룹 : 요청을 처리할 대상에 대한 집합

                 동일 VPC내에 있는 서버들에 대해 타겟그룹 생성 가능            

                 타겟그룹 안의 서버를 다른 타그룹에 속하게 할 수 있지만 타겟그룹을 다수의 로드밸런서에 연결 X

                 서비스를 수행하는 대상의 프로토콜에 따라 L4, L7 으로 구분

                 헬스체크 주기(5~300초) 및 임계값 설정             

                 기본은 Round Robin 설정 (알고리즘 및 Sticky, Proxy Protocol 설정 변경은 생성 이후에 진행)

>프로토콜 : TCP - NLB / Proxy_TCP - NPLB / HTTP - ALB / HTTPS - ALB

 

>타겟그룹 설정 화면 : StickySession, ProxyProtocol, Algorithm

 

 

[로드밸런서]

>기존의 Classic 환경에서는 프록시방식 1가지만 제공, VPC 환경에서는 로드밸런서를 제공하는 방식이 3가지

>부하처리 성능에 따라 Sizing ( Small - CPS 기준 최소 30,000개의 분산처리 보장 / Medium - 60,000 / Large - 90,000) 중선택

>로드밸런싱 알고리즘 : Round Robin, Least Connection, Source IP Hash

  (RR : 클라이언트에서 요청이 오면 서버에 1개씩 분배 / LC : 클라이언트 연결이 제일 적은 서버에게 분배 / 

  Hash : 클라이언트 IP에 대한 해시테이블을 가지고 클라이언트 IP에 매핑되는 서버에 분배: -> 밸런싱 무너질 수 있음)

 

> ALB :

HTTP, HTTPS를 사용하는 웹어플리케이션에 적용

고정 IP 제공(DNS에 고정IP를 넣어야하는 경우 ALB에서 제공하는 IP 사용가능)

URL 기반 분기 가능

알고리즘은 3가지 제공

 

> NLB : 

고성능의 분산처리 가능

클라이언트 IP가 그대로 로깅(ALB의 경우 클라이언트 IP를 보려면 X-Frowarded-for header값을 통해서 확인 / NPLB의 경우 Proxy Protocol 옵션을 활성화시켜 서버에서 클라이언트 IP를 기록 가능 -> iptables나 서버에서 다양한 필터 적용 가능

알고리즘은 Hash, RR만 제공 (프록시 방식의 경우에는 중간에서 로드밸런서가 어느 서버에 세션이 몇개인지 정확히 알고있지만 NLB의 경우 서버로 포워딩을 하 기 때문에 서버에 몇개의 세션이 연결되어있는지 알 수 없음)

 

(NLB의 경우 서버에 접속하여 /var/log/httpd/access_log 확인하면 실제 클라이언트의 RIP가 찍혀있음 / ALB나 NPLB같은 경우에는 LB의 IP가 찍힘)

 

>NPLB :

Classic과 유사한 Proxy-LB (TCP, HTTP, HTTPS 모두 지원 / 클라이언트의 RIP를 보기 위해서는 별도의 X-Forward-for 설정해줘야 함)

 

>NLB의 분산처리 성능이 좋은이유 : NLB는 DSR 기능이 있기 때문에 중간에 병목현상이 발생하지않아 성능이 높음

>DSR(Direct Server Return) : 응답 패킷이 로드밸런서를 거치지 않고 바로 서버가 클라이언트로 보내는 기능

 

>모니터링 : ALB(Concurrent Connection, Connection per Second, Traffic In, Traffic out) / NLB(Concurrent Connection, Connection per Second, Traffic In)

 

[타입별 기능 비교]

>NLB는 로깅은 제공하지 않지만 클라이언트의 IP를 확인 가능, 성능이 좋음(Direct Routing : 서버가 클라이언트에게직접 응답 - outbound / 나머지는 LB가 중간 inbound, outbound 중계)

>SSL 오프로드 : HTTPS web 서버를 대신하여 SSL 트래픽에 대한 모든 암복호화 처리를 수행하는 기능

 

>LB의 구성방식 : NAT , DR(NLB) , Proxy(NPLB, ALB)

 

>LB의 스케줄링 방식 : RR, LC, Source IP Hash, Weighted RR, Weighted LC, Locality-Based LC, Locality-Based LC with Replication, Destination Hash

(서버의 스펙이 달라서 가중치를 두어야 할때 Weighted 스케줄링 방식을 쓰지만 클라우드에서는 서버의 스펙 변경을쉽게 할 수 있기 때문에 해당 방식은 제공하고 있지 않음 )

 

>네이버 클라우드 플랫폼 로드밸런서 헬스 체크 : 6초마다 헬스체크, 3회 연속으로 ok 혹은 error가 뜨면 바인딩 혹은 언바인딩

 

>기본적으로 로드밸런서 하나를 생성하면 HAProxy 2개가 생성됨, HAProxy 1개의 안정적인 동접 성능은 대략 3000 동접 수준, 만약 동접이 수만 동접인 경우 HAProxy를 여러 개 생성해야 함

 

>제약 사항 : 한 서버가 여러 개의 LB에 바인딩 될 수 있지만 포트별 멀티 바인딩을 지원하지않음 / 최대 50대 서버 바인딩 / 관리용 포트(22포트, 18080~18095, …)는 사용 불가

 

>LB의 기본 설정값인 KeepAlive & Connection Idle Time : On(메모리가 충분하고 컨텐츠 서비스 형태여서 사용자가 지속적으로 서버에 요청하는 경우) /  Off(메모리가 충분하지 못하고 사용자가 서버에 지속적으로 머물지 않는 경우)

>로드밸런서 설정에서 idle timeout 설정 있음

LoadBalancer에 http로 접속 시에 https로 리다이렉트 시키는 방법 | 써드아이시스템 기술문서 (3rdeyesys.com)

 

 

타겟그룹 프로토콜  TCP로 선택 -> 부하분산 알고리즘 : RR, Hash / sticky session 선택 가능 , 로드밸런서 : NLB - 설정에 idle timeout, 액세스 로그 수집, sticky session 없음

 

타겟그룹 프로토콜 HTTP로 선택 -> 부하분산 알고리즘 : RR, LC, Hash / sticky session 선택 가능, 로드밸런서 : ALB - 설정에 idle timeout, 액세스로그수집, sticky session 있음

 

========================================================================================

 

[NCP - ALB 리스너 분기처리 테스트] 

목적 : 클라이언트 측에서 하나의 서버에서 포트별로 서비스를 동작시키고 도메인 기반으로 라우팅을 원할 경우 대비 

 

HTTP/HTTPS 트래픽의 패킷 헤더를 기반으로 어플리케이션 계층(L7)에서 로드를 분산

 

<지원되는 규칙>

HTTP Header 기반 분기 처리

Host Header 기반 분기 처리

URL Path Pattern 기반 분기 처리

가중치 기반 분기 처리

Redirection 응답 처리

 

 

1. Test1 - host header 기반 분기 처리 테스트

 

<테스트 전 준비>

1. vm 2개 ( apache 서버 ) - 서버 index.html 내용을 해당 서버 호스트네임이 뜨도록 설정(구분하기 위해)

2. 로드밸런서 생성 - yjy-lb(ALB) / 리스너 설정 (프로토콜 : HTTP / 포트 : 80) 

3. 타겟그룹은 2개(yjy-planet-web-tg, yjy-test-tg)를 생성 - 각 타겟그룹마다 하나의 웹서버를 타겟으로 설정 ( 프로토콜 : HTTP / 포트 : 80 )

4. 도메인 확보(jyyoon.shop) - 레코드 추가( jyyoon.shop / test1.jyyoon.shop / test2.jyyoon.shop -> 로드밸런서(yjy-lb)

 

<테스트>

[로드밸런서 - 리스너 설정 변경 -> 규칙 조회/변경]

 

규칙 조회/변경 화면에서 등록된 규칙을 조회할 수 있는데 규칙은 다음과 같은 특성을 지니고 있다.

- 각 규칙은 조건절과 액션으로 구성

- Default 규칙은 삭제 불가능

- 각 규칙은 우선순위에 따라 순차적으로 적용되며 적용되지 않은 트래픽은 Default 규칙에 따라 동작

 

[규칙 조회/변경 -> 규칙 추가]

 > 디폴트로 설정되어있는 규칙은 타겟그룹  yjy-planet-web-tg 으로 액션 설정 ( 로드밸런서 생성 시 설정 )

 

 

 > 조건 유형은 Host Header, HTTP Header, Path Pattern 중 Host Header 선택

> Host Header의 경우 최대 68자까지 입력 가능

> 각 조건절은 AND 로 동작하며, Host Header 와 Path Pattern 조건절은 각각 여러 개의 조건이 OR 로 동작함

  (ex. Host Header 조건절 - aaa.com, bbb.com &  Path Pattern 조건절 - /ccc , /ddd 일 경우 최종 조건은

  (aaa.com or bbb.com) and (/ccc or /ddd) 이다.)
 

 >액션의 유형은 Target Group과 Redirection을 선택할 수 있다.

 >액션이 Target Group일 경우 다수의 타겟그룹을 지정해 가중치를 부여할 수 있다.

(ex. Test1 타겟그룹의 가중치를 10, Test2 타겟그룹의 가중치를 90으로 부여 -> 트래픽은 1:9 비율로 분산)

 >액션이 Redirection 일 경우 조건에 부합하는 모든 Request를 다른 URL로 전달한다.

 

 

 > test1.jyyoon.shop 인 경우 트래픽을 yjy-planet-web-tg 타겟그룹으로

 > test2.jyyoon.shop 인 경우 트래픽은 yjy-test-tg 타겟그룹으로

 > 디폴트는 yjy-plaent-web-tg 타겟그룹으로

 

<jyyoon.shop>

<test1.jyyoon.shop>

<test2.jyyoon.shop>

> Host Header에 따라 분기처리 되는 것 확인

 

 

 

2. Test2 -  Path Pattern 기반 분기 처리 테스트

 

( jyyoon.shop/test1 , jyyoon.shop/test2 로 입력했을 때 path 기반으로 라우팅되는지 확인 )

 

<테스트 전 준비>

Vm 2개 ( apache 서버 )

- 첫번째 서버에는 /var/www/html/test1 디렉터리 생성 후 test1 디렉터리에 해당 서버 호스트네임이 뜨도록 설정한 index.html 생성

- 두번째 서버에는 /var/www/html/test2 디렉터리 생성 후 test2 디렉터리에 해당 서버 호스트네임이 뜨도록 설정한 index.html 생성

로드밸런서 생성 - yjy-lb(ALB) / 리스너 설정 (프로토콜 : HTTP / 포트 : 80) 

타겟그룹은 2개(yjy-planet-web-tg, yjy-test-tg)를 생성 - 각 그룹마다 하나의 웹서버를 타겟으로 설정 ( 프로토콜 : HTTP / 포트 : 80 / health check : 각각 /test1, /test2 )

도메인 확보(jyyoon.shop) - 레코드 추가( jyyoon.shop -> 로드밸런서(yjy-lb))

 

<타겟그룹 1>

 

<타겟그룹 2>

 

<로드밸런서 규칙 조회/변경>

 

 > 경로 뒤에 애스터리스크(*)를 붙인 이유는 해당 경로로 들어오는 모든 요청을 해당 타겟 그룹으로 보내기 위해서 붙임

 

 

> Path Pattern에 따라 분기처리 되는 것 확인