Azure Functionsは、既存のAzure App Service アプリケーション プラットフォームを拡張するイベント ドリブンのコンピューティング オンデマンド サービスです。 Azure、パートナー サービス、オンプレミス システムで発生するイベントによってトリガーされるコードを実装する機能が追加されています。 Functions を使用すると、データ ソースまたはメッセージング ソリューションに接続するソリューションを構築できます。これにより、イベントの処理と対応が容易になります。 関数は、多くの統合コンポーネントと複雑なAzureデータ センターで実行されます。 ホストされているクラウド環境では、VM が再起動または移動する場合があり、システムのアップグレードが行われることが予想されます。 また、関数アプリは、外部 API、Azure サービス、およびその他のデータベースに依存している可能性があり、定期的に信頼性が低下する可能性もあります。
この記事では、クラウドベースの環境で正常な状態を維持し、パフォーマンスが高い効率的な関数アプリを、設計してデプロイするためのベスト プラクティスについて説明します。
適切なホスティング プランを選択する
Azureで関数アプリを作成するときは、アプリのホスティング プランを選択する必要があります。 選択したプランは、パフォーマンス、信頼性、コストに影響します。 Azure Functionsでは、次のホスティング プランが提供されます。
可能であれば、 Flex 従量課金プラン を使用して、動的スケール アプリをホストします。
App Service プラットフォームのコンテキストでは、関数を動的にホストする Premium プランは Elastic Premium プラン (EP) です。 その他の専用 (App Service) プランは Premium と呼ばれます。 詳細については、「Azure Functions Premium プランを参照してください。
選択するホスティング プランによって、次の動作が決まります。
- 関数アプリが需要に基づいてスケーリングする方法と、インスタンスの割り当てが管理される方法。
- 各 Function App インスタンスに利用できるリソース
- Azure Virtual Network接続などの高度な機能のサポート。
適切なホスティング プランの選択とプラン間の詳細な比較の詳細については、「Azure Functions ホスティング オプションを参照してください。
関数アプリを作成するときに、適切なプランを選択します。 Functions では、ホスティング プランを切り替える機能 (主に、従量課金とエラスティック Premium プランの間) が制限されています。 詳細については、「プランの移行」を参照してください。
ストレージを正しく構成する
Functions では、ストレージ アカウントが関数アプリと関連付けられている必要があります。 Functions ホストは、トリガーの管理や関数の実行のログ記録などの操作にストレージ アカウント接続を使用します。 関数アプリを動的にスケーリングするときにも使用されます。 詳細については、「Azure Functions の
関数アプリでファイル システムまたはストレージ アカウントが正しく構成されていないと、関数のパフォーマンスと可用性に影響する可能性があります。 正しく構成されていないストレージ アカウントのトラブルシューティングについては、ストレージのトラブルシューティングに関する記事を参照してください。
ストレージの接続の設定
動的にスケーリングする関数アプリは、ストレージ アカウント内のAzure Files エンドポイントから、またはスケールアウトされたインスタンスに関連付けられているファイル サーバーから実行できます。 この動作は、次のアプリケーション設定によって制御されます。
これらの設定は、Premium プランと従量課金プランWindowsサポートされています。 Flex 従量課金プランでは、これらの設定は必要なく、Blob Storage コンテナーを使用して、Azure Files共有ではなくデプロイ パッケージをホストします。
Azure ポータルで、またはAzure CLIまたはAzure PowerShellを使用して関数アプリを作成する場合は、必要に応じて関数アプリのこれらの設定を作成します。 Azure Resource Manager テンプレート (ARM テンプレート) からリソースを作成する場合は、テンプレートに WEBSITE_CONTENTAZUREFILECONNECTIONSTRING も含める必要があります。
ARM テンプレートを使用して初めてデプロイするときは、WEBSITE_CONTENTSHARE を含めないでください。自動的に生成されます。
次の ARM テンプレートの例を使用すると、これらの設定を正しく構成できます。
重要
Azure Files サービスは現在、ID ベースの接続をサポートしていません。 Flex 従量課金プランでは、マネージド ID が完全にサポートされています。 詳細については、「
ストレージアカウントの構成
関数アプリを作成する場合は、BLOB、Queue、Table Storage をサポートする汎用Azure Storage アカウントを作成またはリンクする必要があります。 関数は、トリガーの管理や関数の実行のログ記録などの操作にAzure Storageに依存します。 関数アプリのストレージ アカウントの接続文字列は、AzureWebJobsStorageおよびWEBSITE_CONTENTAZUREFILECONNECTIONSTRINGのアプリケーション設定にあります。
このストレージ アカウントを作成するときは、次の点に注意してください。
待機時間を短縮するには、ストレージ アカウントは関数アプリと同じリージョンに作成します。
運用環境でのパフォーマンスを向上させるには、関数アプリごとに個別のストレージ アカウントを使用します。 この側面は、Durable Functionsおよび Event Hubs によってトリガーされる関数では特に当てはまります。
Event Hubs によってトリガーされる関数の場合は、Data Lake Storage が有効になっているアカウント使用しないでください。
大きなデータ セットの処理
Linux で実行する場合は、ファイル共有をマウントすることで、ストレージをさらに追加できます。 共有のマウントは、関数で大規模な既存のデータ セットを処理するのに便利な方法です。 詳細については、「ファイル共有をマウントする」を参照してください。
関数を整理する
ソリューションの一部として、複数の関数を開発して公開することがあります。 このような関数は、多くの場合、1 つの関数アプリに結合されますが、別々の関数アプリ内で実行することもできます。 Premium および専用 (App Service) ホスティング プランでは、同じプランで実行することにより、複数の関数アプリで同じリソースを共有することもできます。 関数と関数アプリをグループ化する方法は、ソリューション全体のパフォーマンス、スケーリング、構成、デプロイ、セキュリティに影響を与える可能性があります。
従量課金と Premium プランでは、関数アプリ内のすべての関数がまとめて動的にスケーリングされます。
関数を整理する方法の詳細については、「関数編成のベスト プラクティス」を参照してください。
デプロイを最適化する
関数アプリをデプロイするときは、Azureの関数のデプロイの単位が関数アプリであることを覚えておいてください。 関数アプリ内のすべての関数は、通常は同じデプロイ パッケージから同時にデプロイします。
デプロイを成功させるには、次のオプションを検討してください。
デプロイ パッケージから関数を実行します。 このようなパッケージから実行する方法には、次の利点があります。
- ファイル コピーのロックに関する問題のリスクを軽減します。
- 運用アプリに直接デプロイでき、再起動はトリガーされません。
- パッケージ内のすべてのファイルをアプリで使用できます。
- ARM テンプレートのデプロイのパフォーマンスが向上します。
- コールド スタート時間が短縮される場合があります。特に、npm パッケージ ツリーが大きい JavaScript 関数の場合です。
継続的配置を使用して、デプロイをソース管理ソリューションに接続することを検討します。 継続的配置を使用すると、デプロイ パッケージから実行することもできます。
Premium プランのホスティングの場合は、ウォームアップ トリガーを追加して、新しいインスタンスが追加されるときの待機時間を短縮することを検討します。 詳細については、「Azure Functionsウォームアップ トリガーを参照してください。
デプロイのダウンタイムを最小限に抑えるには、従量課金プラン、Premium プラン、専用プランのデプロイ スロットを使用します。 または、Flex 従量課金プランでダウンタイムなしのデプロイ用にローリング 更新プログラムを構成します。 詳細については、「Azure Functions のデプロイ スロット」と「Flex Consumption におけるサイト更新戦略」を参照してください。
堅牢な関数を記述する
関数の一般的なパフォーマンスと可用性に役立つ設計原則に従います。 これらの原則は次のとおりです。
一時的な障害はクラウド コンピューティングで一般的であるため、クラウドベースのリソースにアクセスするときは 再試行パターン を使用します。 多くのトリガーとバインドには、再試行が既に実装されています。
完全なアプリケーションとビルド自動化パイプラインのコンテキストで関数を継続的にテストすることで、統合テストに優先順位を付けます。
セキュリティ向けの設計
機能の準備が整った後ではなく、計画段階でセキュリティを検討してください。 詳細については、「Securing Azure Functions」を参照してください。
コンカレンシーを検討する
着信イベントにより関数アプリへの需要が増大すると、従量課金プランと Premium プランが関数アプリをスケールアウトします。 関数アプリが読み込みに応答する方法と、受信イベントを処理するようにトリガーを構成する方法を理解することが重要です。 一般的な概要については、
専用 (App Service) プランでは、関数アプリのスケーリングを提供する必要があります。
ワーカー プロセスの数
場合によっては、スケールアウトする前に、インスタンスに言語ワーカー プロセスと呼ばれる複数のプロセスを作成することで、負荷を処理する方が効率的です。 FUNCTIONS_WORKER_PROCESS_COUNT 設定では、許可される言語ワーカー プロセスの最大数を制御します。 この設定の既定値は 1 で、複数のプロセスが使用されないことを意味します。 プロセスの最大数に達すると、関数アプリは負荷を処理するために、より多くのインスタンスにスケールアウトします。 この設定は、ホスト プロセスで実行される C# クラス ライブラリ関数には適用されません。
Premium プランまたは専用 (App Service) プランで FUNCTIONS_WORKER_PROCESS_COUNT を使用する場合は、プランによって提供されるコアの数を検討してください。 たとえば、Premium プラン EP2 では 2 つのコアが提供されるので、値 2 から開始し、必要に応じて最大値になるまで 2 つずつ増やす必要があります。
トリガーの構成
スループットとスケーリングを計画する場合は、さまざまな種類のトリガーでイベントがどのように処理されるかを理解します。 一部のトリガーでは、バッチ処理の動作とコンカレンシーを制御できます。 これらの値を調整すると、呼び出された関数の要求に合わせて各インスタンスを適切にスケーリングできます。 これらの構成オプションは、関数アプリ内のすべてのトリガーに適用し、アプリの host.json ファイルに保持します。 設定の詳細については、特定のトリガー リファレンスの「構成」セクションを参照してください。
Functions がメッセージ ストリームを処理する方法の詳細については、「Azure Functions信頼性の高いイベント処理を参照してください。
接続を計画する
接続の制限は、 従量課金プランで実行されている関数アプリに適用されます。 これらの制限は各インスタンスに適用されます。 これらの制限と一般的なベスト プラクティスとして、関数コードからの送信接続を最適化します。 詳細については、「manage connections in Azure Functions」を参照してください。
言語固有の考慮事項
選択した言語については、次の点に注意してください。
可用性を最大にする
サーバーレス アーキテクチャでは、コールド スタートが重要な考慮事項です。 詳細については、「 コールド スタート」を参照してください。 コールド スタートがシナリオに問題がある場合は、「 サーバーレスコールド スタートについて」を参照してください。
動的スケールを維持しながらコールド スタートを減らすには、Flex Consumption プランと Premium プランの両方をお勧めします。 コールド スタートを減らし、すべてのホスティング プランの可用性を向上させるには、次のガイダンスを使用します。
| プラン | ガイダンス |
|---|---|
| Flex 従量課金プラン | • 常に準備が整ったインスタンスを使用してインスタンスを実行し続ける • 常に準備ができているインスタンス数を設定する |
| Premium プラン | • 関数アプリでウォームアップ トリガーを実装します • 常時使用可能なインスタンス数と最大バースト制限の値を設定します • 仮想ネットワークで HTTP 以外のトリガーを使用する場合は、仮想ネットワーク トリガーのサポートを使用します |
| Dedicated プラン | • Azure App Service正常性チェックが有効になっている少なくとも 2 つのインスタンスで実行 • 自動スケーリングを実装します |
| 従量課金プラン | • バインドとトリガーについてシングルトン パターンとコンカレンシー設定の使用を確認し、関数アプリのスケーリング方法に人為的な制限を設けないようにします。 • スケールアウトを制限する可能性のある functionAppScaleLimit の設定を確認します• 開発とテストの間に設定された日ごとの使用量クォータ (GB 秒) の上限を確認します。 運用環境では、この制限を削除することを検討します。 |
効率的に監視する
Azure Functionsには、Azure アプリケーション Insights との組み込みの統合が用意されており、コードから書き込まれた関数の実行とトレースを監視できます。 詳細については、「Monitor executions in Azure Functions」を参照してください。 Azure Monitorには、関数アプリ自体の正常性を監視するための機能も用意されています。 詳細については、「Monitor Azure Functions」を参照してください。
Application Insights 統合を使用して関数を監視する場合は、次の考慮事項に注意してください。
AzureWebJobsDashboard アプリケーション設定を削除します。 この設定は、以前のバージョンの Functions でサポートされていました。
AzureWebJobsDashboardを削除すると、関数のパフォーマンスが向上します。Application Insights のログを確認します。 検出しようとしているデータが見つからない場合は、サンプリング設定を調整し、監視シナリオをより適切にキャプチャすることを検討します。
excludedTypes設定を使用して、RequestやExceptionなど、特定の種類をサンプリングから除外します。 詳しくは、「サンプリングを構成する」をご覧ください。
Azure Functions では、システム生成ログやユーザー生成ログを Azure Monitor のログに送信することもできます。 Azure Monitor ログとの統合は現在プレビュー段階です。
冗長性があるように構築する
ビジネス ニーズによっては、データ センターの停止中でも、関数を常に使用できるようにすることが必要になる場合があります。 多地域的アプローチを使用して重要な関数を常に実行し続ける方法については、「reliability in Azure Functions」を参照してください。