Azure Functions Elastic 프리미엄 플랜은 함수 앱을 위한 동적 크기 조정 호스팅 옵션입니다. 다른 호스팅 계획 옵션은 Azure Functions 호스팅 옵션을 참조하세요.
중요
Azure Functions는 Azure App Service 플랫폼에서 실행할 수 있습니다. App Service 플랫폼에서 프리미엄 플랜 함수 앱을 호스팅하는 플랜은 탄력적 프리미엄 플랜이라고 하며 SKU 이름은 EP1과 같습니다. 프리미엄 플랜에서 함수 앱을 실행하기로 선택한 경우 EP1과 같이 "E"로 시작하는 SKU 이름으로 플랜을 만들어야 합니다.
P1V2(프리미엄 V2 소형 플랜)과 같이 "P"로 시작하는 App Service 플랜 SKU 이름은 실제로 전용 호스팅 계획입니다. 탄력적 프리미엄이 아닌 전용이기 때문에 SKU 이름이 "P"로 시작하는 플랜은 동적으로 크기 조정되지 않으며 비용이 증가할 수 있습니다.
프리미엄 플랜 호스팅은 사용자 함수에 다음과 같은 이점을 제공합니다.
- 콜드 부팅을 방지하는 항시 준비 및 미리 준비 인스턴스
- 가상 네트워크 연결
- 더 긴 런타임 기간 지원
- 프리미엄 인스턴스 크기 선택
- 소비 계획에 비해 더 예측 가능한 가격 책정
- 여러 함수 앱을 사용하는 계획에 대한 고밀도 앱 할당
- Linux 컨테이너 배포 지원
프리미엄 계획을 사용하면 Flex Consumption 계획 및 소비 계획과 마찬가지로 들어오는 이벤트 수에 따라 Azure Functions 호스트의 인스턴스가 추가되고 제거됩니다. 여러 함수 앱을 동일한 프리미엄 플랜에 배포할 수 있으며, 이 플랜을 통해 계산 인스턴스 크기, 기본 플랜 크기 및 최대 플랜 크기를 구성할 수 있습니다.
결제
프리미엄 플랜에 대한 청구는 코어 초 수와 여러 인스턴스에 할당된 메모리를 기준으로 합니다. 이 청구는 초당 리소스 사용량 및 실행에 따라 청구되는 소비 계획과 다릅니다. 프리미엄 플랜으로 실행 요금이 부과되지 않습니다. 이 청구는 함수가 활성 상태이든 유휴 상태이든 관계없이 활성 플랜당 최소 월별 비용이 발생합니다. 프리미엄 플랜의 모든 함수 앱은 할당된 인스턴스를 공유합니다. 자세한 내용은 Azure Functions 가격 책정을 참조하세요.
참고
모든 프리미엄 플랜에는 항상 하나 이상의 활성(청구) 인스턴스가 있습니다.
프리미엄 플랜 만들기
Azure Portal에서 함수 앱을 만들 때는 사용 플랜이 기본값입니다. 프리미엄 플랜에서 실행되는 함수 앱을 만들려면 탄력적 프리미엄 SKU 중 하나를 사용하여 Azure Functions 프리미엄 호스팅 계획을 명시적으로 만들거나 선택해야 합니다. 만든 함수 앱은 이 플랜에서 호스트됩니다. Azure Portal을 사용하면 프리미엄 플랜과 함수 앱을 동시에 간편하게 만들 수 있습니다. 동일한 프리미엄 플랜에서 둘 이상의 함수 앱을 실행할 수 있지만 둘 다 동일한 운영 체제(Windows 또는 Linux)에서 실행되어야 합니다.
다음 문서에서는 프리미엄 플랜을 사용하여 프로그래밍 방식으로 함수 앱을 만드는 방법을 보여 줍니다.
콜드 부팅 제거
소비 플랜에서 이벤트 또는 실행이 발생하지 않으면 앱이 0개의 인스턴스로 확장될 수 있습니다. 새 이벤트가 발생하면 실행되는 앱의 새 인스턴스를 특수화해야 합니다. 앱에 따라 새 인스턴스를 특수화하는 데 시간이 걸릴 수 있습니다. 첫 번째 호출에서 이 추가 대기 시간을 콜드 스타트라고 하는 경우가 많습니다.
프리미엄 플랜은 함수에서 콜드 시작을 효과적으로 제거하기 위해 함께 작동하는 두 가지 기능인 항상 준비된 인스턴스 와 미리 준비된 인스턴스를 제공합니다. 항상 준비된 인스턴스는 크기 조정의 영향을 받지 않는 미리 할당된 인스턴스의 범주이며, 미리 준비된 인스턴스는 HTTP 이벤트로 인해 스케일링될 때의 버퍼입니다.
이벤트가 애플리케이션 트리거를 시작하면 먼저 상시 준비 인스턴스로 라우팅됩니다. HTTP 이벤트로 인해 함수가 활성화되면 다른 인스턴스가 버퍼로서 준비됩니다. 이러한 버퍼링된 인스턴스를 미리 준비된 인스턴스라고 합니다. 이 버퍼는 크기 조정 중에 필요한 새 인스턴스의 콜드 부팅을 줄입니다.
항상 준비된 인스턴스
프리미엄 플랜에서는 지정된 수의 인스턴스에서 앱이 상시 준비되도록 할 수 있습니다. 앱은 부하에 관계없이 해당 인스턴스에서 지속적으로 실행됩니다. 부하가 항상 준비된 인스턴스가 처리할 수 있는 한계를 초과하면 더 많은 인스턴스가 필요에 따라 지정된 최댓값까지 추가됩니다.
이 앱 수준 설정은 플랜의 최소 인스턴스도 제어합니다. 예를 들어 동일한 프리미엄 플랜에 세 개의 함수 앱을 사용하는 것이 좋습니다. 두 개의 앱이 항상 준비된 인스턴스 수를 1로 설정하고 세 번째 앱이 5로 설정된 경우 전체 계획의 최소 수는 5개입니다. 또한 플랜의 요금이 청구되는 최소 인스턴스 수도 반영합니다. 앱당 지원되는 항상 준비된 인스턴스의 최대 수는 20개입니다.
Azure Portal에서 함수 앱을 선택하고 , 플랫폼 기능 탭으로 이동하고, 스케일 아웃 옵션을 선택하여 항상 준비된 인스턴스 수를 구성할 수 있습니다. 함수 앱 편집 창에서 상시 준비 인스턴스는 해당 앱에만 적용됩니다.
미리 준비된 인스턴스
사전 예열된 인스턴스 수 설정은 HTTP 확장 및 활성화 이벤트 중에 예열된 인스턴스를 버퍼로 제공합니다. 미리 준비된 인스턴스는 최대 스케일 아웃 한도에 도달할 때까지 계속 버퍼링됩니다. 기본 미리 준비된 인스턴스 수는 1이며, 대부분의 시나리오에서 이 값은 1로 유지되어야 합니다.
사용자 지정 컨테이너에서 실행되는 앱과 같이 덜 일반적인 시나리오를 고려합니다. 사용자 지정 컨테이너의 준비 시간이 길기 때문에 미리 설치된 인스턴스의 버퍼를 늘리는 것이 좋습니다. 미리 준비된 인스턴스는 모든 활성 인스턴스가 사용 중인 이후에만 활성화됩니다.
또한 사전 준비 프로세스 중에 실행되는 준비 트리거를 정의할 수도 있습니다. 준비 트리거를 사용하여 미리 준비 프로세스 중에 사용자 지정 종속성을 미리 로드하여 함수가 요청 처리를 즉시 시작할 준비가 되도록 할 수 있습니다. 자세한 내용은 Azure Functions 웜업 트리거를 참조하세요.
항상 준비된 인스턴스와 미리 준비된 인스턴스가 함께 작동하는 방법을 보여 주는 이 예제를 고려해 보세요. 프리미엄 함수 앱에는 2개의 항상 준비된 인스턴스가 구성되어 있으며 기본적으로 1개의 미리 준비된 인스턴스가 있습니다.
- 앱이 유휴 상태이고 트리거되는 이벤트가 없으면 앱이 프로비전되고 2개의 인스턴스로 실행됩니다. 현재는 항상 준비된 두 인스턴스에 대한 요금이 청구되지만 미리 준비된 인스턴스가 할당되지 않았기 때문에 미리 준비된 인스턴스에 대해서는 요금이 청구되지 않습니다.
- 애플리케이션이 HTTP 트래픽 수신을 시작하면 요청이 항상 준비된 두 인스턴스에서 부하가 분산됩니다. 2개의 인스턴스가 이벤트 처리를 시작하는 즉시 미리 준비된 버퍼를 채우기 위해 인스턴스가 추가됩니다. 이제 앱은 프로비전된 인스턴스 3개, 항상 준비된 인스턴스 5개, 미리 준비된 비활성 버퍼 3개로 실행됩니다. 3개의 인스턴스에 대한 요금이 청구됩니다.
- 부하가 증가하고 앱에 HTTP 트래픽을 처리하기 위해 더 많은 인스턴스가 필요하면 사전 준비 인스턴스가 활성 인스턴스로 교환됩니다. 이제 HTTP 로드가 3개의 모든 인스턴스로 라우팅되고 네 번째 인스턴스가 미리 준비된 버퍼를 채우기 위해 즉시 프로비전됩니다.
- 이 스케일링 및 미리 준비 시퀀스는 앱의 최대 인스턴스 수에 도달하거나 부하가 감소하여 플랫폼이 기간 후에 다시 스케일 인될 때까지 계속됩니다. 인스턴스는 미리 준비되거나 최댓값 이상으로 활성화되지 않습니다.
포털에서 미리 설치된 인스턴스 수 설정을 변경할 수 없습니다. 대신 Azure CLI 또는 Azure PowerShell을 사용해야 합니다.
최대 함수 앱 인스턴스
플랜 최대 버스트 수 외에 앱별 최댓값을 구성할 수 있습니다. 앱 최댓값은 앱 확장 제한을 사용하여 구성할 수 있습니다. 최대 앱 스케일 아웃 제한은 계획의 최대 버스트 인스턴스를 초과할 수 없습니다.
프라이빗 네트워크 연결
프리미엄 플랜에 배포된 함수 앱은 웹앱용 가상 네트워크 통합을 활용할 수 있습니다. 구성된 앱은 가상 네트워크 내의 리소스와 통신하거나 서비스 엔드포인트를 통해 보호할 수 있습니다. 들어오는 트래픽을 제한하기 위해 앱에서 IP 제한을 사용할 수도 있습니다.
프리미엄 플랜에서 함수 앱에 서브넷을 할당할 때 각 잠재적 인스턴스에 대해 충분한 IP 주소가 있는 서브넷이 필요합니다. 사용 가능한 주소가 100개 이상인 IP 블록이 필요합니다.
자세한 내용은 가상 네트워크와 Azure Functions 통합을 참조하세요.
신속한 탄력적 확장
소비 플랜과 동일한 빠른 확장 논리를 사용하여 앱에 대한 추가 컴퓨팅 인스턴스가 자동으로 추가됩니다. 동일한 App Service 플랜의 앱은 개별 앱의 요구 사항에 따라 서로 독립적으로 확장됩니다. 그러나 가능한 경우 동일한 App Service 플랜의 함수 앱은 VM 리소스를 공유하여 비용을 절감합니다. VM과 연결된 앱의 수는 각 앱의 메모리 공간과 VM의 크기에 따라 다릅니다.
확장 작동 방식에 대한 자세한 내용은 Azure Functions의 이벤트 기반 확장을 참조하세요.
더 긴 실행 지속 시간
기능은 소비 플랜에서 한 번의 실행당 10분으로 제한됩니다. 프리미엄 플랜에서 런어웨이 실행을 방지하기 위해 실행 지속 시간은 기본적으로 30분입니다. 그러나 host.json 구성을 수정하여 다음 제한 사항으로 프리미엄 플랜 앱의 지속 시간을 무제한으로 설정할 수 있습니다.
- 플랫폼 업그레이드는 관리형 종료를 트리거하고 10분의 유예 기간으로 함수 실행을 중지할 수 있습니다.
- 새 실행 없이 60분 후에 작업자를 중지하는 유휴 타이머가 있습니다.
- 스케일 인 동작으로 인해 60분 후에 작업자가 종료될 수 있습니다.
- 슬롯 교환은 교환 중에 원본 및 대상 슬롯에 대한 실행을 종료할 수 있습니다.
마이그레이션
기존 함수 앱이 있는 경우 Azure CLI 명령을 사용하여 Windows의 사용량 플랜과 프리미엄 플랜 간에 앱을 마이그레이션할 수 있습니다. 특정 명령은 마이그레이션의 방향에 따라 달라집니다. 자세한 내용은 마이그레이션 계획을 참조하세요.
이 마이그레이션은 Linux에서 지원되지 않습니다.
프리미엄 플랜 설정
플랜을 만들 때, 최소 인스턴스 수(또는 플랜 크기)와 최대 버스트 제한이라는 두 가지 플랜 크기 설정이 있습니다.
앱에 항상 준비된 인스턴스를 초과하는 인스턴스가 필요한 경우 인스턴스 수가 계획 최대 버스트 제한에 도달하거나 구성된 경우 앱 최대 스케일 아웃 제한에 도달할 때까지 계속 확장할 수 있습니다. 인스턴스가 실행 중이고 사용자에게 할당된 경우에만 초 단위로 요금이 청구됩니다. 플랫폼은 애플리케이션을 정의된 최대 한도까지 확장하기 위해 최선을 다합니다.
플랜에 배포된 함수 앱의 설정 아래에서 Scale Out 옵션을 선택하여 Azure Portal에서 해당 플랜 크기 및 최댓값을 구성할 수 있습니다.
모든 프리미엄 플랜의 최솟값은 하나 이상의 인스턴스입니다. 실제 최소 인스턴스 수는 플랜의 앱에서 요청한 항상 준비된 인스턴스를 기준으로 결정됩니다. 예를 들어 동일 플랜에서 앱 A가 5개의 항상 준비된 인스턴스를 요청하고 앱 B가 2개의 항상 준비된 인스턴스를 요청하는 경우 최소 플랜 크기는 5로 결정됩니다. 앱 A는 5개 모두에서 실행되고 앱 B는 2개에서만 실행됩니다.
중요
함수가 실행 중인지 여부에 관계없이 최소 인스턴스 수에 할당된 각 인스턴스에 대해 요금이 청구됩니다.
대부분의 경우 이 자동 계산된 최솟값으로 충분합니다. 그러나 최솟값 이상으로 확장하는 것이 좋습니다. 드물지만, 다른 인스턴스를 사용할 수 없는 경우 특정 시간 스케일 아웃이 지연될 수 있습니다. 최솟값을 자동 계 된 최솟값보다 높게 설정하여 스케일 아웃 전에 인스턴스를 예약합니다.
해당 플랜에 배포된 함수 앱의 설정 아래에서 Scale Out 옵션을 선택하여 Azure Portal에서 최소 인스턴스 수를 구성할 수 있습니다.
사용 가능한 인스턴스 SKU
플랜을 만들거나 스케일링할 때 세 가지 인스턴스 크기 중에서 선택할 수 있습니다. 프로비전된 코어 수와 메모리의 총 개수에 대해 요금이 청구되며, 이는 각 인스턴스가 사용자에게 할당되는 시간(초) 기준입니다. 필요에 따라 앱이 여러 인스턴스로 자동 스케일 아웃될 수 있습니다.
| 재고 관리 번호 (SKU) | 코어 | 메모리 | 스토리지 |
|---|---|---|---|
| 제1화 | 1 | 3.5GB | 250GB |
| 에피소드2 | 2 | 7GB | 250GB |
| 제3화 | 4 | 14GB | 250GB |
메모리 사용량 고려 사항
메모리가 더 많은 컴퓨터에서 실행한다고 해서 함수 앱이 항상 사용 가능한 메모리를 모두 사용하는 것은 아닙니다.
예를 들어 JavaScript 함수 앱은 Node.js의 기본 메모리 제한에 의해 제한됩니다. 이 고정 메모리 제한을 늘리려면 languageWorkers:node:arguments 값으로 앱 설정 --max-old-space-size=<max memory in MB>를 추가합니다.
또한 메모리가 4GB를 초과하는 계획의 경우 Bitness 플랫폼 설정이 64 Bit으로 설정되어 있는지 확인합니다.
지역 최대 스케일 아웃
다음 표에서는 각 지역 및 OS 구성에서 단일 계획에 대해 현재 지원되는 최대 스케일 아웃 값을 나열합니다.
| 지역 | 윈도우즈 | 리눅스 |
|---|---|---|
| 오스트레일리아 중부 | 100 | 20 |
| 오스트레일리아 중부 2 | 100 | 사용할 수 없음 |
| 오스트레일리아 동부 | 100 | 40 |
| 오스트레일리아 남동부 | 100 | 20 |
| 브라질 남부 | 100 | 20 |
| 캐나다 중부 | 100 | 100 |
| 인도 중부 | 100 | 20 |
| 미국 중부 | 100 | 100 |
| 중국 동부 2 | 20 | 20 |
| 중국 북부 2 | 20 | 20 |
| 중국 북부 3 | 20 | 20 |
| 동아시아 | 100 | 20 |
| 미국 동부 | 100 | 100 |
| 미국 동부 2 | 80 | 100 |
| 프랑스 중부 | 100 | 60 (육십) |
| 독일 중서부 | 100 | 20 |
| 이스라엘 중부 | 100 | 20 |
| 이탈리아 북부 | 100 | 20 |
| 일본 동부 | 100 | 20 |
| 일본 서부 | 100 | 20 |
| Jio 인도 서부 | 100 | 20 |
| 한국 중부 | 100 | 20 |
| 한국 남부 | 40 | 20 |
| 멕시코 중부 | 20 | 20 |
| 미국 중북부 | 100 | 20 |
| 북유럽 | 100 | 100 |
| 노르웨이 동부 | 100 | 20 |
| 남아프리카 공화국 북부 | 100 | 20 |
| 남아프리카 공화국 서부 | 20 | 20 |
| 미국 중남부 | 100 | 100 |
| 인도 남부 | 100 | 사용할 수 없음 |
| 동남아시아 | 100 | 20 |
| 스페인 중부 | 20 | 20 |
| 스위스 북부 | 100 | 20 |
| 스위스 서부 | 100 | 20 |
| 아랍에미리트 북부 | 100 | 100 |
| 영국 남부 | 100 | 100 |
| 영국 서부 | 100 | 20 |
| USGov 애리조나 | 20 | 20 |
| USGov 텍사스 | 20 | 사용할 수 없음 |
| USGov 버지니아 | 80 | 20 |
| 미국 중서부 | 100 | 20 |
| 서유럽 | 100 | 100 |
| 인도 서부 | 100 | 20 |
| 미국 서부 | 100 | 100 |
| 미국 서부 2 | 100 | 20 |
| 미국 서부 3 | 100 | 20 |
자세한 내용은 지역별 제품 가용성을 참조하세요.