Knative serving에서 각 버전은 모든 수신 요청을 처리하는 데 필요한 컨테이너 인스턴스 수에 맞게 자동으로 확장됩니다. 버전에 트래픽이 수신되지 않으면 기본적으로 버전이 컨테이너 인스턴스 0개로 축소됩니다. 하지만 원하는 경우 이 기본값을 변경하여 최소 인스턴스 설정을 사용해 이 인스턴스를 유휴 또는 '준비' 상태로 유지하도록 지정할 수 있습니다.
예약된 인스턴스 수는 다음의 영향을 받습니다.
- 요청을 처리하는 데 필요한 CPU 용량
- 동시 실행 설정
- 최대 컨테이너 인스턴스 수 설정
- 최소 컨테이너 인스턴스 수 설정
비용 관리 목적으로 또는 서비스에서 사용하는 다른 리소스와의 호환성을 높이기 위해 시작 가능한 총 컨테이너 인스턴스 수를 제한해야 할 수 있습니다. 예를 들면 Knative serving 서비스가 동시에 열려 있는 연결을 일정한 개수만 처리할 수 있는 데이터베이스와 상호작용하는 경우가 있습니다.
최대 컨테이너 인스턴스 정보
최대 컨테이너 인스턴스 설정을 사용하여 최대 컨테이너 인스턴스 수 설정에 설명된 대로 동시에 시작할 수 있는 총 인스턴스 수를 제한할 수 있습니다.
최대 인스턴스 수 초과
일반적인 상황에서는 수신 트래픽 로드를 처리하기 위해 새 인스턴스를 만들어 버전을 수평 확장합니다. 하지만 최대 인스턴스 한도를 설정하면 경우에 따라 수신 트래픽 로드를 처리하기에 인스턴스가 부족할 수 있습니다. 이 경우 수신 요청은 최대 60초 동안 큐에서 대기합니다. 이 60초 동안 인스턴스가 요청의 처리를 완료하면 큐에 추가된 요청을 처리하는 데 인스턴스를 사용할 수 있게 됩니다. 이 60초 동안 사용 가능하게 되는 인스턴스가 없으면 Cloud Run에서 429
오류 코드와 함께 요청이 실패합니다.
확장 보증
최대 인스턴스 한도는 상한입니다. 한도를 높게 설정한다고 해서 버전이 지정한 컨테이너 인스턴스 수로 수평 확장되는 것은 아니며, 다만 특정 시점의 컨테이너 인스턴스의 수가 한도를 초과하지 않아야 함을 의미합니다.
트래픽 급증
빠르게 트래픽이 증가하는 등 경우에 따라 Knative serving이 지정된 최대 인스턴스 값보다 약간 더 많은 컨테이너 인스턴스를 단시간에 만들 수 있습니다. 서비스가 이 일시적인 동작을 감당할 수 없으면 안전성이 보장되는 여유를 고려하여 최대 인스턴스 값을 더 낮게 설정해야 할 수 있습니다.
배포
새 버전을 배포하면 Knative serving이 이전 버전에서 새 버전으로 트래픽을 점진적으로 마이그레이션합니다. 각 버전에 최대 인스턴스 한도가 설정되기 때문에 배포 후 일정 기간 동안 지정된 한도를 일시적으로 초과할 수도 있습니다.
유휴 인스턴스 및 콜드 스타트 최소화
Kubernetes 리소스는 인스턴스가 요청을 처리할 때만 사용됩니다. 하지만 그렇다고 해서 모든 요청을 처리한 후 Knative serving에서 즉시 인스턴스를 종료하지는 않습니다. 콜드 스타트의 영향을 최소화하기 위해 Knative serving에서 일부 인스턴스를 유휴 상태로 유지할 수 있습니다. 이러한 인스턴스는 갑작스러운 트래픽 급증이 발생할 경우 요청을 처리할 준비가 되어 있습니다.
예를 들어 컨테이너 인스턴스는 요청 처리를 완료한 후에 다른 요청을 처리해야 할 경우에 대비하여 일정 기간 동안 유휴 상태로 유지될 수 있습니다. 유휴 컨테이너 인스턴스는 열린 데이터베이스 연결과 같은 리소스를 유지할 수 있습니다. 하지만 Cloud Run의 경우 CPU를 사용할 수 없습니다.
유휴 인스턴스를 영구적으로 유지하려면 min-instance
설정을 사용하세요.
다음 단계
- Knative serving 서비스의 최대 인스턴스 수를 관리하려면 최대 컨테이너 인스턴스 수 설정을 참조하세요.
- 각 컨테이너 인스턴스에서 처리하는 최대 동시 요청 수를 관리하려면 동시 실행 설정을 참조하세요.
- 동시 실행 설정을 최적화하려면 동시 실행 조정을 위한 개발 팁을 참조하세요.
- 첫 번째 요청에 대한 지연 시간 또는 콜드 스타트를 최소화하기 위해 유휴 인스턴스가 계속 실행되도록 지정하려면
min-instance
를 사용하여 유휴 인스턴스 사용 설정을 참조하세요.