애플리케이션 스케일링 구성

IBM Cloud® Code Engine 를 사용하면, 들어오는 워크로드에 따라 애플리케이션의 실행 중인 인스턴스 수가 자동으로 확장되거나 축소(0개까지)되므로 애플리케이션의 확장성에 대해 따로 신경 쓸 필요가 없습니다. 자동 스케일링 기능을 사용하면 사용하지 않는 리소스에 대해 비용을 지불할 필요가 없습니다.

Code Engine은 시스템 내의 요청 수를 모니터링하고, 애플리케이션에 대한 HTTP 연결을 포함하여 수신 요청의 로드를 충족하기 위해 애플리케이션 인스턴스를 스케일링 업 및 다운합니다. 이러한 HTTP 연결은 이벤트 생성자의 위치에 관계없이 프로젝트 외부, 프로젝트에서 실행 중인 다른 워크로드 또는 구독할 수 있는 이벤트 생성자로부터 오는 요청일 수 있습니다. Code Engine은 애플리케이션 인스턴스를 자동으로 복제하고 요청을 모든 인스턴스 간에 로드 밸런싱하도록 네트워크 인프라를 구성합니다.

스케일링 작동 방식

Code Engine은 시스템 내의 요청 수를 모니터하고, 애플리케이션의 동시성 설정 제한조건 내에서 애플리케이션 인스턴스를 스케일링합니다.

Code Engine 콘솔에서 애플리케이션 스케일링을 관찰하려면 특정 애플리케이션 페이지로 이동하십시오. 애플리케이션이 실행되는 동안에는 실행 중인 인스턴스 수가 지정한 최대 인스턴스 수에 따라 1 이상입니다. 애플리케이션이 구성된 대상 동시성보다 적은 요청을 처리하는 경우 애플리케이션은 실행 중인 인스턴스 수를 구성된 최소 인스턴스 수로 스케일링 다운합니다. 최소 인스턴스 수가 0 (기본값)으로 설정된 경우, 애플리케이션은 0개까지 축소되며 해당 앱의 인스턴스 수는 0 인스턴스를 반영합니다. 애플리케이션이 축소되고 요청이 애플리케이션으로 라우팅되면 Code Engine 는 애플리케이션을 확장하고 요청을 새로 작성된 애플리케이션 인스턴스로 라우팅합니다.

애플리케이션이 완전히 축소할 수 있으려면 애플리케이션 코드가 SIGTERM 신호를 처리해야 합니다. Code Engine 가 자동으로 축소되면, 애플리케이션에 SIGTERM 신호가 전송됩니다. 애플리케이션이 SIGTERM 신호를 처리하지 않으면 앱 인스턴스는 요청 제한시간 값으로 구성된 시간 (기본값은 300초) 동안 Terminating 상태로 유지됩니다. 요청 타임아웃 기간이 지나면, Code Engine 은 Terminating 상태에 있는 앱 인스턴스를 강제 종료하기 위해 SIGKILL 신호를 보냅니다.

스케일링 경계

