Flex 従量課金プランの関数アプリを作成および管理する

この記事では、Azure Functions の Flex 従量課金プランでホストされる関数アプリを作成する方法について説明します。 また、Flex 従量課金プランでホストされるアプリの特定の機能を管理する方法についても説明します。

関数アプリのリソースは言語固有です。 記事の先頭で、推奨されるコード開発言語を必ず選択してください。

前提条件

  • アクティブなサブスクリプションが含まれる Azure アカウント。 まだアカウントがない場合は、無料でアカウントを作成することができます。

  • Azure CLI: Azure でのリソースの作成と管理に使われます。 ローカル コンピューターで Azure CLI を使用している場合は、必ず 2.60.0 以降のバージョンを使用してください。 また、適切な Azure CLI バージョンを含む Azure Cloud Shell を使用することもできます。

  • Go アプリの場合は、Azure CLI バージョン 2.87.0 以降を使用します。 az versionを実行して、インストールされているバージョンを確認します。

  • Visual Studio Code: アプリの作成と開発、Azure リソースの作成、Azure へのコード プロジェクトのデプロイに使われます。 Visual Studio Code を使用している場合は、必ず最新の Azure Functions 拡張機能もインストールしてください。 また、Azure Tools 拡張機能パックをインストールすることもできます。

  • Flex 従量課金プラン アプリを作成する必要はありませんが、新しい関数アプリにデプロイでき、それを検証するコード プロジェクトが必要です。 次のいずれかのクイックスタート記事の最初の部分を完了します。そこでは、HTTP によってトリガーされる関数を含むコード プロジェクトを作成します:

    Maven のデプロイ中に新しい Flex 従量課金プランのアプリを作成するには、ローカル アプリ プロジェクトを作成してから、そのプロジェクトの pom.xml ファイルを更新する必要があります。 詳細については、Maven を使用した Java Flex 従量課金アプリの作成に関するページを参照してください。

    ローカル プロジェクトを作成して実行した後、Azure リソースを作成するよう求められる前にこの記事に戻ります。 関数アプリとその他の Azure リソースは、次のセクションで作成します。

Flex 従量課金アプリを作成する

このセクションでは、Azure CLI、Azure portal、Visual Studio Code のいずれかを使用して、Flex 従量課金プランの関数アプリを作成する方法について説明します。 Bicep/ARM テンプレートを使用して Flex 従量課金プランのアプリを作成する例については、Flex 従量課金リポジトリを参照してください。

代わりに Maven を使用してアプリを作成してデプロイすることを選択する場合は、このセクションをスキップできます。

関数コードをサポートするには、次の 3 つのリソースを作成する必要があります。

  • リソース グループ。関連リソースの論理コンテナーです。
  • ストレージ アカウント。関数についての情報 (状態など) を維持する目的で使用されます。
  • Flex 従量課金プランの関数アプリ。これは、関数コードを実行するための環境を提供します。 関数アプリはローカル関数プロジェクトにマップされるため、関数を Flex 従量課金プランのリソースの管理、デプロイ、共有を容易にするための論理ユニットとしてグループ化できます。

  1. まだ Azure にサインインしていない場合は、Azure にサインインします。

    az login

    az login コマンドで Azure アカウントにサインインします。

  2. az functionapp list-flexconsumption-locations コマンドを使用して、現在 Flex Consumption をサポートしているリージョンの一覧をアルファベット順で確認します。

    az functionapp list-flexconsumption-locations --query "sort_by(@, &name)[].{Region:name}" -o table

  1. 前の手順のコマンドで一覧表示されている現在サポートされているリージョンの 1 つにリソース グループを作成します。

    az group create --name <RESOURCE_GROUP> --location <REGION>

    前のコマンドでは、 <RESOURCE_GROUP> をサブスクリプションで一意の値に置き換え、 <REGION> 現在サポートされているリージョンのいずれかに置き換えます。 az group create コマンドでリソース グループを作成します。

  2. リソース グループとリージョン内に汎用ストレージ アカウントを作成します。

    az storage account create --name <STORAGE_NAME> --location <REGION> --resource-group <RESOURCE_GROUP> --sku Standard_LRS --allow-blob-public-access false

    前の例では、<STORAGE_NAME> を Azure Storage で一意となる、あなたにとって適切な名前に置き換えます。 名前には、数字と小文字のみで構成される 3 ~ 24 文字を含める必要があります。 Standard_LRS は、ストレージ アカウントの要件に従って Azure Functions がサポートする汎用 アカウントを指定します。 az storage account create コマンドでストレージ アカウントを作成します。

    重要

    ストレージ アカウントは、重要なアプリ データを格納するために使用されます。このデータには、アプリケーション コード自体が含まれることがあります。 他のアプリやユーザーによるストレージ アカウントへのアクセスを制限する必要があります。

  3. Azure に関数アプリを作成します。

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime dotnet-isolated --runtime-version 8.0

    インプロセスで実行される C# アプリは現在、Flex 従量課金プランで実行される場合はサポートされていません。

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime java --runtime-version 17

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime node --runtime-version 22

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime python --runtime-version 3.11

    Python アプリの場合は、Python 3.10 も現在サポートされています。

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime powershell --runtime-version 7.4

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime go --runtime-version 1.0 --functions-version 4
az resource update --resource-group <RESOURCE_GROUP> --resource-type Microsoft.Web/sites --name <APP_NAME> --set properties.siteConfig.http20Enabled=false

    az resource update コマンドは、Go パブリック プレビュー中に必要な関数アプリの HTTP/2 を無効にします。

    この例では、<RESOURCE_GROUP> と <STORAGE_NAME> の両方をそれぞれ、前の手順で使用したリソース グループとアカウントの名前に置き換えます。 また、<APP_NAME> も自分に適したグローバルに一意の名前に置き換えます。 <APP_NAME> はまた、関数アプリの既定のドメイン ネーム サーバー (DNS) ドメインでもあります。 az functionapp create コマンドは、Azure に関数アプリを作成します。

    az functionapp create コマンドは、Flex 従量課金プランで実行されている関数アプリを作成します。

    このアプリは、常時使用可能なインスタンスを指定せずに作成したため、関数をアクティブに実行した場合にのみコストが発生します。 また、このコマンドを実行すると、関連する Azure アプリケーション Insights インスタンスが同じリソース グループに作成されます。このインスタンスを使用することで、関数アプリを監視し、ログを確認できます。 詳しくは、「Azure Functions を監視する」をご覧ください。

