제한 시간 및 기한 구성

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

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

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

• 처리 시간 늘리기:
  • 복잡성이 높은 요청을 해결합니다.
  • 더 높은 품질의 응답을 가져옵니다.
• 처리 시간 줄이기:
  • 기본값보다 빠르게 복잡성이 낮은 요청을 해결합니다.
  • 더 짧은 시간에 요청을 해결하지만 응답 품질이 낮아집니다.

참고: 제한 시간 및 기한 매개변수는 solvingMode가 기본값인 DEFAULT_SOLVE로 설정된 경우에만 적용됩니다. VALIDATE_ONLY, DETECT_SOME_INFEASIBLE_SHIPMENTS, TRANSFORM_AND_RETURN_REQUEST와 같은 다른 solvingMode 옵션은 일반적으로 훨씬 빠르기 때문에 제한 시간 조정을 요구하지 않습니다.

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

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

다음 가이드라인은 목표에 맞는 설정을 사용하고 있는지 확인하는 데 도움이 됩니다.

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

아래 버튼을 클릭하여 이 문서의 어느 섹션이 설정과 가장 관련이 있는지 결정하는 데 도움이 되는 다이어그램을 확인하세요.

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

timeout 매개변수 설정

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

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

권장되는 timeout 값

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

기한 설정

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

REST 요청

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

X-Server-Timeout 요청 헤더를 설정하여 기한을 기본값인 60초보다 길게 연장합니다. 요청 본문과 달리 헤더의 값은 초 단위이지만 's' 접미사가 없습니다. 이 헤더에 설정할 수 있는 최댓값은 timeout 매개변수's 제한사항과 일치합니다.

다음 코드 샘플은 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를 사용할 때는 기한을 구성할 필요가 없습니다. 이를 사용할 때의 기본 기한은 3, 600초이며 이 API의 최대 요청 시간입니다. 요청 본문에서 제한 시간 속성만 설정하여 해결 시간을 구성합니다.

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

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

• 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 서버는 핑을 너무 많이 보내는 클라이언트를 거부할 수 있습니다. 연결 유지 핑 빈도를 너무 높게 설정하지 마세요.

연결 유지가 포함된 gRPC 샘플 요청

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

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)