Code Engine 가 애플리케이션의 실행 중인 인스턴스 수를 자동 확장할 때 적용할 최소 및 최대 인스턴스 수 범위를 설정하여 확장 범위를 구성할 수 있습니다. 애플리케이션을 작성하거나 업데이트할 때 이 범위를 구성하십시오.

  • 최소 인스턴스 수-요청이 처리되지 않더라도 항상 실행 중인 앱의 최소 인스턴스 수입니다. 0(기본값)으로 설정하면, Code Engine은 애플리케이션에 도달하는 트래픽이 없는 경우 모든 인스턴스를 제거합니다. 항상 애플리케이션의 실행 중인 인스턴스를 유지하려면 이 값을 0 보다 큰 값으로 설정하십시오. 콘솔에서 Code Engine 를 사용하여 애플리케이션을 작성하거나 업데이트할 때 자원 & 스케일링 탭의 Auto-Scaling 섹션에서 최소 인스턴스 수 값을 설정하십시오. --min-scale CLI를 사용할 때는 app create 및 app update 명령어에서 xml-ph-0000@deepl.internal 옵션을 지정하십시오.

  • 최대 인스턴스 수-앱에 대해 실행할 수 있는 최대 인스턴스 수입니다. 이 한도까지 자동 확장 기능이 작동합니다. 이 값을 0``로 설정하면 애플리케이션이 필요에 따라 확장되며, 앱의 확장 범위는 해당 앱 프로젝트의 리소스 할당량에 따른 인스턴스 수에 의해서만 제한됩니다. Code Engine의 한계 및 할당량을 참조하십시오. 콘솔에서 Code Engine 를 사용하여 애플리케이션을 작성하거나 업데이트할 때 자원 & 스케일링 탭의 Auto-Scaling 섹션에서 최대 인스턴스 수 값을 설정하십시오. --max-scale CLI를 사용할 때는 app create 및 app update 명령어에서 xml-ph-0000@deepl.internal 옵션을 지정하십시오. 이 옵션의 기본값은 10 입니다.

애플리케이션을 이벤트 생성자에 연결하는 경우 스케일 경계 설정 시 해당 생성자의 이벤트 빈도 및 볼륨을 고려해야 합니다. 예를 들어, 동시에 많은 이벤트를 수신할 것으로 예상되고 각 이벤트의 처리 시간이 몇 분씩 소요될 경우, 각 이벤트를 빠르게 처리할 수 있는 경우보다 더 높은 최대 스케일 값이 필요할 수 있습니다. 값을 너무 낮게 설정하면 이벤트 수신이 지연되거나 처리 리소스가 사용 가능하게 될 때까지 대기하는 동안 제한시간 초과로 인해 이벤트가 삭제될 수도 있습니다.

동시성 및 시간 제어를 위한 자동 스케일링 설정