コード プロジェクトをデプロイする

デプロイの場合、Flex Consumption プラン アプリは Blob Storage コンテナーを使用して、プロジェクト コードとアプリの実行に必要なすべてのライブラリを含む .zip パッケージ ファイルをホストします。 詳しくは、「デプロイ」を参照してください。

代わりに Maven を使用してアプリを作成してデプロイすることを選択する場合は、このセクションをスキップできます。

さまざまなツールを使用して、既存の関数アプリにプロジェクト コードをデプロイすることを選択できます。

Go デプロイには、Azure Functions Core Tools バージョン 4.12 以降が必要です。 func --versionを実行して、インストールされているバージョンを確認します。

Azure CLI を使用して、Azure の関数アプリのデプロイ共有にデプロイ パッケージ ファイルをアップロードできます。 このデプロイを行うには、パッケージがアプリにマウントされたときに実行できる .zip パッケージ ファイルを生成する必要があります。

このパッケージ ファイルには、プロジェクトの実行に必要なすべてのビルド出力ファイルと参照先ライブラリが含まれている必要があります。

多数のライブラリを含むプロジェクトの場合は、プロジェクト ファイルのルートをパッケージ化し、 リモート ビルドを要求します。

Python プロジェクトの場合は、プロジェクト ファイルのルートをパッケージ化し、常に remote ビルドを要求します。 リモート ビルドを使用すると、Linux にデプロイする Windows でプロジェクトをビルドするときに発生する可能性のある潜在的な問題を回避できます。

Go プロジェクトの場合は、Core Tools を使用して、すぐに実行できる .zip パッケージをローカルに作成し、Azure CLIでそのパッケージをデプロイします。 func packによって作成された Go パッケージのリモート ビルドを要求しないでください。

  1. 好みの開発ツールを使用して、コード プロジェクトをビルドします。

  2. ビルド ディレクトリの出力を含む .zip ファイルを作成します。 詳細については、「 プロジェクト構造」を参照してください。

  3. 必要に応じて、Azure アカウントにサインインし、az login コマンドを使用してアクティブなサブスクリプションを選択します。

    az login

  4. az functionapp deployment source config-zip コマンドを実行して、相対<FILE_PATH>にあるアプリケーション パッケージをデプロイします。

    az functionapp deployment source config-zip --src <FILE_PATH> --name <APP_NAME> --resource-group <RESOURCE_GROUP>

  1. 好みの開発ツールを使用して、コード プロジェクトをビルドします。

  2. ビルド ディレクトリの出力を含む .zip ファイルを作成します。 詳細については、「 フォルダー構造」を参照してください。

  3. 必要に応じて、Azure アカウントにサインインし、az login コマンドを使用してアクティブなサブスクリプションを選択します。

    az login

  4. az functionapp deployment source config-zip コマンドを実行して、相対<FILE_PATH>にあるアプリケーション パッケージをデプロイします。

    az functionapp deployment source config-zip --src <FILE_PATH> --name <APP_NAME> --resource-group <RESOURCE_GROUP>

  1. コード プロジェクトのルート ディレクトリを含む .zip ファイルを作成します。 詳細については、「 フォルダー構造」を参照してください。

  2. 必要に応じて、Azure アカウントにサインインし、az login コマンドを使用してアクティブなサブスクリプションを選択します。

    az login

  3. az functionapp deployment source config-zip コマンドを実行して、相対<FILE_PATH>にあるアプリケーション パッケージをデプロイします。

    az functionapp deployment source config-zip --src <FILE_PATH> --name <APP_NAME> --resource-group <RESOURCE_GROUP>

  1. コード プロジェクトのルート ディレクトリを含む .zip ファイルを作成します。 詳細については、「 フォルダー構造」を参照してください。

  2. 必要に応じて、Azure アカウントにサインインし、az login コマンドを使用してアクティブなサブスクリプションを選択します。

    az login

  3. az functionapp deployment source config-zip コマンドを実行して、相対<FILE_PATH>にあるアプリケーション パッケージをデプロイします。

    az functionapp deployment source config-zip --src <FILE_PATH> --name <APP_NAME> --resource-group <RESOURCE_GROUP> --build-remote true

    --build-remote trueを実行するには、必ずを設定してください。

  1. コード プロジェクトのルート ディレクトリを含む .zip ファイルを作成します。 詳細については、「 フォルダー構造」を参照してください。

  2. 必要に応じて、Azure アカウントにサインインし、az login コマンドを使用してアクティブなサブスクリプションを選択します。

    az login

  3. az functionapp deployment source config-zip コマンドを実行して、相対<FILE_PATH>にあるアプリケーション パッケージをデプロイします。

    az functionapp deployment source config-zip --src <FILE_PATH> --name <APP_NAME> --resource-group <RESOURCE_GROUP> --build-remote true

    --build-remote trueを実行するには、必ずを設定してください。

  1. ルート プロジェクト フォルダーで、次の Core Tools コマンドを実行して、Go プロジェクトをビルドしてパッケージ化します。

    func pack

    既定では、出力 .zip ファイルの名前はプロジェクト フォルダーと同じです。

  2. 必要に応じて、Azure アカウントにサインインし、 az login コマンドを使用してアクティブなサブスクリプションを選択します。

    az login

  3. az functionapp deployment source config-zip コマンドを実行して、<ZIP_FILE_PATH>にあるパッケージをデプロイします。

    az functionapp deployment source config-zip --resource-group <RESOURCE_GROUP> --name <APP_NAME> --src <ZIP_FILE_PATH>

Maven を使用してアプリを作成してデプロイする

