표준 주제 문제 해결

이 문서에서는 표준 Pub/Sub 주제에 메시지를 게시할 때의 몇 가지 일반적인 문제 해결 팁을 제공합니다.

주제에 메시지를 게시하는 방법과 여러 다른 기능에 대해 자세히 알아봅니다.

긴 게시 지연 시간

게시 지연 시간은 게시자 클라이언트에서 발행한 게시 요청을 완료하는 데 걸리는 시간입니다. 게시 지연 시간은 Pub/Sub에 게시된 메시지가 구독자 클라이언트에게 전송되는 데 걸리는 시간인 엔드 투 엔드 전송 지연 시간과 다릅니다. 다른 지연 시간 유형의 값이 낮더라도 게시 지연 시간 또는 엔드 투 엔드 지연 시간이 길어질 수 있습니다. Pub/Sub 게시자 클라이언트, 클라이언트와 Pub/Sub 백엔드 간 또는 Pub/Sub 백엔드 내 전환에서 게시 지연 시간이 길어질 수 있습니다. topic/send_request_latencies 측정항목을 사용하여 Pub/Sub 백엔드에서 발생한 게시 지연 시간을 검사할 수 있습니다. 백엔드 게시 지연 시간이 길면 다음과 같은 요인과 관련된 것일 수 있습니다.

  • Pub/Sub는 지연 시간이 짧고 처리량이 많은 전송을 위해 설계되었습니다. 주제의 처리량이 적으면 주제와 연결된 리소스를 초기화하는 데 시간이 더 오래 걸릴 수 있습니다.

  • 메시지 스토리지 정책을 사용하면 주제 및 구독에 대한 요청의 전반적인 지연 시간에 영향을 줄 수 있습니다. 이 구성을 사용할 경우 성능 및 가용성에 미치는 영향을 확인합니다.

게시자 클라이언트의 게시 지연 시간이 측정항목에 반영된 것보다 훨씬 긴 경우 다음과 같은 클라이언트 측 요인 중 하나일 수 있습니다.

  • 게시할 때마다 새 게시자를 만들지 않는지 확인하세요. 모든 메시지를 게시하려면 애플리케이션별로 주제당 단일 게시자 클라이언트를 사용하는 것이 좋습니다. 새 게시자 객체를 가동하고 새 스레드를 추가하면 지연 시간 비용이 발생합니다. Cloud Run 함수를 사용하여 메시지를 게시하는 경우 호출이 게시 지연 시간에도 영향을 줄 수 있습니다.

  • 기본 재시도 설정이 사용 사례에 충분하지 않은 경우 적절하게 조정합니다. 단, 새 값이 너무 높지 않은지 확인합니다. 요청 재시도를 구성하는 방법을 참조하세요.

게시 지연 시간이 길면 DEADLINE_EXCEEDED 오류가 발생할 수 있으며 이에 대해서는 다음 섹션에서 설명합니다.

DEADLINE_EXCEEDED로 게시 작업 실패

게시 요청 중 DEADLINE_EXCEEDED 오류는 할당된 시간 내에 요청을 완료할 수 없음을 나타냅니다. 이는 요청이 Pub/Sub 서비스에 도달하지 못하거나 요청에 영향을 미치는 성능 문제 등 다양한 요인으로 인해 발생할 수 있습니다.

게시 요청이 Pub/Sub 서비스에 도달하는지 확인하려면 response_code로 그룹화된 topic/send_request_count 측정항목을 사용하여 주제를 모니터링합니다. 이 측정항목을 통해 Pub/Sub 주제에 도달하기 전에 요청이 실패하는지 확인할 수 있습니다. 측정항목이 비어 있으면 메시지가 Pub/Sub 서비스에 도달하지 못하도록 하는 외부 요인이 있는 것입니다. 또한 간헐적인 문제 가능성을 배제하려면 앞에서 언급한 topic/send_request_count 측정항목 그래프 또는 Google Cloud 콘솔의 API 및 서비스 페이지를 사용하여 오류율을 확인하세요. 오류율이 매우 낮으면 간헐적인 문제일 수 있습니다.

요청이 Pub/Sub에 도달하는 경우 DEADLINE_EXCEEDED 오류와 함께 게시 작업이 실패하는 몇 가지 가능한 원인은 다음과 같습니다.

클라이언트 측 병목 현상

