従量課金ベースのコストの見積もり

  • [アーティクル]

この記事では、従量課金と Flex 従量課金のホスティング プランについてプラン コストを見積もる方法について説明します。

現在、Azure Functions には関数アプリ用に 4 種類のホスティング プランが用意されており、各プランに独自の価格モデルがあります。

プラン 説明
従量課金 関数アプリが実行された時間に対してのみ課金されます。 このプランには、サブスクリプションごとの無料提供が含まれます。
Flex 従量課金プラン 関数が実行されているインスタンスの実行時間に加えて、"常時使用可能" なインスタンスの実行時間に対して料金が発生します。 インスタンスは、受信イベント数に基づいて動的に追加および削除されます。 仮想ネットワークの統合もサポートします。
Premium 従量課金プランと同じ機能とスケーリング メカニズムを備えていますが、パフォーマンスと仮想ネットワークの統合が強化されています。 コストは、お客様が選択した価格レベルに基づきます。 詳細については、「Azure Functions の Premium プラン」を参照してください。
専用 (App Service)
(Basic レベル以上)		 専用 VM または分離環境で実行する必要がある場合は、カスタム イメージつまり超過した App Service プラン容量を使用します。 標準の App Service プランの料金を使用します。 コストは、お客様が選択した価格レベルに基づきます。

重要

現在、Flex 従量課金プランはプレビュー段階です。

関数の実行に必要な機能、パフォーマンス、コストの要件を最もサポートするプランを常に選ぶことをお勧めします。 詳細については、「Azure Functions のスケールとホスティング」を参照してください。

この記事では、従量課金プランと Flex 従量課金プランに焦点を当てます。これらのプランでは、課金が各インスタンス内のアクティブな実行期間に左右されるからです。

また、Durable Functions は、これらの両プランでも実行できます。 Durable Functions を使用する場合のコストに関する考慮事項の詳細については、「Durable Functions の課金」を参照してください。

従量課金ベースのコスト

無料付与を含め、従量課金ベースのコストの計算方法は、各プランによって異なります。 最新のコストと付与情報については、「Azure Functions の価格」ページを参照してください。

1 回の関数実行の実行 "コスト" は、"GB 秒数" で測定されます。 実行コストは、そのメモリ使用量と実行時間を組み合わせて計算されます。 実行時間が長い関数ほどコストが高くなり、メモリ消費量が多い関数ほどコストが高くなります。

関数によって使用されるメモリの量が一定のままである場合を考えてみます。 この場合、コストの計算は単純な乗算です。 たとえば、関数が 0.5 GB を3 秒間消費したとします。 その場合の実行コストは 0.5GB * 3s = 1.5 GB-seconds になります。

メモリ使用量は時間の経過と共に変化するため、計算は実質的には時間経過に伴うメモリ使用量の積分になります。 システムでは、一定の間隔でプロセス (子プロセスを含む) のメモリ使用量をサンプリングすることによって、この計算が行われます。 価格ページで説明されているように、メモリ使用量は最も近い 128 MB のバケットに切り上げられます。 プロセスで 160 MB 使用されている場合は、256 MB の料金が発生します。 計算では同時実行が考慮されます。同時実行とは、同じプロセス内で複数の関数が同時に実行することです。

Note

CPU 使用率は実行コストでは直接考慮されませんが、関数の実行時間に影響する場合は、コストに影響を与える可能性があります。

HTTP によってトリガーされる関数の場合、関数コードの実行が開始される前にエラーが発生した場合、実行に対して課金されることはありません。 これは、API キーの検証または App Service の認証/承認機能が原因のプラットフォームからの 401 応答は、実行コストに対してカウントされないことを意味します。 同様に、5xx 状態コードの応答が要求を処理する関数よりも前のプラットフォームで発生した場合は、カウントされません。 関数コードからエラーが発生しなかった場合でも、関数コードの実行が開始された後にプラットフォームによって生成される 5xx 応答は、引き続き実行としてカウントされます。

プランでの関数実行の全体的なコストを見積もるときは、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 メトリックス エクスプローラーを使用します。

  1. Azure portal で関数アプリに移動します。

  2. 左側のパネルで、 [監視] までスクロールし、 [メトリック] を選択します。

  3. [メトリック] から [関数の実行回数] を選択し、 [集計] から [合計] を選択します。 これにより、選択した期間の実行回数の合計がグラフに追加されます。

    グラフに追加する関数アプリのメトリックを定義する

  4. [メトリックの追加] を選択し、手順 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

次のステップ

関数アプリの監視についての詳細情報