次の方法で共有


Azure Functions の信頼性

この記事では、Azure Functions の信頼性サポートについて説明し、可用性ゾーンによるリージョン内の回復性と、リージョン間のリカバリーおよび事業継続の両方を取り上げます。 Azure における信頼性の原則の詳細については、Azure の信頼性に関するページを参照してください。

Azure Functions の可用性ゾーンのサポートは、 Functions ホスティング プランによって異なります。

ホスティング プラン サポート レベル 詳細をご覧ください
Flex 従量課金プラン プレビュー この記事の上部にある Flex Consumption を選択します。
Elastic Premium プラン GA この記事の上部にある Premium を選択します。
専用 (App Service) プラン GA Azure App Service の信頼性に関するページを参照してください。
従量課金プラン n/a 従量課金プランではサポートされていません。

可用性ゾーン は、各 Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

Azure Functions は、ゾーン冗長デプロイをサポートしています。

可用性ゾーンのサポート

重要

Flex 従量課金プランでアプリをホストするときの可用性ゾーンのサポートは、現在プレビュー段階です。

Flex Consumption プラン アプリをゾーン冗長として構成すると、プラットフォームは、選択したリージョン内のゾーンに関数アプリのインスタンスを自動的に分散し、常時対応インスタンスとオンデマンド インスタンスに対して異なるルールを使用します。

Flex 従量課金プランでゾーン冗長が有効になっている場合、インスタンスの拡散は次のルール内で決定されます。

  • Always-ready インスタンスは、ラウンドロビン方式で少なくとも 2 つのゾーンに分散されます。
  • オンデマンド インスタンスは、アプリが常時対応を超えてスケーリングする際にイベント ソース ボリュームの結果として作成され、 ベスト エフォート ベースで可用性ゾーン間で分散されます。 つまり、オンデマンド インスタンスの場合、可用性ゾーン間での均等な分散よりも、より高速なスケールアウトが優先されます。 プラットフォームは、時間の経過と同時に均等な配布を試みます。
  • 可用性ゾーンを使用してゾーンの回復性を確保するために、プラットフォームは、アプリの常時対応構成に関係なく、 関数ごとのスケーリング関数またはグループごとに少なくとも 2 つの常時対応インスタンスを自動的に維持します。 プラットフォームによって作成されたインスタンスはプラットフォームで管理され、常時対応インスタンスとして課金され、常時対応の構成設定は変更されません。

Elastic Premium 関数アプリ プランをゾーン冗長として構成すると、プラットフォームによって、選択したリージョン内のゾーンに関数アプリ インスタンスが自動的に分散されます。

ゾーン冗長デプロイでのインスタンスの分散は、アプリのスケールインとスケールアウトであっても、次のルール内で決定されます。

  • 関数アプリの最小インスタンス数は 2 です。
  • ゾーンの数より大きい容量を指定すると、容量がゾーンの数の倍数である場合にのみ、インスタンスが均等に分散されます。
  • 容量の値が [ゾーンの数] * インスタンスの数を超える場合、追加のインスタンスは残りのゾーンに分散されます。

重要

Azure Functions は Azure App Service プラットフォームで実行できます。 App Service プラットフォームでは、Premium プラン関数アプリをホストするプランは Elastic Premium プランと呼ばれ、SKU 名は EP1 と呼ばれます。 Premium プランで関数アプリを実行する場合は、Eなど、EP1で始まる SKU 名でプランを作成してください。 P (Premium V2 Small プラン) など、P1V2で始まる App Service プラン SKU 名は、専用ホスティング プランです。 これらは専用であり、Elastic Premium ではないため、 P で始まる SKU 名を持つプランは動的にスケーリングされず、コストが増加する可能性があります。

リージョン別の提供状況

現時点では、すべてのリージョンで Flex Consumption プランのゾーン冗長がサポートされているわけではありません。 Azure CLI を使用して、それをサポートするリージョンを表示できます。

  1. まだインストールしていない場合は、Azure CLI を使用して Azure にインストールしてサインインします。

    az login
    

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

  2. 現在ゾーン冗長 Flex Consumption プランをサポートしているリージョンの一覧を返すには、次の az functionapp list-flexconsumption-locations コマンドを --zone-redundant=true オプションと共に使用します。

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

Azure portal で Flex Consumption アプリを作成すると、選択したリージョンでサポートされている場合、[Zone redundancy] ページの [] セクションが有効になります。

ゾーン冗長 Premium プランは、次のリージョンで利用できます。

