이 문서에서는 Pub/Sub pull 구독에 대한 일반적인 문제 해결 팁을 제공합니다. pull 구독자 가이드에서 pull 구독에 대해 자세히 알아보세요.
Pub/Sub 구독을 효율적으로 모니터링하기 위해서는 먼저 전송 지연 시간 상태 점수(subscription/delivery_latency_health_score)를 보고 예기치 않은 지연 시간 또는 늘어난 지연 시간에 기여할 수 있는 요인이 무엇인지 확인하는 것이 좋습니다.
가장 오래된 미확인 메시지 기간 계속 증가
oldest_unacked_message_age는 Pub/Sub 구독 상태를 모니터링하기 위한 중요한 측정항목입니다. 이 측정항목은 구독 백로그에서 구독자가 아직 확인하지 않은 가장 오래된 메시지의 기간(초)을 측정합니다. 이 측정항목은 잠재적 처리 지연 시간 또는 병목 현상에 대한 중요한 인사이트를 제공합니다.
메시지 백로그 모니터링은 메시지가 신속하게 효과적으로 처리되도록 보장합니다. 가장 오래된 미확인 메시지 기간을 추적하면 고객 서비스가 뒤쳐지는 상황을 사전에 식별할 수 있습니다. 이렇게 하면 성능 저하와 관련된 잠재적 문제를 조기에 개입하여 해결할 수 있습니다.
조사 가능한 일부 일반 백로그 문제는 다음과 같습니다.
클라이언트 구성 문제
oldest_unacked_message_age 및 num_undelivered_messages 측정항목이 동시에 증가하면 구독자가 메시지 볼륨을 따라가지 못하고 있음을 의미할 수 있습니다. 이 경우 구독자 구성요소에 조사를 집중합니다.
클라이언트 상태: CPU, 메모리, 네트워크 대역폭 등 구독자 클라이언트를 호스팅하는 머신의 리소스 사용률을 분석합니다. 처리 효율을 저해할 수 있는 문제 지점을 찾습니다.
클라이언트 코드: 최근의 코드 변경사항을 검토하고 오류 로그를 조사합니다. 구독자 코드의 버그 또는 비효율성이 메시지 처리 속도에 중대한 영향을 줄 수 있습니다. 특정 메시지에 문제가 있을 수 있습니다. 예를 들어 여러 메시지가 데이터베이스에서 동일한 행에 동시에 액세스해야 할 수 있습니다. 이 동작은 경합 및 높은 지연 시간으로 이어질 수 있습니다.
할당량 제한: 호스팅 서비스에서 지정된 Pub/Sub 할당량 또는 제한을 초과하지 않았는지 확인합니다. 구독자가 Google Cloud에서 호스팅되는 경우 Compute Engine 또는 GKE 리소스 할당량을 검토하여 잠재적 병목 현상을 방지합니다.
구독자의 메시지 부정 확인
구독자가 메시지를 부정적으로 확인(nack)하면 Pub/Sub에서 메시지 처리가 성공할 수 없음을 나타냅니다. 그런 후 Pub/Sub는 동일한 메시지를 다시 전송하려고 시도합니다. 반복적인 메시지 부정 호가인은 중복 항목으로 이어지고 메시지 전송 시간이 크게 지연될 수 있습니다.
메시지 부정 확인이 있다고 해서 반드시 다음 pull 작업 시 다른 메시지를 가져오는 것은 아닙니다. Pub/Sub의 다시 전송 정책에 따라 새 메시지가 도착하기 전에 부정 확인된 메시지를 계속해서 다시 전송할 수 있습니다. 따라서 특정 메시지를 필터링하거나 건너뛰기 위한 방법으로 부정 확인을 사용하지 마세요. 대신 지수 백오프를 활용해서 재시도 정책을 설정하는 것이 좋습니다. 이 방법을 사용하면 나중에 처리할 수 있지만 다시 전송을 시도하기 전에 잠시 추가 시간이 필요한 개별 메시지의 전송을 지연할 수 있습니다.
특정 메시지를 의도적으로 건너뛰어야 할 경우에는 처리하지 않더라도 메시지를 확인하는 방법이 권장됩니다. 이렇게 하면 메시지가 구독에서 삭제되어 불필요한 다시 전송이 방지되고 리소스 소비가 줄어듭니다. 의도에 관계없이 메시지를 미확인 상태로 두면 백로그 문제 및 중복 전송 문제가 발생합니다.
높은 전송 지연 시간
Pub/Sub에서 전송 지연 시간은 게시자의 메시지가 구독자에 도달하는 데 걸리는 시간입니다. 다음 섹션에서는 전송 지연 시간이 길어질 수 있는 몇 가지 가능한 원인에 대해 설명합니다.
구독자 수 부족
StreamingPull을 사용하는 클라이언트의 경우 일관적으로 낮은 지연 시간을 달성하기 위해서는 구독에 대해 여러 열린 StreamingPull 연결을 유지합니다. 활성 구독자 연결이 없으면 Pub/Sub가 메시지를 즉시 전송할 수 없습니다. 단일 스트림은 단일 장애점이 되어 지연 시간 위험을 늘립니다. subscription/open_streaming_pulls 측정항목은 활성 스트리밍 연결 수에 대한 가시성을 제공합니다. 이를 사용해서 수신 메시지를 처리할 수 있도록 스트림을 일관적으로 충분하게 유지할 수 있습니다.
단항 pull을 사용하는 클라이언트의 경우 일관적으로 낮은 지연 시간을 달성하기 위해서는 구독에 대해 여러 pull 요청을 보류 중인 상태로 유지합니다. 요청이 간헐적이면 백로그에 메시지가 누적되고 지연 시간이 증가할 가능성이 있습니다. 이 접근 방식은 연결의 격차를 최소화하고 전송 지연 시간을 개선하는 데 도움을 줍니다.
상위 수준의 클라이언트 라이브러리는 최소한의 운영 오버헤드와 처리 비용을 가진 높은 처리량과 짧은 지연 시간이 필요한 경우에 권장됩니다. 기본적으로 상위 수준의 클라이언트 라이브러리는 지연 시간을 최소화하는 데 더 효과적인 StreamingPull API를 사용합니다. 상위 수준의 클라이언트 라이브러리에는 인증, 처리량, 지연 시간 최적화, 메시지 형식 지정, 기타 기능을 위해 기본 API 호출을 처리하는 사전 빌드된 함수와 클래스가 포함됩니다.
클라이언트 구성 문제
클라이언트 구성 문제를 참조하세요.
높은 백로그
Pub/Sub 구독에서 미확인 메시지의 메시지 백로그는 메시지가 구독자에 의해 즉시 처리되지 않기 때문에 기본적으로 엔드 투 엔드 지연 시간을 늘립니다.
순서 키 및 1회만 전송
순서 키 및 1회만 전송은 유용한 기능이지만 올바른 전송을 보장하기 위해 Pub/Sub 내에서 추가적인 조정이 필요합니다. 이러한 조정으로 인해 가용성이 줄어들고 지연 시간이 늘어날 수 있습니다. 안정적인 상태에서는 그 차이가 작지만 필요한 조정 단계로 인해 지연 시간이 일시적으로 증가하거나 오류 비율이 늘어날 수 있습니다. 순서 지정이 사용 설정된 경우 순서 키가 있는 메시지는 동일한 순서 키가 있는 이전 메시지가 확인될 때까지 전송될 수 없습니다.
메시지 순서 지정 또는 1회만 전송이 애플리케이션에 꼭 필요한지 확인하세요. 낮은 지연 시간이 가장 중요한 경우에는 이러한 기능 사용을 최소화하여 메시지 처리 지연 시간을 줄일 수 있습니다.
메시지 크기 증가
메시지 크기가 갑자기 증가하면 Pub/Sub와 클라이언트 사이의 전송 시간이 증가하고 클라이언트 측면에서 메시지 처리 시간이 느려질 수 있습니다.
전송 지연 시간이 증가되는 경우 topic/message_sizes 측정항목을 사용하고 topic_id로 그룹화하여 메시지 크기를 확인할 수 있습니다. 메시지 크기가 급증하면 성능 문제가 발생할 수 있습니다.
메시지 누락
메시지가 구독자에게 성공적으로 전송되지 않는 것으로 의심될 경우 다음 이유 중 하나가 원인일 수 있습니다.
Pub/Sub 구독에서 여러 소비자가 있는 메시지 배포
Pub/Sub에서 메시지는 소비자 간에 균일하지 않게 배포될 수 있습니다. 이러한 동작은 Pub/Sub가 효율성을 위해 활성 소비자 간에 메시지를 배포하기 때문에 발생합니다. 경우에 따라서는 단일 소비자가 예상한 것보다 적은 수의 메시지를 수신하거나, 다른 소비자와 다른 메시지 하위 집합을 수신할 수 있습니다.
메시지가 클라이언트에 대해 미결 상태일 수 있고 승인되지 않은 메시지 백로그가 있다고 해서 다음 pull 요청에 해당 메시지가 반드시 수신되지는 않습니다. 사용자는 Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 pull을 수행하거나 로컬에서 커스텀 구독자를 실행하여 메시지를 확인할 수 있습니다.
단항 pull 클라이언트의 경우 일부 pull 요청이 제로 메시지를 반환하는 것이 관측될 수 있습니다. 구독자 수 부족 섹션에서 설명한 것처럼 일부 요청이 구성된 최대 메시지 수보다 적은 개수를 반환하거나 제로 메시지를 반환할 수도 있으므로 여러 pull 요청을 미결 상태로 유지하는 것이 좋습니다.
이러한 동작이 의심될 경우 구독에 여러 소비자가 동시에 연결되어 있는지 조사합니다.
구독으로 필터링
구독에 필터가 연결되어 있는지 확인합니다. 이 경우 필터와 일치하는 메시지만 수신됩니다. Pub/Sub 서비스는 필터와 일치하지 않는 메시지를 자동으로 확인합니다. 필터가 백로그 측정항목에 미치는 영향을 고려하세요.
returnImmediately 옵션 사용
클라이언트에 단항 pull이 사용되는 경우 returnImmediately 필드가 true로 설정되었는지 확인합니다. 이것은 지원 중단된 필드이며 제로 메시지로 반환하더라도 Pub/Sub 서비스가 pull 요청에 즉시 대응하도록 지정합니다. 그 결과 백로그가 있더라도 pull 요청이 제로 메시지로 반환할 수 있습니다.
중복 처리
Pub/Sub에서 메시지 중복은 구독자가 확인 기한 내에 메시지를 확인할 수 없을 때 자주 발생합니다. 그 결과 메시지가 다시 전송되어 중복 표현이 생성됩니다. subscription/expired_ack_deadlines_count 측정항목을 사용하여 구독자가 확인 기한을 놓치는 비율을 측정할 수 있습니다. 확인 기한 만료 모니터링 방법을 자세히 알아보세요.
중복률을 줄이려면 메시지 기한을 연장합니다.
- 클라이언트 라이브러리는 기한 연장을 자동으로 처리하지만 구성 가능한 최대 연장 기한에는 기본 한도가 있습니다.
- 자체 클라이언트 라이브러리를 빌드하는 경우
modifyAckDeadline메서드를 사용하여 확인 기한을 연장합니다.
처리 및 확인 가능한 것보다 빠르게 메시지를 구독자로 가져올 경우 일부 메시지가 만료되고 기한 연장이 필요할 수 있습니다. 하지만 구독자가 메시지를 처리할 수 없는 상태가 유지되면 반복된 기한 연장 시도가 결국 실패합니다. 최악의 경우에는 중복으로 인해 구독자 오버플로가 발생하여 백로그가 악화될 수 있습니다. 중복 만료로 새로운 중복 생성
구독자 과부하를 방지하기 위해 구독자가 한 번에 가져오는 메시지 수를 줄입니다. 이렇게 하면 구독자가 기한 내에 처리할 메시지 수가 줄어듭니다. 더 적은 메시지가 만료되고 더 적은 메시지가 다시 전송됩니다.
구독자가 한 번에 가져오는 메시지 수를 줄이려면 구독자의 흐름 제어 구성에서 미결 상태의 메시지 최대 개수 설정을 줄여야 합니다. 모든 경우에 적합한 값은 없으므로, 처리량 및 구독자 용량에 맞게 최대 미결 메시지 한도를 조정해야 합니다. 각 애플리케이션의 서로 다른 메시지 처리 방법과 메시지 확인을 위해 필요한 시간 차이를 고려해야 합니다.
강제 재시도
Pub/Sub가 메시지를 재시도하도록 강제하려면 nack 요청을 보냅니다. 상위 수준의 클라이언트 라이브러리를 사용하지 않는 경우 ackDeadlineSeconds를 0으로 설정하여 modifyAckDeadline 요청을 보냅니다.
순서 키
Pub/Sub는 순서 키가 포함된 메시지를 다시 전송할 때 이전에 확인된 경우에도 모든 후속 메시지를 동일한 순서 키를 사용하여 다시 전송합니다. 이 작업은 시퀀스 순서를 보존하기 위해 수행됩니다. 하지만 시퀀스에서 이전 메시지의 확인이 성공적으로 수행된 후 종속 메시지만 전송되는지에 대해서는 엄격하게 보장되지 않습니다.
구독자의 메시지 부정 확인
구독자의 메시지 부정 확인을 참조하세요.
StreamingPull 구독 문제 해결
StreamingPull 스트림이 항상 OK(확인)가 아닌 상태로 종료됩니다. 단항 RPC의 오류 상태와 달리 이 StreamingPull 상태는 단지 스트림이 연결 해제되었음을 나타냅니다. 요청이 실패하지 않습니다. 따라서 StreamingPull API에서 100%라는 놀라운 오류율을 보이더라도 이 동작은 의도적으로 설계된 동작입니다.
StreamingPull 스트림은 항상 오류로 종료되므로 오류를 진단하는 동안 스트림 종료 측정항목을 검사하는 것은 도움이 되지 않습니다. 대신 response_code 또는 response_class로 그룹화된 StreamingPull 응답 측정항목 subscription/streaming_pull_response_count에 집중합니다.
다음 오류를 찾습니다.
사용 중지된 Cloud KMS 키로 암호화된 구독 백로그에 메시지가 있는 경우 실패한 전제조건 오류가 발생할 수 있습니다. 가져오기를 재개하려면 키 액세스를 복원합니다.
사용 불가능한 오류는 Pub/Sub에서 요청을 처리할 수 없을 때 발생할 수 있습니다. 일시적인 상태일 가능성이 높으며 클라이언트 라이브러리에서 요청을 재시도합니다. 클라이언트 라이브러리를 사용 중이면 사용자 작업이 필요하지 않습니다.
오류를 찾을 수 없음은 구독이 삭제되거나 애초에 존재하지 않을 때 발생할 수 있습니다. 후자의 경우는 잘못된 구독 경로를 제공한 경우에 발생합니다.