API7 Enterprise 3.2.9의 새로운 기능: 업그레이드된 Health Check 구성

새로운 헬스 체크 기능 소개

API7 Enterprise 버전 3.2.9에서 헬스 체크의 구성 상호작용 경험이 전면적으로 최적화되었습니다.

1. 이전에 흩어져 있던 구성 항목들이 논리적으로 통합되었습니다. 예를 들어, 프로브 설정과 건강한 노드 및 비정상 노드를 판단하는 기준 등이 더 구조화되었습니다.

2. 일부 추상적인 구성 항목 이름이 더 직관적이고 의미론적인 표현으로 변경되었습니다. 이를 통해 사용자는 빈칸 채우기 형식으로 관련 매개변수를 직접 입력할 수 있으며, 구성의 실제 효과를 더 명확하게 이해할 수 있습니다.

3. 업스트림 노드 및 헬스 체크 프로세스 구성 중에 더 많은 프롬프트 메시지가 추가되었습니다. 이를 통해 사용자는 업스트림 노드와 헬스 체크 간의 내재적 연결을 더 잘 이해할 수 있으며, 더 쉽게 구성 작업을 완료할 수 있습니다.

헬스 체크의 기본 개념

API7 Enterprise에서 업스트림 노드의 우선순위 설정은 로드 밸런싱 및 헬스 체크 메커니즘과 밀접하게 연결되어 있습니다. 사용자가 게이트웨이에 대해 서로 다른 우선순위를 가진 여러 업스트림 노드를 구성할 때, 게이트웨이는 로드 밸런싱 중에 가장 높은 우선순위의 노드를 우선적으로 선택합니다. 이는 가장 높은 우선순위의 노드가 건강한 상태로 유지되는 한, 게이트웨이가 이러한 노드로 트래픽을 계속 라우팅한다는 것을 의미합니다.

헬스 체크 실패로 인해 가장 높은 우선순위의 모든 노드가 사용 불가능한 것으로 판단될 때만, 게이트웨이는 자동으로 다음으로 높은 우선순위의 업스트림 노드로 트래픽을 리디렉션합니다. 이 설계는 트래픽의 효율적인 활용과 높은 시스템 가용성을 보장합니다.

주의할 점은, 서비스에 여러 우선순위 수준의 업스트림 노드가 구성되어 있지만 헬스 체크 기능이 비활성화된 경우, 모든 클라이언트 요청은 실제 건강 상태와 관계없이 항상 가장 높은 우선순위의 노드로 라우팅된다는 것입니다.

헬스 체크 구성 방법

프로브 구성

프로브는 업스트림 노드의 활성 상태와 서비스 상태를 감지하는 데 사용됩니다. APISIX에서 프로브는 "검사관"과 같아서 정기적으로 문을 두드려 업스트림 서비스가 제대로 작동하는지 확인합니다. 문제가 발견되거나 서비스가 "사용 불가능"한 경우, APISIX에게 "이 서비스는 현재 사용 불가능하므로 여기로 요청을 보내지 마세요"라고 알립니다. 이 "문 두드리기" 과정은 프로브를 통해 수행됩니다.

프로브에는 주로 다음과 같은 구성 항목이 포함됩니다:

• 프로브 스킴: 헬스 체크 프로브가 사용하는 프로토콜 유형으로, TCP, HTTP, HTTPS를 지원합니다.

• 동시성: 이 구성 항목을 통해 동시 헬스 체크 요청 수를 설정할 수 있습니다. 즉, 업스트림 서비스의 응답성을 확인하기 위해 동시에 "문을 두드리는" 횟수를 설정하는 것입니다. 동시성을 조정함으로써 실제 시나리오에서 발생할 수 있는 동시 요청을 시뮬레이션할 수 있으며, 이를 통해 업스트림 서비스의 성능과 안정성을 더 잘 평가할 수 있습니다.

• 호스트: 확인할 업스트림 서버의 호스트 주소를 지정합니다. 이는 "문을 두드릴" 집을 결정하는 것과 같습니다.

• 포트: 업스트림 서비스의 포트 번호입니다. 프로브 중에 어떤 문을 두드릴지 알려주는 것과 같습니다.

• 경로: HTTP 프로브를 사용하는 경우, 이 구성 항목은 액세스하려는 URL 경로를 지정합니다. 이는 프로브에게 안으로 들어가서 정확한 방을 확인하라고 알려주는 것과 같습니다.

건강한 노드 판단 기준

건강한 노드 판단에 대해, 시스템은 사용자가 설정한 간격(초 단위)으로 이전에 비정상으로 표시된 노드를 정기적으로 확인하여 일시적인 노드 이상을 적시에 감지하고 적절히 처리할 수 있도록 합니다.

프로브가 TCP 프로토콜을 사용하는 경우, 사용자가 설정한 횟수만큼 프로브가 업스트림 노드에 성공적으로 연결되면 노드를 건강한 것으로 간주합니다.

프로브가 HTTP/HTTPS 프로토콜을 사용하는 경우, 시스템은 노드로부터 지정된 상태 코드(예: 200, 302)를 가진 프로브 요청을 연속적으로 받을 때만 노드를 건강한 것으로 간주합니다. 이는 노드가 이러한 특정 상태 코드를 연속적으로 반환할 때만 정상적으로 작동한다고 간주한다는 것을 의미합니다.

비정상 노드 판단 기준

비정상 노드 판단에 대해, 구성 방법은 건강한 노드 판단과 유사합니다. 시스템은 사용자가 설정한 간격으로 건강한 것으로 표시된 노드를 정기적으로 확인합니다. 이러한 노드가 사전 설정된 비정상 조건을 충족하면 다시 비정상으로 분류됩니다.