Maven を使用して、 pom.xml ファイルを変更することで、デプロイ時に Flex Consumption でホストされる関数アプリと必要なリソースを作成できます。

  1. 次のいずれかのクイックスタート記事の最初の部分を完了して、Java コード プロジェクトを作成します。

  2. Java コード プロジェクトで、pom.xml ファイルを開き、次の変更を行って Flex Consumption プランで関数アプリを作成します。

    • <properties>.<azure.functions.maven.plugin.version> の値を 1.34.0 に変更します。

    • <plugin>.<configuration> の azure-functions-maven-plugin セクションで、次のように <pricingTier> 要素を追加するか、またはコメント解除します。

      <pricingTier>Flex Consumption</pricingTier>

  3. (省略可能) <plugin>.<configuration> セクションに次の要素も含めることによって、Maven デプロイでの Flex 従量課金プランをカスタマイズします。

    • <instanceSize> - 関数アプリのインスタンス メモリ サイズを設定します。 既定値は 2048 です。
    • <maximumInstances> - 関数アプリの最大インスタンス数として最も大きな値を設定します。
    • <alwaysReadyInstances> - HTTP トリガー グループ ()、Durable Functions グループ (<http>)、その他の特定のトリガー (<durable>) の子要素を使用して<my_function>を設定します。 インスタンス数を 0 より大きく設定すると、関数が実行されるかどうかにかかわらず、これらのインスタンスに対して料金が発生します。 詳細については、「課金」を参照してください。

  4. デプロイする前に、Azure CLIを使用してAzure サブスクリプションにサインインします。

    az login

    az login コマンドで Azure アカウントにサインインします。

  5. 次のコマンドを使用して、Flex 従量課金の新しい関数アプリにコード プロジェクトをデプロイします。

    mvn azure-functions:deploy

    Maven では、pom.xml テンプレートの設定を使用して、Azureの Flex 従量課金プランで、他の必要なリソースと共に関数アプリを作成します。 これらのリソースが既に存在する場合は、コードが関数アプリにデプロイされ、既存のコードが上書きされます。

Go アプリを作成してデプロイする

Go 関数アプリは、Flex 従量課金プランでのみサポートされます。 Go 関数アプリを作成、実行、デプロイするには、 コマンド ラインから Go 関数を作成するを参照してください。 Go 固有のプロジェクト構造とデプロイの詳細については、 Go 開発者向けリファレンスを参照してください。

仮想ネットワーク統合を構成する

Flex 従量課金プランでは、アプリの作成時または後でアプリの 仮想ネットワーク統合 を有効にすることができます。 仮想ネットワーク統合を有効にする前に、Flex Consumption に固有のネットワーク動作とサブネットの要件を確認してください。

Flex Consumption ネットワークのしくみ

Flex Consumption インスタンスでは、アプリを統合するサブネットの一意の IP アドレスが使用されるわけではありません。 代わりに、プラットフォームで管理されるネットワーク ゲートウェイのプール (Flex Consumption インフラストラクチャの内部) では、サブネットの IP アドレスを使用して、そのサブネットに統合されているすべてのアプリが提供されます。 この IP 多重化アーキテクチャは、各インスタンスがサブネットから 1 つの IP アドレスを使用する Premium プランとは根本的に異なります。

アプリごとの 40 個の IP ガイドラインにより、プラットフォーム ゲートウェイ プールとその他のインフラストラクチャ コンポーネントに十分な IP アドレスが確保されますが、適用される制限ではありません。 サブネットのサイズを設定するときは、この最小値を計画しますが、実際の IP 消費量は通常低い点を理解してください。 プラットフォームは、サブネット スケールアウトと統合されたアプリとして、共有ゲートウェイ プールから IP を動的に割り当てます。

サブネットのサイズと要件

Flex Consumption アプリに適したサイズのサブネットを選択します。 次の表に、シナリオに基づくガイダンスを示します。

シナリオ 推奨される CIDR 使用可能な IP Notes
Single Flex アプリ /27 27 1 つのアプリでサポートされる最小サブネット サイズ
1 つのサブネット内の複数の Flex アプリ /26 59 複数のアプリをホストする場合や、大規模なワークロード (1,000 以上のインスタンス) の場合に推奨されます。十分なゲートウェイ容量を提供します

サブネットの委任

  • サブネットを Microsoft.App/environments に委任します。 この委任は、Microsoft.Web/serverFarms を使用する Premium プランと Dedicated プランとは異なります。
  • 登録して、サブスクリプション内の Microsoft.App リソース プロバイダーを登録します。

サブネットの使用制限

  • サブネットはプライベート エンドポイントまたはサービス エンドポイントにまだ使用できません。また、他のホスティング プランやサービスに委任することもできません。
  • Azure Container Apps環境と Flex Consumption アプリの間で同じサブネットを共有することはできません。
  • サブネット名にアンダースコア (_) 文字を含めることはできません。これは、Flex 従量課金プランの現在の制限事項です。

サブネットの共有

  • 同じサブネットを Flex 従量課金プランで実行される複数のアプリと共有できます。 ただし、ネットワーク リソースはすべてのアプリで共有されるため、1 つの関数アプリが同じサブネット上の他のアプリのパフォーマンスに影響を与える可能性があります。 複数のアプリを小さなサブネットにパックする場合は、総需要を考慮してください。
  • サブネットとアプリは同じリージョンに存在する必要があります。

IP の割り当てと計画

  • Flex Consumption アプリでは、各インスタンスに一意の IP アドレスは割り当てられません。 代わりに、ネットワーク ゲートウェイのプールはサブネットの IP アドレスを使用します。 アプリごとに 40 個の IP を予約するガイドラインは、ゲートウェイ プールとその他のインフラストラクチャ コンポーネントに十分な IP アドレスがあることを確認するのに役立ちますが、通常は実際の使用量が少なくなります。
  • IP 多重化により、1 つのアプリで最大 1,000 インスタンスをサポートするには、 /27 サブネット (使用可能な IP が 27 個) で十分です。 複数のアプリまたは大規模なワークロードの場合は、 /26 サブネットを使用して適切なゲートウェイ容量を提供します。
  • 多くのアプリがサブネットを共有し、大量の送信トラフィックで多くのスケールアウトを行うと、IP アドレスが使い果たされるのではなく、送信ネットワークのスループットがボトルネックになる可能性があります。 計画された運用スケールでパフォーマンスを評価します。

