Azure Functions の信頼性

このアーティクルでは、 Azure Functionsでの信頼性のサポートについて説明し、リージョン内の回復性と 可用性ゾーン と、リージョン間の復旧とビジネス継続性 の両方について説明します。 Azure における信頼性の原則の詳細については、Azure の信頼性に関するページを参照してください。

Azure Functions における可用性ゾーンのサポートは、Premium (Elastic Premium) および Dedicated (App Service) 両方のプランで利用できます。 この記事では、Premium プランのゾーン冗長性に対するサポートに焦点を当てています。 専用プランのゾーン冗長については、「App Service を可用性ゾーンのサポートありに移行する」を参照してください。

可用性ゾーンのサポート

Azure 可用性ゾーンとは、各 Azure リージョン内にある、3 つ以上に物理的に分離されたデータセンターのグループです。 各ゾーン内のデータセンターには、独立した電源、冷却手段、ネットワーク インフラストラクチャが備わっています。 ローカル ゾーンの障害が発生した場合、可用性ゾーンは、1 つのゾーンが影響を受けたときに、リージョンのサービス、容量、高可用性が残りの 2 つのゾーンによってサポートされるように設計されています。

障害の範囲は、ソフトウェアやハードウェアの障害から、地震、水害、火災などの事象に至る可能性があります。 Azure サービスの冗長と論理的な分離により、障害に対するトレランスが実現されます。 Azure の可用性ゾーンの詳細については、リージョンと可用性ゾーンに関する記事を参照してください。

Azure の可用性ゾーン対応サービスは、適切なレベルの信頼性と柔軟性を提供するように設計されています。 それらは 2 つの方法で構成できます。 それらは、ゾーン間の自動レプリケーションによるゾーン冗長、またはインスタンスを特定のゾーンにピン留めするゾーンベースのいずれかになります。 これらのアプローチを組み合わせることもできます。 ゾーン ベースとゾーン冗長のアーキテクチャを比較した詳細については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。

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

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

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

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

リージョン別の提供状況

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

前提条件

可用性ゾーンのサポートは、Premium プランの特性の 1 つです。 可用性ゾーンを有効にするための現在の要件と制限を次に示します。

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

価格

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

ゾーン冗長 Premium プランと関数アプリの作成

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

"resources": [
    {
        "type": "Microsoft.Web/serverfarms",
        "apiVersion": "2021-01-15",
        "name": "<YOUR_PLAN_NAME>",
        "location": "<YOUR_REGION_NAME>",
        "sku": {
            "name": "EP1",
            "tier": "ElasticPremium",
            "size": "EP1",
            "family": "EP", 
            "capacity": 3
        },
        "kind": "elastic",
        "properties": {
            "perSiteScaling": false,
            "elasticScaleEnabled": true,
            "maximumElasticWorkerCount": 20,
            "isSpot": false,
            "reserved": false,
            "isXenon": false,
            "hyperV": false,
            "targetWorkerCount": 0,
            "targetWorkerSizeId": 0, 
            "zoneRedundant": true
        }
    }
]

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

可用性ゾーンの移行

Azure Function Apps では、現在、既存の関数アプリ インスタンスのインプレース移行はサポートされていません。 パブリック マルチテナント Premium プランを非可用性ゾーンから可用性ゾーンのサポートありに移行する方法については、App Service の可用性ゾーンのサポートありへの移行に関する記事を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

非 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 Bus や Event Hubs を使用したフェールオーバーに関する情報と考慮事項の詳細を参照してください。

次のステップ

• Azure Durable Functions のディザスター リカバリーと地理的分散
• Azure Front Door の作成
• Event Hubs のフェールオーバーの考慮事項
• 可用性ゾーンに関する Azure アーキテクチャ センターのガイド
• Azure での信頼性