건강한 노드 판단과 약간 다른 점은, 비정상 노드 판단 과정에서 클라이언트 요청 검증이라는 추가 구성 항목이 포함된다는 것입니다. 이 기능이 활성화되면, 게이트웨이는 프로브의 검사 결과뿐만 아니라 클라이언트의 요청과 업스트림 서비스의 실제 응답을 깊이 있게 관찰하고 분석합니다. 이러한 데이터와 사용자 정의 판단 기준을 기반으로, 게이트웨이는 업스트림 서비스의 실행 상태를 더 정확하게 평가할 수 있습니다.

헬스 체크의 모범 사례

적절한 프로브 유형 선택

• TCP 프로브: 서비스 포트가 열려 있고 접근 가능한지 확인만 필요한 시나리오에 적합합니다. 예를 들어, 데이터베이스 서비스는 포트 개방을 확인하기 위해 TCP 프로브만 필요할 수 있습니다.

• HTTP/HTTPS 프로브: 네트워크 연결이 정상일 뿐만 아니라 서비스가 요청을 올바르게 처리할 수 있는지 확인이 필요한 시나리오에 더 적합합니다. 예를 들어, 웹 서버나 API 서비스의 경우, 연결을 받을 수 있을 뿐만 아니라 올바른 페이지나 데이터를 반환할 수 있는지 확인해야 합니다.

헬스 체크 매개변수의 합리적인 구성

헬스 체크를 구성할 때, 몇 가지 주요 매개변수에 주의해야 합니다:

• 체크 간격: 너무 짧으면 불필요한 오버헤드가 발생할 수 있고, 너무 길면 문제 발생 시 느린 응답을 초래할 수 있습니다. 예를 들어, 높은 트래픽의 전자상거래 웹사이트의 경우, 30초마다 체크하는 것이 비교적 합리적인 선택입니다. 이 간격은 시스템 리소스를 과도하게 소모하지 않으면서도 웹사이트의 문제를 적시에 감지하고 처리할 수 있습니다.

  물론, 이 간격은 절대적인 것이 아니며, 웹사이트의 실제 상황에 따라 조정이 필요합니다. 예를 들어, 웹사이트의 트래픽이 크게 변동하거나 특정 기간(예: 프로모션 기간) 동안 트래픽이 급증하는 경우, 이러한 변화에 대응하기 위해 체크 간격을 조정해야 할 수 있습니다.

• 타임아웃: 프로브가 서비스 응답을 기다리는 시간입니다. 서비스가 이 시간 내에 응답하지 않으면 프로브는 서비스를 비정상으로 간주합니다. 이 값은 서비스의 실제 응답 시간에 따라 설정해야 합니다.

• 재시도 횟수: 프로브가 서비스를 비정상으로 판단하기 전에 연결을 시도하는 횟수입니다. 이 값은 적당해야 하며, 오판을 피하기 위해 너무 높게 설정하지 않아야 합니다.

비즈니스에 기반한 전략 조정

헬스 체크 전략은 실제 비즈니스 상황에 따라 조정되어야 합니다. 특정 시간대에 서비스가 일반적으로 높은 부하를 경험하는 경우, 이러한 기간 동안 헬스 체크 간격을 늘리거나 재시도 횟수를 줄여 서비스에 추가적인 부담을 주지 않도록 할 수 있습니다.

적절한 클라이언트 요청 검증 활성화

클라이언트 요청 검증은 실제 비즈니스 요청을 기반으로 서비스 상태를 효과적으로 판단할 수 있으며, 특히 비즈니스 로직과 밀접한 관련이 있는 문제를 식별하는 데 유용합니다. 그러나 모든 비즈니스 시나리오에 적합하지는 않을 수 있습니다.

1. 저트래픽 서비스: 서비스 트래픽이 낮은 경우, 클라이언트 요청에 기반한 수동 헬스 체크는 서비스 상태를 정확하게 평가하기에 충분한 데이터 포인트를 제공하지 못할 수 있습니다. 이러한 경우, 활성 프로브 검사에 의존하는 것이 더 신뢰할 수 있습니다.

2. 고동시성 환경에서의 성능 고려: 수동 헬스 체크는 모든 클라이언트 요청을 모니터링하고 처리해야 하므로, 고동시성 환경에서 추가적인 성능 오버헤드를 증가시킬 수 있습니다. 성능이 주요 관심사이고 서비스가 다른 수단을 통해 충분히 모니터링되고 있다면, 수동 헬스 체크를 비활성화할 수 있습니다.

3. 다른 모니터링 시스템의 존재: 기업에 이미 성숙한 모니터링 시스템이 배포되어 있어 실시간으로 서비스 상태를 포착하고 분석할 수 있는 경우, 데이터 중복과 추가적인 복잡성을 피하기 위해 수동 헬스 체크가 필요하지 않을 수 있습니다.

결론

헬스 체크는 API 게이트웨이의 고가용성을 보장하는 중요한 측면입니다. API7 Enterprise 버전 3.2.9에서 우리는 헬스 체크의 상호작용 구성을 전면적으로 최적화하여 작업을 단순화하고 사용자 경험을 향상시켰습니다.

프로브를 적절히 구성하고, 건강한 노드와 비정상 노드에 대한 기준을 설정하며, 실제 비즈니스 요구에 따라 전략을 조정함으로써, 사용자는 업스트림 서비스의 상태를 더 효과적으로 모니터링할 수 있으며, 트래픽이 항상 건강한 노드로 라우팅되도록 할 수 있습니다. 이는 시스템의 안정성과 가용성을 향상시킬 뿐만 아니라, 사용자 요청이 적시에 정확하게 응답받을 수 있도록 보장합니다.