레이어 7 로드 밸런싱은 HTTP 헤더 및 URL과 같은 애플리케이션 레이어 정보를 기반으로 합니다.
레이어 4 인스턴스와 레이어 7 인스턴스의 차이점은 리얼 서버에서 로드 밸런싱을 위해 트래픽을 포워딩하는 방법을 결정하는 기준으로 레이어 4 또는 레이어 7 정보를 사용하는지 여부입니다.
예를 들어 레이어 4 CLB 인스턴스는 레이어 3 IP 주소(VIP) 및 레이어 4 포트 번호를 기반으로 로드 밸런싱이 필요한 트래픽을 결정합니다. 처리할 트래픽에 대해 NAT(Network Address Translation)를 수행한 다음 리얼 서버로 전달합니다. 또한 TCP 또는 UDP 트래픽을 처리한 서버를 기록하고 이 연결의 모든 후속 트래픽을 처리를 위해 동일한 서버로 전달합니다.
레이어 7 CLB는 애플리케이션 레이어 기능과 결합된 레이어 4 CLB 인스턴스입니다.
예를 들어 동일한 Web 서버의 CLB 인스턴스는 VIP 및 포트 80 외에도 레이어 7 URL, 브라우저 유형 및 언어를 기반으로 처리해야 하는 트래픽을 식별할 수 있습니다.
레이어 7 로드 밸런싱은 ‘콘텐츠 교환’이라고도 하며, 메시지의 의미 있는 애플리케이션 레이어 콘텐츠와 CLB 인스턴스에 구성된 서버 선택 방법을 기반으로 내부 서버가 선택됩니다.
실제 애플리케이션 레이어 콘텐츠를 기반으로 서버를 선택하려면 레이어 7 CLB 인스턴스가 클라이언트로부터 실제 애플리케이션 레이어 콘텐츠가 포함된 메시지를 수신하기 위해 최종 서버의 프록시로서 클라이언트와 연결(3방향 핸드셰이크)을 설정해야 합니다. 그런 다음 메시지의 특정 필드와 CLB 인스턴스에 구성된 서버 선택 방법에 따라 내부 서버를 선택합니다. 이 경우 CLB 인스턴스는 프록시 서버에 가깝고 각각 프런트엔드 클라이언트 및 리얼 서버와 TCP 연결을 설정합니다.
TCP는 연결 지향 프로토콜입니다. TCP는 데이터를 수신 및 전송하기 전에 상대방과 신뢰할 수 있는 연결을 설정해야 합니다. UDP는 메시지 지향(연결 없는) 프로토콜입니다. 상대방과 3방향 핸드셰이크를 수행하지 않고 데이터 패킷을 직접 전송합니다. UDP는 화상 채팅, 금융 시장 정보의 실시간 푸시, DNS 및 IoT와 같이 신뢰성보다 실시간성에 중점을 둔 시나리오에 적합합니다.
Cookie 삽입 모드에서는 CLB 인스턴스가 Cookie를 삽입하므로 리얼 서버는 수정할 필요가 없습니다. 첫 번째 HTTP 요청을 하면 (Cookie 없이) CLB 인스턴스에 들어가고 로드 밸런싱 알고리즘 정책에 따라 리얼 서버를 선택하고 서버로 요청을 보냅니다. 그런 다음 리얼 서버는 CLB 인스턴스로 다시 전송되는 HTTP 응답(Cookie 제외)을 보내고, CLB 인스턴스는 Cookie를 삽입하고 HTTP 응답(Cookie 포함)을 클라이언트에 반환합니다.
두 번째 HTTP 요청(CLB 인스턴스가 마지막으로 삽입한 Cookie 사용)을 하면 CLB 인스턴스에 들어가 Cookie의 세션 지속성 값을 읽고(위와 동일한 Cookie 포함) 지정된 리얼 서버로 요청을 보냅니다. 서버는 HTTP 응답을 제공합니다. 서버가 Cookie를 작성하지 않기 때문에 응답에 Cookie가 포함되지 않습니다. 응답 트래픽이 CLB 인스턴스에 다시 입력되면 CLB는 업데이트된 세션 지속성 Cookie를 응답에 기록합니다.
콘솔에서 5초마다 상태 확인 패킷을 보내도록 구성했다고 가정합니다. 그러나 리얼 서버는 1초에 하나 이상의 상태 확인 요청을 받습니다.
자주 발생하는 상태 확인은 CLB 상태 확인의 구현 메커니즘과 관련이 있습니다. client의 100만 요청이 리얼 서버로 전송되기 전에 4개의 CLB 인스턴스에 분산되고 각 CLB 리얼 서버에서 개별적으로 상태 확인을 수행한다고 가정합니다. CLB 인스턴스가 5초마다 상태 확인 요청을 보내도록 구성된 경우 각 CLB 인스턴스는 5s마다 상태 확인 요청을 보냅니다. 이것이 리얼 서버가 여러 상태 확인 요청을 수신하는 이유입니다. 예를 들어 클러스터에 8개의 CLB 인스턴스가 있고 각각 5s마다 요청을 보내는 경우 리얼 서버는 5s 동안 8개의 상태 확인 요청을 수신할 수 있습니다.
이 구현 방식의 장점은 고효율, 정확한 검사, 잘못된 제거 방지입니다. 예를 들어 클러스터의 CLB 서버 8개 중 하나에 장애가 발생하더라도 나머지 7개 서버는 정상적으로 트래픽을 전달할 수 있습니다.
따라서 리얼 서버 확인 빈도가 너무 높은 경우 더 긴 확인 간격(예시: 15s)을 구성할 수 있습니다.
브라우저를 통해 http://example.com 웹사이트를 방문할 때 서버에 대한 루트 디렉터리로의 리디렉션이 필요합니다. 브라우저를 통해 http://example.com/ 웹사이트를 방문하면 서버는 웹사이트 루트 디렉터리의 기본 페이지를 직접 반환합니다. 마찬가지로 http://cloud.tencent.com/movie가 URL 재작성을 통해 http://cloud.tencent.com/movie/로 리디렉션되는 경우 http://cloud.tencent.com/movie를 입력하면 추가 URL 재작성 프로세스로 인해 약간의 성능 저하 및 시간 소모가 발생합니다. 다만, URL 재작성을 통해 http://cloud.tencent.com/product가 http://cloud.tencent.com/product/ 이외의 페이지로 리디렉션되는 경우 보조 URL 뒤에 /를 추가할지 고려해야 합니다.
Tencent Cloud CLB에서 프런트엔드와 백엔드 포트 번호가 다른 경우, HTTP 리디렉션 후 포트 번호 변경을 방지하고 정상적인 페이지 액세스를 보장하기 위해 보조 페이지 방문 시 보조 URL 뒤에 /를 추가해야 합니다.
레이어 7 포워딩에서 CLB 인스턴스의 포트 80과 리얼 서버의 포트 8081이 수신된다고 가정합니다. 클라이언트가 http://www.example.com/movie에 액세스하면 액세스 요청은 CLB 인스턴스를 통해 리얼 서버로 포워딩되고, 서버는 http://www.example.com:8081/movie/ (수신 포트는 8081)로 리다이렉트 합니다. 이 경우 클라이언트 액세스가 실패합니다(포트 오류).
따라서 http://www.example.com/movie/ 와 같이 /를 사용하여 보조 URL에 대한 액세스 요청을 다시 작성하는 것이 좋습니다. 이렇게 하면 HTTP 리디렉션을 방지하고 불필요한 판단을 제거하며 원치 않는 로드를 줄일 수 있습니다. HTTP 리디렉션이 필요한 경우 CLB 수신 포트가 리얼 서버와 동일한지 확인하십시오.
공중망 레이어 7 IPv4 및 IPv6 CLB 인스턴스는 X-Forwarded-For 메소드를 사용하여 실제 클라이언트 IP를 가져옵니다. Client IP 가져오기는 기본적으로 CLB 인스턴스에서 활성화되지만 리얼 서버에서 구성해야 합니다. 자세한 내용은 Obtaining Real Client IPs Over IPv4 CLBs를 참고하십시오.
공중망 레이어 4 IPv4 및 IPv6 CLB 인스턴스(TCP를 통해)는 백엔드 CVM 인스턴스에서 실제 클라이언트 IP를 직접 가져올 수 있으며 추가 구성이 필요하지 않습니다. 2016년 10월 24일 이후 구매한 사설망 레이어 4 CLB 인스턴스의 경우 SNAT(Source Network Address Translation)가 수행되지 않습니다. 추가 구성 없이 server에서 실제 client IP를 직접 가져올 수 있습니다.
CVM별 청구 계정의 CLB 인스턴스에는 트래픽 또는 대역폭 요금이 부과되지 않습니다. CLB 서비스에서 생성된 모든 공중망 트래픽 요금은 바인딩된 백엔드 CVM 인스턴스에 부과됩니다. 총 CLB 송신 트래픽의 변동을 추적할 필요가 없도록 CVM 인스턴스를 구매하고 합리적인 피크 대역폭 임계값을 구성할 때 공중망 대역폭에 대해 트래픽별 청구를 선택하는 것이 좋습니다. 인터넷 Web 비즈니스의 트래픽은 변동이 심하여 정확하게 예측할 수 없습니다. 대역폭별 청구를 선택하면 과도한 대역폭을 구입하는 것이 비용 효율적이지 않지만 대역폭이 충분하지 않은 경우 비즈니스 피크 시 패킷 손실이 발생할 수 있습니다.
CLB 리얼 서버의 보안 그룹은 어떻게 설정하나요? 액세스 블록리스트를 구성하는 방법은 무엇입니까?
CLB 보안 그룹 구성
리얼 서버에 대해 보안 그룹 규칙이 구성된 경우 CLB 인스턴스가 서버와 통신하지 못할 수 있습니다. 따라서 레이어 4 및 레이어 7 포워딩 시 리얼 서버의 보안 그룹을 모든 액세스 요청을 허용하도록 설정하는 것을 권장합니다. 보안 그룹이 활성화되어 있고 기본적으로 모든 프로토콜 또는 IP 세그먼트에서 액세스가 허용되는 경우 모든 클라이언트의 IP를 서버 IP의 보안 그룹 규칙에 맞게 구성해야 합니다.
일부 악성 IP의 경우 보안 그룹의 최상위 규칙에 추가하여 리얼 서버에 액세스하지 못하도록 할 수 있습니다. 그런 다음 모든 IP(0.0.0.0)에서 로컬 서비스 포트로의 액세스 요청을 허용할 수 있으므로 일반 클라이언트가 서버에 액세스할 수 있습니다. 보안 그룹 규칙은 우선 순위에 따라 정렬되고 위에서 아래로 매칭됩니다.
VPC에서 레이어 7 CLB 포워딩에 대해 상태 확인이 구성된 경우 리얼 서버 보안 규칙에서 CLB VIP를 허용해야 합니다. 그렇지 않으면 상태 확인이 실패할 수 있습니다.
액세스 블록리스트 설정
일부 Client IP가 액세스 요청을 거부하도록 블록리스트를 구성해야 하는 경우 클라우드 서비스와 연결된 보안 그룹을 구성할 수 있습니다. 보안 그룹 규칙은 다음과 같이 구성해야 합니다.
주의사항
아래 단계를 주어진 순서대로 엄격하게 따르십시오. 그렇지 않으면 블록리스트 구성이 실패할 수 있습니다.
거부할 client IP + 포트를 보안 그룹에 추가하고 정책 열에서 이 IP의 액세스를 거부하는 옵션을 선택합니다.
기본적으로 모든 IP에서 포트에 대한 액세스 요청을 허용하도록 위의 구성을 완료한 후 다른 보안 그룹 규칙을 추가합니다.
구성이 완료되면 보안 그룹 규칙은 다음과 같습니다.
사설망 CLB의 VIP는 해당 VPC에서 오는 클라이언트 Ping만 지원하며, 다른 VPC나 로컬 IDC에서 오는 클라이언트 Ping은 대답이며 실제 링크를 반영할 수 없기 때문에 Ping을 보장할 수 없습니다. (예: CCN, 피어링 연결 등으로 VPC에 액세스하는 경우, Telnet을 사용하여 테스트하는 것이 좋습니다)
사설망 CLB 인스턴스의 경우 CVM은 클라이언트와 서버가 될 수 없습니다. CLB 인스턴스가 동일한 Client IP 및 Server IP를 읽으면 액세스가 실패합니다.
클라이언트를 서버로 사용해야 하는 경우 최소 2개의 리얼 서버를 바인딩하십시오. CLB에는 자동 루프백을 방지하기 위한 관련 정책이 있습니다. Client A가 CLB 인스턴스에 액세스하면 CLB 인스턴스는 Client A가 아닌 리얼 서버에 요청을 자동으로 스케쥴링합니다.
공중망의 액세스 트래픽을 차단하고 CLB 인스턴스의 액세스만 허용하도록 보안 그룹이 있는 백엔드 CVM 인스턴스를 구성했습니다. 그러나 적용되지 않습니다.
트래픽이 CLB 인스턴스를 통과하는 백엔드 CVM 인스턴스에 액세스할 수 있도록 하려면 백엔드 CVM 및 CLB 보안 그룹 모두에서 공중망의 트래픽을 허용해야 합니다. 먼저 백엔드 CVM 보안 그룹의 공중망을 통한 CLB VIP의 액세스 트래픽만 허용한 다음 필요에 따라 CLB 보안 그룹의 공중망 액세스 IP를 허용하는 것이 좋습니다.
예
아니오
문제 해결에 도움이 되었나요?