일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |
- grafana
- aws-dop
- Prometheus
- pod
- Codepipeline
- Codebuild
- HTTPS Redirect
- ALB
- k8s
- SSL Offload
- alertmanager
- Codedeploy
- ncp
- slack
- AWS
- NFS Client Privisioner
- cicd
- Persistent Volume Claim
- RKE2
- DevOps
- ingress
- emptyDir Volume
- emptyDir
- Naver cloud platform
- codecommit
- node exporter
- kubernetes
- Persistent Volume
- volume
- ingress controller
- Today
- Total
Cloud SA's This and That
[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에 따라 분기처리 되는 것 확인