Pub/Sub 주제에 게시하기 위한 권장사항

게시를 수행할 때 게시자는 Pub/Sub 주제에 메시지를 전송합니다. 다음은 Pub/Sub에 메시지를 게시하기 위한 몇 가지 권장사항에 대한 설명입니다.

이 문서에서는 사용자가 Pub/Sub 주제에 메시지를 게시하는 프로세스에 익숙하다고 가정합니다.

Pub/Sub를 처음 사용하는 경우 빠른 시작 가이드 중 하나를 참조하고 콘솔, gCloud CLI, 클라이언트 라이브러리를 사용하여 Pub/Sub를 실행하는 방법을 알아보세요.

게시 시작 전 구독 연결 또는 주제 보관 사용 설정

연결된 구독자가 없는 주제에 게시를 시작하면 메시지가 보관되지 않습니다. 이러한 메시지는 이후에 연결된 구독에 전송될 수 없습니다. 따라서 메시지 게시를 시작하기 전에 다음 중 하나를 수행합니다.

일괄 메시징 구성

Pub/Sub 내에서 일괄 메시징은 단일 게시 요청으로 게시되는 하나의 배치에 여러 메시지를 조합하는 프로세스를 의미합니다. 메시지 게시를 위해 클라이언트 라이브러리를 사용하는 경우 일괄 처리가 기본적으로 사용 설정됩니다. 메시지 일괄 처리(또는 그룹화)는 게시자가 효율성을 높이고 메시지 전송 처리량을 높이는 데 도움이 됩니다. 일괄 처리를 사용하면 데이터 게시 비용이 줄어듭니다. 하지만 일괄 처리 시에는 일괄 게시 전 게시자가 일괄 처리를 채우는 시간이 걸리기 때문에 개별 메시지에 대해 지연 시간이 발생합니다.

Pub/Sub에서 지연 시간은 다음 두 가지 유형일 수 있습니다.

  • 엔드 투 엔드 지연 시간은 게시자가 메시지를 게시하고 처리를 위해 해당 구독자로 전송하는 데 걸리는 시간입니다.

  • 게시 지연 시간은 메시지를 게시하는 데 걸리는 시간입니다.

일괄 처리를 사용할 때는 두 유형 모두 지연 시간이 늘어나지만 대신 효율성과 처리량이 향상됩니다.

메시지 요청 크기, 메시지 수, 시간에 따라 클라이언트 라이브러리에서 메시지를 일괄 처리할 수 있습니다. 일괄 처리 설정을 구성할 때는 사용 사례에 맞게 비용, 처리량, 지연 시간 간의 적절한 균형을 찾을 수 있습니다.

메시지 일괄 변수의 기본값과 변수 이름은 클라이언트 라이브러리마다 다를 수 있습니다. 클라이언트 라이브러리에서 1개 또는 3개 값을 모두 지정할 수 있습니다. 메시지 일괄 처리 변수의 값 중 하나가 충족되면 클라이언트 라이브러리가 다음 메시지 배치를 게시합니다.

게시자 클라이언트의 일괄 처리 메시징을 구성하려면 게시 요청의 일괄 처리 메시지를 참조하세요.

일시적인 메시지 급증에 대한 흐름 제어 구성

게시자 클라이언트가 대량의 메시지를 처리해야 할 경우 Deadline exceeded 오류로 메시지 게시가 실패할 때까지 메모리에 게시 요청 누적이 시작될 수 있습니다.

일시적인 메시지 게시 급증을 해결하기 위해서는 게시자 설정에서 흐름 제어를 사용할 수 있습니다. 게시자 측 흐름 제어는 게시자 클라이언트 리소스가 과도한 대기 요청으로 오버로드되지 않도록 방지합니다. 게시자 클라이언트에서 메모리, CPU, 스레드가 부족해지면 많은 Deadline exceeded 오류가 발생합니다.

클라이언트 라이브러리에서 흐름 제어를 구성하려면 최대 대기 중 메시지 및 최대 대기 중 메시지 바이트 변수에 적합한 값을 설정합니다. 이러한 값은 메시지 처리량과 시스템 용량 사이에 균형을 제시합니다.

