Azure Functions のホスティング オプション
Azure で関数アプリを作成するときは、アプリのホスティング オプションを選択する必要があります。 Azure には、関数コードの次のホスティング オプションが用意されています。
ホスティング オプション | サービス | 可用性 | コンテナー サポート |
---|---|---|---|
Flex 従量課金プラン | Azure Functions | 一般提供 (GA) | なし |
Premium プラン | Azure Functions | GA | Linux |
専用プラン | Azure Functions | GA | Linux |
コンテナー アプリ | Azure Container Apps | GA | Linux |
従量課金プラン | Azure Functions | GA | なし |
Azure Functions のホスティング オプションは、Linux と Windows の両方の仮想マシン上の Azure App Service インフラストラクチャによって支援されています。 選択したホスティング オプションによって、次の動作が決まります。
- Function App をスケールする方法
- 各 Function App インスタンスに利用できるリソース。
- Azure Virtual Network 接続などの高度な機能のサポート。
- Linux コンテナーのサポート。
選択したプランは、関数コードの実行コストにも影響します。 詳細については、「課金」を参照してください。
この記事では、さまざまなホスティング オプションを詳しく比較します。 Linux コンテナーでの関数コードの実行と管理の詳細については、Azure Functions での Linux コンテナーのサポートに関するページを参照してください。
プランの概要
以下に、Azure Functions ホスティングのさまざまなオプションの利点をまとめます。
オプション | メリット |
---|---|
Flex 従量課金プラン | コンピューティングの選択肢、仮想ネットワーク、従量課金制を使用して、迅速な水平スケーリングを実現します。 Flex 従量課金プランでは、Functions ホストのインスタンスは、構成されているインスタンスごとのコンカレンシーと受信イベントの数に基づいて動的に追加および削除されます。 ✔ 事前にプロビジョニングされた (常時使用可能な) インスタンスの数を指定して、コールド スタートを減らす。 ✔ セキュリティを強化するために仮想ネットワークがサポートされる。 ✔ 関数の実行時に課金される。 ✔ 負荷が高い期間中でも、自動的にスケーリングします。 |
Premium プラン | 需要に応じて自動的にスケーリングを行いながら、事前ウォーミングされたワーカーを使用して、アイドル状態になっても遅延なくアプリケーションを実行したり、より強力なインスタンスで実行したり、仮想ネットワークに接続したりすることができます。 次のような状況では、Azure Functions の Premium プランを検討してください。 ✔ 関数を継続的に、またはほぼ継続的に実行したい。 ✔ インスタンスをより詳細に制御する必要があり、イベントドリブン スケーリングと同じプランで複数の関数アプリをデプロイしたい。 ✔ 小規模な実行の回数が多く、実行料金が高いが、従量課金プランでの GB 秒は低い。 ✔ 従量課金プランで提供されるよりも多くの CPU またはメモリのオプションが必要である。 ✔ 従量課金プランで許可されている最大実行時間よりも長くコードを実行する必要がある。 ✔ 仮想ネットワーク接続が必要である。 ✔ 関数を実行するカスタム Linux イメージを提供したい。 |
専用プラン | App Service プラン内で、Functions を通常の App Service プラン料金で実行します。 Durable Functions を使用できない場合、実行時間の長いシナリオに最適です。 次の状況では、App Service プランを検討してください。 ✔ 既に他の App Service インスタンスを実行している、使用率の低い既存の仮想マシンがある。 ✔ 完全に予測可能な請求情報が必要であるか、インスタンスを手動でスケーリングする必要がある。 ✔ 同じプランで複数の Web アプリと関数アプリを実行したい ✔ より大きなコンピューティング サイズの選択肢にアクセスする必要がある。 ✔ App Service Environment (ASE) によって提供される完全なコンピューティング分離とセキュリティで保護されたネットワーク アクセス。 ✔ メモリ使用量が非常に多く、高スケールである (ASE)。 |
コンテナー アプリ | Azure Container Apps によってホストされるフル マネージド環境で、コンテナー化された関数アプリを作成してデプロイします。 Azure Functions プログラミング モデルを使用して、イベントドリブン、サーバーレス、クラウド ネイティブ関数アプリを構築します。 他のマイクロサービス、API、Web サイト、ワークフローと共に、コンテナーでホストされるプログラムとして関数を実行します。 以下の状況では、Container Apps で関数をホストすることを検討してください。 ✔ 基幹業務アプリをサポートするために、カスタム ライブラリを関数コードと共にパッケージ化したい。 ✔ コード実行をオンプレミスまたはレガシ アプリから、コンテナーで実行されるクラウド ネイティブ マイクロサービスに移行する必要がある。 ✔ Kubernetes クラスターと専用コンピューティングの管理のオーバーヘッドと複雑さを回避したいとき。 ✔ 関数に、専用 GPU コンピューティング リソースによって提供されるハイエンドの処理能力が必要である。 |
従量課金プラン | 関数が自動スケールで実行されている (従量課金制) 場合にのみ、コンピューティング リソースに対して課金されます。 従量課金プランでは、Functions ホストのインスタンスは、受信イベントの数に基づいて動的に追加および削除されます。 ✔ 本当の意味で "サーバーレス" ホスティングを提供する既定のホスティング プラン。 ✔ 関数の実行中にのみ課金されます。 ✔ 負荷が高い期間中でも、自動的にスケーリングします。 |
この記事の残りの表では、さまざまな機能と動作に基づいてホスティング オプションを比較します。
オペレーティング システムのサポート
次の表は、ホスティング オプションに対するオペレーティング システムのサポートを示しています。
ホスティング | Linux1 デプロイ | Windows2 デプロイ |
---|---|---|
Flex 従量課金プラン | ✅ コードのみ ❌ コンテナー (サポートされていません) |
❌ サポート対象外 |
Premium プラン | ✅ コードのみ ✅ コンテナー |
✅ コードのみ |
専用プラン | ✅ コードのみ ✅ コンテナー |
✅ コードのみ |
コンテナー アプリ | ✅ コンテナーのみ | ❌ サポート対象外 |
従量課金プラン | ✅ コードのみ ❌ コンテナー (サポートされていません) |
✅ コードのみ |
- Linux は、Python ランタイム スタックでサポートされている唯一のオペレーティング システムです。
- Windows のデプロイはコードのみです。 現在、Functions では Windows コンテナーはサポートされていません。
Function App タイムアウト期間
関数アプリ内の関数のタイムアウト期間は、host.json プロジェクト ファイルの functionTimeout
プロパティによって定義されます。 このプロパティは、関数の実行に特に適用されます。 トリガーが関数の実行を開始した後、関数はタイムアウト期間内に戻るか応答する必要があります。 タイムアウトを回避するには、堅牢な関数を作成することが重要です。 詳細については、「Azure Functions のパフォーマンスと信頼性を向上させる」を参照してください。
次の表は、特定のプランの既定値と最大値 (分) を示しています。
プラン | Default | 最大1 |
---|---|---|
Flex 従量課金プラン | 30 | 無制限2 |
Premium プラン | 304 | 無制限2 |
専用プラン | 304 | 無制限3 |
コンテナー アプリ | 30 | 無制限5 |
従量課金プラン | 5 | 10 |
- 関数アプリのタイムアウト設定に関係なく 230 秒は、HTTP トリガー関数が要求に応答できる最大時間です。 これは、Azure Load Balancer の既定のアイドル タイムアウトによるものです。 より長い処理時間では、Durable Functions async pattern の使用を検討するか、実際の作業を遅らせて、即座に応答を返します。
- 実行タイムアウトの最長期間は適用されません。 ただし、関数の実行に与えられる猶予期間は、Flex 従量課金プランと Premium プランの場合、スケールイン中は 60 分であり、プラットフォームの更新中は 10 分の猶予期間が与えられます。
- App Service プランが Always On に設定されている必要があります。 プラットフォームの更新中は 10 分の猶予期間が与えられます。
- Functions ホスト ランタイムのバージョン 1.x の既定のタイムアウトは "無制限" です。
- 最小レプリカ数が 0 に設定されている場合、既定のタイムアウトはアプリで使われている特定のトリガーによって異なります。
言語のサポート
Functions での現在のネイティブ言語スタックのサポートについて詳しくは、「Azure Functions でサポートされている言語」を参照してください。
スケール
次の表は、さまざまなホスティング プランのスケーリングの様子を比較したものです。
最大インスタンスは、特に説明がない限り、関数アプリごと (従量課金) またはプランごと (Premium/専用) に示されています。
プラン | スケール アウト | 最大インスタンス数 |
---|---|---|
Flex 従量課金プラン | 関数ごとのスケーリング。 イベントドリブン スケーリングの決定は関数ごとに計算され、アプリ内の関数をより明確にスケーリングする方法が提供されます。 HTTP、Blob Storage (Event Grid)、Durable Functions を除き、アプリ内の他のすべての関数トリガーの種類では、独立したインスタンスでスケーリングされます。 アプリ内のすべての HTTP トリガーでは、すべての Blob Storage (Event Grid) トリガーの場合と同様に、同じインスタンス上のグループとしてまとめてスケーリングされます。 すべての Durable Functions トリガーでもインスタンスが共有され、まとめてスケーリングされます。 | 特定のリージョン全体のすべてのインスタンスの合計メモリ使用量によってのみ制限されます。 詳細については、「インスタンス メモリ」を参照してください。 |
Premium プラン | イベント ドリブン。 負荷が高い期間中であっても、自動的にスケールアウトされます。 Azure Functions インフラストラクチャでは、関数がトリガーされるイベントの数に基づいて Functions ホストのインスタンスを追加することで、CPU とメモリのリソースがスケーリングされます。 | Windows: 100 Linux: 20-1002 |
専用プラン3 | 手動/自動スケール | 10-30 100 (ASE) |
コンテナー アプリ | イベント ドリブン。 負荷が高い期間中であっても、自動的にスケールアウトされます。 Azure Functions インフラストラクチャでは、関数がトリガーされるイベントの数に基づいて Functions ホストのインスタンスを追加することで、CPU とメモリのリソースがスケーリングされます。 | 300-10004 |
従量課金プラン | イベント ドリブン。 負荷が高い期間中であっても、自動的にスケールアウトされます。 Functions インフラストラクチャでは、受信するトリガー イベントの数に基づいて、Functions ホストのインスタンスをさらに追加することで、CPU とメモリのリソースがスケーリングされます。 | Windows: 200 Linux: 1001 |
- 現在、従量課金プランの Linux アプリでは、スケールアウト中に 1 つのサブスクリプションで 1 時間あたり 500 インスタンスの制限があります。
- 一部のリージョンでは、Premium プランの Linux アプリは 100 インスタンスにスケーリングできます。 詳細については、Premium プランに関する記事を参照してください。
- 各種 App Service プラン オプションに固有の制限については、App Service プランの制限に関する記事を参照してください。
- Container Apps での既定値は 10 インスタンスですが、レプリカの最大数を設定でき、合計で最大 1,000 個です。 利用できるコア クォータが十分にある限り、この設定が使用されます。 Azure portal から関数アプリを作成するときは、300 インスタンスに制限されます。
コールド スタートの動作
プラン | 詳細 |
---|---|
Flex 従量課金プラン | 新しいインスタンスをプロビジョニングするときの遅延を減らすために、常時使用可能なインスタンスをサポートします。 |
Premium プラン | 1 つまたは複数の "常にウォーム状態" のインスタンスを維持できるようにすることで、コールド スタートを回避するために常時使用可能なインスタンスをサポートします。 |
専用プラン | 専用プランで実行する場合、Functions ホストを所定の数のインスタンスで継続的に実行できます。つまり、コールド スタートは実際には問題になりません。 |
コンテナー アプリ | レプリカの最小数に依存します。 • 0 に設定した場合: アプリはアイドル時にゼロにスケーリングでき、起動時に一部の要求の待ち時間が長くなる可能性があります。 • 1 以上に設定した場合: ホスト プロセスは常に実行しており、コールド スタートが問題にならないことを意味します。 |
従量課金プラン | アプリはアイドル時にゼロにスケーリングできます。つまり、一部の要求の起動時に待機時間が長くなる可能性があります。 従量課金プランには、コールド スタート時間を短縮するのに役立ついくつかの最適化があります。これには、既にホストと言語プロセスが実行されている、事前ウォーミングされたプレースホルダー関数からのプルが含まれます。 |
サービスの制限
リソース | Flex 従量課金プラン | Premium プラン | 専用プラン/ASE | コンテナー アプリ | 従量課金プラン |
---|---|---|---|---|---|
既定のタイムアウトまでの時間 (分) | 30 | 30 | 301 | 3016 | 5 |
最大のタイムアウトまでの時間 (分) | 無制限9 | 無制限9 | 無制限2 | 無制限17 | 10 |
最大送信接続数 (インスタンスあたり) | unbounded | 無制限 | 無制限 | unbounded | アクティブ 600 (合計 1200) |
最大要求サイズ (MB)3 | 210 | 210 | 210 | 210 | 210 |
クエリ文字列の最大長3 | 4096 | 4096 | 4096 | 4096 | 4096 |
要求 URL の最大長3 | 8192 | 8192 | 8192 | 8192 | 8192 |
インスタンスあたりの ACU | 210 ~ 840 | 100 から 840/210 から 25010 | 状況に応じて異なる | 100 | 状況に応じて異なる |
最大メモリ (インスタンスあたりの GB) | 4<sup4 | 3.5 ~ 14 | 1.75 から 256/8 から 256 | 状況に応じて異なる | 1.5 |
最大インスタンス数 (Windows/Linux) | 100/20 | SKU により異なる/10011 | 10-30018 | 200/100 | 1000 15 |
プランあたりの関数アプリ13 | 100 | 100 | 無制限4 | 無制限4 | 100 |
App Service プラン | 該当なし | リソース グループあたり 100 | リソース グループあたり 100 | 該当なし | リージョンあたり 100 |
アプリあたりのデプロイ スロット12 | 該当なし | 3 | 1 から 2011 | サポートされない | 2 |
ストレージ (一時)5 | 0.8 GB | 21-140 GB | 11-140 GB | 該当なし | 0.5 GB |
ストレージ (永続化) | 0 GB7 | 250 GB | 10 から 1000 GB11 | 該当なし | 1 GB6,7 |
アプリケーションごとのカスタム ドメイン数 | 500 | 500 | 500 | サポートされない | 5007 |
カスタム ドメインの SSL サポート | 無制限の SNI SSL 接続と 1 件の IP SSL 接続が含まれる | 無制限の SNI SSL 接続と 1 件の IP SSL 接続が含まれる | 無制限の SNI SSL 接続と 1 件の IP SSL 接続が含まれる | サポートされない | 無制限の SNI SSL 接続が含まれる |
サービスの制限に関する注意事項:
- 既定では、App Service プランでの Functions 1.x ランタイムのタイムアウトは無制限です。
- App Service プランが Always On に設定されている必要があります。 標準料金でのお支払い。 プラットフォームの更新中は 10 分の猶予期間が与えられます。
- これらの制限はホストで設定されます。
- ホストできる関数アプリの実際の数は、アプリのアクティビティ、マシン インスタンスのサイズ、対応するリソース使用量によって異なります。
- ストレージの上限は、同じ App Service プランのすべてのアプリにまたがる一時ストレージ内の合計コンテンツ サイズです。 Linux の従量課金プランの場合、ストレージは現在 1.5 GB です。
- 従量課金プランでは、永続化されたストレージには Azure Files 共有が使用されます。 独自の Azure Files 共有を指定する場合、特定の共有サイズの制限は、WEBSITE_CONTENTAZUREFILECONNECTIONSTRING に設定したストレージ アカウントによって異なります。
- Linux では、独自の Azure Files 共有を明示的にマウントする必要があります。
- 関数アプリが従量課金プランでホストされている場合、CNAME オプションのみがサポートされます。 Premium プランまたは App Service プランの関数アプリでは、CNAME または A レコードを使用してカスタム ドメインをマップできます。
- 実行タイムアウトの最長期間は適用されません。 ただし、関数の実行に与えられる猶予期間は、スケールイン中は 60 分、プラットフォーム更新中は 10 分です。
- ワーカーは、お客様のアプリをホストする役割です。 ワーカーは、3 つの固定サイズで使用できます。1 vCPU/3.5 GB RAM。2 vCPU/7 GB RAM。4 vCPU/14 GB RAM。
- 詳細については、「App Service の制限」を参照してください。
- 運用スロットを含む。
- 現在、特定のサブスクリプションには 5,000 個という関数アプリの制限があります。
- Flex 従量課金プランのインスタンス サイズは、現在、2,048 MB または 4,096 MB のどちらかとして定義されています。 詳細については、「インスタンス メモリ」を参照してください。
- Flex 従量課金プランには、特定のリージョン全体のすべてのインスタンスの合計メモリ使用量を制限するリージョン サブスクリプション クォータがあります。 詳細については、「インスタンス メモリ」を参照してください。
- 最小レプリカ数が 0 に設定されている場合、既定のタイムアウトはアプリで使われている特定のトリガーによって異なります。
- 最小レプリカ数が 1 以上に設定されている場合。
- Container Apps では最大レプリカ数を設定でき、十分なコア クォータを使用できる限りそれが適用されます。
ネットワーク機能
機能 | Flex 従量課金プラン | 従量課金プラン | Premium プラン | 専用プラン/ASE | Container Apps1 |
---|---|---|---|---|---|
受信 IP の制限 | ✔ | ✔ | ✔ | ✔ | ✔ |
受信プライベート エンドポイント | ✔ | ✔ | ✔ | ||
仮想ネットワークの統合 | ✔ | ✔2 | ✔3 | ✔ | |
送信 IP の制限 | ✔ | ✔ | ✔ | ✔ |
- 詳細については、「Azure Container Apps 環境でのネットワーク」を参照してください。
- 仮想ネットワーク トリガーを使用する場合、特別な考慮事項があります。
- ゲートウェイを必要とする仮想ネットワーク統合をサポートするのは、Dedicated/ASE プランのみです。
請求
プラン | 詳細 |
---|---|
Flex 従量課金プラン | 請求は、実行回数、アクティブに関数を実行しているインスタンスのメモリ、および常時使用可能なインスタンスのコストに基づいています。 詳細については、Flex 従量課金プランの請求に関するページを参照してください。 |
Premium プラン | Premium プランは、事前ウォーミングされた必要なインスタンスで使用されたコア秒数とメモリに基づいています。 プランごとに少なくとも 1 つのインスタンスが常にウォーム状態である必要があります。 このプランでは、最も予測可能な価格が提供されます。 |
専用プラン | App Service プランの Function App に対する支払いは、Web アプリなどの他の App Service リソースの場合と同じです。 ASE の場合、インフラストラクチャに対して支払いを行い、環境のサイズによって変更されない一定の月額料金があります。 App Service プランの vCPU あたりのコストもあります。 ASE でホストされているすべてのアプリは、分離された価格 SKU に含まれます。 詳細については、ASE の概要に関する記事を参照してください。 |
コンテナー アプリ | Azure Container Apps での課金は、プランの種類に基づいています。 詳しくは、「Azure Container Apps での課金」をご覧ください。 |
従量課金プラン | 関数が実行された時間に対してだけ支払います。 課金は、実行数、実行時間、およびメモリの使用量に基づいて行われ、 |
動的ホスティング プラン (従量課金、Flex 従量課金、Premium) の直接のコスト比較については、Azure Functions の価格に関するページを参照してください。 さまざまな専用プラン オプションの価格については、App Service の価格に関するページを参照してください。 Container Apps ホスティングの価格については、「Azure Container Apps の価格」を参照してください。
既存のリソース グループに新しい関数アプリを作成するための制限事項
場合によっては、既存のリソース グループで関数アプリの新しいホスティング プランを作成しようとすると、次のいずれかのエラーが発生することがあります。
- 価格レベルがこのリソース グループで許可されていない
- <SKU_name> ワーカー はリソース グループ <resource_group_name> で使用できない
これは次の条件が当てはまる場合に発生する可能性があります。
- 今までに別の関数アプリまたは Web アプリが含まれていた既存のリソース グループに関数アプリを作成している。 たとえば、Linux 従量課金プラン アプリは、Linux 専用または Linux Premium プランと同じリソース グループではサポートされていません。
- 新しい関数アプリを以前のアプリと同じリージョンに作成している。
- 以前のアプリが何らかの原因で新しいアプリと互換性がない。 このエラーは、SKU、オペレーティング システム間、または可用性ゾーンのサポートなど、他のプラットフォームレベルの機能が原因で発生する可能性があります。
これは、関数アプリと Web アプリのプランが、作成時に異なるリソース プールにマッピングされることに起因しています。 SKU が異なると、異なるインフラストラクチャ機能のセットが必要になります。 リソース グループにアプリを作成すると、そのリソース グループは特定のリソース プールにマッピングおよび割り当てされます。 そのリソース グループに別のプランを作成しようとしたときに、マッピングされたプールに必要なリソースがない場合、このエラーが発生します。
このエラーが発生した場合は、代わりに関数アプリとホスティング プランを新しいリソース グループに作成します。