正常性チェック (プレビュー) を使用して Azure Logic Apps の Standard ワークフローの正常性を監視する

適用対象: Azure Logic Apps (Standard)

Note

この機能はプレビュー段階にあり、「Microsoft Azure プレビューの追加使用条件」が適用されます。

Standard ロジック アプリのワークフローを高い可用性とパフォーマンスで実行できるようにするため、ロジック アプリの正常性チェック機能でワークフローの正常性を監視するように設定します。 この機能により、次の利点が提供され、アプリの回復力が維持されます。

• 顧客に影響を与える前に問題を見つけて対処できるようにする、予防的な監視。

• Azure のロード バランサーからの異常なインスタンスの削除による可用性の向上。

• 異常なインスタンスの置き換えによる自動的な復旧。

Azure Logic Apps での正常性チェックのしくみ

正常性チェックは、異常なインスタンスから要求をリダイレクトし、異常な状態が続く場合は、それらのインスタンスを置き換える Azure App Service プラットフォームの機能です。 Standard ロジック アプリの場合、この目的のために作成し、App Service プラットフォームが定期的に ping を送信する "正常性" ワークフローへのパスを指定できます。 たとえば、次のサンプルは基本的な最小ワークフローを示しています。

正常性チェックを有効にすると、App Service プラットフォームは、すべてのロジック アプリ インスタンスの指定されたワークフロー パスに 1 分間隔で ping を送信します。 ロジック アプリでスケールアウトが必要な場合、Azure はすぐに新しいインスタンスを作成します。 App Service プラットフォームは、ワークフロー パスに再度 ping を送信して、新しいインスタンスの準備ができていることを確認します。

インスタンスで実行されているワークフローが 10 回の要求後に ping に応答しない場合、App Service プラットフォームでインスタンスが異常であると判断され、その特定のロジック アプリのインスタンスは Azure のロード バランサーから削除されます。 最低 2 回の要求で、インスタンスが異常であると判断するために必要な失敗の要求の数を指定できます。 既定の動作のオーバーライドの詳細については、「正常性チェックを使用して App Service インスタンスを監視する」の「構成」を参照してください。

正常性チェックによって異常なインスタンスが削除された後も、この機能はインスタンスに ping を送信し続けます。 インスタンスが正常な状態コード (200 から 299 までの範囲) で応答した場合、正常性チェックはインスタンスをロード バランサーに返します。 ただし、インスタンスが 1 時間異常のままの場合は、正常性チェックによってインスタンスが新しいインスタンスに置き換えられます。 詳細については、「App Service で正常性チェックを使用した処理」を参照してください。

前提条件

• Azure アカウントとサブスクリプション。 サブスクリプションをお持ちでない場合には、無料の Azure アカウントにサインアップしてください。

• 次の属性を持つ Standard ロジック アプリ リソース。

  • 2 つ以上のインスタンスにスケーリングされる App Service プラン。

  • 正常性チェックと次の要素を具体的に実行する "正常性" ワークフロー。

    • [HTTP 要求の受信時] という名前の要求トリガーで始まる。

    • Response という名前の要求アクションが含まれる。 このアクションを 200 から 299までの状態コードを返すように設定する。

    必要に応じて、このワークフローで他のチェックを実行して、依存するサービスが使用可能であり、期待どおりに動作することを確認することもできます。 ベスト プラクティスとして、正常性チェック パスがワークフロー内の重要なコンポーネントを監視していることを確認します。 たとえば、アプリがデータベースとメッセージング システムに依存している場合は、正常性チェックがそれらのコンポーネントにアクセスできることを確認します。

制限事項

• 指定したパスの長さは 65 文字未満にする必要があります。

• 正常性チェックの指定されたパスを変更すると、ロジック アプリが再起動します。 運用アプリへの影響を軽減するには、デプロイ スロットを設定して使用します。

• 正常性チェックは、302 状態コードのリダイレクトに従いません。そのため、リダイレクトを避けて、アプリに存在する有効なパスを選択してください。

正常性チェックの設定

1. Azure portal で、Standard ロジック アプリ リソースにアクセスします。

2. ロジック アプリのメニューで、[問題の診断と解決] を選択します。

3. [問題の診断と解決] ページの検索ボックスで、[正常性チェック機能] を見つけて選択します。

   

4. [正常性チェック機能] セクションで、[ソリューションを表示する] を選択します。

5. 開いたペインで、[正常性チェック機能を構成し有効にする] を選択します。

6. [正常性チェック] タブの [正常性チェック] の横にある [有効にする] を選択します。

