[5부 20장] 리다이렉션과 부하 균형

[im-gnar]

20. 리다이렉션과 부하 균형

20.1 왜 리다이렉트인가?

• 신뢰할 수 있는 HTTP 트랜잭션의 수행 fault tolerance
• 지연 최소화 load balancing
• 네트워크 대역폭 절약 cache

20.2 리다이렉트할 곳

• 서버, 프락시, 캐시, 게이트웨이는 클라이언트 입장에선 모두 서버이다
  • 모두 리다이렉션을 지원
  • 특정 종류의 end point만을 위해 설계된 리다이렉션도 존재함
• 웹 서버
  • IP 별로 요청을 다룸
  • 여러 곳에서 온 요청들을 각각 최적인 웹 서버로 전송
• 프락시
  • 프로토콜별로 요청을 다룸

20.3 리다이렉션 프로토콜의 개요

리다이렉션의 목표: HTTP를 가장 빠른 가용한 웹 서버로 보내는 것

• HTTP 애플리케이션과 라우팅 장치에 영향을 받음
  • 브라우저가 메세지를 프락시 서버로 보내도록 설정이 가능 (프락시로만 가능)
  • DNS resolver 는 클라이언트의 위치에 따라 다른 IP 주소를 내려줄 수 있음
  • 스위치 또는 라우터 장비에서 TCP/IP 주소를 기반으로 라우팅할 수 있음
  • 웹 서버는 HTTP 리다이렉트를 사용해 요청을 다른 웹 서버로 가도록 할 수 있음

일반 리다이렉션 방법

프락시와 캐시 리다이렉션 기법

20.4 일반적인 리다이렉션 방법

방법	description	특징	단점
HTTP 리다이렉션	리다이렉트 서버가 가용한 서버 중 부하가 가장 적은 (최적의) 서버를 찾아 리다이렉트	리다이렉트 서버가 클라이언트의 IP 주소를 안다	- 리다이렉트 서버의 부하가 커질 수 있음 - RTT 가 한번 더 발생하기 때문에 지연이 커짐 - 리다이렉트 서버 고장시 사이트 고장(SPOF)
DNS 리다이렉션	- DNS는 하나의 도메인에 여러 IP가 결부되는 것을 허용 - 서버들을 모니터링하는 authoritative server 가 존재 - 다양한 알고리즘을 통해 반환 서버 결정		- DNS 캐싱으로 인한 부하분산 실패 - 클라이언트가 아닌 로컬DNS 서버의 IP주소에 기반한 결정
임의 캐스트 어드레싱
(Anycast)	백본 라우터의 최단거리 라우팅에 의존하는 방법	- 광고를 통해 백본 라우터에 최단거리 웹 서버임을 알림 - 백본 라우터가 임의 캐스트 주소를 목적지로 하는 패킷을 받으면 자신이 알고 있는 최단거리 웹 서버로 라우팅	- 반드시 라우팅 프로토콜이 있어야함 - 주소 충돌 처리가 가능해야함(실패 시 라우팅 누수 발생)
IP MAC 포워딩	L4 스위치를 이용해 특정 IP와 포트에 대한 요청을 특정 MAC 장비로 포워딩		웹서버나 프록시는 스위치와 한 홉 거리에 있어야함
IP 주소 포워딩	L4 스위치를 이용해 특정 IP와 포트에 대한 요청을 목적지 IP주소의 변경에 따라 라우팅	- IP MAC 포워딩과 다르게 목적지 서버가 한 홉 거리에 있을 필요가 없음 - 스위치에서 NAT를 해줌	라우팅 대칭성 : 모든 응답은 클라이언트의 요청을 받은 스위치에게 돌아가야한다 - 패킷의 출발지 IP를 스위치 IP주소로 바꾼다(완전 NAT) - 웹서버가 결제나 인증에 필요할 수도 있는 클라이언트 IP를 알 수 없다. - 출발지 IP가 클라이언트 주소남는다면 스위치를 거치지 않고 응답을 내려주는 경로가 없어야함(반 NAT) - 웹서버가 클라이언트 IP를 알 수 있으나 약간의 네트워크 통제가 필요
네트워크 구성요소 제어 프로토콜 NECP	NECP는 라우터, 스위치 등의 NE들이 웹서버,프락시 등 SE와 대화하게 해준다. - SE가 NE에 부하 균형 정보 제공 - MAC 포워딩, GRE 캡슐화, NAT 와 같은 패킷 전달 방식들을 제공	예외 개념 지원

