従量課金ベースのコストの見積もり
この記事では、Flex の従量課金と従量課金のホスティング プランについてプラン コストを見積もる方法について説明します。
現在、Azure Functions では関数アプリ用に以下のホスティング プランが提供されており、各プランに独自のホスティング プランの価格モデルがあります。
| プラン | 説明 |
|---|---|
| Flex 従量課金プラン | 関数が実行されているインスタンスの実行時間に加えて、"常時使用可能" なインスタンスの実行時間に対して料金が発生します。 インスタンスは、受信イベント数に基づいて動的に追加および削除されます。 これは、仮想ネットワーク統合もサポートする推奨の動的スケール プランです。 |
| Premium | 従量課金プランと同じ機能とスケーリング メカニズムを備えていますが、パフォーマンスと仮想ネットワークの統合が強化されています。 コストは、お客様が選択した価格レベルに基づきます。 詳細については、「Azure Functions の Premium プラン」を参照してください。 |
| 専用 (App Service) (Basic レベル以上) |
専用 VM または分離環境で実行する必要がある場合は、カスタム イメージつまり超過した App Service プラン容量を使用します。 標準の App Service プランの料金を使用します。 コストは、お客様が選択した価格レベルに基づきます。 |
| コンテナー アプリ | Azure Container Apps によってホストされたフル マネージド環境内で、コンテナー化された関数アプリを作成してデプロイします。これによって、他のマイクロサービス、API、Web サイト、ワークフローと共に、コンテナーでホストされたプログラムとして関数を実行できます。 |
| 従量課金プラン | 関数アプリが実行された時間に対してのみ課金されます。 このプランには、サブスクリプションごとの無料提供が含まれます。 |
関数の実行に必要な機能、パフォーマンス、コストの要件を最もサポートするオプションを常に選ぶことをお勧めします。 詳細については、「Azure Functions のスケールとホスティング」を参照してください。
この記事では、Flex の従量課金プランと従量課金プランに焦点を当てます。これらのプランでは、課金が各インスタンス内のアクティブな実行期間に左右されるからです。
また、Durable Functions は、これらの両プランでも実行できます。 Durable Functions を使用する場合のコストに関する考慮事項の詳細については、「Durable Functions の課金」を参照してください。
従量課金ベースのコスト
無料付与を含め、従量課金ベースのコストの計算方法は、各プランによって異なります。 最新のコストと付与情報については、「Azure Functions の価格」ページを参照してください。
Flex 従量課金プランでアプリを実行するときにコストを決定する 2 つのモードがあります。 各モードは、インスタンスごとに決定されます。
| 課金モード | 説明 |
|---|---|
| オンデマンド | "オンデマンド" モードで実行する場合、関数コードが使用可能なインスタンスで実行されている時間に対してのみ課金されます。 オンデマンド モードでは、最小インスタンス数は必要ありません。 課金の対象: • 各オンデマンド インスタンスが "アクティブに" 関数を実行している間に、プロビジョニングされたメモリの合計量 (GB 秒) から、1 か月あたりの無料付与の GB 秒を引いた値。 • 実行の合計数から、1 か月あたりの無料付与の実行数を引いた値。 |
| 常時使用可能 | 特定のトリガーの種類 (HTTP/Durable/BLOB) と個々の関数に割り当てられた 1 つ以上のインスタンスを構成できます。これらは、要求を処理するために常に利用できます。 常時使用可能なインスタンスが有効になっている場合は、課金の対象は次のとおりです。 • "ベースライン" (GB 秒) と呼ばれる、常時使用可能なすべてのインスタンスにわたってプロビジョニングされたメモリの合計量。 • 常時使用可能なインスタンスがそれぞれ "アクティブに" 関数を実行しているときにプロビジョニングされたメモリの合計量 (GB 秒)。 • 実行回数の合計。 常時使用可能の課金では、無料の付与はありません。 |
実行価格、常時使用可能のベースライン コスト、オンデマンド実行の無料付与に関する最新情報については、Azure Functions の価格に関するページを参照してください。
この図は、このプランでオンデマンド コストがどのように決定されるかを表しています。
実行時間に加えて、1 つ以上の常時使用可能なインスタンスを使う場合、維持する常時使用可能なインスタンス数に対して、より低いベースライン料金で課金されます。 常時使用可能なインスタンスの実行時間は、オンデマンド実行のインスタンスの実行時間よりも安くなる可能性があります。
重要
この記事では、オンデマンドの価格を使用して、計算の例を理解します。 Flex 従量課金プランで関数を実行するときに発生する可能性のあるコストを見積もる場合は、必ず「Azure Functions の価格」ページで現在のコストを確認してください。
HTTP トリガーのみで構成される関数アプリと、次の基本的な事実について考えてみましょう。
- HTTP トリガーは 1 秒あたり 40 個という一定の要求を処理します。
- HTTP トリガーは 10 個の同時要求を処理します。
- インスタンスのメモリ サイズ設定は
2048 MBです。 - "常時使用可能なインスタンスが構成されていません"。つまり、アプリは 0 までスケーリングできます。
このような状況では、コードの実行中に行われる作業の種類によって価格は大きく左右されます。 次の 2 つのワークロード シナリオを見てみましょう。
CPU バインド ワークロード: CPU バインド ワークロードの場合、同じインスタンスで複数の要求を並列処理する利点はありません。 つまり、各要求をそれぞれのインスタンスに分散した方が、要求が競合することなく、可能な限り早く完了します。 このシナリオでは、
1という低い HTTP トリガーのコンカレンシーを設定する必要があります。 同時要求が 10 個ある場合、アプリは約 10 インスタンスの定常状態にスケーリングします。一度に 1 つの要求が処理されるため、各インスタンスは継続的にアクティブになります。各インスタンスのサイズの上限は 2 GB であるため、1 つの継続的にアクティブなインスタンスの消費量は
2 GB * 3600 s = 7200 GB-sになります。これは、想定されるオンデマンド実行レート (無料付与が適用されない場合) では、インスタンスごとに 1 時間あたり$0.1152 USDになります。 CPU バインド アプリは 10 インスタンスにスケーリングされるため、実行時間の 1 時間あたりの合計レートは$1.152 USDです。同様に、1 秒あたり 40 要求のオンデマンド実行単位の料金 (無料付与なし) は、1 時間あたり
40 * 3600 = 144,000回 (つまり 14.4 万回) の実行に相当します。 1 時間あたりの実行コストの合計 (無料付与) は0.144 * $0.20です。これは 1 時間あたり$0.0288です。このシナリオでは、10 個のインスタンスでオンデマンド実行する 1 時間あたりの合計コストは
$1.152 + $0.0288 = $1.1808 USDです。IO バインド ワークロード: IO バインド ワークロードでは、アプリケーション時間のほとんどが受信要求の待機に費やされます。これは、ネットワーク スループットやその他のアップストリーム要因によって制限される可能性があります。 入力が制限されているため、悪影響を受けることなく、コードは複数の操作を同時に処理できます。 このシナリオでは、同じインスタンスで 10 個の同時要求をすべて処理できるものとします。
従量課金料金は、アクティブな各インスタンスのメモリにのみ基づいているため、従量課金料金の計算は単純に
2 GB * 3600 s = 7200 GB-sです。これは、想定されるオンデマンド実行レート (無料付与が適用されていないもの) では、単一インスタンスの場合、1 時間あたり$0.1152 USDとなります。CPU バインド シナリオと同様に、1 秒あたり 40 要求のオンデマンド実行単位の料金 (無料付与なし) は、1 時間あたり
40 * 3600 = 144,000回 (つまり 14.4 万回) の実行に相当します。 この場合、1 時間あたりの実行コストの合計 (無料付与) は0.144 * $0.20です。これは 1 時間あたり$0.0288です。このシナリオでは、1 個のインスタンスでオンデマンド実行する 1 時間あたりの合計コストは
$0.1152 + $0.0288 = $0.144 USDです。
その他の関連コスト
プランでの関数実行の全体的なコストを見積もるときは、Functions のランタイムでは他の複数の Azure サービスが使用されており、各サービスが個別に課金されることに注意してください。 関数アプリの価格を見積もる場合、他の Azure サービスと統合するトリガーとバインドでは、その他のサービスを作成して支払う必要があります。
従量課金プランで実行される関数の場合、合計コストは、関数の実行コストに、帯域幅とその他のサービスのコストを加えたものです。
関数アプリと関連サービスの全体的なコストを見積もるときは、Azure 料金計算ツールを使用します。
| 関連コスト | 説明 |
|---|---|
| ストレージ アカウント | 各関数アプリには、General Purpose Azure ストレージ アカウントが関連付けられている必要があり、これは別途課金されます。 このアカウントは、Functions ランタイムによって内部的に使用されますが、ストレージのトリガーとバインドにも使用できます。 ストレージ アカウントを持っていない場合は、関数アプリの作成時に作成されます。 詳しくは、「ストレージ アカウントの要件」をご覧ください。 |
| Application Insights | Functions では、関数アプリに高パフォーマンスの監視エクスペリエンスを提供するために、Application Insights が利用されます。 必須ではありませんが、Application Insights の統合を有効にすることをお勧めします。 テレメトリ データの無料提供が毎月含まれます。 詳しくは、「Azure Monitor の価格」ページをご覧ください。 |
| ネットワーク帯域幅 | データ移動の方向とシナリオによっては、データ転送のコストが発生する場合があります。 詳しくは、「帯域幅の料金詳細」をご覧ください。 |
実行時間に影響を与える動作
関数の次の動作は、実行時間に影響を与える可能性があります。
トリガーとバインド: 関数バインドからの入力の読み取り、および関数バインドへの出力の書き込みにかかった時間は、実行時間としてカウントされます。 たとえば、Azure Storage キューにメッセージを書き込むために関数で出力バインドが使用されている場合、実行時間にはキューへのメッセージの書き込みにかかった時間が含まれ、これは関数のコストの計算に含まれます。
非同期実行: 非同期要求 (C# では
await) の結果に対する関数の待機時間は、実行時間としてカウントされます。 GB 秒数の計算は、関数の開始時刻と終了時刻、およびその期間のメモリ使用量に基づいています。 その間に発生した CPU アクティビティは、計算では考慮されません。 Durable Functions を使うと、非同期操作中のコストを減らせる場合があります。 オーケストレーター関数での待機時間に対して課金されることはありません。
コスト関連データを表示する
請求書では、 [Total Executions - Functions](合計実行数 - Functions) および [Execution Time - Functions](実行時間 - Functions) のコスト関連データと、実際に請求されたコストを見ることができます。 ただし、この請求データは過去の請求期間の月次集計です。
関数アプリレベルのメトリック
関数のコストをより深く理解するには、Azure Monitor を使って、関数アプリによって現在生成されているコスト関連メトリックを確認できます。
従量課金プランの関数アプリのコスト関連データをグラフィック形式で表示するには、Azure Monitor メトリックス エクスプローラーを使用します。
Azure portal で関数アプリに移動します。
左側のパネルで、 [監視] までスクロールし、 [メトリック] を選択します。
[メトリック] から [関数の実行回数] を選択し、 [集計] から [合計] を選択します。 これにより、選択した期間の実行回数の合計がグラフに追加されます。
[メトリックの追加] を選択し、手順 2 から手順 4 を繰り返して、 [関数の実行単位] をグラフに追加します。
結果のグラフには、選択した時間範囲 (この例では 2 時間) に対する両方の実行メトリックの合計が含まれます。
実行単位の数は実行回数よりはるかに多いため、グラフは実行単位だけのように見えます。
このグラフでは、MB ミリ秒数で測定して、2 時間に合計で 11.1 億の Function Execution Units が消費されたことが示されています。 GB 秒数に変換するには、1,024,000 で割ります。 この例の関数アプリでは、1110000000 / 1024000 = 1083.98 GB 秒が消費されました。 この値を取得し、Functions の価格ページで示されている実行時間の現在の料金を乗算することにより、この 2 時間のコストがわかります (実行時間の無料提供を既に使用してあるものとします)。
関数レベルのメトリック
関数の実行単位は、実行時間とメモリ使用量を組み合わせたものであり、メモリ使用量を理解するのが困難なメトリックになっています。 現在、Azure Monitor では、メモリ データのメトリックは使用できません。 ただし、アプリのメモリ使用量を最適化したい場合は、Application Insights によって収集されるパフォーマンス カウンター データを使用できます。
まだ行っていない場合は、関数アプリで Application Insights を有効にします。 この統合を有効にすると、ポータルでこのテレメトリ データのクエリを実行することができます。
Monitor メトリック データを取得するには、Azure portal の Azure Monitor メトリックス エクスプローラーまたは REST API を使用できます。
メモリの使用量を確認する
[Monitoring](監視) の [ログ (Analytics)] を選択した後、次のテレメトリ クエリをコピーしてクエリ ウィンドウに貼り付け、 [実行] を選択します。 このクエリでは、サンプリングされた各時刻におけるメモリ使用量の合計が返されます。
performanceCounters
| where name == "Private Bytes"
| project timestamp, name, value
結果は次の例のようになります。
| タイムスタンプ [UTC] | name | value |
|---|---|---|
| 9/12/2019, 1:05:14.947 AM | Private Bytes | 209,932,288 |
| 9/12/2019, 1:06:14.994 AM | Private Bytes | 212,189,184 |
| 9/12/2019, 1:06:30.010 AM | Private Bytes | 231,714,816 |
| 9/12/2019, 1:07:15.040 AM | Private Bytes | 210,591,744 |
| 9/12/2019, 1:12:16.285 AM | Private Bytes | 216,285,184 |
| 9/12/2019, 1:12:31.376 AM | Private Bytes | 235,806,720 |
継続時間を確認する
Azure Monitor ではリソース レベルでメトリックが追跡され、Functions の場合は関数アプリです。 Application Insights の統合では、関数ごとにメトリックが出力されます。 関数の平均継続時間を取得するための分析クエリの例を次に示します。
customMetrics
| where name contains "Duration"
| extend averageDuration = valueSum / valueCount
| summarize averageDurationMilliseconds=avg(averageDuration) by name
| name | averageDurationMilliseconds |
|---|---|
| QueueTrigger AvgDurationMs | 16.087 |
| QueueTrigger MaxDurationMs | 90.249 |
| QueueTrigger MinDurationMs | 8.522 |