南北アメリカ ヨーロッパ 中東 アフリカ アジア太平洋
ブラジル南部 フランス中部 イスラエル中部 南アフリカ北部 オーストラリア東部
カナダ中部 ドイツ中西部 カタール中部 インド中部
米国中部 イタリア北部 アラブ首長国連邦北部 中国北部 3
米国東部 北ヨーロッパ 東アジア
米国東部 2 ノルウェー東部 東日本
米国中南部 スウェーデン中部 東南アジア
米国西部 2 スイス北部
米国西部 3 英国南部
西ヨーロッパ

前提条件

可用性ゾーンのサポートは、Flex 従量課金プランのプロパティです。 可用性ゾーンの使用に関する現在の考慮事項を次に示します。

可用性ゾーンのサポートは、Premium プランの特性の 1 つです。 可用性ゾーンの現在の考慮事項を次に示します。

  • アプリの作成時にのみ、プランで可用性ゾーンを有効にすることができます。 既存の Premium プランを変換して可用性ゾーンを使用することはできません。
  • 関数アプリの既定のホストストレージ アカウントには、ゾーン冗長ストレージ アカウント (ZRS) を使用する必要があります。 別の種類のストレージ アカウントを使用すると、ゾーンの停止中にアプリが予期せず動作する可能性があります。
  • Windows と Linux はどちらもサポートされています。
  • Premium プランでホストされる関数アプリには、 常に準備できるインスタンスが少なくとも 2 つ必要です。
  • インスタンス数を 2 未満に指定した場合、プラットフォームはバックグラウンドでこの最小カウントを適用します。
  • Premium プラン、または可用性ゾーンがサポートされるスケール ユニットを使用していない場合、サポート対象外のリージョンにいる場合、または不明な点がある場合は、「移行ガイダンス」を参照してください。

価格

可用性ゾーンの有効化に関連する別のメーターはありません。 ゾーン冗長 Flex Consumption アプリに使用されるインスタンスの価格は、単一ゾーンの Flex Consumption アプリと同じです。 詳しくは、請求をご覧ください。

関数ごとのスケーリング関数またはグループごとに、常時対応インスタンス構成が 2 つ未満のインスタンス構成でアプリで可用性ゾーンを有効にすると、プラットフォームは関数 ごとのスケーリング関数またはグループごとに 、常時対応 型の 2 つのインスタンスを自動的に作成します。 これらの新しいインスタンスは、常に使用可能なインスタンスとして課金されます。

可用性ゾーンの有効化に関連する追加コストはありません。 ゾーン冗長 Premium App Service プランの価格は、1 つのゾーン Premium プランと同じです。 ご利用の App Service プランごとに、選択した SKU、指定した容量、および自動スケーリング条件に基づいてスケーリングする任意のインスタンスに基づいて課金されます。 インスタンスが 2 つ未満のプランで可用性ゾーンを有効にした場合、プラットフォームでは、その App Service プランに対して 2 つのインスタンスの最小数が適用され、両方のインスタンスに対して課金されます。

ゾーン冗長プランで関数アプリを作成する

現在、ゾーン冗長 Flex Consumption アプリをデプロイする方法は複数あります。

  1. Azure portal で、[関数アプリを作成する] ページに移動します。 ポータルでの関数アプリの作成の詳細については、「関数アプリを作成する」をご覧ください。

  2. Flex Consumption を選択し、[選択] ボタンを選択します。

  3. [ 関数アプリの作成 (Flex Consumption)] ページの [ 基本 ] タブで、関数アプリの設定を入力します。 ゾーン冗長に関する特定の要件がある次の表 (次のスクリーンショットでもハイライトされている) の設定には、特に注意してください。

    設定 推奨値 ゾーン冗長に関する注意事項
    リージョン ご希望のサポートされているリージョン Flex 従量課金プランが作成されるリージョン。 可用性ゾーンをサポートするリージョンを選択する必要があります。 利用可能なリージョンの一覧を参照してください。
    ゾーン冗長性 有効化済み この設定では、アプリがゾーン冗長かどうかを指定します。 ゾーンの冗長性をサポートするリージョンを選択した場合にのみ、 Enabled を選択できます。

    Flex Consumption 関数アプリの作成ページの [基本] タブのスクリーンショット。

  4. [ストレージ] タブで、関数アプリ ストレージ アカウントの設定を入力します。 ゾーン冗長に関する特定の要件がある次の表の設定には、特に注意してください。

    設定 推奨値 ゾーン冗長に関する注意事項
    ストレージ アカウント ゾーン冗長ストレージ アカウント 前提条件」セクションで説明した通り、ゾーン冗長関数アプリにはゾーン冗長ストレージ アカウントを使用することを強くお勧めします。
  5. 関数アプリ作成プロセスの残りの部分では、通常どおりに関数アプリを作成します。 作成プロセスの残りの部分には、ゾーン冗長性に影響する設定はありません。

