Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

헤징 게시

메시지를 게시할 때 테일 지연 시간이 길어지는 것은 일시적인 네트워크 지연이나 일시적인 서버 측 속도 저하로 인해 발생할 수 있습니다. 게시 헤징을 사용하면 Pub/Sub 게시자 클라이언트가 진행 중인 요청이 구성된 지연 시간 내에 완료되지 않는 경우 백업(헤징) 게시 요청을 동시에 전송하여 먼저 반환되는 응답을 사용할 수 있습니다.

이 문서에서는 주제에 게시된 메시지에 게시 헤징을 사용하는 방법을 설명합니다.

시작하기 전에

게시 워크플로를 구성하기 전에 다음 작업이 완료되어야 합니다.

주제 및 게시 워크플로 자세히 알아보기
주제 만들기

필요한 역할

헤지된 게시 요청을 주제에 전송하는 데 필요한 권한을 얻으려면 관리자에게 주제에 대한 Pub/Sub 게시자(roles/pubsub.publisher) IAM 역할을 부여해 달라고 요청하세요. 역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.

커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.

주제 및 구독을 만들거나 업데이트하려면 추가 권한이 필요합니다.

게시 헤징 정보

헤징 설정은 Pub/Sub 클라이언트 라이브러리가 헤징된 게시 요청을 전송하는 방법과 시기를 제어합니다. 게시 헤징은 기본적으로 사용 중지되어 있습니다. 사용 설정하면 클라이언트 라이브러리에 다음과 같은 헤징 설정이 적용됩니다.

헤지 지연 시간: 이전 요청이 완료되지 않은 경우 클라이언트 라이브러리가 추가 게시 요청을 동시에 전송하기 전에 대기하는 시간입니다. 기본값은 1초이며 구성된 값은 100밀리초에서 10초 사이여야 합니다.
최대 토큰: 클라이언트 라이브러리가 헤지된 게시 요청을 전송하기 위해 누적할 수 있는 최대 토큰 수입니다. 헤지된 게시 요청마다 토큰 1개가 사용됩니다. 기본값은 50이며 구성된 값은 1에서 250 사이여야 합니다.
보충 비율: 성공적인 게시 요청마다 추가되는 토큰 수입니다. 이 값은 시간 경과에 따라 헤지할 수 있는 게시 요청의 최대 비율을 제어합니다. 예를 들어 보충 비율이 0.1이면 게시 요청의 최대 10% 를 헤지할 수 있습니다. 기본값은 0.1이고 구성된 값은 0.001에서 0.2 사이여야 합니다.

게시 요청을 헤지하려면 헤지 지연 시간이 게시자의 재시도 설정에서 초기 요청 제한 시간과 총 제한 시간보다 짧아야 합니다. 그렇지 않으면 게시자 클라이언트가 초기화되지 않습니다. 게시 헤징이 사용 설정되면 클라이언트 라이브러리는 다음과 같이 게시 요청을 전송합니다.

진행 중인 게시 요청이 헤지 지연 시간 내에 완료되지 않고 토큰이 하나 이상 사용 가능한 경우 클라이언트 라이브러리는 토큰 하나를 사용하고 초기 요청을 미해결 상태로 유지하면서 동일한 메시지 배치에 대한 추가 게시 요청을 동시에 전송합니다.
다른 헤지 지연 후에도 진행 중인 요청이 완료되지 않으면 클라이언트 라이브러리는 토큰을 사용할 수 있고 총 제한 시간이 만료되지 않은 동안 헤지 지연 간격으로 추가 헤지 요청을 계속 전송합니다.
배치에 대한 진행 중인 게시 요청이 성공하면 클라이언트 라이브러리는 게시 작업을 완료하고 해당 배치에 대한 나머지 진행 중인 시도를 취소하고 사용 가능한 토큰을 리필 비율만큼 최대 토큰까지 늘립니다.

게시 요청 헤지

진행 중인 게시 요청이 실패하거나 타임아웃될 때까지 기다리는 재시도 요청과 달리 게시 헤징은 동시 헤징 요청을 전송하는 동안 초기 요청을 미해결 상태로 유지합니다. 이렇게 하면 성공하려는 요청을 조기에 취소하지 않고도 테일 지연 시간이 줄어듭니다.

동일한 메시지 배치에 대한 여러 요청이 동시에 진행될 수 있으므로 게시 요청 취소는 최선의 방식으로 처리되므로 나머지 시도가 취소되기 전에 두 번 이상 시도가 성공할 수 있습니다. 따라서 메시지 ID가 다른 중복 메시지가 수신될 수 있으며, 이로 인해 클라이언트 네트워크 트래픽과 중복 메시지 게시 및 전송에 대한 Pub/Sub 비용이 증가할 수 있습니다. 중복 메시지 처리 도움말은 '중복, 재전송 또는 누락된 메시지 문제 해결'을 참조하세요.

서비스 성능 저하로 인해 지연 시간이나 오류가 지속적으로 증가하는 경우 최대 토큰 및 보충 비율 설정으로 인해 헤지 게시 속도가 너무 높아지지 않습니다. 토큰은 게시 요청이 성공할 때만 추가되므로 지속적인 속도 저하나 오류가 발생하면 사용 가능한 토큰이 빠르게 소진되고 헤지된 요청이 자동으로 제한됩니다.