다음 구성 설정을 사용하여 애플리케이션의 확장성을 제어하십시오.

  • 동시 처리 능력 - 이 값은 앱의 각 인스턴스가 한 번에 처리할 수 있는 요청의 수를 나타냅니다. 예를 들어, 통화 값이 100이라면 코드가 동시에 100개의 동시 요청을 처리할 수 있음을 의미합니다. 이 값은 "엄격한 한계"이며, 이는 Code Engine이 모든 애플리케이션 인스턴스에 동시성 설정에 지정된 것보다 많은 요청이 도달하는 것을 허용하지 않음을 의미합니다. 따라서, 코드가 단일 스레드 방식이며 한 번에 하나의 요청만 처리할 수 있다면, 동시성(concurrency)을 1``로 설정하는 것을 고려해 보십시오. 애플리케이션의 실행 중인 모든 인스턴스에 지정된 수의 요청이 전송되면, Code Engine 는 추가 요청에 대비하여 인스턴스 수를 늘립니다. 콘솔에서 Code Engine 를 사용하여 애플리케이션을 작성하거나 업데이트할 때 자원 & 스케일링 탭의 자동 스케일링 섹션에서 최대 동시성 값을 설정하십시오. CLI를 사용하는 경우에는 --concurrency 및 app create 명령에 app update 옵션을 지정하십시오.

  • 목표 동시 실행 수 - 이 값은 부하가 걸린 시스템에서 인스턴스당 허용하고자 하는 요청 수, 즉 “유연 제한” 역할을 합니다. 예를 들어, concurrency 을 100 으로 지정하고, target concurrency 을 70 으로 지정하면, Code Engine 은 인스턴스당 요청 수를 70개로 제한하려고 시도합니다.이 옵션을 지정한다고 해서 인스턴스당 요청 수가 70건을 초과하지 않는다고 보장할 수는 없습니다. 트래픽이 증가할 경우 요청 수가 70건을 초과할 가능성이 매우 높기 때문입니다. 그러나 70과 100 사이의 완충 구간은 시스템이 새 인스턴스를 작성하여 인스턴스당 로드를 70 아래로 떨어트릴 수 있게 해 줍니다. target concurrency 가 지정되지 않은 경우, 기본값은 concurrency 의 값입니다. 콘솔에서 ‘ Code Engine ’을 사용하여 애플리케이션을 생성하거나 업데이트할 때는 ‘Resources & scaling’ 탭의 ‘Autoscaling’ 섹션에서 대상 동시 실행 수 값을 설정하십시오. --concurrency-target CLI를 사용할 때는 app create 및 app update 명령어에서 xml-ph-0000@deepl.internal 옵션을 지정하십시오.

  • 요청 제한시간-애플리케이션이 요청에 응답해야 하는 시간 (초) 입니다. 그렇지 않으면 실패합니다. 콘솔에서 Code Engine 를 사용하여 애플리케이션을 작성하거나 업데이트할 때 자원 & 스케일링 탭의 자동 스케일링 섹션에서 요청 제한시간 값을 설정하십시오. --request-timeout CLI를 사용할 때는 app create 및 app update 명령어에서 xml-ph-0000@deepl.internal 옵션을 지정하십시오.

  • 축소 지연 시간 - 애플리케이션이 축소되기까지, 동시 처리량이 감소된 상태에서 경과해야 하는 시간(초 단위). 애플리케이션에 대한 수신 요청의 패턴을 알고 있는 경우, 애플리케이션의 스케일링 다운을 지연시키기 위해 기본값 0 보다 큰 값을 지정하도록 선택할 수 있습니다. 이 옵션에 높은 값을 사용하면 동시에 실행 중인 애플리케이션 인스턴스의 평균 수가 증가하여 추가 비용이 발생할 수 있습니다. 0 의 스케일 다운 지연 설정을 사용하는 경우에도 시스템은 애플리케이션이 인스턴스 수를 축소하기 전에 짧은 시간 동안 대기하여 요청 동시성의 드롭 다운이 스케일 다운을 보장할 수 있을 만큼 안정적인지 확인합니다. 콘솔에서 Code Engine 를 사용하여 애플리케이션을 작성하거나 업데이트할 때 자원 & 스케일링 탭의 Auto-Scaling 섹션에서 축소 지연 값을 설정하십시오. --scale-down-delay CLI를 사용할 때는 app create 및 app update 명령어에서 xml-ph-0000@deepl.internal 옵션을 지정하십시오.

예를 들어, 최대 인스턴스 수 값이 10 로 설정되고 동시성이 100 로 설정된 경우, 애플리케이션은 잠재적인 요청 큐 처리가 발생하기 전에 1000개의 동시 요청을 처리할 수 있습니다. 동시에 1000개이상의 요청을 예상하는 경우 앱의 최대 인스턴스 수 값을 늘리는 것을 고려할 수 있습니다.

Code Engine 작동 방식에 대한 자세한 내용은 IBM Cloud Code Engine 애플리케이션 응답 시간 단축을 위한 스케일다운 지연 조정하기를 참조하세요.

인스턴스의 최소 수를 최대 수와 동일하게 설정하면 스케일링이 발생하지 않으며 대상 통화 및 스케일링 다운 지연 값이 적용되지 않습니다. 그러나 동시성 값은 여전히 유효합니다.

자동 스케일링을 위한 예제 시나리오

다음 자동 스케일링 설정으로 구성된 애플리케이션이 있다고 가정하합:은

  • 최소 인스턴스 수 = 4
  • 최대 인스턴스 수 = 20
  • 동시성 = 2