アプリの作成時に仮想ネットワーク統合を有効にする

このセクションの例では、アカウントに 仮想ネットワークとサブネットが既に含まれていることを前提としています。

az functionapp create コマンドを実行し、--vnetパラメーターと--subnet パラメーターを含めることで、仮想ネットワーク統合を有効にします。 サブネットは Microsoft.App/environments に委任する必要があり、少なくとも /27 サイズである必要があります。 詳細については、「サブネットの サイズ設定と要件」を参照してください。

  1. 仮想ネットワークとサブネットをまだ作成していない場合は作成します。

  2. 「Flex 従量課金アプリを作成する」の手順 1 から 4 を完了して、アプリで必要なリソースを作成します。

  3. 次の例のように、az functionapp create コマンドを実行し、--vnet および --subnet パラメーターを含めます。

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime go --runtime-version 1.0 --functions-version 4 --vnet <VNET_RESOURCE_ID> --subnet <SUBNET_NAME>
az resource update --resource-group <RESOURCE_GROUP> --resource-type Microsoft.Web/sites --name <APP_NAME> --set properties.siteConfig.http20Enabled=false

    az resource update コマンドは、Go パブリック プレビュー中に必要な関数アプリの HTTP/2 を無効にします。

    az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime <RUNTIME_NAME> --runtime-version <RUNTIME_VERSION> --vnet <VNET_RESOURCE_ID> --subnet <SUBNET_NAME>

    <VNET_RESOURCE_ID> 値は、仮想ネットワークのリソース ID であり、/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Network/virtualNetworks/<VNET_NAME> という形式です。 <RESOURCE_GROUP> コマンドを使用すると、az network vnet list --resource-group <RESOURCE_GROUP> --output tsv --query "[]".id でフィルター処理された仮想ネットワーク ID の一覧を取得できます。

仮想ネットワーク統合を使用して Flex Consumption でアプリを作成する方法のエンド ツー エンドの例については、次のリソースを参照してください。

仮想ネットワーク統合の変更または削除

既存のアプリの仮想ネットワーク統合を追加、変更、または削除できます。

既存の関数アプリへの仮想ネットワーク統合を有効にするには、az functionapp vnet-integration add コマンドを使用します。

az functionapp vnet-integration add --resource-group <RESOURCE_GROUP> --name <APP_NAME> --vnet <VNET_RESOURCE_ID> --subnet <SUBNET_NAME>

アプリで仮想ネットワーク統合を無効にするには、az functionapp vnet-integration remove コマンドを使用します。

az functionapp vnet-integration remove --resource-group <RESOURCE_GROUP> --name <APP_NAME>

アプリの現在の仮想ネットワーク統合を一覧表示するには、az functionapp vnet-integration list コマンドを使用します。

az functionapp vnet-integration list --resource-group <RESOURCE_GROUP> --name <APP_NAME>

Application Insights に関するネットワークの問題のトラブルシューティング

Application Insights は、Flex Consumption アプリで DNS エラー、依存関係のタイムアウト、またはその他の接続の症状が表示されるタイミングを最初に確認する場所です。 実行時にコードが観察した内容 (例外、送信依存関係呼び出し、エンドツーエンドの実行動作) がキャプチャされます。 これは、アプリケーション レベルの障害と、基になるプラットフォームまたはネットワークの問題を区別するのに役立ちます。

次の Application Insights テーブルは、ネットワーク調査に最も役立ちます。

表 表示される内容 次の目的に使用します:
traces ランタイム、ホスト、 ILogger、スケール コントローラーのログ。 Flex Consumption では、デプロイの初期化の詳細もここに表示されます。 ホストの起動に関する問題、コールド スタート動作、展開エラー、ホストまたは依存関係ログを介して発生する DNS エラー。
requests 期間、結果コード、成功を含む HTTP 呼び出しごとに 1 つのエントリ。 待機時間の長い HTTP トリガー、4xx および 5xx エラー、アプリが要求を受信して処理していることを確認します。
exceptions スタック トレースを含むランタイム例外とユーザー例外。 DNS、Azure Storage、Azure Key Vault、モジュールが見つからない、タイムアウト、および同様のランタイム エラーの根本原因調査。
dependencies 送信されるHTTP、SQL、Service Bus、およびその他の依存関係への呼び出し (タイミング情報とエラーコードを含む)。 "ローカルで動作しますが、Flex Consumption で失敗する" 現象と、仮想ネットワーク、DNS、または NAT の動作によって発生する送信呼び出しでの DNS、TLS、または認証エラー。
customMetrics 期間や成功数、失敗数などの集計メトリック。 トレンド分析、成功率の急激な低下、ならびにスケーリングや停止した実行を示す実行時間の急増。
FunctionAppLogs (リソース ログ) Azure Monitor ログに送信されるプラットフォーム レベルの関数アプリ ログ。 Application Insights データが見つからないか不完全な場合、またはコントロール プレーンやホスト レベルの問題 (バインドエラーなど) の場合。
AzureActivity 開始、停止、同期のトリガー、削除、キーの一覧表示などのコントロールプレーン操作。 構成の変更の監査とトリガー登録の問題の診断 (同期トリガーの失敗が一般的です)。

クエリの例

これらのスターター クエリは、Application Insights リソースの ログ エクスペリエンスで使用します。 <APP_NAME> をお使いの関数アプリの名前に置き換えます。

ホストの起動またはデプロイの失敗 (Flex Consumption 固有):

traces
| where timestamp > ago(1d)
| where cloud_RoleName == "<APP_NAME>"
| where message contains "Starting" or message contains "host"
| project timestamp, message, customDimensions
| order by timestamp desc

HTTP トリガーの問題、待機時間、または 5xx エラー:

requests
| where timestamp > ago(1h)
| where cloud_RoleName == "<APP_NAME>"
| project timestamp, name, resultCode, duration, success, url, operation_Name
| order by timestamp desc

