7주차-1 네트워크(부하분산) 서비스

아이수베어·2022년 1월 21일
0

AFOS[2기]

목록 보기
15/29
post-thumbnail

ELB란?

배경: 고가용성 환경 구성 요구

AWS에서 제공하는 로드 밸런싱 기술이다.
일반적으로 최소 2개의 AZ 사용(복수의 가용영역으로 고가용성 보장)하며 사용자는 Route 53을 통해서 도메인 주소로 접근한다.

ELB 구성 리스너와 대상 그룹

스크린샷 2021-07-21 오후 9 48 42

ELB 종류 및 기능

ALB

프로토콜: HTTP, HTTPS
처리속도: 느림
플랫폼: VPC
OSI 계층: Layer 7(Application)
동일 인스턴스로 다수의 포트 전달: 지원
IP를 통한 관리: 미지원
프라이빗 링크 지원: 미지원
경로 기반 라우팅: 지원
호스트 기반 라우팅: 지원

NLB

프로토콜: TCP, UDP, TLS
처리속도: 빠름
플랫폼: VPC
OSI 계층: Layer 4 (TransPort)
동일 인스턴스로 다수의 포트 전달: 지원
IP를 통한 관리: 지원
프라이빗 링크 지원: 지원
경로 기반 라우팅: 미지원
호스트 기반 라우팅: 미지원

CLB

프로토콜: TCP, TLS, HTTP, HTTPS
처리속도: 중간
플랫폼: VPC, EC2-Classic
OSI 계층: -
동일 인스턴스로 다수의 포트 전달: 미지원
IP를 통한 관리: 미지원
프라이빗 링크 지원: 미지원
경로 기반 라우팅: 미지원
호스트 기반 라우팅: 미지원

ALB VS NLB

ALB는 HTTP/HTTPS 처리에 특화된 애플리케이션 레밸의 로드 밸런서이다.
L7 라우팅 동작 가능, 람다(Lambda)를 대상 그룹 지정이 가능하다.

NLB는 TCP, UDP, TLS 처리할 수 있는 OSI 4계층 레벨의 로드 밸런서이다.
높은 처리량, 고정 IP를 보유한다.

교차 영역 로드 밸런싱

로드 밸런서의 노드는 클라이언트로부터 요청을 가져와서 등록된 대상에 분산한다.
교차 영역 로드 밸런싱을 활성화하면 각 로드 밸런서 노드가 활성화된 모든 가용영역에 있는 등록된 대상 간에 트래픽을 분산한다.
교차 영역 로드 밸런싱을 비활성화하면 각 로드 밸런서 노드가 해당 가용 영역에 있는 등록된 대상 간에만 트래픽을 분산한다.

교차 영역 로드 밸런싱이 비활성화되어 있는 경우

스크린샷 2021-07-21 오후 10 00 55

교차 영역 로드 밸런싱이 활성화되어 있는 경우

스크린샷 2021-07-21 오후 10 01 02



심화 옵션) Linux OS에 snmpget 의 수집 할 수 있는 OID 정보 참고

sysDescr

장비에 대한 설명 정보
Vendor에 따라 사이즈의 차이가 있으며 장비 정보 출력 시 부가 정보로 출력한다
1.3.6.1.2.1.1.1.0 - sysDescr

sysObjectID

장비의 고유한 ID값을 리턴 하며, 해당 값을 이용하여, 장비의 Vendor, 장비 종류를 고유하게 관리할 수 있다.
1.3.6.1.2.1.1.2.0 - sysObjectID

sysUpTime

장비가 부팅되어 현재까지 동작한 milli-second 값이며, 쿼리 시 업데이트 되는 정보
1.3.6.1.2.1.1.3.0 - sysUpTime

sysName

사용자가 장비에 설정한 장비명, 설정하지 않았을 경우 Null 결과값을 출력한다.
Null값 출력 시 해당 장비명 출력은 IP주소 혹은 장비 Alias명으로 한다.
1.3.6.1.2.1.1.5.0 - sysName

심화 정보

reload와 restart의 차이점

restart: 해당 서비스를 stop하고, start 해주는 작업을 한다.
접속 상태에 따라 몇십초 가량의 시간이 소요될 수 있다. 이 시간동안에는 접속이 안되거나 이상현상이 발생할 수 있다.

reload: 서버를 종료하지 않은 채 conf 설정 파일들만 새로 갱신해준다는 차이점이 있다.
기존의 접속자들은 과거의 설정대로 접속을 유지한채 새롭게 연결되는 접속부터 변경점이 적용된다.

현업에서는 최대한 reload로 적용을 하고, reload가 불가한 경우에 restart를 사용하자

Client IP를 가져오는 법

웹 애플리케이션이 client IP를 추출하기 위해서 Http request header를 다음과 같은 순서로 찾는다.

  1. Proxy-Client-IP: 특정 웹 애플리케이션에서 사용 (ex. WebLogic Connector - mod_wl)
  2. WL-Proxy-Client-IP: 특정 웹 애플리케이션에서 사용 (ex. WebLogic Connector - mod_wl)
  3. X-Forwarded-For: HTTP RFC 표준에는 없지만 사실상 표준이다.
  4. request.getRemoteAddr()
  5. CLIENT_IP

X-Forwarded-For: (client), (proxy1), (proxy2)

요청이 여러 프록시를 거치는 경우 x-Forwarded-For 요청 헤더의 clientIPAddress 다음에는 로드 밸런서에 도달하기 전에 요청이 통과하는 각 연속 프록시의 IP주소가 온다.
따라서 가장 오른쪽의 IP주소는 가장 최근의 프록시의 IP주소이고 가장 왼쪽의 IP주소는 원래 클라이언트의 IP주소이다.

access log 를 보면 외부에서 지속적인 접속 및 취약점 시도 등이 이루어짐을 알 수 있다. 특히 /admin, /login

NLB는 클라이언트 IP확인을 위한 HTTP 헤더의 XFF를 왜 사용하지 못할까?

NLB는 Layer 4 계층까지만 이해하고 통제가 가능하여 HTTP 헤더를 이해하지 못한다.



HTTP 프로토콜에 대해서 학습하면 큰 도움이 된다.





참고 자료 : AFOS[2기] 노션 내용
사진 출처: AFOS[2기] 노션 내용, https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones

profile
Junior Cloud Engineer

0개의 댓글