이 샘플 코드는 커스텀 헤징 설정으로 게시자를 만드는 방법을 보여줍니다. 모든 클라이언트 라이브러리가 게시 헤징을 지원하는 것은 아닙니다. 선택한 언어의 API 참고 문서를 참조하세요.

자바

이 샘플을 시도하기 전에 빠른 시작: 클라이언트 라이브러리 사용의 Java 설정 안내를 따르세요. 자세한 내용은 Pub/Sub Java API 참고 문서를 참조하세요.


import com.google.api.core.ApiFuture;
import com.google.cloud.pubsub.v1.HedgingSettings;
import com.google.cloud.pubsub.v1.Publisher;
import com.google.protobuf.ByteString;
import com.google.pubsub.v1.PubsubMessage;
import com.google.pubsub.v1.TopicName;
import java.io.IOException;
import java.time.Duration;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.TimeUnit;

public class PublishWithHedgingSettingsExample {
  public static void main(String... args) throws Exception {
    // TODO(developer): Replace these variables before running the sample.
    String projectId = "your-project-id";
    String topicId = "your-topic-id";

    publishWithHedgingSettingsExample(projectId, topicId);
  }

  public static void publishWithHedgingSettingsExample(String projectId, String topicId)
      throws IOException, ExecutionException, InterruptedException {
    TopicName topicName = TopicName.of(projectId, topicId);
    Publisher publisher = null;

    try {
      // Hedging settings configures how and when the publisher sends multiple concurrent publish
      // requests to reduce tail latency.
      Duration hedgeDelay = Duration.ofMillis(500); // default: 1000 ms (1 second)
      int maxTokens = 100; // default: 50
      float refillRatio = 0.05f; // default: 0.1

      HedgingSettings hedgingSettings =
          HedgingSettings.newBuilder()
              .setHedgeDelay(hedgeDelay)
              .setMaxTokens(maxTokens)
              .setRefillRatio(refillRatio)
              .build();

      // Create a publisher instance with hedging settings bound to the topic
      publisher = Publisher.newBuilder(topicName).setHedgingSettings(hedgingSettings).build();

      String message = "Hello world!";
      ByteString data = ByteString.copyFromUtf8(message);
      PubsubMessage pubsubMessage = PubsubMessage.newBuilder().setData(data).build();

      // Once published, returns a server-assigned message id (unique within the topic)
      ApiFuture<String> messageIdFuture = publisher.publish(pubsubMessage);
      String messageId = messageIdFuture.get();
      System.out.println("Published a message with hedging settings: " + messageId);

    } finally {
      if (publisher != null) {
        // When finished with the publisher, shutdown to free up resources.
        publisher.shutdown();
        publisher.awaitTermination(1, TimeUnit.MINUTES);
      }
    }
  }
}

순서 키로 헤징 게시

게시 헤징은 메시지 순서 지정과 함께 사용할 수 없습니다. 게시 헤징은 동일한 메시지 배치에 대해 동시 게시 요청을 전송하므로 Pub/Sub 서비스에서 이러한 요청을 순서와 관계없이 수신하고 처리할 수 있습니다. 게시자 클라이언트에서 메시지 순서 지정과 게시 헤징을 모두 사용 설정하면 게시자 만들기가 실패하고 오류가 발생합니다.

팁 및 권장사항

게시 헤징을 구성할 때는 다음 권장사항을 고려하세요.

일시적인 꼬리 지연 시간에 헤징 사용: 게시 헤징은 일시적인 네트워크 지연 또는 일시적인 서버 측 속도 저하로 인한 단기 지연 시간 급증을 완화하도록 설계되었습니다. 지속적인 서비스 중단이나 영구적인 오류를 완화하기 위해 헤징에 의존하지 마세요.
재시도 정책을 사용한 헤징: 재시도 설정에서 초기 요청 제한 시간을 더 길게 설정하고 헤지 지연 시간을 더 짧게 설정합니다. 짧고 공격적인 제한 시간은 요청을 조기에 취소하고 전체 재시도를 트리거하여 서버에서 이미 진행 중인 작업을 삭제합니다. 제한 시간이 길면 원래 요청이 약간만 지연되는 경우 완료될 수 있습니다.
클라이언트 측 흐름 제어 및 헤징: 게시 헤징은 CPU 경합 또는 스레드 부족과 같은 클라이언트 측 지연을 해결하지 않습니다. 클라이언트 메모리의 메시지 큐로 인해 게시 지연 시간이 길어지는 경우 흐름 제어를 사용하여 큐 크기를 관리하면 도움이 될 수 있지만 호스트 리소스 제약 조건도 해결해야 합니다.
게시 지연 시간 및 처리량 측정항목 모니터링: topic/send_request_latencies과 같은 Monitoring 측정항목 그래프를 사용하여 테일 지연 시간 급증을 식별하고 헤징이 도움이 될 수 있는지 확인합니다. CANCELLED 오류 비율이 높으면 요청 기한이 너무 낮게 구성되었음을 나타낼 수 있습니다. 게시 헤징을 효과적으로 조정하면 게시 지연 시간 중에도 메시지 처리량과 주제 바이트 비용이 거의 일정하게 유지됩니다.

다음 단계

고급 게시 옵션을 구성하는 방법은 다음을 참조하세요.

헤징 게시 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.