DNS、Key Vault、ストレージ、言語ランタイム モジュールなど、種類別にグループ化された一般的な例外:

exceptions
| where timestamp > ago(1d)
| where cloud_RoleName == "<APP_NAME>"
| summarize count() by type, innermostMessage
| order by count_ desc

送信依存関係エラー (DNS、TLS、認証、仮想ネットワーク ルーティング):

dependencies
| where timestamp > ago(2h)
| where cloud_RoleName == "<APP_NAME>"
| where success == false
| project timestamp, target, resultCode, duration, type, data

起動していない HTTP 以外のトリガー (キュー、Blob、または Event Grid トリガー)。 一般的な原因は、トリガーの登録は成功したが、リスナーが有効にしなかったということです。関連する例外は、スケール コントローラー トレースに表示されます。

traces
| where timestamp > ago(2h)
| where message contains "listener" or message contains "trigger"

ネットワーク パフォーマンスのトラブルシューティング

Flex Consumption アプリが推奨サイズよりも小さいサブネットと統合すると、アプリのスケーリングに伴ってパフォーマンスが低下する可能性があります。 この問題は、スケールアウト時に多数のアプリを同じサブネットに統合し、大量の送信トラフィックがある場合にも発生する可能性があります。

小さすぎるサブネットの兆候

これらの現象を監視します。これは、IP アドレスではなく送信容量が制限要因であることを示します。

  • 依存関係への送信呼び出しの待機時間の増加
  • 外部サービスへの接続タイムアウト
  • これらの問題は、突然の停止ではなく、アプリのスケールアップに伴って増加します

重要

スケールアウト自体は、サブネット サイズによってブロックされません。 サブネットが不足している場合でも、アプリはインスタンスを追加し続けます。 パフォーマンスの低下は、ハード スケールの制限ではなく発生します。

監視と軽減

  • 送信依存関係の待機時間メトリックを使用して Application Insights をインストルメント化します。このメトリックは、不足しているサブネットに対して早期の警告シグナルを提供します。
  • サブネット サイズを設定する前に、運用環境のスケールでロード テスト を行い、サブネットのサイズ設定で予想されるワークロードを処理できることを検証します。
  • Azure Monitor で監視: Azure Monitor で 仮想ネットワーク>サブネット に移動し、Azure Resource Graph と KQL クエリを使用して IP 割り当てデータを確認します。
  • 前のセクションのガイダンスに従って、サブネットのサイズを適切に設定します。 /27最小値を強くお勧めします。複数のアプリには/26をお勧めします。

注

十分なプラットフォームの安定性を確保するには、少なくとも /27 サブネットを使用します。 サブネットが /27 よりも大幅に小さい場合、明示的なエラー メッセージなしでゲートウェイの作成の問題が発生する可能性があります。

デプロイの設定を構成する

Flex 従量課金プランでは、Azure Blob Storage コンテナーはアプリのコードと共にデプロイ パッケージを保持します。 既定では、デプロイでは同じストレージ アカウント (AzureWebJobsStorage) と、Functions ランタイムがアプリの保守に使用する接続文字列が使用されます。 DEPLOYMENT_STORAGE_CONNECTION_STRING アプリケーション設定には、接続文字列が格納されます。 ただし、コードのデプロイ ソースとして、別のストレージ アカウント内の BLOB コンテナーを指定できます。 コンテナーへのアクセスに使用する認証方法を変更することもできます。

カスタマイズされたデプロイ ソースは、次の条件を満たしている必要があります。

  • このストレージ アカウントは既に存在している必要があります。
  • デプロイに使用するコンテナーも存在している必要があります。
  • 複数のアプリが同じストレージ アカウントを使用する場合、各アプリには独自のデプロイ コンテナーが必要です。 アプリごとに一意のコンテナーを使用すると、デプロイ パッケージが上書きされなくなります。これは、アプリが同じコンテナーを共有している場合に発生します。

デプロイ ストレージ認証を構成するときは、次の考慮事項に注意してください。

  • セキュリティのベスト プラクティスとして、アプリからAzure Storageに接続するときにマネージド ID を使用します。 詳細については、「接続」を参照してください。
  • 接続文字列を使用してデプロイ ストレージ アカウントに接続するとき、その接続文字列が含まれるアプリケーション設定が既に存在する必要があります。
  • ユーザー割り当てマネージド ID を使用する場合は、指定された ID を関数アプリにリンクします。 また、デプロイ用ストレージ アカウントをスコープとする Storage Blob Data Contributor ロールを ID に割り当てます。
  • システム割り当てマネージド ID を使用する場合は、有効なシステム割り当て ID がまだアプリに存在しない場合に ID を作成します。 システム割り当て ID が存在する場合は、デプロイ ストレージ アカウントをスコープとした Storage Blob Data Contributor ロールを ID に割り当てます。

Flex 従量課金プランの関数アプリを作成するときにデプロイ設定を構成するには:

az functionapp create コマンドを使用し、デプロイ ストレージをカスタマイズする次の追加オプションを指定します。

パラメーター 説明
--deployment-storage-name デプロイ ストレージ アカウントの名前。
--deployment-storage-container-name アプリのデプロイ パッケージが含まれているアカウント内のコンテナーの名前。
--deployment-storage-auth-type デプロイ ストレージ アカウントに接続するために使用する認証の種類。 指定可能な値は StorageAccountConnectionString、UserAssignedIdentity、SystemAssignedIdentity です。
--deployment-storage-auth-value StorageAccountConnectionString を使用する場合は、このパラメーターを、デプロイ ストレージ アカウントへの接続文字列を含むアプリケーション設定の名前に設定します。 UserAssignedIdentity を設定する場合は、このパラメーターに使用する ID のリソース ID 名を設定します。

