짧은 읽기: 비동기식 건강 확인을 사용하여 천둥 같은 무리를 피하십시오.

건강 검진이 천둥 같은 무리를 유발할 수 있습니까?

필자는 최근에 Readiness Probes와 응용 프로그램이 이를 활용하여 종속 서비스의 문제를 감지하는 방법에 대해 게시했습니다.

여러분 중 많은 분들이 대규모로 건강 검진을 하면 천둥 같은 무리 시나리오가 발생했다는 경고성 이야기를 듣거나 경험하셨을 것입니다.

이러한 상황이 발생할 수 있으므로 준비 상태 프로브를 사용하도록 제안하는 이유는 무엇인가요? 이러한 상황을 피하면서 준비 상태 프로브의 이점을 얻을 수 있는 방법이 있기 때문이며, 이는 비동기 상태 검사를 사용하는 것입니다.

더 잘 이해하기 위해 천둥 같은 무리 시나리오에 들어가는 방법을 살펴보겠습니다.

일반적인 상태 확인 설정은 호출될 때 일련의 작업을 실행하여 종속성의 상태를 검증하고 상태에 따라 양호 또는 불량 응답 코드를 반환하는 HTTP 엔드포인트를 활용합니다.

이러한 상태 확인은 일반적으로 30초마다와 같은 간격으로 예약되고 요청됩니다.

표면적으로, 이것은 그렇게 나쁘지 않은 것처럼 보이며, 30 초마다 요청하여 데이터베이스의 상태를 확인하게하는 데 아무런 문제가 없습니다.

그러나 종속성 중 하나가 다른 서비스 인 경우 문제가 발생합니다. 귀하의 서비스와 마찬가지로 해당 서비스에는 종속 서비스가 있을 수 있으며, 종속 서비스가 있는 사람, 누가 ... 당신은 요점을 이해합니다.

세 가지 서비스 계층의 경우 다음과 같습니다.

1 (K8S) > 2 (서비스 A) > 4 (서비스 B, C) > 8 (서비스 D, E, F, G)

한 번의 상태 확인은 주변 서비스를 트리거하여 상태 확인을 수행하며, 이는 무리에서 겁에 질린 동물 한 마리가 압사를 시작하는 것과 같이 더 많은 상태 확인을 트리거합니다.

많은 서비스에서 공유하는 모든 공통 서비스는 상태 확인이 실행될 때마다 트래픽이 급증하는 형태로 이러한 급증의 영향을 보게 됩니다.

물론 이것은 간단한 예입니다. 문제를 대규모로 살펴보면 시스템이 보유한 서비스 및 인스턴스의 수에 따라 효과가 증폭됩니다.

그렇다면 비동기 상태 확인은 이 문제를 어떻게 해결할까요?

위의 시나리오에서, 천둥 같은 무리는 다른 건강 체크를 트리거한 건강 체크에 의해 트리거되었습니다.

비동기식 상태 확인을 사용하면 HTTP 요청을 트리거로 사용하는 대신 내부적으로 예약된 작업에 의해 확인이 수행됩니다.

각 종속성은 적절한 간격으로 검사되고 상태가 저장됩니다.

Readiness HTTP 요청이 이루어지면 애플리케이션은 후속 검사를 트리거하지 않고 저장된 상태를 즉시 반환할 수 있습니다.

각 서비스가 이 접근 방식을 따르는 경우 공통 서비스는 계속 확인되지만 모든 서비스/인스턴스에 대해 N초마다 한 번만 확인됩니다.

이러한 내부 작업의 스케줄링에 약간의 지터를 도입하면 이 접근 방식이 훨씬 더 지속 가능해지고 상태 확인으로 인한 트래픽 볼륨이 평탄해집니다.

건강 검진과 관련된 주의 이야기에 주의를 기울여야 할 좋은 이유가 있지만, 신중한 접근 방식을 통해 이러한 시나리오를 피할 수 있다는 점을 인식하는 것이 중요합니다.