이러한 설정을 사용하면 앱이 동시에 2개의 동시 요청을 처리할 수 있습니다. 트래픽이 없으면 애플리케이션이 자동으로 4개의 인스턴스로 스케일링 다운됩니다. 4개의 인스턴스는 4 * 2 (통화) = 8개의 요청만 처리할 수 있습니다. 애플리케이션은 최대 20개의 인스턴스까지 확장할 수 있습니다. 이 경우 20개의 인스턴스는 애플리케이션에 대해 충분한 CPU및 메모리 설정을 가정하여 20 * 2 (통화) = 40개의 요청을 처리할 수 있습니다.

애플리케이션이 로그인 페이지를 로드하기 위해 애플리케이션에 대한 6개의 호출이 필요한 정적 웹 애플리케이션이라고 가정합니다. 10명의 사용자가 동시에 애플리케이션 로그인 페이지에 로그인한다고 가정합니다 (10 * 6 = 60호출). 60개의 호출이 앱에서 처리할 수 있는 40개가 넘는 요청을 포함하므로 애플리케이션 사용자는 호출이 큐에 대기할 때 속도가 느려질 수 있습니다.

앱에 대한 트래픽이 없는 약 1분후에 Code Engine 가 자동으로 스케일링 다운을 시작합니다. 애플리케이션이 축소되면 일부 인스턴스가 Terminating 상태로 설정됩니다. Code Engine 는 SIGTERM 신호를 애플리케이션으로 전송하며 코드는 이 신호를 처리하고 종료해야 합니다. 애플리케이션이 이 신호를 처리하지 않는 경우 앱 인스턴스는 요청 제한시간 값 (기본값은 300초) 으로 구성된 시간 동안 Terminating 상태로 유지됩니다. 요청 제한시간이 초과된 후 Code Engine 는 SIGKILL 신호를 전송하여 Terminating 상태의 앱 인스턴스를 강제로 중지합니다.

8개의 활성 인스턴스가 있고 12개의 인스턴스가 300초 (5분) 동안 Terminating 상태로 유지되는 경우. 이 12개의 인스턴스는 요청을 수신하지 않습니다. 8개이상의 * 2 (통화) = 16개이상의 요청이 수신되면 Code Engine 가 새 인스턴스를 스케일링 업합니다.

이 예에서 2 의 동시성 값은 이 정적 컨텐츠에 대해 낮습니다. 앱에 설정할 자동 스케일링 값을 판별해야 합니다. 이는 앱의 구현이 지정된 CPU및 메모리 자원으로 처리할 수 있는 항목에 따라 다릅니다.

대기 시간 및 처리량 최적화

애플리케이션 대기 시간 및 처리량을 최적화하려면 몇 가지 공통 모델 및 우수 사례의 장단점을 이해하여 컨테이너 동시성을 구성하십시오.

애플리케이션을 생성하거나 업데이트할 때, 동시 처리 설정값을 사용하여 인스턴스당 동시에 처리할 수 있는 최대 요청 수를 지정하십시오. Code Engine 콘솔의 경우 런타임 섹션에 동시성 값을 설정하십시오. CLI를 사용할 경우 app create 또는 app update 명령과 함께 --concurrency 옵션(별명 --cn)을 사용하십시오.