この例では、別のデプロイ ストレージ アカウントとユーザー割り当て ID を使用して Flex 従量課金プランの関数アプリを作成します。

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --runtime dotnet-isolated --runtime-version 8.0 --flexconsumption-location "<REGION>" --deployment-storage-name <DEPLOYMENT_ACCOUNT_NAME> --deployment-storage-container-name <DEPLOYMENT_CONTAINER_NAME> --deployment-storage-auth-type UserAssignedIdentity --deployment-storage-auth-value <MI_RESOURCE_ID>

また、既存のアプリのデプロイ ストレージ構成を変更することもできます。

az functionapp deployment config set コマンドを使用して、デプロイ ストレージの構成を変更します。

az functionapp deployment config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --deployment-storage-name <DEPLOYMENT_ACCOUNT_NAME> --deployment-storage-container-name <DEPLOYMENT_CONTAINER_NAME>

インスタンス メモリを構成する

アプリの作成時に、Flex Consumption プランのインスタンス メモリ サイズを設定します。 サポートされているサイズの詳細については、「インスタンスの サイズ」を参照してください。

アプリを作成するときに既定とは異なるインスタンス メモリ サイズを設定するには:

--instance-memory コマンドで az functionapp create パラメーターを指定します。 この例では、インスタンス サイズが 4096 の C# アプリを作成します。

az functionapp create --instance-memory 4096 --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime dotnet-isolated --runtime-version 8.0

アプリで使用されるインスタンス メモリ サイズの設定はいつでも変更できます。

この例では、 az functionapp scale config set コマンドを使用して、インスタンスのメモリ サイズ設定を 512 MB に変更します。

az functionapp scale config set --resource-group <resourceGroup> --name <APP_NAME> --instance-memory 512

常時使用可能なインスタンス数を設定する

関数ごとのスケーリング グループまたは個々の関数に対して、常に準備ができている特定の数のインスタンスを設定して、関数を読み込んで実行する準備を整えます。 関数ごとのスケーリングのように、3 つの特殊なグループが存在します。

  • http - アプリ内のすべての HTTP によってトリガーされる関数は、それぞれ独自のインスタンスにスケールされます。
  • durable - アプリ内のすべての Durable によってトリガーされる関数 (オーケストレーション、アクティビティ、エンティティ) は、それぞれ独自のインスタンスにまとめてスケーリングされます。
  • blob - アプリ内のすべての BLOB (Event Grid) によってトリガーされた関数は、それぞれ独自のインスタンスにまとめてスケーリングされます。

http、durable、またはblobを名前と値のペアの設定の名前として使用して、これらのグループの常に使用可能な数を構成します。 アプリ内の他のすべての関数については、 function:<FUNCTION_NAME>=n形式を使用して、各関数に対して常に準備ができている状態を構成します。

1 つ以上の常時対応インスタンス指定を定義するには、--always-ready-instances コマンドで az functionapp create パラメーターを使用します。 この例では、HTTP によってトリガーされるすべての関数の常時使用可能なインスタンス数を 10 に設定します。

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --always-ready-instances http=10

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --runtime go --runtime-version 1.0 --functions-version 4 --flexconsumption-location <REGION> --always-ready-instances http=10
az resource update --resource-group <RESOURCE_GROUP> --resource-type Microsoft.Web/sites --name <APP_NAME> --set properties.siteConfig.http20Enabled=false

az resource update コマンドは、Go パブリック プレビュー中に必要な関数アプリの HTTP/2 を無効にします。

この例では、すべての Durable トリガー関数の常時使用可能なインスタンス数を 3 に設定し、2 という名前の Service Bus によってトリガーされる関数の常時使用可能なインスタンス数を function5 に設定します。

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --always-ready-instances durable=3 function:function5=2

次の例では、2 という名前のService Busトリガーされた関数に対して、always ready インスタンス数を function5 に設定します。

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --runtime go --runtime-version 1.0 --functions-version 4 --flexconsumption-location <REGION> --always-ready-instances function:function5=2
az resource update --resource-group <RESOURCE_GROUP> --resource-type Microsoft.Web/sites --name <APP_NAME> --set properties.siteConfig.http20Enabled=false

az resource update コマンドは、Go パブリック プレビュー中に必要な関数アプリの HTTP/2 を無効にします。

また、インスタンス指定を追加または削除するか、既存のインスタンス指定数を変更することによって、既存のアプリで常時使用可能なインスタンスを変更することもできます。

この例では、az functionapp scale config always-ready set コマンドを使用して、HTTP トリガー グループの常時使用可能なインスタンス数を 10 に変更します。

az functionapp scale config always-ready set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --settings http=10

常時使用可能なインスタンスを削除するには、HTTP トリガー グループと az functionapp scale config always-ready delete という名前の関数の両方からすべての常時使用可能なインスタンスを削除する次の例のように、hello_world コマンドを使用します。

az functionapp scale config always-ready delete --resource-group <RESOURCE_GROUP> --name <APP_NAME> --setting-names http function:hello_world

HTTP コンカレンシーの制限を設定する

特定の制限を設定しない場合、システムはインスタンス サイズの設定に基づいて Flex Consumption プラン アプリの HTTP コンカレンシーの既定値を決定します。 詳細については、HTTP トリガーのコンカレンシーに関するページを参照してください。

既存のアプリの HTTP コンカレンシー制限を設定する方法を次に示します。

インスタンス サイズには関係なく、アプリの特定の HTTP コンカレンシーの制限を設定するには、az functionapp scale config set コマンドを使用します。

az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --trigger-type http --trigger-settings perInstanceConcurrency=10

この例では、HTTP トリガーのコンカレンシー レベルを 10 に設定します。 HTTP コンカレンシー値を設定すると、アプリのインスタンス サイズ設定が変更されたにもかかわらず、アプリはその値を維持します。

サイトの更新戦略を設定する

Flex Consumption プランでは、関数アプリによるコードのデプロイと構成の変更の処理方法を制御する 2 つの異なるサイト更新戦略が一意にサポートされています。 既定では、Flex 従量課金プラン アプリは、デプロイ中に現在実行中の関数を終了する Recreate 戦略を使用します。 ダウンタイムなしのデプロイを有効にするには、代わりに RollingUpdate 戦略を構成します。 詳細については、「 Flex Consumption のサイト更新戦略」を参照してください。

