CLB 인스턴스는 상태 확인을 통해 리얼 서버의 가용성을 결정하여 프런트엔드 비즈니스가 리얼 서버 예외의 영향을 받는 것을 방지하고 비즈니스의 전반적인 가용성을 향상시킵니다.
상태 확인이 활성화되면 백엔드 CVM 인스턴스의 가중치(0 포함)에 관계없이 CLB 인스턴스는 항상 상태 확인을 수행합니다. 인스턴스 목록 페이지 또는 리스너의 바인딩된 리얼 서버 세부 정보 페이지의 상태 열에서 ‘상태 확인’ 상태를 확인할 수 있습니다.
백엔드 CVM 인스턴스가 비정상인 경우 CLB 인스턴스는 새 요청을 비정상 인스턴스가 아닌 다른 일반 CVM 인스턴스에 자동으로 포워딩합니다.
비정상적인 CVM 인스턴스가 복구되면 CLB 서비스에서 다시 사용되며 새로운 요청을 받습니다.
모든 리얼 서버가 비정상으로 확인되면 요청이 모든 백엔드 CVM 인스턴스로 포워딩됩니다.
상태 확인이 비활성화된 경우 CLB 인스턴스는 비정상적인 서버를 포함한 모든 리얼 서버로 트래픽을 포워딩합니다. 따라서 CLB 인스턴스의 상태 확인을 활성화하여 리얼 서버를 자동으로 확인하고 비정상적인 서버를 제거하는 것이 좋습니다.
상태 확인 상태
백엔드 CVM 인스턴스의 상태 확인 상태 설명은 다음과 같습니다.
상태
설명
트래픽 포워딩 여부
감지 중
확인 간격 × 정상 임계값 기간 동안의 새 백엔드 CVM 인스턴스의 상태입니다. 예를 들어 확인 간격이 2s이고 정상 임계값이 3회라고 가정하면 백엔드 CVM 인스턴스는 6s 동안 이 상태를 유지합니다.
CLB는 ‘감지 중’인 백엔드 서비스로 트래픽을 포워딩하지 않습니다.
정상
리얼 서버 정상
CLB는 트래픽을 ‘정상’ 백엔드 서비스로 포워딩합니다.
비정상
리얼 서버 비정상
CLB는 ‘비정상’ 백엔드 서비스로 트래픽을 포워딩하지 않습니다.
레이어 4 리스너 또는 레이어 7 URL 규칙에 따라 CLB 인스턴스가 모든 리얼 서버가 비정상임을 감지하면 모든 리얼 서버로 요청을 포워딩합니다.
비활성화됨
상태 확인 비활성화
CLB는 트래픽을 백엔드 서비스로 포워딩합니다.
TCP 상태 확인
레이어 4 TCP 리스너의 경우 SYN 패킷, 즉 TCP 3방향 핸드셰이크를 통해 백엔드 CVM 인스턴스의 상태를 가져오도록 TCP 상태 확인을 구성할 수 있습니다. 또한 이를 위해 프로토콜의 요청 및 반환 내용을 사용자 지정할 수 있습니다.
TCP 상태 확인 메커니즘은 다음과 같습니다.
1. CLB 인스턴스는 백엔드 CVM 인스턴스(사설망 IP+상태 확인 포트)에 SYN 연결 요청 패킷을 보냅니다.
2. SYN 요청 패킷을 수신한 후 백엔드 CVM 인스턴스는 포트가 정상적으로 수신 중이면 SYN+ACK 응답 패킷을 반환합니다.
3. CLB 인스턴스가 응답 제한 시간 내에 반환된 SYN+ACK 응답 패킷을 받으면 리얼 서버가 정상이고 상태 확인 결과가 성공적임을 나타냅니다. 그런 다음 CLB 인스턴스는 백엔드 CVM 인스턴스에 TCP 재설정(RST) 패킷을 보내 TCP 연결을 끊습니다.
4. CLB 인스턴스가 응답 제한 시간 내에 반환된 SYN+ACK 응답 패킷을 수신하지 못하면 리얼 서버가 비정상적이며 상태 확인 결과가 실패한 것입니다. 그런 다음 CLB 인스턴스는 백엔드 CVM 인스턴스에 TCP 재설정(RST) 패킷을 보내 TCP 연결을 끊습니다.
UDP 상태 확인
레이어 4 UDP 리스너의 경우 Ping 명령을 실행하고 UDP 감지 패킷을 상태 확인 포트로 전송하여 백엔드 CVM 인스턴스의 상태를 가져오도록 UDP 상태 확인을 구성할 수 있습니다. 또한 이를 위해 프로토콜의 요청 및 반환 내용을 사용자 지정할 수 있습니다.
UDP 상태 확인 메커니즘은 다음과 같습니다.
1. CLB 인스턴스는 백엔드 CVM 인스턴스의 사설망 IP에 Ping 명령을 보냅니다.
2. 그런 다음 CLB 인스턴스는 UDP 감지 패킷을 (사설망 IP+상태 확인 포트) 백엔드 CVM 인스턴스로 보냅니다.
3. Ping 명령이 성공하고 백엔드 CVM 인스턴스가 응답 제한 시간 내에 port XX unreachable오류를 반환하지 않으면 리얼 서버가 정상이고 상태 확인 결과가 성공임을 나타냅니다.
4. Ping 명령이 실패하거나 백엔드 CVM 인스턴스가 응답 제한 시간 내에 port XX unreachable 오류를 반환하는 경우 리얼 서버가 비정상적이며 상태 확인 결과가 실패임을 나타냅니다.
주의：
1. UDP 상태 확인은 ICMP를 기반으로 하므로 백엔드 CVM 인스턴스가 ICMP 패킷(즉, Ping 명령이 지원됨) 및 ICMP 포트에 연결할 수 없는 패킷(즉, 포트를 감지할 수 있음)에 응답하도록 허용되어야 합니다.
2. Linux 서버가 백엔드 CVM 인스턴스로 사용되는 경우 Linux 서버는 ICMP 공격으로부터 자신을 방어하는 메커니즘이 있으므로 높은 동시성 동안 ICMP 패킷을 보내는 서버의 속도가 제한됩니다. 이 경우 리얼 서버가 비정상이더라도 port XX unreachable 오류를 CLB 인스턴스에 반환할 수 없습니다. 그러면 CLB 인스턴스는 상태 확인 결과가 성공적이라고 판단하므로 리얼 서버의 실제 상태를 반환할 수 없습니다.
솔루션: 사용자 지정 입력 및 출력 문자열을 사용하여 UDP 상태 확인을 구성할 수 있습니다. 그래서 상태 확인에서 사용자 지정 입력 문자열은 리얼 서버로 보내지고, 그 결과는 CLB 인스턴스가 사용자 지정 응답 문자열을 받은 후에야 성공으로 판단됩니다. 이 메소드는 상태 확인 입력 문자열을 처리하고 사용자 지정 출력 문자열을 반환해야 하는 리얼 서버를 기
반으로 합
니다.
HTTP 상태 확인
레이어 4 TCP 리스너 및 레이어 7 HTTP/HTTPS 리스너의 경우 HTTP 요청을 전송하여 백엔드 CVM 인스턴스의 상태를 가져오도록 HTTP 상태 확인을 구성할 수 있습니다.
HTTP 상태 확인 메커니즘은 다음과 같습니다.
1. 상태 확인 구성에 따라 CLB 인스턴스는 HTTP 요청(대상 도메인 이름이 지정됨)을 백엔드 CVM 인스턴스(사설망 IP+상태 확인 포트+확인 경로)로 보낼 수 있습니다.
2. 요청을 수신한 후 백엔드 CVM 인스턴스는 해당 HTTP 상태 코드를 반환합니다.
3. CLB 인스턴스가 응답 제한 시간 내에 반환된 HTTP 상태 코드를 수신하고 HTTP 상태 코드가 설정된 값과 일치하면 상태 확인 결과가 성공했음을 나타내며, 그렇지 않으면 실패했음을 나타냅니다.
4. CLB 인스턴스가 응답 제한 시간 내에 백엔드 CVM 인스턴스로부터 응답을 받지 못하면 상태 확인 결과가 실패했음을 나타냅니다.
설명：
레이어 7 HTTPS 리스너의 경우 HTTPS 리스너 포워딩 규칙의 백엔드 프로토콜로 HTTP를 선택하면 HTTP 상태 확인이 수행됩니다. HTTPS를 선택하면 HTTPS 상태 확인이 수행됩니다.
HTTPS 상태 확인은 기본적으로 HTTP 상태 확인과 동일합니다. 차이점은 HTTPS 상태 확인에서 HTTPS 요청이 전송되고 백엔드 CVM 인스턴스 상태가 반환된 HTTPS 상태 코드에 의해 결정된다는 것입니다.
상태 확인 시간 창
CLB 상태 확인 메커니즘은 비즈니스 가용성을 향상시키지만 빈번한 상태 확인 오류는 불필요한 서버 전환을 유발하여 시스템 가용성을 손상시킬 수 있습니다. 따라서 상태 확인 시간 창에서 결과가 여러 번 동일한 경우에만 상태 확인 상태를 정상과 비정상으로 전환할 수 있습니다. 상태 확인 시간 창은 아래 요소를 기반으로 합니다.
상태 확인 구성
설명
기본값
응답 시간 초과
상태 확인에 대한 최대 응답 시간 초과입니다.
리얼 서버가 제한 시간 내에 응답하지 않으면 비정상으로 간주됩니다.
값 범위: 2 - 60초.
2 - 60초
확인 간격
두 상태 확인 사이의 간격입니다.
값 범위: 5 - 300초.
5초
비정상 임계값
상태 확인 결과가 n회(n은 사용자 지정 가능한 값) 동안 실패하면 백엔드 CVM 인스턴스가 비정상으로 간주되어 콘솔에 예외로 표시됩니다.
값 범위: 2 - 10회.
3회
정상 임계값
상태 확인 결과가 n회(n은 사용자 지정 가능한 값) 동안 성공하면 백엔드 CVM 인스턴스가 정상으로 간주되고 콘솔에 표시되는 상태가 정상입니다.
값 범위: 2 - 10회.
3회
레이어 4 상태 확인 시간 창의 계산은 다음과 같습니다.
설명：
레이어 4 상태 확인, 즉 TCP 상태 확인 또는 UDP 상태 확인, 두 확인 사이의 시간 간격은 결과가 성공하거나 응답 시간이 초과되는지 여부에 관계없이 설정된 값입니다.
실패한 결과가 있는 상태 확인의 시간 창 = 확인 간격 × (비정상 임계값 - 1)
아래 예시에서 상태 확인 응답 시간 초과는 2s, 확인 간격은 5s, 비정상 임계값은 3회이므로, 결과가 실패한 상태 확인의 시간 창 = 5 x (3-1) = 10s.
성공적인 결과가 있는 상태 확인의 시간 창 = 확인 간격 × (정상 임계값 - 1)
아래 예시에서 성공적인 상태 확인 응답의 기간은 1s, 확인 간격은 5s, 정상 임계값은 3회이므로 성공적인 결과가 있는 상태 확인의 시간 창 = 5 x (3-1) = 10s.
레이어 7 상태 확인 시간 창의 계산은 다음과 같습니다.
실패한 결과가 있는 상태 확인의 시간 창 = 응답 시간 초과 × 비정상 임계값 + 확인 간격 × (비정상 임계값 - 1)
아래 예시에서 상태 확인 응답 시간 초과는 2s, 점검 간격은 5s, 비정상 임계값은 3회이므로 실패한 결과가 있는 상태 점검의 시간 창 = 2 x 3 + 5 x (3-1) = 16s.
성공적인 결과가 있는 상태 확인의 시간 창 = 성공적인 상태 확인 응답 기간 × 정상 임계값 + 확인 간격 × (건강 임계값 - 1)
아래 예시에서 성공적인 상태 확인 응답의 주기는 1s, 확인 간격은 5s, 정상 임계값은 3회이므로 성공적인 결과가 있는 상태 확인의 시간 창 = 1 x 3 + 5 x (3-1) = 13s.
상태 확인 식별자
CLB 상태 확인이 시작된 후 리얼 서버는 일반 비즈니스 요청 외에 상태 확인 요청을 수신합니다. 상태 확인 요청에는 다음 속성이 있을 수 있습니다.
상태 확인 소스 IP는 CLB VIP 또는 100.64 IP 대역입니다.
레이어 4 리스너(TCP, UDP 및 TCP SSL)의 상태 확인 요청은 ‘HEALTH CHECK’으로 표시됩니다.
레이어 7 리스너(HTTP 및 HTTPS)의 상태 확인 요청의 경우 Header의 user-agent는 ‘clb-healthcheck’입니다.
예
아니오
문제 해결에 도움이 되었나요?