검색

4.2. 자동 확장

download PDF

4.2.1. 자동 확장

Knative Serving에서는 애플리케이션이 들어오는 요구에 맞게 자동 스케일링 또는 자동 스케일링 을 제공합니다. 예를 들어 애플리케이션에 트래픽이 수신되지 않고 scale-to-zero가 활성화된 경우 Knative Serving에서 애플리케이션을 복제본 0개로 축소합니다. scale-to-zero가 비활성화된 경우 애플리케이션은 클러스터의 애플리케이션에 대해 구성된 최소 복제본 수로 축소됩니다. 애플리케이션에 대한 트래픽이 증가하는 경우 복제본을 확장하여 요구에 맞게 확장할 수도 있습니다.

Knative 서비스에 대한 자동 스케일링 설정은 클러스터 또는 전용 관리자가 구성하는 글로벌 설정 또는 개별 서비스에 대해 구성된 버전별 설정일 수 있습니다.

OpenShift Dedicated 웹 콘솔을 사용하거나 서비스의 YAML 파일을 수정하거나 Knative(kn) CLI를 사용하여 서비스의 버전별 설정을 수정할 수 있습니다.

참고

서비스에 대해 설정한 모든 제한 또는 대상은 애플리케이션의 단일 인스턴스에 대해 측정됩니다. 예를 들어 target 주석을 50 으로 설정하면 자동 스케일러가 애플리케이션을 스케일링하여 각 버전이 한 번에 50개의 요청을 처리하도록 구성됩니다.

4.2.2. 스케일링 경계

스케일 바인딩에는 언제든지 애플리케이션을 제공할 수 있는 최소 및 최대 복제본 수가 결정됩니다. 콜드 스타트를 방지하거나 컴퓨팅 비용을 제어하는 데 도움이 되는 애플리케이션의 규모 범위를 설정할 수 있습니다.

4.2.2.1. 최소 스케일링 범위

애플리케이션을 제공할 수 있는 최소 복제본 수는 min-scale 주석에 따라 결정됩니다. scale to 0이 활성화되지 않은 경우 min-scale 값은 기본적으로 1 입니다.

다음 조건이 충족되는 경우 min-scale 값은 기본적으로 복제본이 0 으로 설정됩니다.

  • min-scale 주석이 설정되어 있지 않음
  • 0으로 스케일링 활성화
  • KPA 클래스 사용

min-scale 주석이 있는 서비스 사양의 예

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/min-scale: "0"
...

4.2.2.1.1. Knative CLI를 사용하여 min-scale 주석 설정

Knative(kn) CLI를 사용하여 min-scale 주석을 설정하면 YAML 파일을 직접 수정하는 것보다 더 간소화되고 직관적인 사용자 인터페이스가 제공됩니다. kn service 명령을 --scale-min 플래그와 함께 사용하여 서비스의 min-scale 값을 생성하거나 수정할 수 있습니다.

사전 요구 사항

  • Knative Serving이 클러스터에 설치되어 있습니다.
  • Knative(kn) CLI가 설치되어 있습니다.

절차

  • --scale-min 플래그를 사용하여 서비스의 최소 복제본 수를 설정합니다.

    $ kn service create <service_name> --image <image_uri> --scale-min <integer>

    명령 예

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --scale-min 2

4.2.2.2. 최대 스케일링 경계

애플리케이션을 제공할 수 있는 최대 복제본 수는 max-scale 주석에 따라 결정됩니다. max-scale 주석을 설정하지 않으면 생성된 복제본 수에 대한 상한이 없습니다.

max-scale 주석이 있는 서비스 사양의 예

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/max-scale: "10"
...

4.2.2.2.1. Knative CLI를 사용하여 max-scale 주석 설정

Knative(kn) CLI를 사용하여 max-scale 주석을 설정하면 YAML 파일을 직접 수정하는 것보다 더 간소화되고 직관적인 사용자 인터페이스가 제공됩니다. kn service 명령을 --scale-max 플래그와 함께 사용하여 서비스의 max-scale 값을 생성하거나 수정할 수 있습니다.

