次の方法で共有

Azure Logic Apps の信頼性

  • [アーティクル]

この記事では、可用性ゾーンによるリージョン内の回復性とマルチリージョン デプロイを含め、Azure Logic Apps の信頼性のサポートについて説明します。

回復性は、お客様と Microsoft の間の共同責任であるため、この記事では、お客様が、ニーズに合った回復性があるソリューションを構築する方法についても説明します。

ロジック アプリのワークフローを使用すると、記述する必要があるコードの量を減るため、アプリ、クラウド サービス、オンプレミスのシステム間でデータを簡単に統合し、調整することができます。 回復性を計画する際は、ロジック アプリだけでなく、ロジック アプリで使用する次の Azure リソースについても考慮してください。

マルチテナント Azure Logic Apps は、従量課金ワークフローのコンピューティング インフラストラクチャとリソースを自動的に管理します。 仮想マシン (VM) を構成または管理する必要はありません。 従量課金ワークフローでは、コンピューティング インフラストラクチャが多くの顧客間で共有されます。

シングルテナント Azure Logic Apps では、Standard ワークフローを専用のコンピューティング リソースで実行します。これはお客様専用で、"プラン" と呼ばれます。 各プランには複数のインスタンスを含めることができ、それらのインスタンスは、必要に応じて複数の可用性ゾーン間で分散することができます。 ワークフローは、プランのインスタンスで実行されます。

運用環境デプロイに関する推奨事項

分離またはネットワーク セキュリティの要件があるエンタープライズおよびセキュリティで保護されたワークフローの場合、マルチテナント Azure Logic Apps の従量課金ワークフローではなく、シングルテナント Azure Logic Apps で Standard ワークフローを作成して実行することをお勧めします。 詳細については、「さまざまな環境を作成してデプロイする」を参照してください。

シングルテナント Azure Logic Apps を使用した運用環境のデプロイでは、ゾーン冗長を有効にして、ロジック アプリ リソースを複数の可用性ゾーン間で分散する必要があります。

一時的な障害

一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 短期間経過すると、自然に修正されます。 アプリケーションが、通常は影響を受ける要求を再試行することにより、一時的な障害を処理することが重要です。

すべてのクラウド ホステッド アプリケーションは、クラウド ホステッド API、データベース、その他のコンポーネントと通信するときに、Azure の一時的な障害処理ガイダンスに従う必要があります。 一時的な障害の処理の詳細については、「一時的な障害を処理するための推奨事項」を参照してください。

Azure Logic Apps では、多くのトリガーおよびアクションで "再試行ポリシー" がサポートされます。これは、一時的な障害が原因で失敗した要求を自動的に再試行します。 ロジック アプリの再試行ポリシーを変更または無効にする方法については、「Azure Logic Apps におけるエラーと例外の処理」を参照してください。

アクションが失敗した場合、以降のアクションの動作をカスタマイズできます。 また、"スコープ" を作成して、一緒に失敗または成功する可能性のある関連アクションをグループ化することもできます。

Azure Logic Apps での障害の処理について詳しくは、「Azure Logic Apps におけるエラーと例外の処理」を参照してください。

可用性ゾーンのサポート

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

Azure の可用性ゾーンの詳細については、「可用性ゾーンとは」を参照してください。

Azure Logic Apps では、"ゾーン冗長" がサポートされており、コンピューティング リソースが複数の可用性ゾーン間で分散されます。 ロジック アプリ ワークフローのリソースを可用性ゾーン間で分散すると、運用ロジック アプリ ワークロードの回復性と信頼性が向上します。

マルチテナント Azure Logic Apps の新規または既存の従量課金ロジック アプリでは、ゾーン冗長が有効になっています。

シングルテナント Azure Logic Apps では、ホスティング オプションのワークフロー サービス プランを使用する Standard ワークフローの場合、必要に応じてゾーン冗長を有効にすることができます。