Code Engine 애플리케이션의 동시성 예
모델 장점 단점
단일 동시성, --cn=1 애플리케이션이 메모리 집약적 또는 CPU 집약적 워크로드를 처리하는 경우 단일 동시성 구성을 선택하십시오. 이 경우 한 번에 하나의 요청만 애플리케이션 인스턴스에 진입하므로 인스턴스에 대해 구성된 전체 CPU 및 메모리 양을 사용할 수 있기 때문입니다. 단일 동시성 모델을 사용하는 애플리케이션은 빠르게 스케일 확장됩니다. 기존 인스턴스를 재사용하는 것보다 애플리케이션 인스턴스를 새로 작성하는 것이 더 비싸기 때문에 스케일 확장의 경우 지연 시간이 추가되고 처리량이 낮아질 수 있습니다. 요청을 동시에 처리할 수 있고 대기 시간이 애플리케이션의 중요한 측면인 경우에는 이 모델을 선택하지 마십시오.
높은 동시성, --cn=100(기본값) 이상 애플리케이션이 대량의 HTTP 요청 또는 응답 워크로드를 처리하는데 이 워크로드가 CPU 집약적 또는 메모리 집약적이지 않으며 리소스를 기다릴 수 있는 경우 이 구성을 선택하십시오. 원격 데이터베이스에 대한 생성, 조회, 업데이트, 삭제 작업 시 데이터를 읽고 쓰는 API 백엔드의 경우, 이 동시성 구성을 선택할 수 있습니다. 일부 요청이 I/O를 기다리는 동안, 전체 대기 시간과 처리량에 영향을 미치지 않고 다른 요청을 처리할 수 있습니다. 동시 요청이 CPU, 메모리 또는 I/O를 얻기 위해 경쟁할 경우 이 설정은 최적이 아닙니다. 리소스 경쟁이 실행을 지연시키고 대기 시간과 처리량에 부정적인 영향을 줄 수 있기 때문입니다.
최적의 동시성, --cn=N 애플리케이션에 대해 원하는 응답 시간을 충족하기 위해 단일 요청에 필요한 리소스의 양을 알고 있는 경우 최적의 동시성 구성을 선택하십시오. 앱이 자연어 번역 애플리케이션이고, 언어 변환을 위한 머신러닝 모델의 크기가 32 GB이며, 요청당 단일 번역 계산에 약 0.7 vCPU 가 소요되는 경우 이 구성을 선택할 수 있습니다. 인스턴스당 9vCPU 및 32GB 메모리의 구성을 선택할 수 있습니다. 최적의 컨테이너 동시성은 약 13(9 vCPU/0.7 vCPU)입니다. 애플리케이션에 대한 리소스 요구사항을 모르는 경우에는 최적의 동시성 구성을 선택하지 마십시오. 잘못된 컨테이너 동시성을 설정하면 너무 공격적이거나 너무 지연된 스케일링이 발생할 수 있으며, 이로 인해 애플리케이션의 지연 시간, 오류 비율, 비용에 영향을 미칠 수 있습니다. 자세한 정보는 애플리케이션 컨테이너의 동시성 판별을 참조하십시오.
무한 동시성, --cn=0(사용 안함) 사용 안함 Code Engine에서는 무한 동시성 구성이 지원되지 않습니다. 무한 동시성 구성은 가능한 많은 요청을 단일 애플리케이션 인스턴스에 전달하므로, 추가 애플리케이션 인스턴스의 스케일링이 지연될 수 있습니다.

애플리케이션 컨테이너의 동시성 판별

최적의 컨테이너 동시성 값은 애플리케이션이 허용 가능한 요청 대기 시간으로 처리할 수 있는 최대 동시 요청 수에 따라 결정됩니다.

컨테이너 동시성은 애플리케이션의 성공률, 대기 시간 및 처리량에 직접적인 영향을 미칩니다. 컨테이너의 동시성 값이 애플리케이션이 처리할 수 있는 수준을 초과하면 지연 시간과 처리량에 부정적인 영향을 미치며, ‘ 502 ’ 및 ‘ 503 ’ 오류 응답이 발생할 수 있습니다.

컨테이너 동시성 값이 애플리케이션에 대해 너무 낮은 경우, 시스템에서는 애플리케이션을 더 빨리 스케일 확장하고 많은 애플리케이션 인스턴스에 요청을 분산시키므로 추가 비용과 대기 시간이 발생합니다. 로드가 폭발적으로 발생하는 동안 낮은 동시성 값은 시스템의 내부 버퍼가 오버될 때 임시 502 응답으로 이어질 수도 있습니다.