注

サイト更新戦略の構成は現在パブリック プレビュー段階であり、Bicep または ARM テンプレートでのみ使用できます。 Azure CLI、Azure ポータル、またはVisual Studio Codeを使用して、この設定を構成することはできません。

Azure CLIは現在、サイト更新戦略の構成をサポートしていません。 「サイト更新戦略の構成」の説明に従って、Bicep または ARM テンプレートを使用します。

エンドツーエンドのTLS暗号化を設定

エンドツーエンド(E2E)TLS暗号化は、Azureプラットフォームのフロントエンドと関数を動かすワーカー間の通信を暗号化します。 この機能は現在、Flex Consumptionプランの機能アプリ向けにプレビューされています。

endToEndEncryptionEnabledサイトプロパティをARMまたはBicepテンプレートでtrue設定することでE2E TLS暗号化を有効にしてください。

E2E TLS暗号化がトラフィックをどのように保護するかの詳細については、「Azure App ServiceのエンドツーエンドTLS暗号化」をご覧ください。

サイト レベルの証明書を構成する

Flex Consumption では、サイト スコープの証明書が導入されています。これは、TLS/SSL 証明書が、同じ Web スペース内のアプリ間で共有されるのではなく、個々の関数アプリにスコープが設定される新しいモデルです。 次の表に、サポートされている証明書の種類と、それぞれの証明書を関数アプリに追加する方法を示します。

証明書タイプ 追加する方法 次の値にカウントされます
App Service マネージド証明書 カスタム ドメインのポータルで作成 プライベート証明書の制限
App Service 証明書 Azureを通じて購入した後、インポート プライベート証明書の制限
Key Vault からインポートされた証明書 Azure Key Vaultからインポート プライベート証明書の制限
アップロードされたプライベート証明書 (.pfx) PFX ファイルとしてアップロード プライベート証明書の制限
アップロードされたパブリック証明書 (.cer) CER ファイルとしてアップロード パブリック証明書の制限

サイト単位の証明書に関する考慮事項

  • Flex 従量課金プランで実行されているアプリでサイト スコープの証明書を使用するためのサポートは、現在プレビュー段階です。
  • この機能が使用できるようになる前に作成された既存のアプリには、現在、証明書の移行パスがありません。 サイト スコープ証明書を使用するには、新しい Flex Consumption 関数アプリを作成してください。
  • Azure CLI では、サイト スコープ証明書を管理する機能はまだサポートされていません。 それまでの間は、Azure ポータル または ARM/Bicep テンプレート を使用して証明書を管理します。
  • 各アプリでは、最大 3 つのプライベート証明書と 3 つのパブリック証明書がサポートされています。
  • プライベート証明書は、証明書チェーン内のすべての中間証明書とルート証明書を含む パスワードで保護された PFX ファイル としてエクスポートする必要があります。
  • 楕円曲線暗号 (ECC) 証明書は、PFX としてアップロードするときにサポートされます。
  • Flex Consumption は Linux 上で実行されるため、コードでは、Windows証明書ストアからではなく、ファイル パスから証明書を読み込む必要があります。 まず、「コードから証明書に アクセス できるようにする」の手順に従って、ランタイム環境に証明書を読み込みます。 次に、アプリケーション コードから証明書ファイルを読み取る方法については、「 Linux/Windows コンテナーでの証明書の読み込みを参照してください。

証明書を追加する

証明書の種類に応じて、いくつかの方法で証明書をアプリに追加できます。 無料のマネージド証明書とAzure証明書をポータルに直接追加します。

次のいずれかのタブを選択して、マネージド、プライベート (.pfx)、パブリック (.cer)、またはKey Vaultマネージド証明書を追加する方法を確認します。

カスタム ドメインの無料のマネージド証明書を作成してバインドするには:

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

  2. 左側のメニューで、[ 設定] を 展開し、[ カスタム ドメイン] を選択します。

  3. [カスタム ドメインの追加] を選択します。

  4. [ TLS/SSL 証明書] で、[ App Service マネージド証明書] を選択します。

  5. [ TLS/SSL の種類] で、[ SNI SSL] を選択します。

  6. ドメインの検証を完了し、[ 追加] を選択します。

    マネージド証明書が自動的に作成され、カスタム ドメインにバインドされます。 証明書が発行されるまでに最大 10 分かかる場合があります。

コードから証明書にアクセスできるようにする

証明書を追加した後、関数コードから明示的にアクセスできるようにする必要があります。

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

  2. 左側のメニューで、[ 設定] を 展開し、[証明書] を選択 します。

  3. [ Bring your own certificates (.pfx)] または [ 公開キー証明書 (.cer)] を選択します。

  4. アクセス可能にする証明書の横にある [... ] (省略記号) を選択し、[ アプリ コードからアクセスできるようにする] を選択します。

アクセシビリティ対応のアプリ コードを有効にすると、プラットフォームはすべてのインスタンスのランタイム環境にファイルとして証明書を読み込みます。

証明書ファイルは拇印によって名前が付けられ、次のディレクトリに配置されます。

証明書タイプ Path
パブリック証明書 (.cer) /var/ssl/certs
プライベート証明書 (.pfx) /var/ssl/private

証明書を更新または再発行する

無料のマネージド証明書は、プラットフォームによって自動的に更新されます。 他のすべての証明書について、期限切れの証明書を更新する方法は、証明書のソースによって異なります。

  • Key Vault からインポートされた証明書: Key Vault で証明書を更新すると、プラットフォームのバックグラウンド ジョブによって、更新された証明書が 24 時間以内に関数アプリに自動的に同期されます。 新しい証明書バージョンは、手動の手順なしですべてのインスタンスに読み込まれます。

  • アップロードされた証明書: 新しい証明書をアップロードし、アプリ コードからアクセスできるようにします。 コードが拇印によって証明書を参照する場合は、コードまたはアプリの設定で拇印参照を更新します。

現在サポートされているリージョンを表示する