ゾーン冗長プランを作成してデプロイすると、新しいプランでホストされている Flex Consumption 関数アプリはゾーン冗長と見なされます。

Flex 従量課金プランをゾーン冗長に更新する

アプリのゾーン冗長性を変更するには再起動が必要です。これにより、アプリのダウンタイムが発生します。

Flex 従量課金プランをゾーン冗長に更新する前に、既定のホスト ストレージ アカウントもゾーン冗長に更新する必要があります。 アプリのデプロイ コンテナーに別のストレージ アカウントを使用する場合は、ゾーン冗長に更新する必要があります。

次の手順を使用して、変更に備えてストレージ アカウントを準備します。

  1. ストレージに関する考慮事項を確認します
  2. ゾーン冗長ストレージ アカウントを作成または識別して、アプリの既定のホスト ストレージ アカウントにします。
  3. ゾーン冗長ストレージ アカウントを参照するように、アプリのストレージ関連のアプリケーション設定 ( AzureWebJobsStorage など) を更新します。 「アプリケーション設定の操作」を参照してください。
  4. アプリのデプロイ ストレージ アカウントを更新します。これは、アプリに関連付けられているストレージ アカウントと同じでも異なる場合もあります。 展開設定の構成を参照してください。

アプリで使用されているストレージ アカウントが更新されたら、Bicep または ARM テンプレートを使用して、Flex Consumption プランをゾーン冗長に更新できます。 現在、Azure portal では、プランに対するゾーン冗長更新の作成はサポートされていません。

現在サポートされていません。

現在、ゾーン冗長 Premium プランと関数アプリをデプロイする方法は 2 つあります。 Azure portal か ARM テンプレートを使用できます。

  1. Azure portal で、[関数アプリを作成する] ページに移動します。 ポータルでの関数アプリの作成の詳細については、「関数アプリを作成する」をご覧ください。

  2. [Functions Premium プラン] を選択し、[選択する] ボタンを選択します。

  3. [関数アプリを作成する] (Functions Premium プラン) ページの [基本情報] タブで、関数アプリの設定を入力します。 ゾーン冗長に関する特定の要件がある次の表 (次のスクリーンショットでもハイライトされている) の設定には、特に注意してください。

    設定 推奨値 ゾーン冗長に関する注意事項
    リージョン ご希望のサポートされているリージョン Elastic Premium プランが作成されるリージョン。 可用性ゾーンをサポートしているリージョンを選択する必要があります。 利用可能なリージョンの一覧を参照してください。
    料金プラン Elastic Premium プランの 1 つ。 詳細については、「利用可能インスタンス SKU」をご覧ください。 この記事では、Premium プランでゾーン冗長アプリを作成する方法について説明します。 ゾーン冗長性は、現在、従量課金プランでは使用できません。 App Service プランのゾーン冗長については、「Azure App Service の信頼性」をご覧ください。
    ゾーン冗長性 有効化済み この設定では、アプリがゾーン冗長かどうかを指定します。 前述した通り、ゾーン冗長をサポートするリージョンを選択しない限り、Enabled を選択することはできません。

    関数アプリの作成ページの [基本情報] タブのスクリーンショット。

  4. [ストレージ] タブで、関数アプリ ストレージ アカウントの設定を入力します。 ゾーン冗長に関する特定の要件がある次の表の設定には、特に注意してください。

    設定 推奨値 ゾーン冗長に関する注意事項
    ストレージ アカウント ゾーン冗長ストレージ アカウント 前提条件」セクションで説明した通り、ゾーン冗長関数アプリにはゾーン冗長ストレージ アカウントを使用することを強くお勧めします。
  5. 関数アプリ作成プロセスの残りの部分では、通常どおりに関数アプリを作成します。 作成プロセスの残りの部分には、ゾーン冗長性に影響する設定はありません。

ゾーン冗長プランが作成およびデプロイされると、新しいプランでホストされている関数アプリはゾーン冗長としてみなされます。

可用性ゾーンの移行

現在、既存の関数アプリの Elastic Premium プランの可用性ゾーンのサポートを変更することはできません。 パブリック マルチテナント Premium プランを非可用性ゾーンから可用性ゾーンのサポートに移行する方法については、「 App Service を可用性ゾーンのサポートに移行する」を参照してください。

ゾーン ダウン エクスペリエンス

