Azure Functions geo ディザスター リカバリーAzure Functions geo-disaster recovery

Azure リージョンやデータ センター全体にダウンタイムが発生した場合に、別のリージョンで計算の処理を続行することが重要です。When entire Azure regions or datacenters experience downtime, it is critical for compute to continue processing in a different region. この記事では、ディザスター リカバリーを可能にする関数をデプロイするために使用できる、いくつかの戦略について説明します。This article will explain some of the strategies that you can use to deploy functions to allow for disaster recovery.

基本的な概念Basic concepts

Azure Functions は特定のリージョンで実行されます。Azure Functions run in a specific region. 可用性を高めるために、同じ関数を複数のリージョンにデプロイできます。To get higher availability, you can deploy the same functions to multiple regions. 複数のリージョンでは、関数を "アクティブ/アクティブ" パターンまたは "アクティブ/パッシブ" パターンで実行できます。When in multiple regions you can have your functions running in the active/active pattern or active/passive pattern.

  • アクティブ/アクティブ。Active/active. 両方のリージョンがアクティブであり、(重複またはローテーションして) イベントを受信しています。Both regions are active and receiving events (duplicate or rotationally). アクティブ/アクティブは、HTTPS 関数を Azure Front Door と組み合わせる場合にお勧めします。Active/active is recommended for HTTPS functions in combination with Azure Front Door.
  • アクティブ/パッシブ。Active/passive. 1 つのリージョンがアクティブでイベントを受信し、セカンダリがアイドル状態です。One region is active and receiving events, while a secondary is idle. フェールオーバーが必要になると、セカンダリ リージョンがアクティブになり、処理を引き継ぎます。When failover is required, the secondary region is activated and takes over processing. これは、Service Bus や Event Hubs のような HTTP 以外の関数の場合にお勧めします。This is recommended for non-HTTP functions like Service Bus and Event Hubs.

マルチリージョン デプロイの詳細については、複数のリージョンでアプリを実行する方法に関する記事をご覧ください。Read how to run apps in multiple regions for more information on multi-region deployments.

HTTPS 関数でのアクティブ/アクティブActive/active for HTTPS functions

関数のアクティブ/アクティブ デプロイを実現するには、両方のリージョンの間でイベントを調整できるコンポーネントが必要です。To achieve active/active deployments of functions, it requires some component that can coordinate the events between both regions. HTTPS 関数の場合、この調整は Azure Front Door を使用して行われます。For HTTPS functions, this coordination is accomplished using Azure Front Door. Azure Front Door は、複数のリージョン関数の間で HTTPS 要求をルーティングおよびラウンドロビンすることができます。Azure Front Door can route and round-robin HTTPS requests between multiple regional functions. また、各エンドポイントの正常性も定期的にチェックします。It also periodically checks the health of each endpoint. リージョン関数が正常性チェックに応答しなくなった場合、Azure Front Door はそれをローテーションから外し、正常な関数だけにトラフィックを転送します。If a regional function stops responding to health checks, Azure Front Door will take it out of rotation and only forward traffic to healthy functions.

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

HTTPS 以外の関数でのアクティブ/アクティブActive/active for non-HTTPS functions

