제한 시간 및 기한 구성

이 문서에서는 Route Optimization API 요청의 제한 시간 및 기한 설정을 구성하는 방법을 설명합니다. 이러한 값을 설정하지 않거나 잘못 설정하면 연결 또는 응답 품질 문제가 발생할 수 있습니다.

요청 본문에서 제한 시간을 정의하고 요청 헤더에서 기한을 정의합니다. Route Optimization API는 이러한 매개변수로 정의된 시간 제한 내에서 요청을 처리하며, 가장 짧은 시간 값을 따릅니다.

제한 시간 및 기한을 구성하면 다음과 같은 방법으로 처리 시간을 관리할 수 있습니다.

  • 처리 시간 증가:
    • 복잡성이 높은 요청을 해결합니다.
    • 더 높은 품질의 대답을 얻습니다.
  • 처리 시간 단축:
    • 복잡성이 낮은 요청을 기본 모델보다 빠르게 해결합니다.
    • 요청을 더 빨리 해결하지만 품질이 낮은 응답을 받습니다.

제한 시간 및 기한 요구사항 이해

제한 시간 및 기한을 구성하기 전에 이 섹션을 검토하여 엔드포인트 및 프로토콜 선택이 이러한 설정에 미치는 영향을 이해했는지 확인하세요.

다음 가이드라인을 참고하여 목표에 적합한 설정을 사용하고 있는지 확인하세요.

  • 연속적이고 반복적인 요청과 해결 시간이 길어질수록 유리한 복잡한 요청에는 비차단 엔드포인트를 사용합니다.
  • 작은 요청과 빠른 결과 전송을 위해 차단 엔드포인트를 사용하여 품질 절충을 허용합니다.
  • 일상적인 워크플로, 특히 프로덕션 애플리케이션에는 gRPC를 사용합니다.
  • 테스트, 실험 또는 일회성 요청에는 REST를 사용합니다.

아래 버튼을 클릭하면 이 문서의 어떤 섹션이 설정과 가장 관련이 있는지 파악하는 데 도움이 되는 다이어그램을 볼 수 있습니다.

별도의 탭에서 다이어그램 열기

timeout 매개변수 설정

요청 본문에서 timeout 매개변수의 값을 설정하여 서버가 응답을 반환하기 전에 요청을 처리하는 최대 시간을 지정합니다. API가 최대 할당 시간에 도달하기 전에 최적의 솔루션을 찾으면 실제 소요 시간이 할당된 시간보다 짧을 수 있습니다.

기간 프로토콜 버퍼를 사용하여 timeout 매개변수를 설정합니다. 이 매개변수는 1초에서 1,800초 사이의 기간(초)입니다. allowLargeDeadlineDespiteInterruptionRisk를 사용하여 이 값을 최대 3,600초까지 늘립니다.

다음 표에는 요청 복잡성과 배송 및 차량 수를 기준으로 권장되는 timeout 값이 나와 있습니다.

배송 및 차량 수 제약 조건 없음 느슨한 시간대 및 부하 제약조건 또는 긴 경로 짧은 시간대, 적재 제약조건, 복잡한 제약조건 또는 매우 긴 경로
1 ~ 8 2초 2초 5초
9~32 5초 10초 20초
33~100 15초 30초 60s
101~1,000개 45초 90년대 180초
1,001~10,000명 120초 360초 900초
10,001명 이상 배송 10,000건당 60초 + 120초 배송 10,000건당 360초 배송 10,000건당 900초

마감일 설정

요청 헤더에 기한을 설정하여 Route Optimization API가 요청을 처리하는 데 소요되는 최대 시간을 정의합니다. 다음 하위 섹션에서는 REST 및 gRPC 요청의 기한을 설정하는 방법을 설명합니다.

REST 요청

REST를 사용하여 차단 엔드포인트를 호출할 때는 기본값인 60초를 초과하여 기한을 연장할 수 있습니다. 이 기본값은 복잡한 요청에는 너무 짧은 경우가 많습니다. 기본 기한은 요청 본문에 설정된 60초보다 큰 timeout 값을 재정의하므로 요청 본문에 더 긴 기한을 이미 지정한 경우에도 이 작업을 수행해야 합니다.

X-Server-Timeout 요청 헤더를 설정하여 기한을 기본 60초 이상으로 연장합니다. 요청 본문과 달리 헤더 값은 초 단위이지만 's' 서픽스가 없습니다. 이 헤더에 설정할 수 있는 최댓값은 timeout 파라미터의 제한사항과 일치합니다.

다음 코드 샘플은 X-Server-Timeout가 1,800초로 설정된 HTTP 헤더를 보여줍니다.

curl -X POST 'https://routeoptimization.googleapis.com/v1/projects/:optimizeTours' \
-H "Content-Type: application/json" \
-H "X-Server-Timeout: 1800" \
-H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
--data @- << EOM
{
  "model": {
    ...
  }
}
EOM

클라이언트 라이브러리 및 gRPC 요청

클라이언트 라이브러리 또는 gRPC를 사용할 때는 기한을 구성할 필요가 없습니다. 이를 사용할 때의 기본 기한은 이 API의 최대 요청 시간인 3, 600초입니다. 요청 본문에서 제한 시간 속성만 설정하여 풀이 시간을 구성합니다.

제한 시간 및 기한에 영향을 미치는 매개변수

다음 매개변수는 제한 시간과 기한이 작동하는 방식에 영향을 미칩니다.

  • allowLargeDeadlineDespiteInterruptionRisk를 사용하여 최대 요청 기한을 제어합니다.
  • searchMode를 사용하여 솔루션 품질과 지연 시간의 균형을 맞추는 검색 동작을 정의합니다.

allowLargeDeadlineDespiteInterruptionRisk

