Azure Functions の信頼性
このアーティクルでは、 Azure Functionsでの信頼性のサポートについて説明し、リージョン内の回復性と 可用性ゾーン と、リージョン間の復旧とビジネス継続性 の両方について説明します。 Azure における信頼性の原則の詳細については、Azure の信頼性に関するページを参照してください。
Azure Functions における可用性ゾーンのサポートは、Premium (Elastic Premium) および Dedicated (App Service) 両方のプランで利用できます。 この記事では、Premium プランのゾーン冗長性に対するサポートに焦点を当てています。 専用プランのゾーン冗長については、「App Service を可用性ゾーンのサポートありに移行する」を参照してください。
可用性ゾーンのサポート
可用性ゾーンとは、各 Azure リージョン内にある、物理的に分離されたデータセンターのグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Azure の可用性ゾーンの詳細情報については、「可用性ゾーンとは」を参照してください。
Azure Functions は、ゾーン冗長デプロイをサポートしています。
Functions をゾーン冗長として構成した場合、プラットフォームによって、選択されたリージョン内の 3 つのゾーンに対して関数アプリ インスタンスが自動的に分散されます。
ゾーン冗長デプロイでのインスタンスの分散は、アプリのスケールインとスケールアウトであっても、次のルール内で決定されます。
- 関数アプリ インスタンスの最小数は 3 です。
- 3 より大きい容量を指定すると、容量が 3 の倍数の場合にのみインスタンスが均等に分散されます。
- 容量の値が 3* N を超える場合、余分のインスタンスは残りの 1 つまたは 2 つのゾーンに分散されます。
重要
Azure Functions は Azure App Service プラットフォームで実行できます。 App Service プラットフォームでは、Premium プラン関数アプリをホストするプランは Elastic Premium プランと呼ばれており、EP1 のような SKU 名があります。 Premium プランで関数アプリを実行することを選択した場合、EP1 のように "E" で始まる SKU 名を持つプランを必ず作成してください。 P1V2 (Premium V2 Small プラン) のように "P" で始まる App Service プラン SKU 名は実際には専用ホスティング プランです。 Dedicated であり、Elastic Premium ではないため、"P" で始まる SKU 名のプランは動的にスケールせず、コストが増えることがあります。
リージョン別の提供状況
ゾーン冗長 Premium プランは、次のリージョンで使用できます。
| アメリカ | ヨーロッパ | 中東 | アフリカ | アジア太平洋 |
|---|---|---|---|---|
| ブラジル南部 | フランス中部 | イスラエル中部 | 南アフリカ北部 | オーストラリア東部 |
| カナダ中部 | ドイツ中西部 | カタール中部 | インド中部 | |
| 米国中部 | イタリア北部 | アラブ首長国連邦北部 | China North 3 | |
| 米国東部 | 北ヨーロッパ | 東アジア | ||
| 米国東部 2 | ノルウェー東部 | 東日本 | ||
| 米国中南部 | スウェーデン中部 | 東南アジア | ||
| 米国西部 2 | スイス北部 | |||
| 米国西部 3 | 英国南部 | |||
| 西ヨーロッパ |
前提条件
可用性ゾーンのサポートは、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 テンプレートを使用できます。
Azure portal で、[関数アプリを作成する] ページに移動します。 ポータルでの関数アプリの作成の詳細については、「関数アプリを作成する」をご覧ください。
[Functions Premium プラン] を選択し、[選択する] ボタンを選択します。 この記事では、Premium プランでゾーン冗長アプリを作成する方法について説明します。 ゾーン冗長性は、現在 Consumption プランでは使用できません。 App Service プランのゾーン冗長については、「Azure App Service の信頼性」をご覧ください。
[関数アプリを作成する] (Functions Premium プラン) ページの [基本情報] タブで、関数アプリの設定を入力します。 ゾーン冗長に関する特定の要件がある次の表 (次のスクリーンショットでもハイライトされている) の設定には、特に注意してください。
設定 推奨値 ゾーン冗長に関する注意事項 リージョン ご希望のサポートされているリージョン 新しい関数アプリが作成されるリージョン。 可用性ゾーンをサポートしているリージョンを選択する必要があります。 利用可能なリージョンの一覧を参照してください。 料金プラン Elastic Premium プランの 1 つ。 詳細については、「利用可能インスタンス SKU」をご覧ください。 この記事では、Premium プランでゾーン冗長アプリを作成する方法について説明します。 ゾーン冗長性は、現在 Consumption プランでは使用できません。 App Service プランのゾーン冗長については、「Azure App Service の信頼性」をご覧ください。 ゾーン冗長性 Enabled この設定では、アプリがゾーン冗長かどうかを指定します。 前述した通り、ゾーン冗長をサポートするリージョンを選択しない限り、 Enabledを選択することはできません。![関数アプリの作成ページの [基本情報] タブのスクリーンショット。](../azure-functions/media/functions-az-redundancy/azure-functions-basics-az.png)
[ストレージ] タブで、関数アプリ ストレージ アカウントの設定を入力します。 ゾーン冗長に関する特定の要件がある次の表の設定には、特に注意してください。
設定 推奨値 ゾーン冗長に関する注意事項 ストレージ アカウント ゾーン冗長ストレージ アカウント 前提条件セクションで説明した通り、ゾーン冗長関数アプリにはゾーン冗長ストレージ アカウントを使用することを強くお勧めします。 関数アプリ作成プロセスの残りの部分では、通常どおりに関数アプリを作成します。 作成プロセスの残りの部分には、ゾーン冗長性に影響する設定はありません。
ゾーン冗長プランが作成およびデプロイされると、新しいプランでホストされている関数アプリはゾーン冗長としてみなされます。
可用性ゾーンの移行
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 はそれをローテーションから外し、残りの正常な関数にのみトラフィックを転送します。
例については、分散 Azure リージョンのジオードに API をデプロイしてジオード パターンを実装する方法のサンプルを参照してください。
重要
ただし、非 HTTPS トリガー関数には、 アクティブ/パッシブ パターン を使用することを強くお勧めします。 非 HTTP トリガー関数のアクティブ/アクティブデプロイを作成できます。 ただし、2 つのアクティブなリージョンが互いに対話または調整する方法を検討する必要があります。 それぞれが同じ Service Bus キューでトリガーされる 2 つのリージョンに同じ関数アプリをデプロイすると、それらのアプリは、そのキューのデキューでの競合コンシューマーとして機能します。 つまり、各メッセージはどちらか 1 つのインスタンスによってのみ処理されますが、これは、1 つの Service Bus インスタンスに単一障害点が引き続き存在することも示しています。
代わりに、2 つの Service Bus キューを、プライマリ リージョンに 1 つ、セカンダリ リージョンに 1 つデプロイすることもできます。 この場合は、それぞれが自身のリージョン内でアクティブな Service Bus キューを指している 2 つの関数アプリが存在することになります。 このトポロジでの課題は、キュー メッセージを 2 つのリージョン間でどのように分散するかという点です。 これは多くの場合、各発行元がメッセージを "両方の" リージョンに発行しようとするため、各メッセージが両方のアクティブな関数アプリによって処理されることを示しています。 これにより、目的のアクティブ/アクティブのパターンが作成されますが、同時に、コンピューティングの重複やデータがいつ、またはどのように統合されるかに関する他の課題も生じます。
非 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 を使用したフェールオーバーに関する情報と考慮事項の詳細を参照してください。