HTTPS 以外の関数でも、アクティブ/アクティブ デプロイを実現できます。You can still achieve active/active deployments for non-HTTPS functions. ただし、2 つのリージョンが相互に作用または調整し合う方法を検討する必要があります。However, you need to consider how the two regions will interact or coordinate with one another. 同じ関数アプリを 2 つのリージョンにデプロイし、それぞれが同じ Service Bus キューでトリガーする場合、それらはそのキューのデキューで競合するコンシューマーとして動作します。If you deployed the same function app into two regions, each triggering on the same Service Bus queue, they would act as competing consumers on de-queueing that queue. これは、各メッセージがいずれかのインスタンスによってのみ処理されることを意味しますが、1 つのサービス バスに単一障害点があることも意味します。While this means each message is only being processed by one of the instances, it also means there is still a single point of failure on the single Service Bus. 2 つの Service Bus キューを (プライマリ リージョンに 1 つ、セカンダリ リージョンに 1 つ) デプロイし、2 つの関数アプリがそれらのリージョン キューを指している場合、2 つのリージョン間でどのようにキュー メッセージが分配されるのかが課題になります。If you deploy two Service Bus queues (one in a primary region, one in a secondary region), and the two function apps pointed to their region queue, the challenge now comes in how the queue messages are distributed between the two regions. 多くの場合、これは、各発行元がメッセージを "両方" のリージョンに発行しようとし、各メッセージが両方のアクティブ関数アプリによって処理されることを意味します。Often this means that each publisher attempts to publish a message to both regions, and each message is processed by both active function apps. これによってアクティブ/アクティブ パターンが作成されますが、計算の重複やデータをいつどのように統合するかに関する別の課題が生じます。While this creates an active/active pattern, it creates other challenges around duplication of compute and when or how data is consolidated. このような理由で、HTTPS 以外のトリガーではアクティブ/パッシブ パターンの使用をお勧めします。For these reasons, it is recommended for non-HTTPS triggers to use the active/passive pattern.

HTTPS 以外の関数でのアクティブ/パッシブActive/passive for non-HTTPS functions

アクティブ/パッシブは、1 つの関数だけが各メッセージを処理する方法を提供しますが、障害が発生した場合にセカンダリ リージョンにフェールオーバーするメカニズムを提供します。Active/passive provides a way for only a single function to process each message, but provides a mechanism to fail over to a secondary region in case of a disaster. Azure Functions は Azure Service Bus geo リカバリーAzure Event Hubs geo リカバリーとともに動作します。Azure Functions works alongside Azure Service Bus geo-recovery and Azure Event Hubs geo-recovery.

例として Azure Event Hubs トリガーを使用した場合、アクティブ/パッシブ パターンには以下が含まれます。Using Azure Event Hubs triggers as an example, the active/passive pattern would involve the following:

  • プライマリ リージョンとセカンダリ リージョンの両方にデプロイされた Azure Event Hubs。Azure Event Hub deployed to both a primary and secondary region.
  • プライマリとセカンダリのイベント ハブをペアにするために、geo ディザスターが有効になります。Geo-disaster enabled to pair the primary and secondary Event Hub. これにより、接続情報を変更せずにイベント ハブに接続し、プライマリからセカンダリに切り替えるために使用できる "別名" も作成されます。This also creates an "alias" you can use to connect to event hubs and switch from primary to secondary without changing the connection info.
  • プライマリ リージョンとセカンダリ リージョンの両方にデプロイされた関数アプリ。Function apps deployed to both a primary and secondary region.
  • 関数アプリは、それぞれのイベント ハブの "直接" (別名ではない) 接続文字列でトリガーされます。The function apps are triggering on the direct (non-alias) connection string for its respective event hub.
  • イベント ハブへの発行元は、別名の接続文字列に対して発行する必要があります。Publishers to the event hub should publish to the alias connection string.

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

フェールオーバーの前に、共有された別名に送信する発行元はプライマリ イベント ハブにルーティングします。Before failover, publishers sending to the shared alias will route to the primary event hub. プライマリ関数アプリは、プライマリ イベント ハブだけをリッスンします。The primary function app is listening exclusively to the primary event hub. セカンダリ関数アプリはパッシブになり、アイドル状態になります。The secondary function app will be passive and idle. フェールオーバーが開始されるとすぐに、共有された別名に送信する発行元はセカンダリ イベント ハブにルーティングするようになります。As soon as failover is initiated, publishers sending to the shared alias will now route to the secondary event hub. セカンダリ関数アプリがアクティブになり、自動的にトリガーを開始します。The secondary function app will now become active and start triggering automatically. セカンダリ リージョンへの効果的なフェールオーバーは、イベント ハブから完全に実行でき、それぞれのイベント ハブがアクティブになった場合にのみ関数がアクティブになります。Effective failover to a secondary region can be driven entirely from the event hub, with the functions becoming active only when the respective event hub is active.

Service Busイベント ハブによるフェールオーバーに関する情報と考慮事項の詳細を参照してください。Read more on information and considerations for failover with Service Bus and event hubs.

次のステップNext steps