• 라운드 로빈
  • 웹 서버 팜 전체에 대한 부하 균형 유지에 초점
  • 서버의 위치와 상태에 대한 고려가 없음
  • 다중 주소 집합의 첫 번째 주소만 사용하는 클라이언트를 고려해 룩업 당 주소를 순환시켜 첫 번째에 위치하는 주소를 다르게 한다
• 부하 균형 알고리즘
  • 웹 서버의 부하를 추적하여 부하가 가장 낮은 서버를 목록의 첫 번째에 위치시킴
• 근접 라우팅 알고리즘
  • 사용자와 가장 가까운 위치의 웹 서버로 라우팅
• 결함 마스킹 알고리즘
  • 네트워크 상태를 모니터링하여 장애 지점을 피해 라우팅

ref. DNS란 뭐고, 네임서버란 뭔지 개념정리

20.5 프락시 리다이렉션 방법

방법	description	특징	단점
명시적 브라우저 설정	브라우저는 프락시 이름, IP주소, 포트번호를 설정할 수 있음		- 프락시로부터 응답이 없어도 원서버로 가지 않음 - 네트워크 아키텍처 변경을 브라우저 사용자에게 전파하기 어려움
프락시 자동 설정	PAC을 통한 브라우저의 동적 프락시 설정 변경	네트워크 아키텍처가 변경되어도 PAC 파일만 업데이트하면 브라우저는 해당 설정을 읽어서 반영
웹 프락시 자동 발견 프로토콜 WPAD	브라우저가 수동 설정이나 트래픽 인터셉터에 의존하지 않고 프락시를 발견할 수 있는 방법을 제공 (관련 내용은 이전에 6장에서 다룸)	WPAD 는 HTTP 클라이언트가 PAC 파일 위치를 알아내 적절한 프락시 서버 이름을 알 수 있게 한다 WPAD 시작 시점은 웹 클라이언트 시작 시, 네트워크 스택으로부터 변경 이벤트를 받을 때, PAC이 만료됏을때	발견 프로토콜이 여러 가지 존재 프락시 사용에 대한 설정이 브라우저마다 다름

20.6 캐시 리다이렉션 방법

WCCP 리다이렉션

• 라우터가 캐시를 검사하고 특정 트래픽을 특정 캐시로 포워딩

WCCP 리다이렉션 동작

• WCCP 를 제공하는 라우터, 다른 캐시와 의사소통이 가능한 캐시가 포함된 네트워크
• 라우터 집합과 그 대상이 되는 캐시들이 WCCP 서비스 그룹을 구성
  • 서비스 그룹 설정으로 트래픽 분류와 로드밸런싱 방법에 대해 명시
• HTTP 트래픽 리다이렉션 설정이 되있다면 HTTP 요청을 서비스 그룹의 캐시로 보낸다
• 서비스 그룹 라우터는 HTTP 요청을 아이피 주소의 해시나 마스크/값 집합 대조 스킴 중 하나에 근거하여 서비스 그룹의 캐시를 선택
• 라우터는 요청 패킷을 캐시의 아이피 주소와 함께 캡슐화하거나 IP MAC 포워딩하여 캐시로 보냄
• 캐시가 요청을 처리할 수 없다면 라우터로 돌아와 평범하게 포워딩
• 서비스 그룹의 구성원들은 지속적인 하트비트 메세지로 다른 구성원들의 가용성을 체크

WCCP 메세지

메세지 구성요소

• 각 WCCP2 메세지를 헤더와 구성요소로 구성 되어있다
• 헤더는 메세지 종류, WCCP 버전, 헤더를 제외한 메세지 길이를 포함
• 각 구성요소는 종류와 길이를 서술하는 4바이트 헤더로 시작
  

