Azure Logic Apps の事業継続とディザスター リカバリー
予期しないイベントがビジネスや顧客に与える影響および結果を軽減するために、ディザスター リカバリー (DR) ソリューションを用意しておくことで、データの保護、重要なビジネス機能をサポートするリソースの迅速な復元、およびの事業継続 (BC)を維持するための操作を実行し続けることができます。 たとえば、中断には、停止、基盤となるインフラストラクチャまたはストレージ、ネットワーク、またはコンピューティングリソースなどのコンポーネントの損失、回復不能なアプリケーション エラー、またはデータセンター全体の損失が含まれます。 企業または組織は、事業継続とディザスター リカバリー (BCDR) とディザスターリカバリーソリューションを準備しておくことにより、計画済みまたは計画外の中断に迅速に対応し、顧客のダウンタイムを短縮できます。
この記事では、Azure Logic Apps を使用して自動化されたワークフローを作成するときに利用できる BCDR ガイダンスと戦略について説明します。 ロジック アプリのワークフローを使用すると、記述する必要があるコードの量を減るため、アプリ、クラウド サービス、オンプレミスのシステム間でデータを簡単に統合し、調整することができます。 BCDR を計画するときは、ロジック アプリだけでなく、ロジック アプリで使用する次の Azure リソースについても考慮してください。
接続: ロジック アプリ ワークフローから他のアプリ、サービス、およびシステムに対して作成します。 詳細については、このトピックで後述する「リソースへの接続」を参照してください。
オンプレミス データ ゲートウェイ: オンプレミスのシステムのデータにアクセスするためロジック アプリで作成して使用する Azure リソースです。 各ゲートウェイ リソースは、ローカル コンピューター上の個別のデータ ゲートウェイ インストールを表します。 詳細については、このトピックで後述する「オンプレミス データ ゲートウェイ」を参照してください。
統合アカウント: ロジック アプリが 企業間 (B2B) のエンタープライズ統合シナリオに使用する成果物を定義して格納します。 たとえば、統合アカウントに複数のリージョンにわたるディザスター リカバリーを設定できます。
プライマリおよびセカンダリの場所
各ロジック アプリでは、Azure リージョン (例: "米国西部") など、デプロイに使用する場所を指定する必要があります。 このディザスター リカバリー戦略では、Azure Logic Apps も利用可能な別の場所にあるスタンバイまたはバックアップ ロジック アプリにフェールオーバーするように、プライマリ ロジック アプリを設定することに重点を置いています。 こうすることで、プライマリに損失、中断、または障害が発生した場合、セカンダリは作業を引き継ぐことができます。 この戦略では、セカンダリ ロジック アプリと依存リソースがすでに別の場所に展開され、準備ができている必要があります。
Note
また、統合アカウントに格納されている取引先、契約、スキーマ、マップ、証明書などの B2B 成果物でロジックアプリを使用する場合は、統合アカウントとロジック アプリの両方で同じ場所を使用する必要があります。
適切な DevOps プラクティスに従っている場合、ロジック アプリとその依存リソースを定義して展開するのに、Azure Resource Manager テンプレートをすでに使用しています。 Resource Manager テンプレートでは、単一のデプロイ定義を使用し、パラメーター ファイルにより各展開先に使用する構成値を指定することができます。 この機能を使うと、開発、テスト、運用など、異なる環境に同じロジック アプリを展開できるようになります。 また、同じロジック アプリを別の Azure リージョンにデプロイすることもできます。これにより、ペアになっているリージョンを使用するディザスター リカバリー戦略がサポートされます。
フェールオーバー戦略では、ロジック アプリと場所は次の要件を満たす必要があります。
セカンダリ ロジック アプリのインスタンスは、プライマリ ロジック アプリのインスタンスと同じアプリ、サービス、およびシステムにアクセスできます。
どちらのロジック アプリのインスタンスもホスト型は同じです。 このため、両方のインスタンスが、グローバル マルチテナント Azure Logic Apps のリージョンまたはシングルテナント Azure Logic Apps のリージョンにデプロイされます。 BCDR のペアになっているリージョンのベストプラクティスと詳細については、「Azure でのリージョン間レプリケーション: 事業継続とディザスター リカバリー」を参照してください。
例: マルチテナント Azure
この例では、このシナリオに対して、グローバル マルチテナント Azure 内の個別のリージョンに展開された、プライマリおよびセカンダリのロジック アプリ インスタンスを示します。 1つの Resource Manager テンプレートが、ロジック アプリのインスタンスおよびそれらのロジック アプリで必要とされる依存リソースの両方を定義します。 個別のパラメーター ファイルは、各デプロイ場所に使用する構成値を指定します。
リソースへの接続
Azure Logic Apps には、数百ものコネクタ操作が用意されています。ロジック アプリ ワークフローはこれらを使用して、他のアプリ、サービス、システムなどのリソース (Azure Storage アカウント、SQL Server データベース、職場または学校の電子メール アカウントなど) を利用することができ ます。 ロジック アプリがこれらのリソースへのアクセスを必要とする場合は、これらのリソースへのアクセスを認証する接続を作成します。 各接続は、特定の場所に存在する個別の Azure リソースのため、他の場所のリソースが使用することはできません。
ディザスター リカバリー戦略では、ロジック アプリのインスタンスに関連する依存リソースが存在する場所について検討してください。
プライマリ インスタンスと依存リソースは異なる場所に存在します。 この場合、セカンダリ インスタンスは同じ依存リソースまたはエンドポイントに接続できます。 ただし、セカンダリ インスタンス専用の接続を作成する必要があります。 こうすることで、プライマリの場所が使用できなくなった場合、セカンダリの接続は影響を受けません。
たとえば、プライマリ ロジック アプリが Salesforce などの外部サービスに接続しているとします。 通常、外部サービスの可用性と場所は、ロジック アプリの可用性から独立しています。 この場合、セカンダリ インスタンスは同じサービスに接続できますが、独自の接続が必要です。
プライマリ インスタンスと依存リソースは同じ場所に存在します。 この場合、依存リソースはバックアップまたは複製されたバージョンを別の場所に配置し、セカンダリ インスタンスがこれらのリソースに引き続きアクセスできるようにする必要があります。
たとえば、プライマリ ロジック アプリが、Azure SQL Database など、同じ場所またはリージョンにあるサービスに接続しているとします。 このリージョン全体が使用できなくなった場合、そのリージョンの Azure SQL Database サービスも利用できなくなる可能性があります。 この場合、望ましいのは、セカンダリ インスタンスがレプリケートされたデータベースまたはバックアップ データベースを、そのデータベースへの個別の接続で使用することです。
オンプレミス データ ゲートウェイ
ロジック アプリがマルチテナント Azure で実行されていて、SQL Server データベースなどのオンプレミス リソースへのアクセスが必要な場合は、オンプレミス データ ゲートウェイをローカル コンピューターにインストールする必要があります。 そうすることで、Azure portal にデータ ゲートウェイ リソースを作成できるようになり、リソースへの接続の作成時にロジック アプリがゲートウェイを使用できるようになります。
データ ゲートウェイ リソースは、ロジック アプリのリソースと同様に、場所または Azure リージョンに関連付けられています。 ディザスター リカバリー戦略では、ロジック アプリで使用できるようにデータ ゲートウェイを維持しておく必要があります。 複数のゲートウェイがインストールされている場合は、ゲートウェイに対してい高可用性を有効にすることができます。
アクティブ/アクティブとアクティブ/パッシブ ロールの比較
プライマリとセカンダリの場所を設定し、次の場所にあるロジック アプリ インスタンスでこれらのロールを実行できるようにします。
| プライマリ/セカンダリ ロール | 説明 |
|---|---|
| アクティブ/アクティブ | 両方の場所にあるプライマリ ロジック アプリとセカンダリ ロジック アプリのインスタンスは、次のいずれかのパターンに従って要求をアクティブに処理します。 - - : 両方のインスタンスでエンドポイントをリッスンし、必要に応じて各インスタンスへのトラフィックを負荷分散することができます。 - - : キューからのメッセージに対してインスタンスが競合するように、両方のインスタンスを競合コンシューマーにすることができます。 1 つのインスタンスで障害が発生すると、もう一方のインスタンスがワークロードを引き継ぎます。 |
| アクティブ/パッシブ | プライマリ ロジック アプリのインスタンスは、ワークロード全体をアクティブに処理しますが、セカンダリ インスタンスはパッシブ (無効または非アクティブ) です。 セカンダリは、プライマリが使用できないか、中断または障害によって動作していないことを示す信号を待ち、アクティブなインスタンスとしてワークロードを引き継ぎます。 |
| 組み合わせ | 一部のロジック アプリはアクティブ/アクティブ ロールを実行し、他のロジックアプリはアクティブ/パッシブ ロールを再生します。 |
アクティブ/アクティブの例
これらの例は、ロジック アプリ インスタンスがどちらも要求またはメッセージをアクティブに処理するアクティブ/アクティブのセットアップを示しています。 他の一部のシステムまたはサービスは、次のいずれかの方法で、インスタンス間に要求またはメッセージを配布します。
トラフィックをルーティングするハードウェアなどの「物理」 ロードバランサー
Azure Load Balancer、Azure API Management などの「ソフト」ロードバランサー。 API Management では、着信トラフィックを負荷分散する方法を決定するポリシーを指定できます。 また、Azure Service Bus など、状態のトラッキングをサポートするサービスを使用することもできます。
この例では、主に Azure Load Balancer について示されていますが、シナリオのニーズに最適なオプションを使用することもできます。
各ロジック アプリのインスタンスはコンシューマーとして機能し、キューからのメッセージに対して両方のインスタンスが競合します。
アクティブ/パッシブの例
この例では、プライマリ ロジック アプリのインスタンスが 1 つの場所でアクティブになっているものの、セカンダリ インスタンスが別の場所で非アクティブのままになっているアクティブ/パッシブのセットアップを示します。 プライマリに中断または障害が発生した場合、セカンダリをアクティブ化してワークロードを引き継がせるスクリプトをオペレーターに実行させることができます。
アクティブ/アクティブとアクティブ/パッシブの組み合わせ
この例では、プライマリの場所にアクティブなロジック アプリのインスタンスが両方あり、セカンダリの場所にアクティブ/パッシブ ロジック アプリのインスタンスがある場合の設定の組み合わせを示します。 プライマリの場所で中断や障害が発生した場合、セカンダリの場所にあるアクティブなロジック アプリは、既に一部のワークロードを処理しているため、ワークロード全体を引き継ぐことができます。
プライマリの場所では、アクティブなロジック アプリがメッセージの Azure Service Bus キューをリッスンし、もう 1 つのアクティブなロジック アプリが Office 365 Outlook のポーリング トリガーを使用してメールをチェックします。
セカンダリの場所では、アクティブなロジック アプリが同じ Service Bus キューからのメッセージをリッスンして競合することにより、プライマリの場所にあるロジック アプリと連携します。 一方、パッシブな非アクティブ ロジック アプリは、プライマリの場所が使用できなくなったときに電子メールをチェックするようにスタンバイで待機していますが、電子メールを再読み込みしないように無効になっています。
ロジック アプリの状態と履歴
ロジック アプリがトリガーされ、実行されると、アプリの状態は、アプリが開始した場所と同じ場所に格納され、別の場所には転送できなくなります。 障害または中断が発生した場合、進行中のワークフロー インスタンスはすべて破棄されます。 プライマリとセカンダリの場所が設定されている場合、新しいワークフロー インスタンスはセカンダリの場所で実行を開始します。
破棄された進行中のインスタンスを削減する
破棄された進行中のワークフロー インスタンスの数を最小限に抑えるには、次の例のように、実装できる各種メッセージ パターンから選択します。
-
このエンタープライズ メッセージ パターンは、ビジネス プロセスを小さなステージに分割します。 各ステージで、そのステージのワークロードを処理するロジック アプリを設定します。 ロジック アプリは、Azure Service Bus のキューやトピックなど、非同期メッセージング プロトコルを使用して相互に通信します。 プロセスを小さなステージに分割すると、障害の発生したロジック アプリのインスタンスでスタックする可能性があるビジネス プロセスの数を削減できます。 このパターンの一般的な情報については、「Enterprise 統合パターン - ルート指定スリップ」を参照してください。
この例では、各ロジック アプリが 1 つのステージを表し、Service Bus キューを使用してプロセス内の次のロジック アプリと通信するルート指定スリップ パターンを示しています。
プライマリとセカンダリのロジック アプリのインスタンスがどちらもそれぞれの場所で同じルート指定スリップ パターンに従っている場合、それらのインスタンスに対してアクティブ/アクティブ ロールを 設定することにより、競合コンシューマー パターンを実装できます。
トリガーと実行履歴へのアクセス
ロジック アプリの過去のワークフロー実行に関する詳細情報を取得するには、アプリのトリガーおよび実行履歴を確認します。 ロジック アプリの実行履歴は、ロジックアプリが実行されたのと同じ場所またはリージョンに格納されます。つまり、この履歴を別の場所に移行することはできません。 プライマリ インスタンスがセカンダリ インスタンスにフェールオーバーした場合、アクセスできるのは、それらのインスタンスが実行された各場所にある各インスタンスのトリガーおよび実行履歴のみです。 ただし、Azure Log Analytics ワークスペースに診断イベントを送信するようにロジック アプリを設定すると、ロジック アプリの履歴に関する場所に依存しない情報を取得できます。 これにより、複数の場所で実行されているロジックアプリの正常性と履歴を確認できます。
トリガー タイプのガイダンス
ロジック アプリで使用するトリガー タイプにより、ディザスター リカバリー戦略で複数の場所にロジックアプリを設定する方法の選択肢が決まります。 以下は、ロジック アプリで利用できるすべてのトリガー タイプの一覧です。
Recurrence トリガー
Recurrence トリガーは、特定のサービスまたはエンドポイントから独立しており、指定されたスケジュールに基づいてのみ起動し、その他の条件はありません。次に例を示します。
- 固定の頻度と間隔 (10 分ごとなど)
- より詳細なスケジュール (毎月最後の月曜日の午後 5:00 時など)
ロジック アプリが Recurrence トリガーで起動する場合、アクティブ/パッシブ ロールでプライマリおよびセカンダリ ロジック アプリのインスタンスを設定する必要があります。 中断または障害発生後にビジネス プロセスを復元するための目標期間を示す目標復旧時間 (RTO) を削減するため、アクティブ/パッシブ ロールとパッシブ/アクティブ ロールの組み合わせを使用して、ロジック アプリのインスタンスを設定します。 このセットアップでは、スケジュールを複数の場所に分割します。
たとえば、10 分ごとに実行する必要のあるロジック アプリがあるとします。 ロジック アプリと場所を設定することで、プライマリの場所が使用できなくなった場合に、セカンダリの場所が作業を引き継ぐことができます。
プライマリの場所で、これらのロジック アプリのアクティブ/パッシブ ロールを設定します。
アクティブな有効化されたロジック アプリでは、Recurrence トリガーを 1 時間の最初から開始し、20 分ごとに繰り返すように設定します (午前 9:00、午前 9:20 など)。
パッシブな無効化されたロジックアプリでは、Recurrence トリガーを同じスケジュールで設定しますが、10 分後から開始し、20 分ごとに繰り返すように設定します (午前 9:10、午前 9:30 など)。
セカンダリの場所では、これらのロジック アプリに対して パッシブ/アクティブを設定します。
パッシブな無効化されたロジック アプリでは、Recurrence トリガーをプライマリの場所にあるアクティブなロジック アプリと同じスケジュールに設定します。つまり1時間の最初から開始し 20 分ごとに繰り返します (午前 9:00、午前 9:10 など) 。
アクティブな有効化されたロジック アプリでは、Recurrence トリガーをプライマリの場所にあるパッシブなロジック アプリと同じスケジュールに設定します。つまり 10 分後から開始し、20 分ごとに繰り返すように設定します (午前 9:10、午前 9:20 など)。
プライマリの場所で破壊的なイベントが発生した場合は、別の場所にあるパッシブなロジック アプリをアクティブ化します。 こうすることで、障害の発見に時間がかかる場合、このセットアップにより、遅延中に失われた繰り返しの数が制限されます。
ポーリング トリガー
処理する新しいデータが特定のサービスまたはエンドポイントから利用できるかどうかを定期的に確認するには、ロジックアプリでポーリング トリガーを使用し、固定の繰り返しスケジュールに基づいてサービスまたはエンドポイントを定期的に呼び出します。 サービスまたはエンドポイントが提供するデータは、次のいずれかのタイプです。
- 常に読み取り可能なデータを記述する静的データ
- 読み取り後に使用できなくなったデータを記述する揮発性データ。
同じデータを繰り返し読み取ることがないように、ロジック アプリでは、クライアント側またはサーバー、サービス、またはシステム側で状態を維持することにより、以前に読み取られたデータを記憶する必要があります。
クライアント側の状態で動作するロジック アプリは、状態を維持できるトリガーを使用します。
たとえば、電子メールの受信トレイから新しいメッセージを読み取るトリガーでは、最後に読み取られたメッセージをそのトリガーが記憶できる必要があります。 これにより、トリガーは、次の未読メッセージが到着した場合にのみロジック アプリを起動します。
サーバー、サービス、またはシステム側の状態で動作するロジック アプリは、プロパティ値またはサーバー、サービス、またはシステム側の設定を使用します。
たとえば、データベースから行を読み取るクエリ ベースのトリガーでは、行に
isRead列がFALSEに設定されている必要があります。 トリガーが行を読み取るたびに、ロジック アプリは、isRead列をFALSEからTRUEに変更して、その行を更新します。このサーバー側のアプローチは、キューのセマンティクスを持つ Service Bus キューまたはトピックと同様に機能します。この場合、ロジック アプリがメッセージを処理するときにトリガーがメッセージの読み取りとロックを行います。 ロジック アプリの処理が完了すると、トリガーによってキューまたはトピックからメッセージが削除されます。
ディザスター リカバリーの観点から、ロジック アプリのプライマリ インスタンスとセカンダリ インスタンスを設定するとき、ロジック アプリがクライアント側とサーバー側のどちらで状態を追跡するかに基づいて、これらの動作を考慮してください。
クライアント側の状態で動作するロジック アプリの場合は、ロジックアプリが同じメッセージを複数回読み取ることがないようにしてください。 任意の時点でアクティブなロジック アプリのインスタンスを持つことができるのは 1 つの場所のみです。 プライマリのインスタンスが別の場所にフェールオーバーするまで、別の場所にあるロジック アプリのインスタンスが非アクティブ、または無効になっていることを確認します。
たとえば、Office 365 Outlook トリガーは、クライアント側の状態を維持し、最後に読み取られた電子メールのタイムスタンプを追跡して、読み取りの重複を回避します。
サーバー側の状態で動作するロジック アプリの場合、ロジック アプリのインスタンスが競合コンシューマーとして機能するアクティブ/アクティブ ロール、またはプライマリ インスタンスが別の場所にフェールオーバーするまで代替インスタンスが待機するアクティブ/パッシブ ロールのいずれかを実行するようにロジック アプリを設定します。
たとえば、Azure Service Bus キューなど、メッセージ キューからの読み取りではサーバー側の状態を使用することで、キュー サービスがメッセージのロックを保持し、他のクライアントが同じメッセージを読み取れないようにします。
注意
ロジック アプリが Service Bus キューからなど、特定の順序でメッセージを読み取る必要がある場合、競合コンシューマー パターンを使用できます。これは Service Bus セッションと組み合わせた場合にのみ可能でシーケンシャルなコンボイ パターンとも呼ばれています。 それ以外の場合は、アクティブ/パッシブ ロールでロジック アプリのインスタンスを設定する必要があります。
Request トリガー
Request トリガーを使用すると、ロジック アプリを他のアプリ、サービス、およびシステムから呼び出せるようになります。通常は、次の機能を提供するために使用されます。
他から呼び出せるロジック アプリのダイレクト REST API。
たとえば、Request トリガーを使用してロジック アプリを起動すると、他のロジック アプリは呼び出しワークフロー - Logic Apps アクションを使ってトリガーを呼び出せるようになります。
ロジック アプリの webhook またはコールバック機構
たとえば、特定のタスクを実行する PowerShell スクリプトを使用して、ユーザー操作またはルーチンを手動で実行してロジック アプリを呼び出すことができます。
ディザスター リカバリーの観点からすると、Request トリガーはパッシブな受信側です。ロジック アプリは何の作業を実行せず、他のサービスまたはシステムが明示的にトリガーを呼び出すまで待機します。 パッシブなエンドポイントとして、次の方法でプライマリおよびセカンダリのインスタンスを設定できます。
アクティブ/アクティブ: どちらのインスタンスも、要求または呼び出しをアクティブに処理します。 呼び出し元またはルーターは、これらのインスタンス間のトラフィックをバランス化または分散します。
アクティブ/パッシブ:プライマリ インスタンスだけがアクティブになり、すべての作業が処理されまる一方、セカンダリ インスタンスは、プライマリに中断または障害が発生するまで待機します。 呼び出し元またはルーターは、セカンダリ インスタンスを呼び出すタイミングを決定します。
推奨されるアーキテクチャとして、Azure API Management を Request トリガーを使用するロジック アプリのプロキシとして使用できます。 API Management には、組み込みのリージョン間の回復機能および複数のエンドポイント間でトラフィックをルート指定する機能が用意されています。
webhook トリガー
webhook トリガーは、コールバック URL をサービスに渡すことにより、ロジック アプリがそのサービスを登録する機能を提供します。 ロジック アプリは、特定のイベントがそのサービスのエンドポイントで特定のイベントが発生するのをリッスンし、待機します。 イベントが発生すると、サービスはコールバック URL を使用して webhook トリガーを呼び出し、次にロジック アプリが実行されます。 有効にすると、webhook トリガーはサービスに登録されます。 無効にすると、トリガーはサービスから登録解除します。
ディザスター リカバリーの観点から、webhook トリガーを使用してアクティブ/パッシブ ロールを実行するプライマリ インスタンスとセカンダリ インスタンスを設定します。これは、1 つのインスタンスのみが登録されたエンドポイントからイベントまたはメッセージを受信するためです。
プライマリ インスタンスの正常性の評価
ディザスター リカバリー戦略を機能させるには、次のタスクを実行する方法がソリューションに必要です。
このセクションでは、そのまま、または独自の設計の基礎として、使用できる 1 つのソリューションについて説明します。 次にこのソリューションの大まかな視覚的な概要を示します。
プライマリ インスタンスの可用性の確認
プライマリ インスタンスが使用可能か、実行されているか、または動作可能かを判断するには、プライマリ インスタンスと同じ場所に「正常性チェック」ロジック アプリを作成します。 この正常性チェック アプリは、別の場所から呼び出すことができます。 正常性チェック アプリが正常に応答した場合は、そのリージョンの Azure Logic Apps サービスの基礎となるインフラストラクチャは使用可能であり、動作しています。 正常性チェックアプリが応答に失敗した場合は、その場所はすでに正常ではないと見なすことができます。
このタスクでは、次のタスクを実行する基本的な正常性チェック ロジック アプリを作成します。
Request トリガーを使用して、ウォッチドッグ アプリから呼び出しを受信する。
Response アクションを使用して、チェックしたロジック アプリが動作するかどうかを示す状態を含めて応答する。
重要
正常性チェック ロジック アプリでは、アプリが非同期的ではなく同期的に応答するように、Response アクションを使用する必要があります。
必要に応じて、プライマリの場所が正常かどうかをさらに判断するため、この場所でターゲットのロジック アプリと対話する他のサービスの正常性について考慮することができます。 これらの他のサービスの正常性も評価するように正常性チェック ロジック アプリを拡張するだけです。
ウォッチドッグ ロジック アプリの作成
プライマリ インスタンスの正常性を監視し、正常性チェック ロジックアプリを呼び出すには、「ウォッチドッグ」ロジック アプリを別の場所に作成します。 たとえば、正常性チェック ロジックの呼び出しが失敗した場合に、ウォッチドッグからオペレーション チームにアラートを送信し、エラーおよびプライマリ インスタンスが応答しない理由について調査できるように、ウォッチドッグ ロジック アプリを設定することができます。
重要
ウォッチドッグ ロジック アプリが、 プライマリ ロケーションとは異なる場所にあることを確認します。 プライマリの場所で Azure Logic Apps に問題が発生した場合、ウォッチドッグ ロジック アプリ ワークフローが実行されない場合があります。
このタスクでは、セカンダリの場所で、次のタスクを実行するウォッチドッグ ロジック アプリを作成します。
Recurrence トリガーを使用し、固定またはスケジュールされた繰り返しを基に実行する。
繰り返しを目標復旧時間 (RTO) の許容レベルを下回る値に設定します。
HTTP アクションを使用して、プライマリの場所で正常性チェック ロジック アプリ ワークフローを呼び出します。
また、数回エラーが発生した後に別のロジック アプリを呼び出し、プライマリで障害が発生した場合にセカンダリの場所へ自動的に切り替える、より洗練されたウォッチドッグ ロジック アプリを作成することもできます。
セカンダリ インスタンスのアクティブ化
セカンダリ インスタンスを自動的にアクティブにするには、Azure Resource Manager コネクタなどの管理 API を呼び出し、セカンダリの場所で適切なロジック アプリをアクティブ化するロジック アプリを作成します。 ウォッチドッグ アプリを拡張して、所定の数のエラーが発生した後にこのアクティブ化ロジック アプリを呼び出すことができます。
可用性ゾーンを使用したゾーン冗長
各 Azure リージョンにおいて、"可用性ゾーン" とは、局所的な障害にトレラントな物理的に分離された場所です。 そのような障害の範囲は、ソフトウェアやハードウェアの障害から、地震、水害、火災などの事象にまで及びます。 Azure サービスの冗長性と論理的な分離によって、これらのゾーンに耐性が備わります。
回復性と分散型可用性を実現するために、ゾーン冗長性がサポートされ、有効化された Azure リージョンには、少なくとも 3 つの分離された可用性ゾーンが存在します。 Azure Logic Apps プラットフォームでは、これらのゾーンを配置し、ロジック アプリのワークロードをこれらのゾーン全体に分散します。 この機能は、回復性があるアーキテクチャを有効にし、リージョンでデータセンターの障害が発生した場合に高可用性を提供するための重要な要件です。
現時点で、この機能はプレビュー段階であり、特定のリージョンの新しい従量課金ロジック アプリで使用できます。 詳しくは、次のドキュメントをご覧ください。
診断データの収集
ロジック アプリの実行のログ記録を設定し、結果の診断データを Azure Storage、Azure Event Hubs、および Azure Log Analytics などのサービスに送信して、さらに処理することができます。
このデータを Azure Log Analytics で使用する場合は、ロジック アプリの診断設定を設定し、データを複数の Log Analytics ワークスペースに送信することで、プライマリとセカンダリの両方の場所でデータが使用できるようになります。 詳細については、「Azure Monitor ログを設定し、Azure Logic Apps の診断データを収集する」を参照してください。
Azure Storage または Azure Event Hubs にデータを送信する場合は、geo 冗長性を設定することにより、プライマリとセカンダリの両方の場所でデータが使用できるようになります。 詳細と例については、次の記事をご覧ください。