애플리케이션의 컨테이너 동시성 구성을 판별하려면 요청 및 대기 시간을 검토하십시오.

  1. 애플리케이션을 작성한 후 동시성을 1000(최대값)으로 설정하고 min-scale 및 max-scale을 모두 1로 설정하십시오.

    ibmcloud ce application create --name APPNAME --image APPIMAGE --min-scale=1 --max-scale=1 --concurrency=1000

  2. 높은 속도의 요청을 전송하여 시작하십시오. 502 오류가 있는 경우 결과에 성공률이 100%로 표시될 때까지 속도를 줄이십시오.

  3. 2단계 출력의 요청 대기 시간을 찾으십시오. 해당 요청 대기 시간을 허용할 수 없는 경우 요청 대기 시간이 허용 가능한 수준으로 보일 때까지 요청 비율을 추가로 줄이십시오. 요청 계산에 2초 또는 100밀리초가 걸리는 경우 차이가 발생하므로 요청 지속 시간도 중요합니다.

    허용되는 요청 속도 및 대기 시간은 애플리케이션 특성 및 스케일링 구성에 따라 다릅니다. 예를 들어 애플리케이션 내 계산에 100밀리초가 걸리고 동시성 설정이 10인 경우, 한 애플리케이션 인스턴스는 약 100밀리초의 지연 시간(네트워크 대기 시간 무시)으로 초당 약 100개의 요청을 처리할 수 있습니다.

  4. 애플리케이션의 컨테이너 동시성 값을 계산하려면 2단계의 속도(req/s)를 사용하고 3단계의 대기 시간(초)으로 나누십시오(CC = RATE/LATENCY). 예를 들어 속도가 초당 80개 요청이고 대기 시간이 2초인 경우, 결과적으로 동시성은 80 req/s / 2 s = 40입니다.

  5. 애플리케이션을 업데이트하여 컨테이너 동시성을 이전 단계에서 찾은 값으로 설정하고 워크로드를 다시 실행하여 성공률과 대기 시간이 허용 가능한지 여부를 확인하십시오.

  6. 컨테이너 동시성 값을 늘리고 성공률과 대기 시간을 관찰하여 애플리케이션을 시험해 보십시오.

  7. 최적의 컨테이너 동시성 값으로 애플리케이션을 업데이트한 후 애플리케이션이 자동으로 스케일링되도록 min-Scale 및 max-scale 경계를 제거하십시오.

CLI를 사용하여 앱을 스케일링하는 방법 관찰

CLI를 사용하여 앱의 실행 중인 인스턴스 수를 관찰할 수 있습니다.

  1. app create 명령을 사용하여 애플리케이션을 작성하십시오.

    ibmcloud ce application create --name myapp --image icr.io/codeengine/helloworld

  2. 애플리케이션을 호출하십시오. app create 명령의 출력에서 앱의 URL을 확보하거나 ibmcloud ce app get --name myapp --output url을 실행할 수 있습니다.

    curl https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud

  3. application get 명령을 실행하여 애플리케이션 상태를 표시하십시오. Running instances의 값을 찾으십시오. 이 예에서 앱의 실행 중인 인스턴스 수는 1입니다. 예를 들면 다음과 같습니다.

    ibmcloud ce application get --name myapp

    출력 예

    [...]
OK
Name:          myapp
[...]
URL:           https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud
Cluster Local URL:  http://myapp.4svg40kna19.svc.cluster.local
Console URL:   https://cloud.ibm.com/codeengine/project/us-south/01234567-abcd-abcd-abcd-abcdabcd1111/application/myapp/configuration
Status Summary:  Application deployed successfully
Environment Variables:
    Type     Name             Value
    Literal  CE_API_BASE_URL  https://api.private.us-south.codeengine.cloud.ibm.com
    Literal  CE_APP           myapp
    Literal  CE_DOMAIN        us-south.codeengine.appdomain.cloud
    Literal  CE_PROJECT_ID    abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
    Literal  CE_REGION        us-south
    Literal  CE_SUBDOMAIN     abcdabcdab
Image:                icr.io/codeengine/helloworld
Resource Allocation:
    CPU:                1
    Ephemeral Storage:  400M
    Memory:             4G