사전 요구 사항

  • Knative Serving이 클러스터에 설치되어 있습니다.
  • Knative(kn) CLI가 설치되어 있습니다.

절차

  • --scale-max 플래그를 사용하여 서비스의 최대 복제본 수를 설정합니다.

    $ kn service create <service_name> --image <image_uri> --scale-max <integer>

    명령 예

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --scale-max 10

4.2.3. 동시성

동시성은 언제든지 애플리케이션의 각 복제본에서 처리할 수 있는 동시 요청 수를 결정합니다. 동시성은 소프트 제한 또는 하드 제한 으로 구성할 수 있습니다.

  • 소프트 제한은 엄격하게 적용된 바인딩이 아닌 대상 요청 제한입니다. 예를 들어 트래픽이 급증하는 경우 소프트 제한 대상을 초과할 수 있습니다.
  • 하드 제한은 엄격하게 적용되는 상한 요청 제한입니다. 동시성이 하드 제한에 도달하면 surplus 요청이 버퍼링되고 요청을 실행할 수 있는 여유 용량이 충분할 때까지 기다려야 합니다.

    중요

    하드 제한 구성을 사용하는 것이 애플리케이션과 관련된 명확한 사용 사례가 있는 경우에만 사용하는 것이 좋습니다. 낮은 하드 제한을 지정하면 애플리케이션의 처리량 및 대기 시간에 부정적인 영향을 미칠 수 있으며 콜드 시작이 발생할 수 있습니다.

소프트 대상 및 하드 제한을 추가하면 자동 스케일러가 동시 요청의 소프트 대상 수를 대상으로 하지만 최대 요청 수에 대한 하드 제한 값의 하드 제한을 적용합니다.

하드 제한 값이 소프트 제한 값보다 작으면 실제로 처리할 수 있는 수보다 더 많은 요청을 대상으로 할 필요가 없기 때문에 소프트 제한 값이 조정됩니다.

4.2.3.1. 소프트 동시성 대상 구성

소프트 제한은 엄격하게 적용된 바인딩이 아닌 대상 요청 제한입니다. 예를 들어 트래픽이 급증하는 경우 소프트 제한 대상을 초과할 수 있습니다. 사양에서 autoscaling.knative.dev/target 주석을 설정하거나 올바른 플래그와 함께 kn service 명령을 사용하여 Knative 서비스에 대한 소프트 동시성 대상을 지정할 수 있습니다.

절차

  • 선택 사항: Service 사용자 정의 리소스의 사양에 Knative 서비스의 autoscaling.knative.dev/target 주석을 설정합니다.

    서비스 사양의 예

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: example-service
      namespace: default
    spec:
      template:
        metadata:
          annotations:
            autoscaling.knative.dev/target: "200"

  • 선택 사항: kn service 명령을 사용하여 --concurrency-target 플래그를 지정합니다.

    $ kn service create <service_name> --image <image_uri> --concurrency-target <integer>

    요청 수가 50개인 동시성 대상을 사용하여 서비스를 생성하는 예

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-target 50

4.2.3.2. 하드 동시성 제한 구성

하드 동시성 제한은 엄격하게 적용되는 상한 요청 제한입니다. 동시성이 하드 제한에 도달하면 surplus 요청이 버퍼링되고 요청을 실행할 수 있는 여유 용량이 충분할 때까지 기다려야 합니다. containerConcurrency 사양을 수정하거나 올바른 플래그와 함께 kn service 명령을 사용하여 Knative 서비스에 대한 하드 동시성 제한을 지정할 수 있습니다.