서비스 그룹

• 서비스 그룹은 WCCP 메세지를 교환할 수 있는 라우터와 캐시들의 집합으로 구성
• 라우터들은 웹 트래픽을 서비스 그룹의 캐시로 포워딩
• 라우터와 캐시는 Here I am 과 I See You 메세지로 서비스그룹 설정 정보를 교환

GRE 패킷 캡슐화

• WCCP 지원 라우터들은 HTTP 패킷을 특정 서버의 IP 주소와 함께 캡슐화해서 리다이렉트함
• GRE 임을 나타내는 IP 헤더 proto 필드로 식별
• 클라이언트 IP 주소를 잃어버리지 않는다
  

WCCP 부하 균형

• 라우터들과 서버들은 지속적인 하트비트 메세지로 가용상태를 체크
• 가용불가로 판단되면 라우터는 트래픽을 리다이렉트하지 않고 인터넷으로 포워딩

20.7 인터넷 캐시 프로토콜 (ICP)

• 형제 캐시에 일어난 캐시 적중을 확인할 수 있도록 하는 프로토콜 (캐시 클러스터링)
• 원 서버보다 형제 캐시로부터 컨텐츠를 받아오는 비용이 더 적을 것을 전제로 함
• 근처 모든 캐시에 특정 URL 을 가지는지 질의
  • 응답은 HIT / MISS
  • HIT 응답을 준 캐시에 HTTP 커넥션을 열 수 있다
• Network byte order 를 따르는 32비트 구조체, UDP 기반

메세지	설명	bit
OP 코드	메세지의 의미를 서술 ICP_OP_QUERY ,ICP_OP_MISS, ICP_OP_HIT	8
버전	ICP 버전번호를 의미하는	8
길이	메세지의 총 길이를 바이트 단위로 나타낸 것	16
요청번호	추적을 위한 고유 요청번호
옵션	ICP 동작 변경 플래그를 담은 비트 백터 ICP_FLAG_HIT_OBJ : 문서 데이터 ICP 반환 가능 여부 ICP_FLAG_SRC_RTT : 형제 캐시가 원서버로 왕복하는 시간 추정	32
옵션 데이터	(선택적) 옵션 기능을 위한 예약	32
발송자 호스트 주소	발송자의 IP 주소로, 실제로는 사용되지않음	32
페이로드	메세지 형태에 따라 다름 ICP_OP_QUERY일 경우 : 요청 호스트 주소, NUL로 끝나는 URL ICP_FLAG_HIT_OBJ일 경우: NUL로 끝나는 URL, 16비트 객체 크기, 객체 데이터

20.8 캐시 배열 라우팅 프로토콜(CARP)

• 프락시 서버의 배열이 하나의 캐시처럼 보이도록 해주는 프로토콜
• ICP로 연결된 프락시들은 프락시 서버 전체에 걸친 웹 객체에 대한 중복 엔트리가 허용되는 독립적 객체
• CARP는 해시를 사용해 웹 객체를 특정 프락시에 매핑하여 중복을 허용하지 않음
• CARP는 어느 하나의 프락시가 다운되면 해시 함수가 수정되어야하기 때문에, 캐시된 컨텐츠들의 재배치로 인한 비용이 든다

20.9 하이퍼텍스트 캐싱 프로토콜(HTCP)

• ICP는 HTTP/0.9 기반으로 설계됨
  • 헤더가 없는 단순 URL 만 보내도록 되어있음
    -HTCP 는 형제 캐시에 질의할 때 URL 과 모든 요청 및 응답 헤더를 사용

Appendix

Non-authoritative answer? 🤔

그냥 뭔가해서 찾아봣슴다

위에서 나온 L4 스위치 관련 ++
ref. L4/L7 스위치의 대안, 오픈 소스 로드 밸런서 HAProxy
ref. 로드 밸런서(Load Balancer)란?

[ruthetum]

A 레코드, CNAME
https://dev.plusblog.co.kr/30