ゾーン冗長 Flex Consumption プラン アプリの使用可能なすべての関数アプリ インスタンスが有効になり、イベントが処理されます。 Flex Consumption アプリは、同じリージョン内の他のゾーンで障害が発生した場合でも引き続き実行されます。 ただし、他の可用性ゾーンで障害が発生した結果、ランタイム以外の動作が影響を受ける可能性があります。 可用性に影響を与える可能性がある標準関数アプリの動作は次のとおりです。

  • スケーリング
  • アプリの作成
  • 構成の変更
  • デプロイメント

Flex Consumption プランのゾーン冗長性では、実行中のデプロイ済みアプリケーションの継続的なアップタイムのみが保証されます。

ゾーンがダウンすると、Functions は失われたインスタンスを検出し、必要に応じて、使用可能なゾーンで代替インスタンスの検索または作成を自動的に試行します。 ゾーンの停止中、プラットフォームは残りの利用可能なゾーンの残高を復元しようとします。

ゾーン冗長関数アプリの使用可能な関数アプリ インスタンスはすべて有効になり、イベントを処理しています。 ゾーンがダウンした場合は、失われたインスタンスが Functions によって検出され、必要な場合、新しい代替インスタンスの検索が自動的に試行されます。 エラスティック スケールの動作は引き続き適用されます。 ただし、ゾーンダウンシナリオでは、失われたインスタンスのバックフィルはベストエフォートベースで行われるため、より多くのインスタンスの要求が成功する保証はありません。 可用性ゾーンが有効になっている Premium プランにデプロイされたアプリケーションは、同じリージョン内の他のゾーンが停止した場合でも、引き続き実行されます。 ただし、他の可用性ゾーンでの停止によって、実行時間以外の動作が引き続き影響を受ける可能性があります。 このような影響を受ける動作には、Premium プランのスケーリング、アプリケーションの作成、アプリケーションの構成、アプリケーションの公開などがあります。 Premium プランのゾーン冗長で保証されるのは、デプロイされたアプリケーションの継続的なアップタイムのみです。

Functions によってインスタンスがゾーン冗長 Premium プランに割り当てられると、基になる Azure Virtual Machine Scale Sets によって提供されるベスト エフォートのゾーン負荷分散が使用されます。 Premium プランは、Premium プランで使用される他のすべてのゾーンで各ゾーンに同じ数の仮想マシンがあり、1 つの仮想マシンをプラスまたはマイナスで持っている場合、バランスが取れていると見なされます。

リージョン間のディザスター リカバリーおよび事業継続

ディザスター リカバリー (DR) とは、自然災害やデプロイの失敗など、ダウンタイムやデータ損失につながる影響の大きいイベントから組織が復旧するために使用するプラクティスを指します。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を開始する前に、 ディザスター リカバリー戦略の設計に関する推奨事項を参照してください。

DR の場合、Microsoft は 共有責任モデルを使用します。 このモデルでは、Microsoft はベースライン インフラストラクチャとプラットフォーム サービスを確実に利用できるようにします。 ただし、多くの Azure サービスでは、データが自動的にレプリケートされたり、障害が発生したリージョンから別の有効なリージョンにクロスレプリケートされたりすることはありません。 それらのサービスに対して、ワークロードに適したディザスター リカバリー計画を設定する責任はユーザーにあります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されています。 サービス固有の機能を使用して高速復旧をサポートし、DR プランの開発に役立ちます。

このセクションでは、ディザスター リカバリーを可能にする関数アプリのデプロイに使用できる戦略の一部について説明します。

Durable Functions のディザスター リカバリーについては、「Azure Durable Functions のディザスター リカバリーと地理的分散」を参照してください。

複数リージョンのディザスター リカバリー

利用できる冗長性は組み込みがないため、関数は特定の Azure リージョンの関数アプリで実行されます。 停止中に実行が失われることを回避するために、同じ関数を複数のリージョン内の関数アプリに冗長にデプロイできます。 複数リージョン デプロイの詳細については、「可用性の高い複数リージョンの Web アプリケーション」のガイダンスを参照してください。

複数のリージョンで同じ関数コードを実行する場合は、アクティブ/アクティブアクティブ/パッシブ、2 つのパターンを考慮する必要があります。

HTTP トリガー関数のアクティブ/アクティブ パターン

アクティブ/アクティブ パターンでは、両方のリージョンの関数がアクティブに実行され、重複する方法またはローテーションでイベントが処理されます。 アクティブ/アクティブ パターンは、重要な HTTP によってトリガーされる関数に Azure Front Door と組み合わせて使用する必要があります。これは、複数のリージョンで実行されている関数間で HTTP 要求をルーティングおよびラウンドロビンできます。 Front Door では、各エンドポイントの正常性を定期的にチェックすることもできます。 あるリージョン内の関数が正常性チェックへの応答を停止すると、Azure Front Door はそれをローテーションから外し、残りの正常な関数にのみトラフィックを転送します。