Flex 従量課金プランを現在サポートしているリージョンの一覧を表示するには、次を参照してください。

  1. まだ Azure にサインインしていない場合は、Azure にサインインします。

    az login

    az login コマンドで Azure アカウントにサインインします。

  2. az functionapp list-flexconsumption-locations コマンドを使用して、現在 Flex Consumption をサポートしているリージョンの一覧をアルファベット順で確認します。

    az functionapp list-flexconsumption-locations --query "sort_by(@, &name)[].{Region:name}" -o table

Azure ポータルまたは Visual Studio Code を使用してアプリを作成すると、リージョンの一覧には現在サポートされていないリージョンが除外されます。

Azure でアプリを監視する

Azure Monitor には、Azure での関数アプリの実行方法をより深く理解するのに役立つ、次の個別のメトリック セットが用意されています。

  • プラットフォーム メトリック: インフラストラクチャ レベルの分析情報を提供する
  • Application Insights: トレースやエラー ログなど、コード レベルの分析情報を提供します。

アプリで Application Insights を有効にすると、次のことができます。

  • 詳細な実行時間と依存関係を追跡する
  • 個々の関数のパフォーマンスを監視する
  • エラーと例外を分析する
  • カスタム クエリを使用してプラットフォーム メトリックとアプリケーションの動作を関連付ける

詳しくは、「Azure Functions を監視する」をご覧ください。

サポートされているメトリック

このスクリプトを実行して、アプリで現在使用可能なすべてのプラットフォーム メトリックを表示します。

appId=$(az functionapp show --name <APP_NAME> --resource-group <RESOURCE_GROUP> --query id -o tsv)
az monitor metrics list-definitions --resource $appId --query "[].{Name:name.localizedValue,Value:name.value}" -o table

この例では、 <RESOURCE_GROUP> と <APP_NAME> をリソース グループと関数アプリの名前に置き換えます。 このスクリプトは、完全修飾アプリ ID を取得し、テーブル内の使用可能なプラットフォーム メトリックを返します。

メトリックを表示する

現在のメトリックは、Azure portal または Azure CLI を使用して確認できます。

Azure portal では、メトリック アラートを作成し、グラフやその他のレポートをポータルのダッシュボードにピン留めすることもできます。

このスクリプトを使用して、アプリの現在のメトリックのレポートを生成します。

appId=$(az functionapp show --name <APP_NAME> --resource-group <RESOURCE_GROUP> --query id -o tsv)

echo -e "\nAlways-ready and on-demand execution counts..."
az monitor metrics list --resource $appId --metric "AlwaysReadyFunctionExecutionCount" --interval PT1H --output table
az monitor metrics list --resource $appId --metric "OnDemandFunctionExecutionCount" --interval PT1H --output table

echo -e "\nExecution units (MB-ms) in always-ready and on-demand execution counts..."
az monitor metrics list --resource $appId --metric "AlwaysReadyFunctionExecutionUnits" --interval PT1H --output table
az monitor metrics list --resource $appId --metric "OnDemandFunctionExecutionUnits" --interval PT1H --output table

echo -e "\nAlways-ready resource utilization..."
az monitor metrics list --resource $appId --metric "AlwaysReadyUnits" --interval PT1H --output table

echo -e "\nMemory utilization..."
az monitor metrics list --resource $appId --metric "AverageMemoryWorkingSet" --interval PT1H --output table
az monitor metrics list --resource $appId --metric "MemoryWorkingSet" --interval PT1H --output table

echo -e "\nInstance count and CPU utilization..."
az monitor metrics list --resource $appId --metric "InstanceCount" --interval PT1H --output table
az monitor metrics list --resource $appId --metric "CpuPercentage" --interval PT1H --output table

Azure Functions のメトリックの詳細については、「Azure Functions の監視」を参照してください。

ログを表示する

アプリを Application Insights に接続すると、実行中にアプリのパフォーマンスを分析し、問題のトラブルシューティングを行うことができます。 アプリの Application Insights リソースで、次の手順を実行します。

  • パフォーマンスを使用して応答時間と依存関係を分析します。
  • 移行後に発生したエラーを特定するには、 Failures を使用します。
  • 関数の動作を分析するためのカスタム クエリを ログ に作成します。

たとえば、次のクエリを使用して、インスタンスごとの成功率を比較します。

このクエリを使用して、成功率をインスタンス別に比較します。

requests
| where timestamp > ago(7d)
| summarize successCount=countif(success == true), failureCount=countif(success == false) by bin(timestamp, 1h), cloud_RoleName
| render timechart

このクエリを使用して、関数をアクティブに処理しているインスタンスの数を分析します。

let _startTime = ago(20m); //Adjust start time as needed
let _endTime = now(); //Adjust end time as needed
let bins = 1s; //Adjust bin as needed - this will give per second results
requests
| where operation_Name == 'EventHubsTrigger' //Replace with the name of the function in the function app that you are analyzing
| where timestamp between(_startTime .. _endTime)
| make-series dcount(cloud_RoleInstance) default=0 on timestamp from _startTime to _endTime step bins
| render columnchart

コストを表示する

パフォーマンスと運用コストを調整するようにアプリを調整できるため、Flex 従量課金プランでのアプリの実行に関連するコストを追跡することが重要です。

現在のコストを表示するには:

  1. Azure portal の関数アプリ ページで、リソース グループのリンクを選択します。

  2. リソース グループ ページで、 コスト管理>コスト分析を選択します。

  3. アプリ自体の現在のコストとコストの軌道を確認します。

  4. 必要に応じて、[ Cost Management>Alerts ] を選択し、[ + 追加] を選択して、アプリの新しいアラートを作成します。

アプリを微調整する

Flex Consumption プランには、アプリのパフォーマンスを調整するために調整できるいくつかの設定が用意されています。 実際のパフォーマンスとコストは、アプリ固有のワークロード パターンと構成によって異なる場合があります。 たとえば、 メモリ インスタンスのサイズ を大きくすると、メモリを集中的に使用する操作のパフォーマンスが向上しますが、アクティブな期間あたりのコストは高くなります。

パフォーマンスとコストを微調整するために行うことができるいくつかの調整を次に示します。

関連コンテンツ

  • Last updated on