allowLargeDeadlineDespiteInterruptionRisk 매개변수는 최대 요청 기한을 3,600초로 늘립니다. 이 매개변수가 설정되지 않은 경우 제한 시간 및 기한 매개변수의 최댓값은 1, 800초입니다.

allowLargeDeadline DespiteInterruptionRisk를 true로 설정하여 제한 시간 및 기한 매개변수 값을 최대 3,600초까지 늘립니다.

allowLargeDeadline DespiteInterruptionRisk에 허용되는 값은 다음과 같습니다.

  • true: 중단 위험을 인식하면서 제한 시간 및 기한 매개변수의 최댓값을 3,600초로 늘립니다.
  • false (기본값): 제한 시간 및 기한 매개변수의 최댓값을 1,800초로 유지합니다.

3, 600초보다 긴 제한 시간이 필요하다고 생각되면 Google 담당자에게 문의하세요.

searchMode

searchMode 매개변수는 최적화 도구가 솔루션을 검색하는 방법을 제어하여 더 빠른 응답 (지연 시간 단축) 또는 더 높은 품질의 솔루션에 우선순위를 지정할 수 있습니다.

솔루션 품질을 우선시하면 최적화 도구에서 고품질 솔루션을 찾는 데 상당한 시간이 걸립니다. 이러한 긴 요청의 경우 연결 문제를 방지하기 위해 더 긴 제한 시간을 설정하고 비차단 엔드포인트를 사용하는 것이 좋습니다.

searchMode에 허용되는 값은 다음과 같습니다.

  • SEARCH_MODE_UNSPECIFIED (기본값): 지정되지 않은 검색 모드로, RETURN_FAST와 동일합니다.
  • RETURN_FAST: 첫 번째 적절한 솔루션을 찾은 후 검색을 중지합니다.
  • CONSUME_ALL_AVAILABLE_TIME: 사용 가능한 모든 시간을 더 나은 솔루션을 찾는 데 사용합니다. API는 최적의 솔루션을 조기에 찾으면 사용 가능한 모든 시간을 사용하지 않습니다.

연결 유지 핑 사용 설정

제한 시간이 60초보다 긴 차단 엔드포인트에 요청을 보낼 때 연결 유지 핑은 응답을 기다리는 동안 연결 손실을 방지하는 데 도움이 됩니다. 연결 유지 핑은 연결 활동을 유지하고 연결 손실을 감지하고 방지하기 위해 전송되는 작은 패킷입니다.

사용하는 API 프로토콜에 따라 다음 매개변수를 구성합니다.

  • REST: TCP 연결 수준에서 연결 유지를 구성합니다.
  • gRPC: 기본 TCP 소켓 또는 gRPC 프로토콜에서 직접 연결 유지 핑을 구성합니다.

다음 섹션에서는 두 프로토콜 모두에 대해 연결 유지 핑을 설정하는 방법을 설명합니다.

REST 연결 유지

REST를 사용할 때 연결 유지 핑을 구성하는 방법은 HTTP 클라이언트 라이브러리에 따라 다릅니다. curl과 같은 클라이언트 라이브러리 및 도구는 특정 구성 옵션을 제공하거나 자동으로 핑을 사용 설정할 수 있습니다.

라이브러리가 기본 TCP 소켓을 노출하는 경우 SO_KEEPALIVE과 같은 옵션을 사용하여 TCP 소켓에서 직접 연결 유지 핑을 구성할 수 있습니다. setsockopt()와 같은 함수 또는 이에 상응하는 함수를 사용하여 이 작업을 수행합니다.

GitHub에서 호스팅되는 이 함수는 Python 기본 제공 HTTP 클라이언트에 대해 이를 올바르게 설정하는 방법을 보여줍니다.

TCP 수준 연결 유지에 대한 자세한 내용은 TLDP 연결 유지 개요 또는 HTTP 클라이언트 라이브러리 문서를 참조하세요.

gRPC 연결 유지

gRPC는 프로토콜의 일부로 자체 내장된 연결 유지 메커니즘을 제공합니다. 클라이언트 언어로 이를 설정하는 방법은 gRPC 연결 유지 가이드를 참조하세요.

연결 유지 기능이 있는 gRPC 샘플 요청

다음 예시에서는 Python 클라이언트 라이브러리와 gRPC 수준 연결 유지 핑을 사용하여 optimizeTours 요청을 수행하는 방법을 보여줍니다.

from google.maps import routeoptimization_v1 as ro
from google.maps.routeoptimization_v1.services.route_optimization.transports import grpc as grpc_transport
import sys

_REQUEST_TIMEOUT_SECONDS = 1800
_KEEPALIVE_PING_SECONDS = 30

def create_channel(*args, **kwargs):
  raw_options = kwargs.pop("options", ())
  options = dict(raw_options)
  options["grpc.keepalive_time_ms"] = _KEEPALIVE_PING_SECONDS * 1000
  options["grpc.keepalive_timeout_ms"] = 5000
  # Allow any number of pings between the request and the response.
  options["grpc.http2.max_pings_without_data"] = 0
  print(f"Using options: {options}", file=sys.stderr)
  return grpc_transport.RouteOptimizationGrpcTransport.create_channel(
      *args,
      options=list(options.items()),
      **kwargs,
  )

def create_grpc_transport(*args, **kwargs):
  if "channel" in kwargs:
    raise ValueError(
        "`channel` is overridden by this function, and must not be provided."
    )
  return grpc_transport.RouteOptimizationGrpcTransport(
      *args,
      channel=create_channel,
      **kwargs,
  )

def run_optimize_tours(request):
  client = ro.RouteOptimizationClient(transport=create_grpc_transport)
  return client.optimize_tours(request, timeout=_REQUEST_TIMEOUT_SECONDS)