Revisions:
myapp-ds8fn-1:
    Age:                6m25s
    Traffic:            100%
    Image:              icr.io/codeengine/helloworld (pinned to fe0446)
    Running Instances:  1
Runtime:
    Concurrency:    100
    Maximum Scale:  10
    Minimum Scale:  0
    Timeout:        300
Conditions:
    Type                 OK    Age    Reason
    ConfigurationsReady  true  6m10s
    Ready                true  5m56s
    RoutesReady          true  5m56s
Events:
    Type    Reason   Age    Source              Messages
    Normal  Created  6m28s  service-controller  Created Configuration "myapp"
    Normal  Created  6m28s  service-controller  Created Route "myapp"
Instances:
    Name                                       Revision       Running  Status   Restarts  Age
    myapp-ds8fn-1-deployment-79bdd76749-khtmw  myapp-ds8fn-1  2/2      Running  0         32s

    앱이 0으로 스케일링되는 데 몇 분 정도 걸릴 수 있으므로 잠시 기다리십시오.

  4. application get 명령을 다시 실행하여 Running instances의 값이 0으로 스케일링되었는지 확인하십시오. 애플리케이션이 구성된 대상 동시성보다 적은 요청을 처리하는 경우 애플리케이션은 실행 중인 인스턴스 수를 구성된 최소 인스턴스 수로 스케일링 다운합니다. 이 시나리오에서 실행 중인 인스턴스의 수는 자동으로 0으로 스케일링됩니다. --min-scale 옵션이 0 (기본값) 로 설정되면 실행 중인 인스턴스의 수가 자동으로 0으로 스케일링됩니다.

    앱이 0으로 스케일링되는 데 몇 분 정도 걸릴 수 있으므로 잠시 기다리십시오.

    ibmcloud ce application get -n myapp

    출력 예

    OK
Name:          myapp
[...]
URL:           https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud
Cluster Local URL:  http://myapp.4svg40kna19.svc.cluster.local
Console URL:   https://cloud.ibm.com/codeengine/project/us-south/01234567-abcd-abcd-abcd-abcdabcd1111/application/myapp/configuration
Image:                icr.io/codeengine/helloworld
Resource Allocation:
    CPU:                1
    Ephemeral Storage:  400M
    Memory:             4G
Revisions:
myapp-ds8fn-1:
    Age:                12m
    Traffic:            100%
    Image:              icr.io/codeengine/helloworld (pinned to 548d5c)
    Running Instances:  0
Runtime:
    Concurrency:         100
    Maximum Scale:       10
    Minimum Scale:       0
    Timeout:             300
Conditions:
    Type                 OK    Age    Reason
    ConfigurationsReady  true  3m7s
    Ready                true  2m54s
    RoutesReady          true  2m54s
Events:
    Type    Reason   Age    Source              Messages
    Normal  Created  3m21s  service-controller  Created Configuration "myapp"
    Normal  Created  3m20s  service-controller  Created Route "myapp"

  5. 애플리케이션을 다시 호출하여 0에서 스케일링하십시오.

    curl https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud

  6. application get 명령을 다시 실행하여 Running instances의 값이 0에서 스케일링되었는지 확인하십시오. 예를 들면 다음과 같습니다.

    ibmcloud ce application get -n myapp

    출력 예

    OK
Name:          myapp
[...]
URL:           https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud
Cluster Local URL:  http://myapp.4svg40kna19.svc.cluster.local
Console URL:   https://cloud.ibm.com/codeengine/project/us-south/01234567-abcd-abcd-abcd-abcdabcd1111/application/myapp/configuration
Status Summary:     Application deployed successfully
Environment Variables:
    Type     Name             Value
    Literal  CE_API_BASE_URL  https://api.private.us-south.codeengine.cloud.ibm.com
    Literal  CE_APP           myapp
    Literal  CE_DOMAIN        us-south.codeengine.appdomain.cloud
    Literal  CE_PROJECT_ID    abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
    Literal  CE_REGION        us-south
    Literal  CE_SUBDOMAIN     abcdabcdab