ホスティング プランの App Service Environment v3 を使用する Standard ワークフローの場合、必要に応じてゾーン冗長を有効にすることができます。 App Service Environments v3 で可用性ゾーンをサポートする方法の詳細については、「App Service の信頼性」を参照してください。

サポートされているリージョン

可用性ゾーンをサポートする任意のリージョンにデプロイされた従量課金ロジック アプリは、自動的にゾーン冗長になります。 西日本は例外です。このリージョンでは、一部の依存関係サービスでゾーン冗長がまだサポートされていないため、現時点ではゾーン冗長ロジック アプリはサポートされていません。

Azure App Service の可用性ゾーンをサポートする任意のリージョンに、ワークフロー サービス プランを使用するゾーン冗長 Standard ロジック アプリをデプロイできます。 西日本は例外です。このリージョンでは、ゾーン冗長ロジック アプリはサポートされていません。 詳細については、「Azure App Service の信頼性」を参照してください。

App Service Environment v3 の可用性ゾーンをサポートするリージョンについては、「リージョン」を参照してください。

要件

ワークフロー サービス プランのインスタンスを少なくとも 3 つデプロイする必要があります。 各インスタンスは、ほぼ 1 つの VM に対応します。 これらのインスタンス (VM) を可用性ゾーン間で分散するには、少なくとも 3 つのインスタンスが必要です。

考慮事項

  • ストレージ: ステートフル Standard ワークフローの外部ストレージを構成する場合、ゾーン冗長のストレージ アカウントを構成する必要があります。 詳細については、「Azure Functions のストレージに関する考慮事項」を参照してください。

  • コネクタ: ロジック アプリがゾーン冗長の場合、組み込みコネクタは自動的にゾーン冗長になります。

  • 統合アカウント: Premium SKU 統合アカウントは、既定でゾーン冗長です。

コスト

ゾーン冗長の使用に追加のコストは適用されません。ゾーン冗長は、マルチテナント Azure Logic Apps の新規および既存の従量課金ワークフローに対して自動的に有効になります。

ワークフロー サービス プランを使用する Standard ワークフローをシングルテナント Azure Logic Apps で使用する場合、プランのインスタンスが 3 つ以上ある限り、可用性ゾーンを有効にしても追加コストは適用されません。 プラン SKU、指定した容量、自動スケーリング条件を基にスケールアップまたはスケールダウンした任意のインスタンスに基づいて課金されます。 可用性ゾーンを有効にした場合、3 つ未満のインスタンスの容量を指定すると、プラットフォームによって、最小の 3 つのインスタンスが適用され、これら 3 つのインスタンスに対して課金されます。

App Service Environment v3 には、ゾーン冗長のための特定の価格モデルがあります。 App Service Environment v3 の価格情報については、「価格」を参照してください。

可用性ゾーン構成のサポート

従量課金ロジック アプリ ワークフローではゾーン冗長がサポートされるため、構成は必要ありません。

  • ゾーン冗長を使用する新しいワークフローを作成する。

    Standard ロジック アプリ ワークフローのゾーン冗長を有効にするには、「ロジック アプリのゾーン冗長を有効にする」を参照してください。

  • 移行

    サービス プランを作成した後、ゾーン冗長を有効にすることはできません。 代わりに、ゾーン冗長を有効にして新しいプランを作成し、古いプランを削除する必要があります。

  • ゾーン冗長を無効にする。

    ワークフロー サービス プランを作成した後、ゾーン冗長を無効にすることはできません。 代わりに、ゾーン冗長を無効にして新しいプランを作成し、古いプランを削除する必要があります。

容量の計画と管理

可用性ゾーンの障害に備えるには、サービスの容量の "オーバープロビジョニング" を検討します。 オーバープロビジョニングにより、ソリューションは、ある程度の容量損失を許容でき、パフォーマンスが低下することなく引き続き機能できます。

オーバープロビジョニングするインスタンスの数を確認するには、プラットフォームによってインスタンスが複数のゾーン間で分散されることを認識しておくことが重要です。 少なくとも 1 つのゾーンの障害を考慮する必要があります。

