이 문서에서는 표준 Pub/Sub 주제에 메시지를 게시할 때의 몇 가지 일반적인 문제 해결 팁을 제공합니다.
주제에 메시지를 게시하는 방법과 여러 다른 기능에 대해 자세히 알아봅니다.
긴 게시 지연 시간
게시 지연 시간은 게시자 클라이언트에서 발행한 게시 요청을 완료하는 데 걸리는 시간입니다. 게시 지연 시간은 Pub/Sub에 게시된 메시지가 구독자 클라이언트에게 전송되는 데 걸리는 시간인 엔드 투 엔드 전송 지연 시간과 다릅니다. 다른 지연 시간 유형의 값이 낮더라도 게시 지연 시간 또는 엔드 투 엔드 지연 시간이 길어질 수 있습니다. Pub/Sub 게시자 클라이언트, 클라이언트와 Pub/Sub 백엔드 간 또는 Pub/Sub 백엔드 내 전환에서 게시 지연 시간이 길어질 수 있습니다. topic/send_request_latencies 측정항목을 사용하여 Pub/Sub 백엔드에서 발생한 게시 지연 시간을 검사할 수 있습니다. 백엔드 게시 지연 시간이 길면 다음과 같은 요인과 관련된 것일 수 있습니다.
Pub/Sub는 지연 시간이 짧고 처리량이 많은 전송을 위해 설계되었습니다. 주제의 처리량이 적으면 주제와 연결된 리소스를 초기화하는 데 시간이 더 오래 걸릴 수 있습니다.
메시지 스토리지 정책을 사용하는 경우 주제 및 구독에 대한 요청의 전체 지연 시간에 영향을 줄 수 있습니다. 이 구성을 사용할 경우 성능 및 가용성에 미치는 영향을 확인합니다.
게시자 클라이언트의 게시 지연 시간이 측정항목에 반영된 것보다 훨씬 긴 경우 다음과 같은 클라이언트 측 요인 중 하나일 수 있습니다.
게시할 때마다 새 게시자를 만들지 않는지 확인하세요. 애플리케이션마다 주제별로 단일 게시자 클라이언트를 사용하여 모든 메시지를 게시하는 것이 좋습니다. 새 게시자 객체를 가동하고 새 스레드를 추가하면 지연 시간 비용이 발생합니다. Cloud Functions를 사용하여 메시지를 게시하는 경우 호출은 게시 지연 시간에도 영향을 줄 수 있습니다.
기본 재시도 설정이 사용 사례에 충분하지 않다고 판단되면 해당 조정을 수행합니다. 단, 새 값이 너무 높지 않은지 확인합니다. 재시도 요청 구성 방법 알아보기
게시 지연 시간이 길면 DEADLINE_EXCEEDED 오류가 발생할 수 있습니다. 이에 대해서는 다음 섹션에서 설명합니다.
DEADLINE_EXCEEDED로 게시 작업 실패
게시 요청 중 DEADLINE_EXCEEDED 오류는 할당된 시간 내에 요청이 완료되지 않았음을 나타냅니다. Pub/Sub 서비스에 도달하지 않는 요청 또는 요청에 영향을 미치는 성능 문제와 같은 다양한 요인으로 인해 발생할 수 있습니다.
게시 요청이 Pub/Sub 서비스에 도달하는지 확인하려면 response_code별로 그룹화된 topic/send_request_count 측정항목을 사용하여 주제를 모니터링합니다. 이 측정항목은 Pub/Sub 주제에 도달하기 전에 요청이 실패했는지 확인하는 데 도움이 됩니다. 측정항목이 비어 있으면 메시지가 Pub/Sub 서비스에 도달하지 못하도록 하는 외부 요소가 있습니다. 또한 간헐적인 문제일 가능성을 배제하려면 오류율을 확인합니다. 오류율이 매우 낮으면 간헐적인 문제일 수 있습니다.
요청이 Pub/Sub에 도달하는 경우 DEADLINE_EXCEEDED 오류와 함께 게시 작업이 실패하는 몇 가지 가능한 원인은 다음과 같습니다.
클라이언트 측 병목 현상
게시 실패는 메모리 부족, CPU 부담, 스레드 상태 불량, 게시자 클라이언트를 호스팅하는 VM의 네트워크 정체와 같은 클라이언트 측 병목 현상으로 인해 발생할 수 있습니다. Publish 호출이 DEADLINE_EXCEEDED를 반환하면 비동기 Publish 호출이 서비스로 전송되는 것보다 더 빨리 큐에 추가되므로 요청 지연 시간이 점점 더 늘어날 수 있습니다. 또한 다음 도움말을 참고하여 시스템에서 병목 현상이 발생할 수 있는지 확인합니다.
메시지를 클라이언트가 보낼 수 있는 것보다 빠르게 게시하는지 확인합니다. 일반적으로 각 비동기
Publish호출은Future객체를 반환합니다. 전송 대기 중인 메시지 수를 추적하려면 각Publish호출과 함께 전송될 메시지의 수를 저장하고 이를Future객체의 콜백에서만 삭제하세요.게시자가 실행 중인 머신과 Google Cloud 간에 업로드 대역폭이 충분한지 확인합니다. 개발 Wi-Fi 네트워크의 대역폭은 일반적으로 1~10MB/초 또는 초당 일반 메시지 1,000~10,000건입니다. 비율 제한 없이 루프에 메시지를 게시하면 짧은 기간에 짧은 고대역폭 버스트가 발생할 수 있습니다. 이를 방지하려면 Google Cloud 내의 머신에서 게시자를 실행하거나 사용 가능한 대역폭과 일치하도록 메시지를 게시하는 비율을 줄이세요.
스타트업 네트워크 정체 또는 방화벽과 같은 이유로 호스트와 Google Cloud 간에 발생하는 지연 시간이 크게 늘어나는지 확인하세요. 네트워크 처리량 계산에는 다양한 시나리오에서 대역폭과 지연 시간을 확인하는 방법이 나와 있습니다.
궁극적으로 단일 머신이 게시할 수 있는 데이터의 양은 제한이 있습니다. 수평적으로 확장하거나 게시자 클라이언트의 여러 인스턴스를 여러 머신에서 실행해야 할 수 있습니다. 스트리밍 성능을 극대화하기 위한 Cloud Pub/Sub 클라이언트 테스트는 CPU 수가 늘어나면서 단일 Google Cloud VM에서 Pub/Sub가 어떻게 확장되는지를 보여줍니다. 예를 들어 16코어 Compute Engine 인스턴스에서는 메시지 1KB에 대해 초당 500MB~700MB에 도달할 수 있습니다.
게시 제한 시간 불충분
게시 호출의 제한 시간 비율을 줄이려면 게시자 클라이언트의 재시도 설정에 제한 시간이 충분히 설정되어 있는지 확인하세요. 재시도 설정의 경우 초기 기한을 10초로 설정하고 총 제한 시간을 600초로 설정합니다. 보내지 않은 메시지의 큰 백로그를 누적하지 않더라도 요청 지연 시간이 급증하면 게시 호출이 시간 초과될 수 있습니다. 시간 초과가 아닌 지속적인 병목 현상으로 인해 문제가 발생하는 경우 재시도 횟수가 늘어날수록 더 많은 오류가 발생할 수 있습니다.
클라이언트 라이브러리 문제
알려진 문제가 있는 클라이언트 라이브러리 버전을 실행할 수 있습니다. 다음 목록에는 모든 클라이언트 라이브러리의 Issue Tracker가 포함되어 있습니다. 사용 중인 클라이언트 라이브러리 버전에 영향을 미치는 알려진 문제가 있는 경우 최신 버전의 클라이언트 라이브러리로 업그레이드합니다. 이렇게 하면 수정 및 성능 개선을 포함한 관련 업데이트가 적용됩니다.
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
스키마 문제
게시가 INVALID_ARGUMENT를 반환하기 시작하면 누군가 주제를 업데이트하여 연결된 스키마를 변경했거나 스키마를 삭제했거나 주제와 관련된 스키마 버전을 삭제했을 수 있습니다. 이 경우 게시 중인 메시지와 일치하는 스키마 및 버전 집합으로 주제 스키마 설정을 업데이트하거나 현재 스키마와 일치하도록 메시지 형식을 조정합니다.
메시지 암호화 문제
고객 관리 암호화 키를 사용하여 게시된 메시지를 암호화하도록 Pub/Sub 주제를 구성한 경우 FAILED_PRECONDITION 오류와 함께 게시가 실패할 수 있습니다. 이 오류는 Cloud KMS 키가 사용 중지된 경우 또는 Cloud EKM을 통해 외부 관리 키에 더 이상 액세스할 수 없을 때 발생할 수 있습니다. 게시를 재개하려면 키 액세스를 복원합니다.