클라이언트 라이브러리가 게시자 흐름 제어를 지원하는지 확인하고 이를 구성하려면 흐름 제어를 참조하세요.

네트워크 대역폭과 지연 시간 이해

게시자 처리량은 네트워크 대역폭 및 전송되는 요청 수에 따라 제한됩니다. 대역폭이 양호하지만 네트워크 지연 시간이 높은 경우에는 많은 수의 작은 요청으로 시스템이 오버로드되지 않도록 해야 합니다. 게시자 측 흐름 제어는 클라이언트 측 네트워크 문제에 도움이 될 수 있습니다.

게시자 처리량도 CPU 및 메모리로 제한됩니다. 사용 가능한 머신 코어가 많을수록 더 높은 스레드 수를 설정해서 게시 처리량을 높일 수 있습니다. 스트리밍 성능 극대화 방법을 자세히 알아보려면 스트리밍 성능 극대화를 위해 Cloud Pub/Sub 클라이언트 테스트를 참조하세요.

실패한 게시의 재시도 요청 변수 조정

메시지가 게시자 클라이언트에서 게시될 때 게시 오류가 발생할 수 있습니다. 이러한 오류는 일반적으로 서비스 CPU 부족, 잘못된 스레드 상태, 네트워크 정체 등의 클라이언트 측 병목 현상으로 인해 발생합니다. publisher retry policy는 메시지 전송 실패 시 동작을 결정합니다. 재시도 정책은 Pub/Sub가 메시지 전송을 시도할 횟수와 각 시도 사이의 시간 길이를 정의합니다.

예를 들어 Pub/Sub용 Java 클라이언트 라이브러리에서 게시자 클라이언트에는 다음 값이 포함됩니다.

  • initialRetryDelay. 게시자가 게시 작업을 재시도하기 전에 기다리는 초기 지연 시간입니다. 기본값은 100 milliseconds입니다.

  • retryDelayMultiplier. 재시도 사이의 지연 시간을 계산하는 데 사용되는 배율 요소입니다. 기본값은 4입니다. 즉, 재시도 사이의 지연 시간은 두 번째 재시도의 경우 최대 100 milliseconds * 4 = 400 milliseconds이고, 세 번째 재시도의 경우 최대 400 milliseconds * 4 = 1600 milliseconds입니다.

  • maxRetryDelay. 게시자가 게시 작업을 재시도하기 전에 기다리는 최대 지연 시간입니다. 기본값은 60 seconds입니다.

  • initialRpcTimeout. 게시자가 RPC 호출이 완료될 때까지 기다리는 초기 제한 시간입니다. 기본값은 5 seconds입니다.

  • rpcTimeoutMultiplier. RPC 제한 시간을 계산하는 데 사용되는 배율 요소입니다. 기본값은 4.0입니다. 즉, RPC 호출의 제한 시간은 두 번째 재시도의 경우 최대 5 seconds * 4 = 20 seconds이고, 세 번째 재시도의 경우 최대 10 seconds * 4 = 40 seconds입니다.

  • maxRpcTimeout. 게시자가 RPC 호출이 완료될 때까지 기다리는 최대 제한 시간입니다. 기본값은 600 seconds입니다.

  • totalTimeout. 게시 작업의 총 제한 시간입니다. 여기에는 RPC 호출이 완료될 때까지 기다리는 데 걸리는 시간과 재시도 사이의 대기 시간이 포함됩니다. 기본값은 600 seconds입니다.

기본 재시도 설정이 해당 사용 사례에 충분하지 않은 경우에만 지정된 값을 조정하세요. 예를 들어 많은 수의 메시지를 게시할 경우 initialRetryDelay 및 maxRetryDelay 값을 늘릴 필요가 없습니다. 하지만 이러한 상황에서는 흐름 제어와 일괄 처리를 조정할 수 있습니다. 신뢰할 수 없는 인터넷 연결 또는 대역폭이 제한된 연결을 사용해서 게시할 경우에는 initialRpcTimeout, maxRpcTimeout, rpcTimeoutMultiplier 변수에 대해 여러 값을 실험해볼 수 있습니다. 권장되는 값은 DEADLINE_EXCEEDED로 게시 작업 실패를 참조하세요.