절차

  • 선택 사항: Service 사용자 정의 리소스의 사양에 Knative 서비스의 containerConcurrency 사양을 설정합니다.

    서비스 사양의 예

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: example-service
      namespace: default
    spec:
      template:
        spec:
          containerConcurrency: 50

    기본값은 0 입니다. 즉, 한 번에 하나의 서비스 복제본으로 전달될 수 있는 동시 요청 수에 대한 제한이 없음을 의미합니다.

    값이 0 보다 크면 한 번에 하나의 서비스 복제본으로 전달될 수 있는 정확한 요청 수를 지정합니다. 이 예제에서는 하드 동시성 제한을 50개의 요청으로 활성화합니다.

  • 선택 사항: kn service 명령을 사용하여 --concurrency-limit 플래그를 지정합니다.

    $ kn service create <service_name> --image <image_uri> --concurrency-limit <integer>

    50개의 요청의 동시성 제한이 있는 서비스를 생성하는 명령의 예

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-limit 50

4.2.3.3. 동시성 대상 사용

이 값은 실제로 자동 스케일러가 대상으로 하는 동시성 제한의 백분율을 지정합니다. 이는 정의된 하드 제한에 도달하기 전에 자동 스케일러를 확장할 수 있는 복제본이 실행되는 스를 지정하는이라고도 합니다.

예를 들어 containerConcurrency 값이 10으로 설정되고 target-utilization-percentage 값이 70%로 설정된 경우 기존 복제본의 평균 동시 요청 수가 7에 도달하면 자동 스케일러는 새 복제본을 생성합니다. 7~10 사이의 요청은 기존 복제본으로 계속 전송되지만 containerConcurrency 값에 도달한 후 필요한 항목이 예상되어 추가 복제본이 시작됩니다.

target-utilization-percentage 주석을 사용하여 구성된 서비스의 예

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target-utilization-percentage: "70"
...

4.2.4. Scale-to-zero

Knative Serving에서는 애플리케이션이 들어오는 요구에 맞게 자동 스케일링 또는 자동 스케일링 을 제공합니다.

4.2.4.1. scale-to-zero

enable-scale-to-zero 사양을 사용하여 클러스터의 애플리케이션에 대해 전체적으로 scale-to-zero 사양을 활성화하거나 비활성화할 수 있습니다.

사전 요구 사항

  • 클러스터에 OpenShift Serverless Operator 및 Knative Serving을 설치했습니다.
  • 클러스터 또는 전용 관리자 권한이 있어야 합니다.
  • 기본 Knative Pod Autoscaler를 사용하고 있습니다. Kubernetes Horizontal Pod Autoscaler를 사용하는 경우 0으로 스케일링 기능을 사용할 수 없습니다.

절차

  • KnativeServing CR(사용자 정의 리소스)에서 enable-scale-to-zero 사양을 수정합니다.

    KnativeServing CR의 예

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
    spec:
      config:
        autoscaler:
          enable-scale-to-zero: "false" 1

    1
    enable-scale-to-zero 사양은 "true" 또는 "false" 일 수 있습니다. true로 설정하면 scale-to-zero가 활성화됩니다. false로 설정하면 애플리케이션이 구성된 최소 스케일 바인딩 으로 축소됩니다. 기본값은 "true" 입니다.

4.2.4.2. scale-to-zero 유예 기간 구성

Knative Serving에서는 애플리케이션의 Pod를 0개로 자동 축소합니다. scale-to-zero-grace-period 사양을 사용하여 Knative가 애플리케이션의 마지막 복제본이 제거되기 전에 Knative가 0으로 전환될 때까지 대기하는 상한 시간 제한을 정의할 수 있습니다.

사전 요구 사항

  • 클러스터에 OpenShift Serverless Operator 및 Knative Serving을 설치했습니다.
  • 클러스터 또는 전용 관리자 권한이 있어야 합니다.
  • 기본 Knative Pod Autoscaler를 사용하고 있습니다. Kubernetes Horizontal Pod Autoscaler를 사용하는 경우에는 scale-to-zero 기능을 사용할 수 없습니다.

절차

  • KnativeServing CR(사용자 정의 리소스)에서 scale-to-zero-grace-period 사양을 수정합니다.

    KnativeServing CR의 예

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
    spec:
      config:
        autoscaler:
          scale-to-zero-grace-period: "30s" 1

    1
    유예 기간(초)입니다. 기본값은 30초입니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.