Možnosti hostování Azure Functions
Při vytváření aplikace funkcí v Azure musíte zvolit plán hostování vaší aplikace. Azure Functions nabízí tři základní plány hostování Azure Functions: plán Consumption, plán Premium a plán Dedicated (App Service). Tyto plány hostování usnadňují infrastrukturu služby Aplikace Azure a obecně dostupné (GA) na virtuálních počítačích s Linuxem i Windows.
Plán hostování Azure Functions, který zvolíte, určuje následující chování:
- Jak se aplikace funkcí škáluje.
- Prostředky dostupné pro každou instanci aplikace funkcí.
- Podpora pokročilých funkcí, jako je připojení k virtuální síti Azure.
Kromě hostování Azure Functions můžete také hostovat kontejnerizované aplikace funkcí v kontejnerech, které je možné nasadit také do clusterů Kubernetes a do Azure Container Apps. Pokud se rozhodnete hostovat funkce v clusteru Kubernetes, zvažte použití clusteru Kubernetes s podporou Azure Arc. Další informace o nasazení vlastních kontejnerových aplikací najdete v tématu Azure Container Apps hostování služby Azure Functions.
Tento článek obsahuje podrobné porovnání různých plánů hostování, včetně možností hostování založených na kontejnerech.
Poznámka:
Hostování kontejnerů Azure Functions v clusterech Kubernetes s podporou Azure Arc i v Azure Container Apps je aktuálně ve verzi Preview.
Přehled plánů
Následuje souhrn výhod tří hlavních plánů hostování Azure Functions:
| Plánování | Zaměstnanecké výhody |
|---|---|
| Plán Consumption | Škálujte automaticky a plaťte za výpočetní prostředky, jenom když jsou spuštěné vaše funkce. V plánu Consumption se instance hostitele služby Azure Functions přidávají a odebírají automaticky na základě počtu příchozích událostí. ✔ Výchozí plán hostování ✔ Platíte jenom v případech, kdy jsou funkce spuštěné. ✔ Škáluje se automaticky i během období vysokého zatížení. |
| Plán Premium | Automaticky škáluje na základě poptávky pomocí předem připravených pracovních procesů, které spouští aplikace bez zpoždění po nečinnosti, běží na výkonnějších instancích a připojuje se k virtuálním sítím. V následujících situacích zvažte plán Azure Functions Premium: ✔ Aplikace funkcí běží nepřetržitě nebo téměř nepřetržitě. ✔ V plánu Consumption máte velký počet malých spuštění a fakturu za vysoké provedení, ale nízké GB sekund. ✔ Potřebujete více možností procesoru nebo paměti, než poskytuje plán Consumption. ✔ Váš kód musí běžet déle, než je maximální doba provádění povolená v plánu Consumption. ✔ Potřebujete funkce, které nejsou v plánu Consumption dostupné, například připojení k virtuální síti. ✔ Chcete zadat vlastní image Linuxu, na které chcete spouštět funkce. |
| Vyhrazený plán | Spouštějte funkce v rámci plánu služby App Service s pravidelnými sazbami plánu služby App Service. Nejvhodnější pro dlouhotrvající scénáře, kdy durable Functions nejde použít. V následujících situacích zvažte plán služby App Service: ✔ Máte existující nedostatečně využité virtuální počítače, na kterých už běží jiné instance služby App Service. ✔ Vyžaduje se prediktivní škálování a náklady. |
Srovnávací tabulky v tomto článku obsahují také následující možnosti hostování, které poskytují nejvyšší míru kontroly a izolace, ve které se mají spouštět aplikace funkcí.
| Možnost hostování | Detaily |
|---|---|
| ASE | App Service Environment (ASE) je funkce služby App Service, která poskytuje plně izolované a vyhrazené prostředí pro bezpečné spouštění aplikací App Service ve velkém měřítku. Služba ASE je vhodná pro úlohy aplikací, které vyžadují: ✔ Velmi vysoké měřítko. ✔ Úplná izolace výpočetních prostředků a zabezpečený přístup k síti ✔ Vysoké využití paměti. |
| Azure Container Apps | Azure Container Apps je plně spravované prostředí, které umožňuje spouštět mikroslužby a kontejnerizované aplikace na bezserverové platformě. Služba Azure Container Apps umožňuje spouštět funkce s výkonem základní služby Azure Kubernetes Service (AKS) a zároveň odstraňuje složitost práce s rozhraními API Kubernetes. |
| Kubernetes (Přímé nebo přímé Azure Arc) |
Kubernetes poskytuje plně izolované a vyhrazené prostředí spuštěné nad platformou Kubernetes. Kubernetes je vhodný pro úlohy aplikací, které vyžadují: ✔ Požadavky na vlastní hardware. ✔ Izolace a zabezpečení síťového přístupu. ✔ Schopnost spouštět v hybridním nebo multicloudových prostředích ✔ Spusťte společně se stávajícími aplikacemi a službami Kubernetes. |
Zbývající tabulky v tomto článku porovnávají plány různých funkcí a chování. Porovnání nákladů mezi plány dynamického hostování (Consumption a Premium) najdete na stránce s cenami služby Azure Functions. Ceny různých možností vyhrazeného plánu najdete na stránce s cenami služby App Service.
Operační systém/modul runtime
Následující tabulka uvádí podporu operačního systému a jazyka pro plány hostování.
| Linux1,2 pouze kód |
Pouze kód windows | Linux1,2,3 Kontejner Dockeru |
|
|---|---|---|---|
| Plán Consumption | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
Žádná podpora |
| Plán Premium | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Vyhrazený plán | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| ASE | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Kubernetes (přímé) | Není k dispozici | Není k dispozici | C# JavaScript Java PowerShell Core Python TypeScript |
| Azure Arc (Preview) | C# JavaScript Java Python TypeScript |
Není k dispozici | C# JavaScript Java PowerShell Core Python TypeScript |
1 Linux je jediný podporovaný operační systém pro zásobník modulu runtime Pythonu.
Podpora PowerShellu v Linuxu je aktuálně ve verzi Preview.
3 Linux je jediný podporovaný operační systém pro kontejnery Dockeru.
Doba trvání časového limitu aplikace funkcí
Doba trvání časového limitu pro funkce v aplikaci funkcí je definována functionTimeout vlastností v souboru projektu host.json . Tato vlastnost se vztahuje konkrétně na provádění funkcí. Po spuštění triggeru funkce musí funkce v době časového limitu vrátit nebo odpovědět. Další informace najdete v tématu Zlepšení výkonu a spolehlivosti azure Functions.
Následující tabulka uvádí výchozí a maximální hodnoty (v minutách) pro konkrétní plány:
| Plánování | Výchozí | Maximálně1 |
|---|---|---|
| Plán Consumption | 5 | 10 |
| Plán Premium | 302 | Neomezené3 |
| Vyhrazený plán | 302 | Neomezené3 |
1 Bez ohledu na nastavení časového limitu aplikace funkcí je maximální doba, po kterou může funkce aktivovaná protokolem HTTP reagovat na požadavek. Důvodem je výchozí časový limit nečinnosti služby Azure Load Balancer. V případě delší doby zpracování zvažte použití asynchronního vzoru Durable Functions nebo odložit skutečnou práci a vrátit okamžitou odpověď.
2 Výchozí časový limit pro modul runtime služby Functions verze 1.x je neomezený.
3 Zaručeno až 60 minut. Opravy operačního systému a běhové opravy, opravy ohrožení zabezpečení a škálování v chování můžou stále rušit provádění funkcí, aby se zajistilo zápis robustních funkcí.
Měřítko
Následující tabulka porovnává chování škálování různých plánů hostování.
Maximální počet instancí se podává v aplikaci pro jednotlivé funkce (Consumption) nebo podle plánu (Premium/Dedicated), pokud není uvedeno jinak.
| Plánování | Horizontální navýšení kapacity | Maximální počet instancí # |
|---|---|---|
| Plán Consumption | Řízené událostmi. Horizontální navýšení kapacity automaticky i během období vysokého zatížení Infrastruktura Azure Functions škáluje prostředky procesoru a paměti přidáním dalších instancí hostitele Functions na základě počtu příchozích událostí triggeru. | Windows: 200 Linux: 1001 |
| Plán Premium | Řízené událostmi. Horizontální navýšení kapacity automaticky i během období vysokého zatížení Infrastruktura Azure Functions škáluje prostředky procesoru a paměti přidáním dalších instancí hostitele Functions na základě počtu událostí, na které se aktivují jeho funkce. | Windows: 100 Linux: 20-1002 |
| Vyhrazený plán3 | Ruční nebo automatické škálování | 10-30 |
| ASE3 | Ruční nebo automatické škálování | 100 |
| Kubernetes | Automatické škálování řízené událostmi pro clustery Kubernetes pomocí KEDA | Liší se podle clusteru |
1 Během horizontálního navýšení kapacity je v současné době limit 500 instancí na předplatné za hodinu pro aplikace pro Linux v plánu Consumption.
2 V některých oblastech můžou aplikace pro Linux v plánu Premium škálovat na 100 instancí. Další informace najdete v článku o plánu Premium.
3 Konkrétní omezení pro různé možnosti plánu služby App Service najdete v omezeních plánu služby App Service.
Chování studeného startu
| Plánování | Detaily |
|---|---|
| Plán Consumption | Aplikace se můžou při nečinnosti škálovat na nulu, což znamená, že některé požadavky můžou mít při spuštění další latenci. Plán Consumption má některé optimalizace, které pomáhají zkrátit dobu studeného spuštění, včetně načítání z předem připravených zástupných funkcí, které už mají spuštěné hostitelské funkce a procesy jazyka. |
| Plán Premium | Časově teplé instance, aby nedocházelo k žádnému studenému startu. |
| Vyhrazený plán | Když běží v plánu Dedicated, hostitel Functions může běžet nepřetržitě, což znamená, že studený start ve skutečnosti není problém. |
| ASE | Když běží v plánu Dedicated, hostitel Functions může běžet nepřetržitě, což znamená, že studený start ve skutečnosti není problém. |
| Kubernetes | V závislosti na konfiguraci KEDA je možné nakonfigurovat aplikace tak, aby se zabránilo studenému startu. Pokud je nakonfigurované škálování na nulu, pro nové události dojde ke studenému startu. |
Omezení služby
| Resource | Plán Consumption | Plán Premium | Vyhrazený plán | ASE | Kubernetes |
|---|---|---|---|---|---|
| Výchozí doba trvání časového limitu (min) | 5 | 30 | 301 | 30 | 30 |
| Maximální doba trvání časového limitu (min) | 10 | nevázaná7 | nevázané2 | Neomezeně | Neomezeně |
| Maximální počet odchozích připojení (na instanci) | 600 aktivních (celkem 1200) | Neomezeně | Neomezeně | Neomezeně | Neomezeně |
| Maximální velikost požadavku (MB)3 | 100 | 100 | 100 | 100 | Závisí na clusteru. |
| Maximální délkařetězce dotazu 3 | 4096 | 4096 | 4096 | 4096 | Závisí na clusteru. |
| Maximální délka adresyURL požadavku 3 | 8192 | 8192 | 8192 | 8192 | Závisí na clusteru. |
| ACU na instanci | 100 | 210-840 | 100-840 | 210-2508 | Ceny AKS |
| Maximální paměť (GB na instanci) | 1.5 | 3.5-14 | 1.75-14 | 3.5 - 14 | Podporuje se libovolný uzel. |
| Maximální počet instancí (Windows/Linux) | 200/100 | 100/20 | liší se podle skladové položky9 | 1009 | Závisí na clusteru. |
| Aplikace funkcí na plán11 | 100 | 100 | nevázané4 | Neomezeně | Neomezeně |
| Plány služby App Service | 100 na oblast | 100 na skupinu prostředků | 100 na skupinu prostředků | - | - |
| Sloty nasazení na aplikaci10 | 2 | 3 | 1–209 | 20 | Není k dispozici |
| Úložiště5 | 5 GB | 250 GB | 50–1000 GB | 1 TB | Není k dispozici |
| Vlastní domény na aplikaci | 5006 | 500 | 500 | 500 | Není k dispozici |
| Podpora SSL vlastní domény | Zahrnuté nevázané připojení SSL SNI | Zahrnutá nevázaná připojení SSL a 1 IP SSL | Zahrnutá nevázaná připojení SSL a 1 IP SSL | Zahrnutá nevázaná připojení SSL a 1 IP SSL | Není k dispozici |
1 Ve výchozím nastavení je časový limit modulu runtime Functions 1.x v plánu služby App Service nevázaný.
2 Vyžaduje, aby plán služby App Service byl nastavený na AlwaysOn. Platíte podle standardních sazeb.
3 Tato omezení jsou nastavena v hostiteli.
4 Skutečný počet aplikací funkcí, které můžete hostovat, závisí na aktivitě aplikací, velikosti instancí počítačů a odpovídajícím využití prostředků.
5 Limit úložiště je celková velikost obsahu v dočasném úložišti napříč všemi aplikacemi ve stejném plánu služby App Service. Plán Consumption používá službu Azure Files k dočasnému úložišti.
6 Pokud je vaše aplikace funkcí hostovaná v plánu Consumption, podporuje se pouze možnost CNAME. U aplikací funkcí v plánu Premium nebo plánu služby App Service můžete namapovat vlastní doménu pomocí CNAME nebo záznamu A.
7 Zaručeno až 60 minut.
8 Pracovních procesů jsou role, které hostují zákaznické aplikace. Pracovní procesy jsou k dispozici ve třech pevných velikostech: jeden vCPU/3,5 GB RAM; Dvě vCPU/7 GB RAM; Čtyři vCPU/14 GB RAM.
9 Podrobnosti najdete v omezeních služby App Service.
10 Včetně produkčního slotu.
11 V daném předplatném je aktuálně limit 5 000 aplikací funkcí.
Omezení pro vytváření nových aplikací funkcí v existující skupině prostředků
V některých případech se při pokusu o vytvoření nového plánu hostování aplikace funkcí ve stávající skupině prostředků může zobrazit jedna z následujících chyb:
- Cenová úroveň není v této skupině prostředků povolená.
- <> SKU_name pracovní procesy nejsou k dispozici ve skupině <prostředků resource_group_name>
K tomu může dojít, když jsou splněny následující podmínky:
- Aplikaci funkcí vytvoříte ve stávající skupině prostředků, která někdy obsahovala jinou aplikaci funkcí nebo webovou aplikaci. Například aplikace Consumption pro Linux nejsou podporované ve stejné skupině prostředků jako plány Linux Dedicated nebo Linux Premium.
- Nová aplikace funkcí se vytvoří ve stejné oblasti jako předchozí aplikace.
- Předchozí aplikace je nějakým způsobem nekompatibilní s novou aplikací. K tomu může dojít mezi skladovými jednotkami, operačními systémy nebo jinými funkcemi na úrovni platformy, jako je podpora zón dostupnosti.
Důvodem je to, jak se aplikace funkcí a plány webových aplikací mapují na různé fondy prostředků při vytváření. Různé skladové položky vyžadují jinou sadu funkcí infrastruktury. Když vytvoříte aplikaci ve skupině prostředků, tato skupina prostředků se namapuje a přiřadí ke konkrétnímu fondu prostředků. Pokud se pokusíte vytvořit jiný plán v této skupině prostředků a mapovaný fond nemá požadované prostředky, dojde k této chybě.
Pokud k této chybě dojde, místo toho vytvořte aplikaci funkcí a plán hostování v nové skupině prostředků.
Síťové funkce
| Funkce | Plán Consumption | Plán Premium | Vyhrazený plán | ASE |
|---|---|---|---|---|
| Omezení příchozích IP adres | ✅Ano | ✅Ano | ✅Ano | ✅Ano |
| Příchozí privátní koncové body | ❌Ne | ✅Ano | ✅Ano | ✅Ano |
| Integrace virtuální sítě | ❌Ne | ✅Ano (oblast) | ✅Ano (regionální a brána) | ✅Ano |
| Triggery virtuální sítě (jiné než HTTP) | ❌Ne | ✅Ano | ✅Ano | ✅Ano |
| Hybridní připojení (jenom Windows) | ❌Ne | ✅Ano | ✅Ano | ✅Ano |
| Omezení odchozích IP adres | ❌Ne | ✅Ano | ✅Ano | ✅Ano |
Fakturace
| Plánování | Detaily |
|---|---|
| Plán Consumption | Platíte jenom za čas, kdy vaše funkce běží. Fakturace vychází z počtu spuštění, doby spuštění a použité paměti. |
| Plán Premium | Plán Premium je založený na počtu jader sekund a paměti využité napříč potřebnými a předem zahřátými instancemi. Nejméně jedna instance na plán musí být vždy v teple. Tento plán poskytuje nej předvídatelnější ceny. |
| Vyhrazený plán | Platíte totéž za aplikace funkcí v plánu služby App Service jako u jiných prostředků služby App Service, jako jsou webové aplikace. |
| App Service Environment (ASE) | Služba ASE platí za infrastrukturu plochou měsíční sazbu a nemění se s velikostí služby ASE. Existují také náklady na virtuální procesor plánu služby App Service. Všechny aplikace hostované ve službě ASE jsou ve skladové položce s izolovanou cenou. |
| Kubernetes | Platíte pouze náklady na cluster Kubernetes; žádné další účtování funkcí. Aplikace funkcí běží v clusteru jako úloha aplikace, stejně jako běžná aplikace. |