본문 기반 라우팅 구성

HTTP 요청 본문에서 직접 모델 이름을 추출하여 추론 요청을 라우팅할 수 있는 GKE 추론 게이트웨이의 기능인 본문 기반 라우팅을 구성하는 방법을 알아봅니다.

이는 모델 식별자가 헤더나 URL 경로가 아닌 요청 페이로드 내에 삽입되는 경우가 많은 OpenAI API와 같은 사양을 준수하는 애플리케이션에 특히 유용합니다.

신체 기반 라우팅 작동 방식

GKE 추론 게이트웨이는 Envoy 프록시의 ext_proc 확장 프로그램으로 본문 기반 라우팅을 구현합니다. 요청 흐름은 기존 게이트웨이 API 구성과 원활하게 통합되도록 설계되었습니다.

  1. 요청 수신: 7계층 부하 분산기가 수신되는 추론 요청을 수신합니다.
  2. 본문 매개변수 추출: 레이어 7 부하 분산기가 요청을 Body to Header 확장 프로그램에 전달합니다. 이 확장 프로그램은 HTTP 요청 본문에서 표준 model 매개변수를 추출합니다.
  3. 헤더 삽입: 추출된 모델 매개변수의 값이 키 X-Gateway-Model-Name이 있는 새 요청 헤더로 삽입됩니다.
  4. 라우팅 결정: 이제 요청 헤더에서 모델 이름을 사용할 수 있으므로 GKE 추론 게이트웨이는 기존 게이트웨이 API HTTPRoute 구조를 사용하여 라우팅 결정을 내릴 수 있습니다. 예를 들어 HTTPRoute 규칙은 삽입된 헤더와 일치하여 트래픽을 적절한 InferencePool로 전달할 수 있습니다.
  5. 엔드포인트 선택: 7계층 부하 분산기가 적절한 InferencePool (BackendService) 및 엔드포인트 그룹을 선택합니다. 그런 다음 선택한 풀 내에서 세부적인 엔드포인트 선택을 위해 요청 및 엔드포인트 정보를 엔드포인트 선택기 확장 프로그램에 전달합니다.
  6. 최종 라우팅: 요청이 엔드포인트 선택기 확장 프로그램에서 선택한 특정 모델 복제본으로 라우팅됩니다.

이 프로세스를 통해 모델 정보가 요청 본문 내에 깊이 있어도 GKE 추론 게이트웨이가 트래픽을 올바른 백엔드 서비스로 지능적으로 라우팅할 수 있습니다.

본문 기반 라우팅 구성

GKE 추론 게이트웨이의 본문 기반 라우팅 (BBR) 확장 프로그램은 Kubernetes 클러스터 내에서 관리하는 서비스로 실행됩니다. 레이어 7 부하 분산기 관점에서 BBR 확장 프로그램은 외부 gRPC 서버입니다. 부하 분산기가 모델 이름을 확인하기 위해 요청 본문을 검사해야 하는 경우 BBR 서비스에 gRPC 호출을 실행합니다. 그러면 BBR 서비스가 요청을 처리하고 라우팅을 위해 삽입할 헤더와 같은 정보를 부하 분산기에 반환합니다.

본문 기반 라우팅을 사용 설정하려면 BBR 확장 프로그램을 포드로 배포하고 GCPRoutingExtension 및 HTTPRoute 리소스를 사용하여 통합합니다.

기본 요건

바디 기반 라우터 배포

본문 기반 라우팅 확장 프로그램은 클러스터 내의 GCPRoutingExtension 리소스와 함께 Kubernetes 배포 및 서비스로 배포됩니다. Helm을 사용하여 설치를 간소화할 수 있습니다.

본문 기반 라우터에 필요한 리소스를 배포하려면 다음 명령어를 실행합니다.

helm install body-based-router oci://registry.k8s.io/gateway-api-inference-extension/charts/body-based-routing \
    --set provider.name=gke \
    --set inferenceGateway.name=GATEWAY_NAME

GATEWAY_NAME을 게이트웨이 리소스 이름으로 바꿉니다.

이 명령어는 다음 리소스를 배포합니다.

  • 바디 기반 라우팅 확장 프로그램의 서비스 및 배포
  • 본문 기반 라우팅 확장 프로그램을 GKE 게이트웨이 리소스에 연결하는 GCPRoutingExtension 리소스 및 GCPHealthCheckPolicy 리소스

모델 인식 라우팅을 위해 HTTPRoute 구성

확장 프로그램을 배포하고 구성한 후에는 삽입된 헤더 (X-Gateway-Model-Name)를 사용하여 라우팅 결정을 내리는 HTTPRoute 리소스를 정의할 수 있습니다.

다음은 모델 인식 라우팅을 위한 HTTPRoute 매니페스트의 예입니다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: routes-to-llms
spec:
  parentRefs:
  - name: GATEWAY_NAME
  rules:
  - matches:
    - headers:
      - type: Exact
        name: X-Gateway-Model-Name
        value: chatbot # Matches the extracted model name
      path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: gemma # Target InferencePool for 'chatbot' model
      kind: InferencePool
      group: "inference.networking.k8s.io"
  - matches:
    - headers:
      - type: Exact
        name: X-Gateway-Model-Name
        value: sentiment # Matches another extracted model name
      path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: llama # Target InferencePool for 'sentiment' model
      kind: InferencePool
      group: "inference.networking.k8s.io"

이 매니페스트를 클러스터에 적용하려면 httproute-for-models.yaml로 저장하고 다음 명령어를 실행합니다.

kubectl apply -f httproute-for-models.yaml

고려사항 및 제한사항

신체 기반 라우팅 구현을 계획할 때는 다음 사항을 고려하세요.

  • 실패 시 닫힘 동작: Body-Based Routing 확장 프로그램은 '실패 시 닫힘' 모드에서 작동하도록 설계되었습니다. 확장 프로그램을 사용할 수 없거나 요청 처리에 실패하면 잘못된 라우팅이 발생하는 대신 오류가 발생합니다 (예: 기본 백엔드가 구성되지 않은 경우 404 또는 503 응답 코드). 서비스 안정성을 유지하기 위해 배포가 고가용성인지 확인하세요.

  • 요청 본문 크기 및 스트리밍: 특히 스트리밍이 사용 설정된 상태에서 큰 HTTP 요청 본문을 처리하면 복잡해질 수 있습니다. Envoy 프록시가 요청 본문을 스트리밍하도록 강제되는 경우 (일반적으로 250KB보다 큰 본문의 경우) 새 헤더를 삽입하지 못할 수 있습니다. 이로 인해 라우팅 실패 (예: 헤더 일치 규칙을 적용할 수 없는 경우 404 오류)가 발생할 수 있습니다.

  • 장기 유지관리: Body-Based Routing 확장 프로그램은 GKE 클러스터 내에서 구성요소로 실행됩니다. 업그레이드, 보안 패치, 지속적인 작동 보장 등 수명 주기 관리는 사용자의 책임입니다.

다음 단계