Image:                  icr.io/codeengine/helloworld
Resource Allocation:
CPU:                1
Ephemeral Storage:  400M
Memory:             4G
Revisions:
myapp-00001:
    Age:                42s
    Latest:             true
    Traffic:            100%
    Image:              icr.io/codeengine/helloworld (pinned to 1cee99)
    Running Instances:  1
Runtime:
Concurrency:       100
Maximum Scale:     10
Minimum Scale:     0
Scale Down Delay:  0
Timeout:           300
Conditions:
Type                 OK    Age  Reason
ConfigurationsReady  true  25s
Ready                true  12s
RoutesReady          true  12s
Events:
Type    Reason   Age  Source              Messages
Normal  Created  44s  service-controller  Created Configuration "myapp"
Normal  Created  43s  service-controller  Created Route "myapp"
Instances:
Name                                    Revision     Running  Status   Restarts  Age
myapp-00001-deployment-d59b87654-xkqh7  myapp-00001  3/3      Running  0         43s

앱의 최소 및 최대 인스턴스 수 설정

앱 인스턴스 수의 최소값 및 최대값을 업데이트하여 앱의 실행 중인 인스턴스 수를 변경할 수 있습니다.

애플리케이션의 최소 인스턴스 수에 대한 기본값은 0 입니다. 앱이 트래픽을 수신하지 않으면 0 로 스케일링되고 앱의 인스턴스가 실행되지 않습니다. 이 상황에서는 애플리케이션이 다시 트래픽을 수신할 때 응답 속도가 느려질 수 있으며, 스케일링 업이 가능합니다. 애플리케이션을 업데이트하고 콘솔이나 CLI에서 최소 스케일을 1 로 설정하면 이 동작을 변경할 수 있습니다.

앱의 최대 인스턴스 수에 대한 기본값은 10 입니다. 자세한 정보는 경계 스케일링 을 참조하십시오.

콘솔에서 자동 스케일링 범위 변경

Code Engine 가 콘솔에서 앱에 대해 실행 중인 인스턴스 수를 자동 스케일링하는 범위를 변경하려면 다음 단계를 수행하십시오.

  1. 앱으로 이동하십시오.
  2. ‘구성 ’ 탭을 선택하십시오.
  3. '리소스 및 확장 ' 탭을 선택합니다.
  4. 앱의 최소 및 최대 인스턴스 수를 설정하십시오.
  5. (선택사항) 앱을 자동 스케일링하기 위한 요청 동시성 및 타이밍 설정을 검토하고 설정하십시오.
  6. '배포'를 클릭하여 변경 사항을 저장하고 앱 개정판을 배포하세요.

애플리케이션을 업데이트하면 앱이 새 개정을 작성하고 해당 인스턴스에 트래픽을 라우팅합니다.

CLI를 사용하여 자동 스케일링 범위 변경

Code Engine 가 CLI를 사용하여 앱에 대해 실행 중인 인스턴스 수를 자동 스케일링하는 범위를 변경하려면 --min-scale 및 --max-scale 옵션을 사용하여 application update 명령을 앱에 대해 원하는 인스턴스 수로 설정하여 실행하십시오. 선택적으로 앱에 대한 요청 동시성 및 타이밍 설정을 설정할 수 있습니다. 이러한 옵션에는 --concurrency, --concurrency-target, --request-timeout 및 --scale-down-delay 가 포함됩니다. 이러한 자동 스케일링 값 설정에 대한 자세한 정보는 스케일링 경계 및 동시성 및 타이밍에 대한 자동 스케일링 설정 을 참조하십시오.

애플리케이션을 업데이트하면 앱이 새 개정을 작성하고 해당 인스턴스에 트래픽을 라우팅합니다.