Azure Functions は、明示的なインフラストラクチャのプロビジョニングや管理を行わずに、小さなコード ブロック (functions を実行するイベントドリブン コンピューティング サービスです。 関数は、HTTP 要求、タイマー、キュー メッセージ、その他のAzure サービスの変更などのイベントに応答できます。 この機能により、Functions はデータ処理、システム統合、バックグラウンド タスクに適しています。
Azureを使用する場合、信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの障害、リージョン全体の障害など、さまざまな潜在的な障害や問題に対する回復性を関数に提供する方法について説明します。 また、Functions サービス レベル アグリーメント (SLA) に関する重要な情報も強調表示されています。
運用環境のデプロイに関する推奨事項
Azure Well-Architected Framework は、信頼性、セキュリティ、コスト、運用、パフォーマンスに関する推奨事項を提供します。 これらの領域が相互にどのように影響し、信頼性の高い Functions ソリューションに貢献するかについては、「 Functions のアーキテクチャのベスト プラクティス」を参照してください。
信頼性アーキテクチャの概要
Functions をデプロイするときは、次の概念を理解することが重要です。
ホスティング プラン: プランは、関数アプリのホスティング環境を表します。 プランによって、使用可能なコンピューティング リソース、価格モデル、スケーリング動作が決まります。
ストレージ アカウント: 関数アプリを作成するときは、ホスト ストレージ アカウントを指定する必要があります。 ストレージ アカウントは、関数コードストレージ、ログ記録、コンカレンシー管理 (特定のトリガーの種類の BLOB リースなど) など、関数アプリの内部操作の側面を管理します。
デプロイにはストレージ アカウントを使用することもできます。 このストレージ アカウントは、ホスト ストレージ アカウントまたは別のストレージ アカウントと同じ場合があります。
Important
ストレージ アカウントは、Functions の信頼性アーキテクチャの重要な部分です。 関数アプリの回復性の要件を満たすように構成します。
トリガーとバインド: トリガーとバインドを使用すると、関数はイベントに応答し、他のサービスからデータを受信し、他のサービスにデータを書き込みます。
永続的な関数: Durable Functions は Functions の機能です。 実行時間の長いオーケストレーションやステートフル エンティティなどのステートフル関数が提供されます。
永続関数を使用する場合は、状態を格納する ストレージ プロバイダー を構成します。 選択した状態ストアの信頼性特性を評価し、回復性の要件を満たすように構成します。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
関数アプリで一時的な障害を処理する場合は、次の推奨事項を検討してください。
トリガーとバインド: Functions プラットフォームには、トリガーとバインドに対する一時的な障害処理が組み込まれています。 サポートされているトリガーの起動中に一時的な障害が発生した場合、またはサポートされているバインディングがデータの読み取りまたは書き込みを行うときに、プラットフォームは自動的に操作を再試行できます。 この組み込みの再試行動作により、一時的な接続の問題やサービスの中断があっても、関数の実行が妨げられることはありません。 詳細については、「 関数のエラー処理と再試行」を参照してください。
この保護では、一時的な障害のみが対象となります。 プラットフォームは、正しく構成されていない接続文字列や削除されたリソースなど、永続的なエラーを再試行しません。
プラットフォームは、永続的な障害と繰り返される一時的な障害をエラーとして扱います。 関数の実行エラーに関する情報をキャプチャするようにログ記録を構成します。 詳細については、「 関数の監視の構成」を参照してください。
関数コード: 関数コードでは、関数が外部サービスを呼び出すときの一時的なエラーを処理する必要があります。 関数コードで行われる外部サービス呼び出しに応じて、再試行ロジック、タイムアウト、およびサーキット ブレーカー パターンを実装します。 可能な限り、再試行によって重複する副作用が発生しないように関数をべき等に設計します。
クライアント： HTTP 接続など、関数に同期的に接続するクライアント アプリケーションは、一時的な障害に対する回復性が必要です。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
従量課金プランでは、可用性ゾーンはサポートされていません。 ワークロードにゾーン冗長性が必要な場合は、代わりに Flex Consumption、Premium、または Dedicated (Azure App Service) プランの使用を検討してください。
Flex Consumption プランでは、ゾーン冗長デプロイがサポートされます。
Premium プランでは、ゾーン冗長デプロイがサポートされます。
ゾーン冗長が有効になっている場合、プラットフォームは選択したリージョン内のすべての可用性ゾーンにプラン インスタンスを自動的に分散します。 リージョン内の可用性ゾーンに問題がある場合は、正常なゾーンのインスタンスを使用して関数が引き続き実行されます。
ホスト ストレージ アカウントでゾーン冗長ストレージ (ZRS) を有効にする必要があります。これにより、ゾーンの停止に対する回復性も確保されます。
この図は、3 つの可用性ゾーンを示しています。 各ゾーンには、Functions インスタンスが含まれています。 ZRS アカウントは、3 つの可用性ゾーンすべてにまたがっています。
専用 (App Service) プランでは、ゾーン冗長デプロイがサポートされます。 ゾーンの冗長性が有効になっている場合、プラットフォームは選択したリージョン内のすべての可用性ゾーンにインスタンスを自動的に分散します。 プランでゾーン冗長を構成します。 Azure App Service がゾーン冗長性を処理する方法の詳細については、「Reliability in App Service」を参照してください。
ゾーン冗長を有効にしない場合、プランは 非ゾーン または リージョン です。 プラットフォームは、リージョン内または同じゾーン内の任意の可用性ゾーンにプラン インスタンスを配置できます。 プラン インスタンスは、可用性ゾーンの障害に対応できません。 リージョン内の任意のゾーンで障害が発生すると、プランにダウンタイムが生じる可能性があります。
必要条件
- リージョンのサポート: ゾーン冗長 Flex Consumption プランは、特定のリージョン セットにデプロイできます。 Azure CLI を使用して、サポートされているリージョンの現在の一覧を取得できます。 詳細については、「 可用性ゾーンをサポートするリージョンを表示する」を参照してください。
リージョンのサポート: ゾーン冗長 Premium プランは、次のリージョンにデプロイできます。
南北アメリカ ヨーロッパ 中東 Africa アジア太平洋 ブラジル南部 フランス中部 イスラエル中部 南アフリカ北部 オーストラリア東部 カナダ中部 ドイツ中西部 カタール中部 インド中部 米国中部 イタリア北部 アラブ首長国連邦北部 中国北部 3 米国東部 北ヨーロッパ 東アジア 米国東部 2 ノルウェー東部 東日本 米国中南部 スウェーデン中部 東南アジア 米国西部 2 スイス北部 米国西部 3 英国南部 西ヨーロッパ Operating systems: プラットフォームでは、ゾーン冗長Windowsおよび Linux プランのデプロイがサポートされています。
最小インスタンス数: Premium プランのゾーン冗長性には、少なくとも 2 つの常時対応インスタンスが必要です。
- ホスト ストレージ アカウント:ZRS を使用するには、関数アプリの既定のホスト ストレージ アカウントを構成する必要があります。 ZRS 用に構成されていないホスト ストレージ アカウントを使用すると、ゾーンの停止中にアプリが予期せず動作する可能性があります。
- デプロイ コンテナー ストレージ アカウント: アプリのデプロイ コンテナーに別のストレージ アカウントを使用する場合は、ゾーン冗長に更新します。
考慮事項
実行時間以外の動作: ゾーン冗長では、デプロイされたアプリケーションの継続的なアップタイムのみが保証されます。 可用性ゾーンの停止は、アプリケーションが引き続きトラフィックを処理する場合でも、Functions の側面に影響を与える可能性があります。 これらの動作には、プランのスケーリング、アプリケーションの作成、アプリケーション構成、アプリケーションの発行が含まれます。
ゾーン間でのインスタンスの分散
Flex Consumption プラン アプリをゾーン冗長として構成すると、プラットフォームは選択したリージョン内の複数のゾーンにプラン インスタンスを自動的に分散し、常時対応インスタンスとオンデマンド インスタンスに対して異なるルールを使用します。
Always-ready インスタンスは、 ラウンドロビン分散を使用して、少なくとも 2 つのゾーンに分散されます。
ゾーンの回復性を確保するために、プラットフォームは、アプリの常時対応構成に関係なく、 関数ごとのスケーリング関数またはグループごとに少なくとも 2 つの常時対応インスタンスを自動的に維持します。 プラットフォームによって作成されるインスタンスはプラットフォームで管理され、常時対応インスタンスとして課金され、常時対応の構成設定は変更されません。
オンデマンド インスタンスは、 アプリが常時対応のインスタンス数を超えてスケーリングされるため、イベント ソース ボリュームによって発生します。 オンデマンド インスタンスは、ベスト エフォートベースで可用性ゾーン間で分散されます。 プラットフォームは、ゾーン間の均等な分散よりも迅速なスケールアウトに優先順位を付けます。 プラットフォームは、時間の経過と同時にディストリビューションを均等に実行しようとします。
Elastic Premium 関数アプリ プランをゾーン冗長として構成すると、プラットフォームによって、選択したリージョン内の複数のゾーンにプラン インスタンスが自動的に分散されます。 インスタンスの拡散は、アプリのスケール インとスケールアウトを行う場合でも、次の規則に従います。
関数アプリの最小インスタンス数は 2 です。
ゾーンの数より大きい容量を指定すると、容量がゾーンの数の倍数である場合にのみ、インスタンスが均等に分散されます。
ゾーンの数とインスタンスの数を乗算した値よりも大きな容量値の場合、追加のインスタンスは残りのゾーンに分散されます。
Functions は、ゾーン冗長 Premium プランにインスタンスを割り当てるときに、基になるAzure Virtual Machine Scale Setsが提供する best-effort ゾーン分散 を使用します。 Azureでは、プレミアムプランは、各ゾーンが他のゾーンと同じ数の仮想マシン (VM) を持ち、プラスまたはマイナス1つのVMの違いに収まる場合、バランスが取れていると見なされます。
Cost
ゾーンの冗長性を有効にすると、追加コストは発生しません。 ゾーン冗長プランの価格は、単一ゾーン プランと同じです。 ただし、ゾーン冗長を有効にすると、プラン内のインスタンスの最小数に影響します。
関数ごとのスケーリング関数またはグループごとに常に 2 つ未満のインスタンス構成でアプリで可用性ゾーンを有効にすると、プラットフォームは、 関数ごとのスケーリング関数またはグループごとに always-ready 型 の 2 つのインスタンスを自動的に作成します。 これらの新しいインスタンスは、常に使用可能なインスタンスとして課金されます。
インスタンスが 2 つ未満のプランで可用性ゾーンを有効にした場合、プラットフォームではそのプランに対して 2 つのインスタンスの最小数が適用され、両方のインスタンスに対して課金されます。
価格の詳細については、「 Functions の価格」を参照してください。
可用性ゾーンのサポートを設定する
新しいゾーン冗長ファンクションプランを作成します。 新しいプランを作成するときに、ゾーン冗長を有効にすることができます。 詳細については、「 ゾーン冗長関数アプリの作成」を参照してください。
既存のプランでゾーン冗長を有効にします。 既存の Elastic Premium プランの可用性ゾーンのオンとオフを切り替えることができます。 Elastic Premium プランには、専用 (App Service) プランとは異なる特定の容量動作があり、追加の構成手順が必要です。 詳細な手順については、「 既存のプランでゾーン冗長を有効にする」を参照してください。
新しいゾーン冗長の関数プランを作成します。 新しいプランを作成するときに、ゾーン冗長を有効にすることができます。 詳細については、「 ゾーン冗長関数アプリの作成」を参照してください。
既存のプランでゾーン冗長を有効にします。 Premium プランの場合は、プランの作成時にのみゾーン冗長を有効にすることができます。 既存の Premium プランをゾーン冗長に変換することはできません。 代わりに、新しい Premium プラン アプリにサイド バイ サイドデプロイを作成して、アプリを移行します。 詳細については、「 既存のプランでゾーン冗長を有効にする」を参照してください。
容量の計画と管理
ゾーン冗長関数アプリは、リージョン内のゾーンで障害が発生した場合でも引き続き実行されます。
ゾーンの停止中に、Functions は失われたインスタンスを検出し、正常なゾーンで置換インスタンスの検索または作成を自動的に試行します。 プラットフォームはベスト エフォートベースでこのプロセスを実行し、成功を保証しません。 ワークロードで予想されるサービス レベルを維持するために特定の数のインスタンスが必要な場合は、常時対応インスタンスの数 をオーバープロビジョニング することを検討してください。 オーバープロビジョニングにより、ソリューションは容量の損失を許容し、パフォーマンスを低下させることなく引き続き機能します。 詳細については、「 オーバープロビジョニングによる容量の管理」を参照してください。
すべてのゾーンが正常な場合の動作
このセクションでは、プランがゾーン冗長で、ホスト ストレージ アカウントが ZRS を使用し、すべての可用性ゾーンが動作している場合に想定される内容について説明します。
ゾーン間操作: Functions でゾーン冗長を構成すると、要求は各可用性ゾーン内のインスタンスに自動的に分散されます。 要求は、任意の可用性ゾーン内の任意のインスタンスに送信される場合があります。
ゾーン間データ レプリケーション: 関数はステートレス コンピューティング サービスであるため、ゾーン間でレプリケートするデータはありません。 プラットフォームは、ゾーン間で構成を自動的にレプリケートします。
ホスト ストレージ アカウントで ZRS が使用されている場合、Azure Storage は複数の可用性ゾーンにデータを同期的にレプリケートします。
永続関数の場合は、ストレージ プロバイダーを確認して、ゾーン間でデータがどのようにレプリケートされるかを確認します。
ゾーン障害時の動作
このセクションでは、プランがゾーン冗長で、ホスト ストレージ アカウントで ZRS が使用され、可用性ゾーンの停止が発生した場合に想定される内容について説明します。
- 検出と応答: Functions プラットフォームは、可用性ゾーンでの障害の検出を担当します。 ゾーンのフェールオーバーを開始する必要はありません。
- 通知: ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Resource Health を 使用して個々のリソースの正常性を監視したり、 Resource Health アラート を設定して問題を通知したりすることはできます。 また、Azure Service Health を使用して、ゾーンエラーを含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知することもできます。
アクティブな要求: 可用性ゾーンが使用できない場合、障害のある可用性ゾーン内のインスタンスに接続する進行中の要求は終了し、再試行する必要があります。 一時的な障害処理のガイダンスに従って、アプリケーションが準備されていることを確認します。
予想されるデータ損失: Functions はステートレス サービスであるため、ゾーンの障害によってデータが失われるとは考えられません。
ホスト ストレージ アカウントで ZRS が使用されている場合、Storage はゾーン障害によるデータ損失を防ぎます。
永続関数の場合は、ストレージ プロバイダーを確認して、ゾーン障害時にデータ損失が発生する可能性があるかどうかを確認します。
予想されるダウンタイム: ゾーンの停止中に、トラフィックが再配布されるときに通常数秒続く短い中断が接続で発生する可能性があります。 一時的な障害処理のガイダンスに従って、アプリケーションが準備されていることを確認します。
トラフィックの再ルーティング: 関数は、そのゾーンから失われたインスタンスを検出し、新しい置換インスタンスの検索を試みます。 Functions は、置換を見つけた後、必要に応じて新しいインスタンス間でトラフィックを分散します。
Important
Azure では、ゾーンダウン シナリオで、より多くのインスタンスの要求が成功することを保証しません。 プラットフォームは、失われたインスタンスをベストエフォート方式でバックフィルしようとします。 可用性ゾーンの障害時に保証された容量が必要な場合は、容量をオーバープロビジョニングして、ゾーンの損失を考慮するようにプランを作成して構成します。
実行時間以外の動作: ゾーン冗長関数アプリプランのアプリケーションは、可用性ゾーンで障害が発生した場合でも、引き続き実行され、トラフィックを処理します。 ただし、可用性ゾーンの停止中に、実行時以外の動作が影響を受ける可能性があります。 これらの動作には、関数アプリのスケーリング、アプリケーションの作成、アプリケーション構成、アプリケーションの発行が含まれます。
ゾーンの回復
可用性ゾーンが復旧すると、Functions は可用性ゾーン内のインスタンスを自動的に復元し、他の可用性ゾーンで作成された一時インスタンスを削除し、インスタンス間のトラフィックを通常どおりに再ルーティングします。
ゾーンエラーのテスト
Functions プラットフォームは、ゾーン冗長リソースのトラフィック ルーティング、フェールオーバー、ゾーン回復を管理します。 何も開始する必要はありません。 Azureこの機能を完全に管理するため、可用性ゾーンの障害プロセスを検証する必要はありません。
リージョン全体の障害に対する回復性
機能は単一リージョンのサービスです。 リージョンが使用できなくなった場合、Functions リソースも使用できなくなります。
回復性のためのカスタム マルチリージョン ソリューション
リージョン全体の停止中にサービスが中断されないようにするために、同じ関数を複数のリージョンの関数アプリに冗長にデプロイできます。
お客様の責任は次のとおりです。
関数アプリを複数のリージョンにデプロイする。
リージョン間のトラフィック分散の管理。
フェールオーバー メカニズムの実装。
リージョン間でのデータ整合性の確保 (該当する場合)。
リージョン間デプロイの監視と管理。
複数のリージョンで同じ関数コードを実行する場合は、 アクティブ/アクティブ / パッシブ パターンを検討してください。 以降のセクションでは、これらのパターンについて説明しますが、詳細なガイダンスや構成手順については説明しません。
HTTP トリガー関数のアクティブ/アクティブ パターン
アクティブ/アクティブ パターンでは、両方のリージョンの関数がアクティブに実行され、重複する方法またはローテーションでイベントが処理されます。 アクティブ/アクティブ パターンを Azure Front Door と組み合わせて使用することで、重要な HTTP トリガー関数の間で、複数のリージョンにわたる HTTP リクエストをラウンドロビン方式でルーティングできます。 Azure Front Door では、各エンドポイントの正常性を定期的に確認することもできます。 あるリージョン内の関数が正常性チェックへの応答を停止した場合、Azure Front Doorはローテーションから削除され、残りの正常な関数にのみトラフィックが転送されます。
この図は、上部にAzure Front Doorを示しています。 次の 2 つのリージョンが表示されます。左側のプライマリ リージョンと右側のセカンダリ リージョンです。 各リージョンには、Functions アプリとデータベースが含まれています。 矢印は、Azure Front Doorから両方の関数アプリへ向かっています。 矢印は、各関数アプリからそれぞれのデータベースを指しています。
非 HTTP トリガー関数のアクティブ/パッシブ パターン
イベント ドリブンの非 HTTP トリガー関数 (Azure Service Bus トリガーやAzure Event Hubs トリガーなど) には、アクティブ/パッシブ パターンを使用します。 アクティブ/パッシブ パターンでは、関数インスタンスはイベントを受信するリージョンで実行されますが、セカンダリ リージョン内のインスタンスはアイドル状態のままです。 このパターンにより、各メッセージを処理する関数は 1 つだけであり、データの一貫性を維持するのに役立ちます。 また、リージョンの停止などの障害発生時にセカンダリ リージョンにフェールオーバーする方法も提供されます。
関数アプリのフェールオーバーを、次のような他のサービスのフェールオーバー動作と共に検討します。
Event Hubs 名前空間が geo ディザスター リカバリー用に構成されている Event Hubs トリガーを使用するトポロジの例を考えてみましょう。 この場合、アクティブ/パッシブ パターンには次のコンポーネントが必要です。
プライマリ リージョンとセカンダリ リージョンの両方にデプロイされた Event Hubs 名前空間。
geo ディザスター リカバリーを有効 にして、プライマリ イベント ハブとセカンダリ イベント ハブをペアにします。 この構成では、Event Hubs 名前空間に接続し、接続情報を変更せずにプライマリからセカンダリにエイリアスを切り替えるために使用できる エイリアス も作成されます。
プライマリ リージョンとセカンダリ リージョンの両方にデプロイされた関数アプリ。 セカンダリ リージョン内のアプリは、メッセージを受信しないため、アイドル状態のままです。
各関数アプリのトリガーでは、それぞれの Event Hubs 名前空間にダイレクト（非エイリアス）接続文字列が使用されます。
Event Hubs 名前空間へのパブリッシャーは、エイリアス接続文字列に発行します。
この図は、左側にプライマリ リージョン、右側にセカンダリ リージョンを示しています。 プライマリ リージョンには、アクティブな Event Hubs 名前空間、関数アプリ、およびデータベースが含まれています。 セカンダリ リージョンには、パッシブ Event Hubs 名前空間、関数アプリ、およびデータベースが含まれています。 エイリアスから Event Hubs ジオディザスターリカバリーに矢印が向けられ、プライマリとセカンダリの Event Hubs 名前空間が接続されます。 矢印は、各イベント ハブからそれぞれの関数アプリを指します。 矢印は、各関数アプリからそれぞれのデータベースを指しています。
フェールオーバー前に、共有エイリアスにイベントを送信するパブリッシャーは、プライマリ イベント ハブにトラフィックをルーティングします。 プライマリ機能アプリは、プライマリイベントハブのみを監視しています。 セカンダリ機能アプリは受動的で待機状態のままです。
フェールオーバーが開始されると、共有エイリアスにイベントを送信するパブリッシャーはセカンダリ イベント ハブにルーティングされます。 セカンダリ関数アプリがアクティブになり、自動的にトリガーされます。 イベント ハブはフェールオーバー プロセス全体を駆動でき、各関数アプリは、対応するイベント ハブがアクティブな場合にのみ実行されます。
永続的な関数
永続的な関数の複数リージョンのディザスター リカバリーについては、「Disaster recovery and geo-distribution in Azure durable functionsを参照してください。
サービス メンテナンスに対する回復性
Functions は、通常のサービス アップグレードやその他のメンテナンス タスクを実行します。
- 一時的な障害の回復性: サービスのメンテナンス中に、関数アプリを実行するインスタンスが再起動したり、一時的な中断が発生したりする可能性があります。 関数アプリと対話するクライアント アプリケーションが 、一時的な障害に対する回復性があることを確認します。
- ゾーン冗長を有効にする: プランでゾーン冗長を有効にすると、プラットフォームの更新中の回復性も向上します。 プランに複数のインスタンスをデプロイし、プランのゾーン冗長性を有効にすると、アップグレード中にインスタンスまたはゾーンが異常になった場合に回復性の層が追加されます。
追加の一時インスタンス: アップグレード中に予想される容量を維持するために、プラットフォームはアップグレード プロセス中にプランのインスタンスを自動的に追加します。
ゾーン冗長を有効にする: プランでゾーン冗長を有効にすると、プラットフォームの更新中の回復性も向上します。 更新ドメインは、更新中にオフラインになる VM のコレクションで構成され、可用性ゾーンにマップされます。 プランに複数のインスタンスをデプロイし、プランのゾーン冗長性を有効にすると、アップグレード中にインスタンスまたはゾーンが異常になった場合に、回復性のレイヤーが追加されます。
App Service 環境: App Service Environment で関数アプリをホストする場合は、アップグレード サイクルをカスタマイズできます。 ワークロードに対するアップグレードの影響を検証する必要がある場合は、手動アップグレードを有効にします。 運用環境のインスタンスにアップグレードを適用する前に、非運用環境のインスタンスを検証してテストするには、この方法を使用します。
メンテナンス設定の詳細については、「App Service Environment の計画メンテナンスのアップグレード設定」をご覧ください。
アプリケーションのデプロイに対する回復性
アプリケーションのデプロイでは、運用環境で問題が発生するリスクが生じます。 問題が発生した場合は、更新プログラムをロールバックする準備をしてください。 更新プログラムのロールアウト方法を制御して、アプリケーションの再起動による中断を減らします。
Flex Consumption プランでは、 アプリの更新プログラムをデプロイするための複数の方法を提供するサイト更新戦略がサポートされています。 これらの戦略には、ゼロダウンタイムデプロイメントのためのローリング更新が含まれます。
Functions デプロイ スロット を使用すると、関数アプリのダウンタイムなしのデプロイが可能になります。 デプロイ スロットを使用して、ユーザーのデプロイと構成の変更の影響を最小限に抑えます。 デプロイ スロットを使用すると、アプリケーションが再起動する可能性も低くなります。 アプリケーションを再起動すると、一時的なエラーが発生します。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、 オンライン サービスの SLA を参照してください。
Functions では、従量課金プランとその他のプランの種類に対して個別の可用性 SLA が提供されます。