7. [正常性プローブ パス] の [パス] ボックスに、ワークフローの有効な URL パスを入力します。次に例を示します。

   /api/{workflow-name}/triggers/{request-trigger-name}/invoke?api-version=2022-05-01

8. 変更を保存。 ツールバーで、 [Save](保存) をクリックします。

9. お使いのロジック アプリ リソースで、次の手順に従って host.json ファイルを更新します。

   1. ロジック アプリのメニューの [開発ツール] で、[高度なツール]>[移動] を選択します。

   2. KuduPlus ツール バーの [デバッグ コンソール] メニューから、[CMD] を選択します。

   3. site/wwwroot フォルダーを参照し、host.json ファイルの横にある [編集] を選択します。

   4. host.json ファイル エディターで、 Workflows.HealthCheckWorkflowName プロパティと正常性ワークフローの名前を追加して、正常性チェックの認証と認可を有効にします。次に例を示します。

      "extensions": {
          "workflow": {
              "settings": {
                  "Workflows.HealthCheckWorkflowName" : "{workflow-name}"
              }
          }
      }
      

   5. 終了したら、 [保存] を選択します。

トラブルシューティング

正常性パスを設定した後、正常性ワークフローがトリガーされません。

1. ロジック アプリのメニューで、[問題の診断と解決] を選択します。

2. [カテゴリのトラブルシューティング] で、[可用性とパフォーマンス] を選択します。

   

3. [状態コード] セクションを見つけて確認します。

   状態コードが 401 の場合は、次の項目を確認します。

   • Workflows.HealthCheckWorkflowName プロパティとお使いの正常性ワークフローの名前が正しく表示されることを確認します。

   • 指定したパスがワークフローと要求トリガー名と一致することを確認します。

一般的な正常性の問題

ロジック アプリ リソースにワークフローはないが、リソースが引き続き複数のインスタンスにスケールアウトして、コストが発生する。

この動作は、ロジック アプリ リソースが正常でない場合、または関連付けられているストレージ アカウントにリソースがアクセスできないときに典型的に発生する可能性があります。 ストレージ アカウントにアクセスをブロックするネットワーク設定がないか、アクセスをブロックするネットワーク ファイアウォール ポリシーがないかを確認してみてください。

ロジック アプリ リソースにはワークフローがあるが、実行されていないか、大量には実行されていない。 それなのに、リソースが引き続き複数のインスタンスにスケールアウトして、コストが発生する。

1. 関連付けられているストレージ アカウントにリソースがアクセスできるかどうかを確認します。

   たとえば、アクセスをブロックするネットワーク設定が、ストレージ アカウントにないでしょうか。 アクセスをブロックするネットワーク ファイアウォール ポリシーがないでしょうか。

2. ワークフローがサービス プロバイダー ベースのトリガーで始まる場合は、トリガーが正常に予期したとおりに動作することを確認します。

   • サービス プロバイダーベースのトリガーが失敗すると、不要なスケーリングが発生し、コストが大幅に増加する可能性があります。

     たとえば、よくある見落としとして、Service Bus キューや Storage BLOB コンテナーなどの宛先へのアクセス許可やアクセス権をロジック アプリに付与せずにトリガーを設定することがあります。

   • 問題を迅速に検出して修正できるように、このようなトリガーは必ず常時監視してください。

ワークフローが断続的に何時間もメッセージの処理を停止するが、それ以外の時間には良好に実行されている。

Standard ロジック アプリがワークフロー サービス プランという名前のホスティング オプションを使用していて、App Service Environment でホストされていない場合は、[Runtime Scale Monitoring] (ランタイム スケールの監視) が有効になっていて、[常時使用可能なインスタンス] が [1] 以上に設定されていることを確認します。

1. まだ開いていなければ、Azure portal でロジック アプリを見つけて開きます。

2. ロジック アプリ メニューの [設定] で、 [構成] を選択します。

3. [ワークフロー ランタイムの設定] タブの [Runtime Scale Monitoring] (ランタイム スケールの監視) で [オン] を選びます。

4. [構成] ページのツール バーで、[保存] を選びます。

5. ロジック アプリ メニューの [設定] で、[Scale Out (App Service のプラン)] を選びます。

6. [アプリのスケールアウト]で、[常時使用可能なインスタンス] の値が [0] に "設定されていない" ことを確認します。

関連するコンテンツ

• ワークフローの診断データを監視および収集する
• Standard ワークフローの拡張テレメトリを有効にして表示する
• 正常性とパフォーマンスのメトリックを表示する