이 문서에서는 Pub/Sub StreamingPull 구독에 대한 일반적인 문제 해결 팁을 제공합니다. StreamingPull 구독은 StreamingPull API를 사용합니다.
풀 구독자 가이드에서 StreamingPull 구독에 대해 자세히 알아보세요.
StreamingPull의 오류율이 100%
StreamingPull 스트림이 항상 OK(확인)가 아닌 상태로 종료됩니다. 단항 RPC와 달리 이 StreamingPull 상태는 단순히 스트림이 손상되었음을 나타냅니다. 요청이 실패하지 않습니다. 따라서 StreamingPull API에서 100%라는 놀라운 오류율을 보이더라도 이 동작은 의도적으로 설계된 동작입니다.
전제조건 실패, 사용 불가 또는 오류를 찾을 수 없음
StreamingPull 스트림은 항상 오류로 종료되므로 오류를 진단하는 동안 스트림 종료 측정항목을 검사하는 것은 도움이 되지 않습니다. 대신 subscription/streaming_pull_response_count와 같은 StreamingPull 응답 측정항목에 집중합니다.
다음 오류를 찾습니다.
다음 경우에 발생할 수 있는 전제조건 실패 오류입니다.
Pub/Sub는 사용 중지된 Cloud KMS 키가 있는 메시지의 복호화를 시도합니다.
사용 중지된 Cloud KMS 키로 암호화되는 구독 백로그에 메시지가 있는 경우 구독이 일시적으로 중지됩니다.
사용 불가능한 오류는 Pub/Sub에서 요청을 처리할 수 없을 때 발생할 수 있습니다. 일시적인 상태일 가능성이 높으며 클라이언트 라이브러리에서 요청을 재시도합니다.
오류를 찾을 수 없음은 구독이 삭제되거나 애초에 존재하지 않을 때 발생할 수 있습니다. 후자는 잘못된 구독 경로를 제공할 때 발생합니다.
StreamingPull 구독에 있는 작은 메시지의 대규모 백로그
gRPC StreamingPull 스택은 높은 처리량에 최적화되어 있어 메시지 버퍼링이 발생합니다. 작은 메시지의 대규모 백로그를 처리하려고 하면 메시지가 여러 번 전송될 수 있습니다. 이러한 메시지는 클라이언트 간에 부하 분산이 효율적으로 되지 않을 수 있습니다.
Pub/Sub 서비스와 클라이언트 라이브러리 사용자 공간 사이의 버퍼는 약 10MB입니다. 이 버퍼가 클라이언트 라이브러리 동작에 미치는 영향을 이해하려면 다음 예시를 살펴보세요.
구독에 1KB 메시지 10,000개의 백로그가 있습니다.
단일 스레드 클라이언트 인스턴스에서 각 메시지를 순차적으로 처리하는 데 1초가 걸립니다.
해당 구독에 대한 서비스와 StreamingPull 연결을 설정하는 첫 번째 클라이언트 인스턴스는 메시지 10,000개로 버퍼를 모두 채웁니다.
버퍼를 처리하는 데 10,000초(약 3시간)가 걸립니다.
이때 일부 버퍼링된 메시지가 확인 기한을 초과해 같은 클라이언트로 재전송되므로 중복이 발생합니다.
여러 클라이언트 인스턴스가 실행 중인 경우 한 클라이언트의 버퍼에 갇힌 메시지를 다른 클라이언트 인스턴스에서 사용할 수 없습니다. StreamingPull에 흐름 제어를 사용하는 경우에는 이 상황이 발생하지 않습니다. 이 서비스는 한 번에 전체 메시지 10MB를 보유하지 않으며 여러 구독자 간에 메시지 부하를 효과적으로 분산할 수 있습니다.