Azure で関数アプリを作成するときは、アプリのホスティング オプションを選択する必要があります。 Azure には、関数コードの次のホスティング オプションが用意されています。
ホスティング オプション | サービス | 可用性 | コンテナー サポート |
---|---|---|---|
Flex 従量課金プラン | Azure Functions | 一般提供 (GA) | なし |
Premium プラン | Azure Functions | GA | Linux |
専用プラン | Azure Functions | GA | Linux |
コンテナー アプリ | Azure Container Apps | GA | Linux |
従量課金プラン | Azure Functions | Windows - GA Linux - 廃止 |
なし |
Important
2028 年 9 月 30 日以降、従量課金プランで Linux で関数アプリをホストするオプションは廃止されます。 中断を回避するには、Linux 上で実行されている既存の従量課金プラン アプリを、その日付より前の Flex 従量課金プラン に移行します。 従量課金プランで Windows で実行されているアプリは、この変更の影響を受けません。 詳細については、 Linux 従量課金プランの提供終了に関する通知を参照してください。
Azure Functions のホスティング オプションは、Linux と Windows の両方の仮想マシン上の Azure App Service インフラストラクチャによって支援されています。 選択したホスティング オプションによって、次の動作が決まります。
- 関数アプリをスケールする方法。
- 各関数アプリ インスタンスに利用できるリソース。
- Azure Virtual Network 接続などの高度な機能のサポート。
- Linux コンテナーのサポート。
選択したプランは、関数コードの実行コストにも影響します。 詳細については、「課金」を参照してください。
この記事では、さまざまなホスティング オプションを詳しく比較します。 Linux コンテナーでの関数コードの実行と管理の詳細については、Azure Functions での Linux コンテナーのサポートに関するページを参照してください。
プランの概要
以下に、Azure Functions ホスティングのさまざまなオプションの利点をまとめます。
オプション | メリット |
---|---|
Flex 従量課金プラン | 柔軟なコンピューティング オプション、仮想ネットワーク統合、サーバーレス従量課金制を使用して、迅速な水平スケーリングを体験できます。 Flex Consumption プランでは、関数インスタンスは、最適な効率を得るために、構成されたインスタンスごとのコンカレンシー、受信イベント、および関数ごとのワークロードに基づいて動的にスケールアウト (最大 1,000) されます。 次の場合は、Flex 従量課金プランを検討してください。 ✔ 関数コードにはサーバーレス ホストが必要で、オンデマンド実行に対してのみ料金が支払われます。 ✔ Azure リソースに安全にアクセスするには、仮想ネットワーク接続が必要です。 ✔ ワークロードは可変であり、アクティビティがない状態から、要求の厳しい迅速なイベントドリブンのスケーリングが必要になることがあります。 ✔ メモリ サイズ (512 MB、2 GB、または 4 GB) でコンピューティングをカスタマイズし、1 つ以上の事前プロビジョニング (常時対応) インスタンスを使用してコールド スタートを減らす必要があります。 |
Premium プラン | 需要に応じて自動的にスケーリングを行いながら、事前ウォーミングされたワーカーを使用して、アイドル状態になっても遅延なくアプリケーションを実行したり、より強力なインスタンスで実行したり、仮想ネットワークに接続したりすることができます。 次のような状況では、Azure Functions の Premium プランを検討してください。 ✔ 関数を継続的に、またはほぼ継続的に実行したい。 ✔ インスタンスをより詳細に制御する必要があり、イベントドリブン スケーリングと同じプランで複数の関数アプリをデプロイしたい。 ✔ 小規模な実行の回数が多く、実行料金が高いが、従量課金プランでの GB 秒は低い。 ✔ 従量課金プランで提供されるよりも多くの CPU またはメモリのオプションが必要である。 ✔ 従量課金プランで許可されている最大実行時間よりも長くコードを実行する必要がある。 ✔ Azure リソースに安全にアクセスするには、仮想ネットワーク接続が必要です。 ✔ 関数を実行するカスタム 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 コンピューティング リソースによって提供されるハイエンドの処理能力が必要である。 |
従量課金プラン | Windows で自動スケールを使用して関数が実行されている (従量課金制) 場合にのみ、コンピューティング リソースに対して支払います。 従量課金プランでは、関数インスタンスは、受信イベントの数に基づいて動的に追加および削除されます。 次の場合は、コンシュームプランを検討してください。 ✔ v1 ランタイム、完全な .NET Framework、特定の PowerShell モジュールなどの Windows 固有の機能の使用など、Windows に依存している ✔ サーバーレス課金モデルが必要であり、関数が実行されている場合にのみ課金されます。 |
この記事の残りの表では、さまざまな機能と動作に基づいてホスティング オプションを比較します。
オペレーティング システムのサポート
次の表は、ホスティング オプションに対するオペレーティング システムのサポートを示しています。
Hosting | Linux1 デプロイ | Windows2 デプロイ |
---|---|---|
Flex 従量課金プラン |
✅ コードのみ ❌ コンテナー (サポートされていません) |
❌ サポート対象外 |
Premium プラン |
✅ コードのみ ✅ コンテナー |
✅ コードのみ |
専用プラン |
✅ コードのみ ✅ コンテナー |
✅ コードのみ |
コンテナー アプリ | ✅ コンテナーのみ | ❌ サポート対象外 |
従量課金プラン3 |
✅ コードのみ (廃止) ❌ コンテナー (サポートされていません) |
✅ コードのみ |
- Linux は、Python ランタイム スタックでサポートされている唯一のオペレーティング システムです。
- Windows のデプロイはコードのみです。 現在、Functions では Windows コンテナーはサポートされていません。
- 従量課金プランで Linux 上でアプリを実行する機能は、2028 年 9 月 30 日に廃止される予定です。 詳細については、 従量課金プランを参照してください。
関数アプリ タイムアウト期間
関数アプリ内の関数のタイムアウト期間は、functionTimeout
プロジェクト ファイルの プロパティによって定義されます。 このプロパティは、関数の実行に特に適用されます。 トリガーによって関数の実行が開始された後、関数はタイムアウト期間内に戻るか応答する必要があります。 タイムアウトを回避するには、 堅牢な関数を記述することが重要です。 詳細については、「Azure Functions のパフォーマンスと信頼性を向上させる」を参照してください。
次の表は、特定のプランの既定値と最大値 (分) を示しています。
プラン | 既定値 | 最大1 |
---|---|---|
Flex 従量課金プラン | 30 | 無制限2 |
Premium プラン | 304 | 無制限2 |
専用プラン | 304 | 無制限3 |
コンテナー アプリ | 30 | 無制限5 |
従量課金プラン | 5 | 10 |
- 関数アプリのタイムアウト設定に関係なく、HTTP トリガー関数が要求に応答できる最大時間は 230 秒です。 これは、Azure Load Balancer の既定のアイドル タイムアウトによるものです。 より長い処理時間では、Durable Functions async pattern の使用を検討するか、実際の作業を遅らせて、即座に応答を返します。
- 実行タイムアウトの最長期間は適用されません。 ただし、関数の実行に与えられる猶予期間は、Flex 従量課金プランと Premium プランの場合、スケールイン中は 60 分であり、プラットフォームの更新中は 10 分の猶予期間が与えられます。
- App Service プランが Always On に設定されている必要があります。 プラットフォームの更新中は 10 分の猶予期間が与えられます。
- Functions ホスト ランタイムのバージョン 1.x の既定のタイムアウトは "無制限" です。
- 最小レプリカ数が 0 に設定されている場合、既定のタイムアウトは、アプリで使用されている特定のトリガーによって異なります。
この表の値は、Azure Functions ホスト プロセスが開始され、正常に実行されていることを前提としています。 言語固有のワーカー プロセスも開始するには、最大 60 秒のタイムアウトが許容されます。 ワーカー プロセスのスタートアップ タイムアウトは現在構成できません。
言語のサポート
Functions での現在のネイティブ言語スタックのサポートについて詳しくは、「Azure Functions でサポートされている言語」を参照してください。
スケール
次の表は、さまざまなホスティング プランのスケーリングの様子を比較したものです。
最大インスタンスは、特に説明がない限り、関数アプリごと (従量課金) またはプランごと (Premium/専用) に示されています。
プラン | スケール アウト | 最大インスタンス数 |
---|---|---|
Flex 従量課金プラン | イベントドリブンの迅速なスケーリングの決定は、関数ごとのスケーリングと呼ばれる関数ごとに計算されます。これは、アプリ内の 関数をより明確にスケーリングする方法を提供します。 HTTP、Blob Storage (Event Grid)、Durable Functions を除き、アプリ内の他のすべての関数トリガーの種類では、独立したインスタンスでスケーリングされます。 アプリ内のすべての HTTP トリガーでは、すべての Blob Storage (Event Grid) トリガーの場合と同様に、同じインスタンス上のグループとしてまとめてスケーリングされます。 すべての Durable Functions トリガーでもインスタンスが共有され、まとめてスケーリングされます。 | 10001 |
Premium プラン | イベント ドリブン。 負荷が高い期間中であっても、自動的にスケールアウトされます。 Azure Functions インフラストラクチャでは、関数がトリガーされるイベントの数に基づいて Functions ホストのインスタンスをさらに追加すると、CPU とメモリのリソースがスケーリングされます。 |
Windows: 1006 Linux: 20-1002,6 |
専用プラン | 手動/自動スケーリング | 10 から 303 100 (ASE) |
コンテナー アプリ | イベント ドリブン。 負荷が高い期間中であっても、自動的にスケールアウトされます。 Azure Functions インフラストラクチャでは、関数がトリガーされるイベントの数に基づいて Functions ホストのインスタンスをさらに追加すると、CPU とメモリのリソースがスケーリングされます。 | 300-10004 |
従量課金プラン | イベント ドリブン。 イベントのソースに基づく自動スケール。 Functions インフラストラクチャは、受信トリガー イベントの数に基づいて、関数ホストのインスタンスを追加することでリソースをスケーリングします。 |
Windows: 200 Linux: 1005 |
- Flex 従量課金プランには、特定のリージョン全体のすべてのインスタンスの合計メモリ使用量を制限するリージョン サブスクリプション クォータがあります。 詳細については、「 リージョン サブスクリプションのメモリ クォータ」を参照してください。 Flex Consumption プランでは現在、Linux のみがサポートされています。
- 一部のリージョンでは、Premium プランの Linux アプリを 100 インスタンスにスケーリングできます。 詳しくは、Premium プランに関する記事をご覧ください。
- さまざまな App Service プラン オプションに固有の制限については、App Service プランの制限に関する記事をご覧ください。
- Container Apps での既定値は 10 インスタンスですが、レプリカの最大数を設定でき、合計で最大 1,000 個です。 利用できるコア クォータが十分にある限り、この設定が使用されます。 詳細については、「Azure Container Apps のクォータ」を参照してください。 Azure portal から関数アプリを作成する際は、300 インスタンスに制限されます。
- 現在、従量課金プランの Linux アプリでは、スケールアウト中に 1 つのサブスクリプションで 1 時間あたり 500 インスタンスの制限があります。
- プライベート エンドポイントの制限付き http トリガーの場合、スケールアウトは最大 20 インスタンスに制限されます。
コールド スタートの動作
プラン | 詳細 |
---|---|
Flex 従量課金プラン | ゼロにスケーリングした場合でもコールド スタートが改善されました。 新しいインスタンスをプロビジョニングするときの遅延をさらに減らすために、 常に準備が整 ったインスタンスをサポートします。 |
Premium プラン | 1 つまたは複数の "常にウォーム状態" のインスタンスを維持できるようにすることで、コールド スタートを回避するために常時使用可能なインスタンスをサポートします。 |
専用プラン | 専用プランで実行する場合、Functions ホストを所定の数のインスタンスで継続的に実行できます。つまり、コールド スタートは実際には問題になりません。 |
コンテナー アプリ |
レプリカの最小数に依存します。 • 0 に設定した場合: アプリはアイドル時にゼロにスケーリングでき、起動時に一部の要求の待機時間が長くなる可能性があります。 • 1 以上に設定した場合: ホスト プロセスは常に実行しており、コールド スタートが問題にならないことを意味します。 |
従量課金プラン | アプリはアイドル時にゼロにスケーリングできます。つまり、一部の要求の起動時に待機時間が長くなる可能性があります。 従量課金プランには、既にホストと言語プロセスが実行されている事前ウォーミング済みプレースホルダー関数からのプルなど、コールド スタート時間を短縮するのに役立ついくつかの最適化があります。 |
サービスの制限
リソース | Flex 従量課金プラン | Premium プラン | 専用プラン/ASE | コンテナー アプリ | 従量課金プラン |
---|---|---|---|---|---|
既定のタイムアウト期間 (分) | 30 | 30 | 301 | 3016 | 5 |
最大タイムアウト期間 (分) | 無制限9 | 無制限9 | 無制限2 | 無制限17 | 10 |
最大アウトバウンド接続数 (インスタンスあたり) | 無制限 | 無制限 | 無制限 | 無制限 | 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) | 414 | 3.5 から 14 | 1.75 から 256/8 から 256 | 状況に応じて異なる | 1.5 |
最大インスタンス数 (Windows |Linux)15 | 該当なし | 1000 | 20-100 | 10-30 (100 ASE)11 | 300-100018 | 200 | 100 |
プランあたりの関数アプリ数13 | 1 | 100 | 無制限4 | 無制限4 | 100 |
App Service プラン | n/a | リソース グループあたり 100 | リソース グループあたり 100 | n/a | リージョンあたり 100 |
アプリあたりのデプロイ スロット数12 | n/a | 3 | 1 から 2011 | サポート対象外 | 2 |
ストレージ (一時)5 | 0.8 GB | 21 から 140 GB | 11 から 140 GB | n/a | 0.5 GB |
ストレージ (永続化) | 0 GB7 | 250 GB | 10 から 1000 GB11 | n/a | 1 GB6,7 |
アプリケーションあたりのカスタム ドメイン数 | 258 | 500 | 500 | サポート対象外 | 5008 |
カスタム ドメインの TSL/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 に設定されている必要があります。 Standard 料金で支払います。 プラットフォームの更新中は 10 分の猶予期間が与えられます。
- これらの制限はホストで設定されます。
- ホストできる関数アプリの実際の数は、アプリのアクティビティ、マシン インスタンスのサイズ、対応するリソース使用量によって異なります。
- ストレージの制限は、同じ App Service プランのすべてのアプリにまたがる一時ストレージ内の合計コンテンツ サイズです。 Linux の従量課金プランの場合、ストレージは現在 1.5 GB です。
- 従量課金プランでは、永続化されたストレージには Azure Files 共有が使用されます。 独自の Azure Files 共有を指定する場合、特定の共有サイズの制限は、WEBSITE_CONTENTAZUREFILECONNECTIONSTRING に設定したストレージ アカウントによって異なります。
- Linux では、独自の Azure Files 共有を明示的にマウントする必要があります。
- 関数アプリが従量課金プランでホストされている場合、CNAME オプションのみがサポートされます。 Premium プランまたは App Service プランの関数アプリでは、CNAME または A レコードを使用してカスタム ドメインをマップできます。
- 実行タイムアウトの最長期間は適用されません。 ただし、関数の実行に与えられる猶予期間は、スケールイン中は 60 分、プラットフォーム更新中は 10 分です。
- worker は、お客様のアプリをホストするロールです。 worker は、3 つの固定サイズ (1 vCPU/3.5 GB RAM、2 vCPU/7 GB RAM、4 vCPU/14 GB RAM) で使用できます。
- 詳細については、「App Service の制限」を参照してください。
- 運用スロットを含みます。
- 現在、特定のサブスクリプション内の関数アプリ数には 5,000 個という制限があります。
- Flex 従量課金プランのインスタンス サイズは、現在、512 MB、2,048 MB、または 4,096 MB として定義されています。 詳細については、「インスタンス メモリ」を参照してください。
- 詳細については、ホスティングの比較に関する記事の スケール を参照してください。
- 最小レプリカ数が 0 に設定されている場合、既定のタイムアウトは、アプリで使用されている特定のトリガーによって異なります。
- 最小レプリカ数が 1 以上に設定されている場合。
ネットワーク機能
特徴量 | Flex 従量課金プラン | 従量課金プラン | Premium プラン | 専用プラン/ASE | Container Apps1 |
---|---|---|---|---|---|
受信 IP の制限 | ✔ | ✔ | ✔ | ✔ | ✔ |
受信方向のプライベート エンドポイント | ✔ | ✔ | ✔ | ||
仮想ネットワークの統合 | ✔ | ✔2 | ✔3 | ✔ | |
送信 IP の制限 | ✔ | ✔ | ✔ | ✔ |
- 詳細については、「Azure Container Apps 環境でのネットワーク」を参照してください。
- 仮想ネットワーク トリガーを使用する場合、特別な考慮事項があります。
- ゲートウェイが必要な仮想ネットワーク統合をサポートするのは、専用/ASE プランのみです。
課金
プラン | 詳細 |
---|---|
Flex 従量課金プラン | 請求は、実行回数、アクティブに関数を実行しているインスタンスのメモリ、および常時使用可能なインスタンスのコストに基づいています。 詳細については、Flex 従量課金プランの請求に関するページを参照してください。 |
Premium プラン | Premium プランは、事前ウォーミングされた必要なインスタンスで使用されたコア秒数とメモリに基づいています。 プランごとに少なくとも 1 つのインスタンスが常にウォーム状態である必要があります。 このプランでは、最も予測可能な価格が提供されます。 |
専用プラン | App Service プランの関数アプリに対する支払いは、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 が異なると、異なるインフラストラクチャ機能のセットが必要になります。 リソース グループにアプリを作成すると、そのリソース グループは特定のリソース プールにマッピングおよび割り当てされます。 そのリソース グループに別のプランを作成しようとしたときに、マッピングされたプールに必要なリソースがない場合、このエラーが発生します。
このエラーが発生した場合は、代わりに関数アプリとホスティング プランを新しいリソース グループに作成します。