메시지 스토리지 정책을 사용하여 데이터 지역성 보장

Pub/Sub의 주제 메시지 스토리지 정책은 주제에 게시된 메시지가 게시 요청이 시작된 위치와 관계없이 지정한 Google Cloud 리전 집합 외부에서 유지되지 않도록 하는 방법을 제공합니다.

메시지 스토리지 정책을 사용해서 Pub/Sub가 메시지 데이터를 디스크에 저장하도록 허용된 Google Cloud 리전 목록을 지정할 수 있습니다. 메시지가 이 목록에 없는 리전으로 게시될 경우 처리가 허용된 가장 가까운 리전으로 요청이 전달됩니다. 이러한 정책은 특정 주제에 대한 정책으로 또는 프로젝트, 프로젝트 폴더, 전체 조직에 대한 조직 정책으로 구성할 수 있습니다. 조직 정책이 구성될 때는 조직 정책을 위반하지 않는 방식으로만 개별 주제 정책을 변경할 수 있습니다.

예를 들어 유럽에서 운영되는 회사는 지역 법률을 준수하기 위해 모든 데이터가 EU 리전에 저장되도록 보장하기 위해 메시지 스토리지 정책을 사용할 수 있습니다.

자세한 내용은 메시지 스토리지 정책 구성을 참조하세요.

구독의 순서가 지정된 메시징 권장사항

메시지 순서를 사용하는 경우 다음 사항을 확인합니다.

  • 위치별 엔드포인트를 사용합니다. 메시지 순서는 게시 측에서 그리고 리전 내에 보존됩니다. 즉, 메시지를 여러 리전에 게시할 경우 동일 리전 내의 메시지만 일관된 순서로 전송됩니다. 메시지가 모두 동일한 리전에 게시되지만 구독자가 여러 리전에 분산된 경우에는 구독자에게 모든 메시지가 순서대로 수신됩니다. 동일한 리전에 메시지를 게시하려면 위치별 엔드포인트를 사용합니다.

  • 게시 재개 함수 구성. 클라이언트 라이브러리가 요청을 재시도하고 메시지에 순서 키가 있는 경우, 클라이언트 라이브러리는 재시도 설정과 관계없이 요청을 재시도합니다. 다시 시도할 수 없는 오류가 발생하면 클라이언트 라이브러리는 메시지를 게시하지 않으며 동일한 순서 키가 포함된 다른 메시지의 게시를 중지합니다. 게시가 실패한 순서 키로 게시를 계속할 준비가 되었으면 resumePublish 메서드를 호출합니다.

권장사항 요약

다음 표에서는 이 문서에 설명된 권장사항을 요약해서 보여줍니다.

주제 태스크
메시지 보관 구성 메시지 보관을 게시하거나 사용 설정하기 전에 구독을 연결합니다.
게시 요청 한 번으로 메시지 일괄 처리 게시자 효율을 높이고 높은 처리량으로 메시지를 전송하기 위한 일괄 또는 그룹 메시지입니다.
흐름 제어 일시적인 트래픽 급증을 처리하도록 게시자 설정에서 흐름 제어를 구성합니다.
스트리밍 성능 극대화를 위한 Pub/Sub 클라이언트 테스트 사용 가능한 머신 코어 및 네트워크 대역폭을 늘려서 게시자 처리량을 확대합니다.
재시도 요청 기본 설정이 해당 사용 사례에 충분하지 않은 경우에만 게시자 재시도에 대해 지정된 값을 조정합니다.
메시지 스토리지 정책 구성 메시지 스토리지 정책을 사용하여 특정 위치의 디스크에만 메시지 데이터를 저장합니다.
게시 중 순서 키를 사용할 때 위치별 엔드포인트 사용 정렬된 메시징을 사용할 때 위치별 엔드포인트를 사용하고 게시 실패에 대한 게시 재개 함수를 구성합니다.

다음 단계