プロビジョニングする必要があるインスタンスの合計数を確認するには、次の手順に従います。

  1. ピーク時のワークロードに必要なインスタンスの数を決定します。 次の例では、2 つのシナリオを使用します。 1 つは 3 つのインスタンスを使用し、もう 1 つは 4 つのインスタンスを使用します。
  2. ピーク時のワークロード インスタンス数に係数 [(ゾーン数/(ゾーン数-1)] を乗算して、オーバープロビジョニングするインスタンスを取得します。
  3. 結果を最も近い整数に四捨五入します。

Note

次の表では、3 つの可用性ゾーンを使用していることを前提としています。 別の可用性ゾーン数を使用する場合は、数式を適宜調整してください。

ピーク時のワークロード インスタンス数 係数 [(ゾーン数/(ゾーン数-1)] 式 プロビジョニングするインスタンス (丸め)
3 3/2 または 1.5 (3 x 1.5 = 4.5) 5 個のインスタンス
4 3/2 または 1.5 (4 x 1.5 = 6) 6 インスタンス

ゾーン間のトラフィック ルーティング

通常の操作中、ワークフローの呼び出しでは、リージョン内の任意の可用性ゾーンのコンピューティング リソースを使用できます。

通常の操作中、ワークフローの呼び出しは、すべての可用性ゾーンにわたってすべての使用可能なプラン インスタンス間に分散されます。

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

検出と対応: Azure Logic Apps プラットフォームは、可用性ゾーンでの障害の検出を担当します。 ゾーンのフェールオーバーを開始するために何もする必要はありません。

アクティブな要求: 可用性ゾーンが使用できなくなった場合、障害のある可用性ゾーン内の VM で実行されている進行中のワークフロー実行は終了します。 そのワークフローは、Azure Logic Apps プラットフォームによって、別の可用性ゾーン内の別の VM で自動的に再開されます。 この動作により、新しい VM が残りの可用性ゾーンに追加されるため、アクティブなワークフローでは、一時的な障害が発生したり、待機時間が長くなったりする可能性があります。

フェールバック

可用性ゾーンが復旧すると、Azure Logic Apps によって、復旧した可用性ゾーンにインスタンスが自動的に作成されます。別の可用性ゾーンに作成された一時インスタンスは削除され、トラフィックは通常どおりインスタンス間で再ルーティングされます。

ゾーン障害のテスト

Azure Logic Apps プラットフォームは、ゾーン冗長ロジック アプリ リソースのトラフィック ルーティング、フェールオーバー、フェールバックを管理します。 何も開始する必要はありません。 この機能は完全に管理されているため、可用性ゾーンの障害プロセスを検証する必要はありません。

マルチリージョン サポート

各ロジック アプリは、1 つの Azure リージョンにデプロイされます。 リージョンが使用できなくなった場合、ロジック アプリも使用できなくなります。

代替のマルチリージョン アプローチ

回復性を高めるために、スタンバイまたはバックアップ ロジック アプリをセカンダリ リージョンにデプロイし、プライマリ リージョンが使用できない場合にその他のリージョンにフェールオーバーすることができます。 この機能を有効にするには、次のタスクを実行します。

  • ロジック アプリをプライマリとセカンダリの両方のリージョンにデプロイします。
  • 必要に応じて、リソースへの接続を再構成します。
  • 負荷分散とフェールオーバーのポリシーを構成します。
  • プライマリ インスタンスの正常性を監視し、フェールオーバーを開始する計画を立てます。

複数リージョンへのロジック アプリ ワークフローのデプロイについて詳しくは、次のドキュメントを参照してください。

サービス レベル アグリーメント

Azure Logic Apps のサービス レベル アグリーメント (SLA) では、このサービスの期待される可用性について説明しています。 この契約では、この期待を達成するために満たす必要がある条件についても説明しています。 これらの条件を理解するために、「Online Services のサービス レベル アグリーメント (SLA)」を必ず確認してください。

関連するコンテンツ