게시 실패는 메모리 부족, CPU 부담, 스레드 상태 불량, 게시자 클라이언트를 호스팅하는 VM의 네트워크 정체와 같은 클라이언트 측 병목 현상으로 인해 발생할 수 있습니다. Publish 호출이 DEADLINE_EXCEEDED를 반환하면 비동기 Publish 호출이 서비스로 전송되는 것보다 더 빨리 큐에 추가되므로 요청 지연 시간이 점점 더 늘어날 수 있습니다. 또한 다음 도움말을 참고하여 시스템에서 병목 현상이 발생할 수 있는지 확인합니다.

  • 메시지를 클라이언트가 보낼 수 있는 것보다 빠르게 게시하는지 확인합니다. 일반적으로 각 비동기 Publish 호출은 Future 객체를 반환합니다. 전송 대기 중인 메시지 수를 추적하려면 각 Publish 호출과 함께 전송될 메시지의 수를 저장하고 이를 Future 객체의 콜백에서만 삭제하세요.

  • 게시자가 실행 중인 머신과 Google Cloud 간에 업로드 대역폭이 충분한지 확인합니다. 개발 Wi-Fi 네트워크의 대역폭은 일반적으로 1~10MBps 또는 초당 일반 메시지 1,000~10,000건입니다. 비율 제한 없이 메시지를 루프에 게시하면 짧은 기간에 짧은 고대역폭 버스트가 발생할 수 있습니다. 이를 방지하려면 Google Cloud 내 머신에서 게시자를 실행하거나 사용 가능한 대역폭과 일치하도록 메시지를 게시하는 비율을 줄입니다.

  • 스타트업 네트워크 정체 또는 방화벽과 같은 이유로 호스트와 Google Cloud 간에 발생하는 지연 시간이 크게 늘어나는지 확인하세요. 네트워크 처리량 계산에는 다양한 시나리오에서 대역폭과 지연 시간을 확인하는 방법이 나와 있습니다.

  • 궁극적으로 단일 머신이 게시할 수 있는 데이터의 양은 제한이 있습니다. 수평적으로 확장하거나 게시자 클라이언트의 여러 인스턴스를 여러 머신에서 실행해야 할 수 있습니다. 스트리밍 성능을 극대화하기 위한 Cloud Pub/Sub 클라이언트 테스트는 CPU 수가 늘어나면서 단일 Google Cloud VM에서 Pub/Sub가 어떻게 확장되는지를 보여줍니다. 예를 들어 16코어 Compute Engine 인스턴스에서는 메시지 1KB에 대해 500MBps~700MBps에 도달할 수 있습니다.

게시 제한 시간이 적절하지 않음

게시 호출의 제한 시간 비율을 줄이려면 게시자 클라이언트의 재시도 설정에 제한 시간이 충분히 설정되어 있는지 확인하세요. 재시도 설정의 경우 초기 기한을 10초로, 총 제한 시간을 600초로 설정합니다. 보내지 않은 메시지의 큰 백로그를 누적하지 않더라도 요청 지연 시간이 가끔 급증하면 게시 호출이 시간 초과될 수 있습니다. 하지만 시간 초과가 아닌 지속적인 병목 현상으로 인해 문제가 발생하는 경우 재시도 횟수가 늘어날수록 더 많은 오류가 발생할 수 있습니다.

클라이언트 라이브러리 문제

알려진 문제가 있는 클라이언트 라이브러리 버전을 실행할 수 있습니다. 다음 목록에는 모든 클라이언트 라이브러리의 Issue Tracker가 포함되어 있습니다. 사용 중인 클라이언트 라이브러리 버전에 영향을 주는 알려진 문제가 발견되면 최신 버전의 클라이언트 라이브러리로 업그레이드합니다. 이렇게 하면 수정 및 성능 개선을 포함한 관련 업데이트가 적용됩니다.

스키마 문제

게시가 INVALID_ARGUMENT를 반환하기 시작하면 누군가 주제를 업데이트하여 연결된 스키마를 변경했거나 스키마를 삭제했거나 주제와 관련된 스키마 버전을 삭제했을 수 있습니다. 이 경우 게시 중인 메시지와 일치하는 스키마 및 버전 집합으로 주제 스키마 설정을 업데이트하거나 현재 스키마와 일치하도록 메시지 형식을 조정합니다.

메시지 암호화 문제

고객 관리 암호화 키를 사용하여 게시된 메시지를 암호화하도록 Pub/Sub 주제를 구성한 경우 FAILED_PRECONDITION 오류와 함께 게시가 실패할 수 있습니다. 이 오류는 Cloud KMS 키가 사용 중지된 경우 또는 Cloud EKM을 통해 외부 관리 키에 더 이상 액세스할 수 없을 때 발생할 수 있습니다. 게시를 재개하려면 키 액세스를 복원합니다.