Azure Front Door と関数のアーキテクチャ

例については、 分散 Azure リージョンの geod に API をデプロイして geode パターンを実装する方法のサンプルを参照してください。

非 HTTPS トリガー関数のアクティブ/パッシブ パターン

Service Bus や Event Hubs によってトリガーされる関数など、イベント ドリブンの非 HTTP のトリガーされた関数にはアクティブ/パッシブ パターンを使用することをお勧めします。

HTTP 以外のトリガー関数の冗長性を作成するには、アクティブ/パッシブ パターンを使用します。 アクティブ/パッシブ パターンでは、イベントを受信しているリージョンで関数がアクティブに実行されます。2 番目のリージョンの同じ関数はアイドル状態のままです。 アクティブ/パッシブ パターンは、障害発生時にセカンダリ リージョンにフェールオーバーするメカニズムを提供しながら、1 つの関数のみが各メッセージを処理する方法を提供します。 関数アプリは、パートナー サービスのフェールオーバー動作 (Azure Service Bus の geo リカバリーAzure Event Hubs の geo リカバリーなど) と連携します。

Azure Event Hubs トリガーを使用したトポロジの例を考えてみます。 この場合、アクティブ/パッシブ パターンには次のコンポーネントが必要です。

  • プライマリとセカンダリ両方のリージョンにデプロイされた Azure Event Hubs。
  • プライマリとセカンダリのイベント ハブをペアリングするために有効にされた geo ディザスター。 これにより、接続情報を変更することなくイベント ハブに接続し、プライマリからセカンダリに切り替えるために使用できる "別名" も作成されます。
  • 関数アプリは、プライマリとセカンダリ (フェールオーバー) の両方のリージョンにデプロイされますが、セカンダリ リージョン内のアプリは、メッセージが送信されないため、基本的にアイドル状態です。
  • 関数アプリは、対応するイベント ハブの "直接の" (非エイリアス) 接続文字列でトリガーされます。
  • イベント ハブへの発行元は、別名の接続文字列に対して発行する必要があります。

アクティブ/パッシブ アーキテクチャの例

フェールオーバーの前、共有された別名に送信する発行元は、プライマリ イベント ハブにルーティングされます。 プライマリ関数アプリは、プライマリ イベント ハブだけをリッスンします。 セカンダリ関数アプリはパッシブで、かつアイドル状態です。 フェールオーバーが開始されるとすぐに、共有された別名に送信する発行元は、セカンダリ イベント ハブにルーティングされます。 セカンダリ関数アプリがアクティブになり、自動的にトリガーを開始します。 セカンダリ リージョンへの効果的なフェールオーバーは、イベント ハブから完全に実行でき、それぞれのイベント ハブがアクティブになった場合にのみ関数がアクティブになります。

Service BusEvent Hubs を使用したフェールオーバーに関する情報と考慮事項の詳細を参照してください。

非 HTTPS トリガー関数のアクティブ・アクティブパターン

非 HTTPS トリガー関数には アクティブ/パッシブ パターン を使用することをお勧めしますが、HTTP によってトリガーされていない関数のアクティブ/アクティブデプロイを作成することもできます。 このパターンを実装する前に、2 つのアクティブな領域がどのように相互作用するか、相互に連携するかを検討する必要があります。

たとえば、同じ Service Bus トリガー関数コードを 2 つのリージョンにデプロイし、同じ Service Bus キューでトリガーすることを検討してください。 この場合、両方の関数は、1 つのキューをデキューする際に競合コンシューマーとして機能します。 各メッセージは 2 つのアプリ インスタンスのいずれかによってのみ処理できますが、単一の障害点 (Service Bus インスタンス) がまだ存在することも意味します。

代わりに、プライマリ リージョンに 1 つ、セカンダリ リージョンに 1 つずつ、2 つの Service Bus キューをデプロイできます。 この場合は、それぞれが自身のリージョン内でアクティブな Service Bus キューを指している 2 つの関数アプリが存在することになります。 このトポロジでの課題は、キュー メッセージを 2 つのリージョン間でどのように分散するかという点です。 これは多くの場合、各発行元がメッセージを "両方の" リージョンに発行しようとするため、各メッセージが両方のアクティブな関数アプリによって処理されることを示しています。 これにより、目的のアクティブ/アクティブのパターンが作成されますが、同時に、コンピューティングの重複やデータがいつ、またはどのように統合されるかに関する他の課題も生じます。

次のステップ