Azure Logic Apps の制約と構成の参考文献

従量課金プラン ロジック アプリ ワークフローでは、同じ設定を使用して、ワークフローを実行し、実行履歴をストレージに保持できる最大日数を制御します。

• マルチテナント Azure Logic Apps では、90 日間の既定の制限は上限と同じです。 この値は減らすことしかできません。

たとえば、保持期間の制限を 90 日間から 30 日間に減らしたとします。 実行履歴から 60 日前の実行が削除されます。 保有期間を 30 日間から 60 日間に増やした場合、20 日前の実行はさらに 40 日間実行履歴に残ります。

ポータル

1. Azure portal 検索ボックスで、ロジック アプリ ワークフローをデザイナーで開きます。

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

3. [ランタイム オプション] で、 [実行履歴の保持期間 (日数)] リストから [カスタム] を選択します。

4. スライダーをドラッグして、目的の日数に変更します。

5. 操作が完了したら、 [ワークフロー設定] のツールバーで、 [保存] を選択します。

ARM テンプレート

Azure Resource Manager テンプレートを使用する場合、この設定はワークフローのリソース定義内にプロパティとして表示されます。これについては、「Microsoft.Logic ワークフロー テンプレートのリファレンス」を参照してください。

{
   "name": "{logic-app-name}",
   "type": "Microsoft.Logic/workflows",
   "location": "{Azure-region}",
   "apiVersion": "2019-05-01",
   "properties": {
      "definition": {},
      "parameters": {},
      "runtimeConfiguration": {
         "lifetime": {
            "unit": "day",
            "count": {number-of-days}
         }
      }
   }
}

Standard ロジック アプリ ワークフローの場合、90 日間の既定の制限を増減できますが、次の設定とその値をロジック アプリのリソースまたはプロジェクトに追加する必要があります。

• Workflows.RuntimeConfiguration.RetentionInDays という名前のアプリ設定

• Runtime.FlowMaintenanceJob.RetentionCooldownInterval という名前のホスト設定

既定では、Workflows.RuntimeConfiguration.RetentionInDays という名前のアプリ設定は、90 日間データを保持するように設定されています。 Runtime.FlowMaintenanceJob.RetentionCooldownInterval という名前のホスト設定は、古いデータを削除するかどうかを 7 日ごとに確認するように設定されています。 これらの既定値のままにすると、''最大'' 97 日経過したデータが表示される場合があります。 たとえば、Azure Logic Apps で X 日に確認し、X 日から 90 日より前のデータを削除し、7 日間待機してから再び実行するとします。 この動作により、ジョブが再び実行されるまで最大 97 日経過したデータが存在することになります。 しかし、間隔を 1 日に設定しても、保有日数を既定値のままにした場合、古いデータを削除するまでの最大遅延日数は 90 + 1 日となります。

ポータル

1. これらの手順に従って、Workflows.RuntimeConfiguration.RetentionInDays という名前のアプリ設定を追加し、ワークフローの実行履歴を保持する日数に値を設定します。

2. これらの手順に従って、Runtime.FlowMaintenanceJob.RetentionCooldownInterval という名前のホスト設定を追加し、保持しない実行履歴を確認してから削除する間隔として日数に値を設定します。

Visual Studio Code

1. これらの手順に従って、Workflows.RuntimeConfiguration.RetentionInDays という名前のアプリ設定を追加し、ワークフローの実行履歴を保持する日数に値を設定します。

2. これらの手順に従って、Runtime.FlowMaintenanceJob.RetentionCooldownInterval という名前のホスト設定を追加し、保持しない実行履歴を確認してから削除する間隔として日数に値を設定します。

シングルテナントの Azure Logic Apps では、Standard ロジック アプリ リソースは、ワークフローを実行するためのプライマリ リソースとしてストレージとコンピューティングを使用します。

Storage

シングルテナント Azure Logic Apps のステートフル ワークフローでは、実行時の永続的なデータ ストレージに Azure Table Storage、ワークフロー実行履歴を維持するための Azure Blob Storage、スケジュール設定のために Azure Queue Storage が使用されます。 たとえば、1 つのストレージ アカウントを使用すると、パーティションあたり最大 2,000 要求、ストレージ アカウント レベルで 1 秒あたり 20,000 要求のレートで大量の要求を処理できます。 1 つのストレージ アカウントで適切に高いスループットを処理できますが、これらのしきい値を超えると、要求レートは調整の対象となり、ワークフローの実行速度が増加すると、パーティション レベルの調整やアカウント レベルの調整が発生する可能性があります。 ワークフローが円滑に動作することを確認するには、考えられる制限事項とその対処方法を理解することが重要です。

さまざまな Azure Storage サービスのスケーリングターゲットと制限事項の詳細については、次のドキュメントを参照してください。

• Table Storage のスケール ターゲット
• Table Storage のデータ操作ターゲット
• Blob Storage のターゲットをスケーリングする
• Queue Storage のターゲットをスケーリングする

ストレージの制限に合わせてロジック アプリをスケーリングする

Standard ロジック アプリ ワークフローのスケーリングには、次の推奨事項が適用されます。

• 複数のワークフロー間でワークロードを共有する。

  シングルテナントの Azure Logic Apps では、ストレージ トランザクションを複数のパーティションに分散することで、パーティション レベルの調整が既に最小限に抑えられます。 ただし、分散を改善し、パーティション レベルの調整を軽減するには、単一のワークフローに依存するのではなく複数のワークフローにわたってワークロードを分散。

• 複数のストレージ アカウント間でワークロードを共有します。

  ワークフローで高スループットが必要な場合は、1 つのストレージ アカウントに依存するのではなく、複数のストレージ アカウントにワークロードを分散することで、スループットを大幅に向上させることができます。 制限として最大 32 個のストレージ アカウントを使用するように Standard ロジック アプリ リソースを設定できます。 必要なストレージ アカウントの数を決定するには、ストレージ アカウントごとに 1 分あたり最大 100,000 個のアクション実行を目指すという一般的なガイドラインを使用します。 この見積もりはほとんどのシナリオに適していますが、ワークフロー アクションが計算量が多い場合 (たとえば、大規模なデータ配列を処理するクエリ アクションなど) は、使用するアクションの実行数が少なくなります。 運用環境で使用する前に、必ずロード テストを実行し、ソリューションを調整してください。

  複数のストレージ アカウントの使用を有効にするには、Standard ロジック アプリを作成する前に、次の手順に従います。 それ以外の場合、作成後に設定を変更すると、データが失われたり、必要なスケーラビリティが得られない可能性があります。

  1. 使用するストレージ アカウント を作成します。 各ストレージ アカウントの接続文字列を保存します。

  2. Standard ロジック アプリを見つけて開き、ロジック アプリのホスト設定 (host.json ファイル) を編集、Runtime.ScaleUnitsCount 設定のworkflowオブジェクトとsettings オブジェクトを含む次のextensions オブジェクトを含めます。

     "extensions": {
         "workflow": {
             "settings": {
                 "Runtime.ScaleUnitsCount": "<storage-accounts-number>"
             }
         }
     }
     

     次の例では、ストレージ アカウントの数として 3 を指定します。

     {
         "version": "2.0",
         "extensionBundle": {
             "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
             "version": "[1.*, 2.0.0)"
         },
         "extensions": {
             "workflow": {
                 "settings": {
                     "Runtime.ScaleUnitsCount": "3"
                 }
             }
         }
     }
     

  3. ロジック アプリのアプリケーション構成設定 (local.settings.json)を編集して、CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU0<storage-account-number> という名前のアプリ設定を追加します。ConnectionStringおよび対応するストレージ アカウントは、次の構文を使用して接続文字列。最初のストレージ アカウント番号は、ストレージ アカウントの数から 1 を引いた数まで00されます。

     アプリ設定の名前	Value
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString	<connection-string-1>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU01.ConnectionString	<connection-string-2>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU02.ConnectionString	<connection-string-3>

     重要

     ユーザー名やパスワードを含む接続文字列などの機密情報がある場合は必ず、利用可能な最も安全な認証フローを使用してください。 たとえば、Standard ロジック アプリ ワークフローでは、securestring や secureobject などのセキュリティで保護されたデータ型はサポートされていません。 Microsoft では、可能な場合はマネージド ID を使用して Azure リソースへのアクセスを認証し、必要最小限の特権を持つロールを割り当てることをお勧めします。

     この機能を使用できない場合は必ず、Azure Key Vault など、アプリ設定で使用できる他の手段を使用して接続文字列をセキュリティで保護してください。 これで、接続文字列やキーなど、セキュリティで保護された文字列を直接参照できます。 デプロイ時に環境変数を定義できる ARM テンプレートと同様に、ロジック アプリのワークフロー定義内でアプリ設定を定義できます。 その後、動的に生成されたインフラストラクチャ値 (接続エンドポイント、ストレージ文字列など) を取得できます。 詳細については、「Microsoft ID プラットフォームのアプリケーションの種類」を参照してください。

  4. ロジック アプリのアプリケーション構成設定で、AzureWebJobsStorage 設定値を、CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString 設定と同じ接続文字列で更新します。

Compute

Standard ロジック アプリは、さまざまなレベルの仮想 CPU とメモリを提供する 利用可能なコンピューティング プランのいずれかを使用するか、より多くのコンピューティング オプションを提供する App Service Environment v3 を使用して実行されます。

シングルテナントの Azure Logic Apps は、負荷の増加に効果的に対応するために動的にスケーリングされます。 ロジック アプリでは、次の主な要因を使用してスケーリングするかどうかを決定します。

• トリガー

  スケーリング要件を決定するために、スケーラーはロジック アプリ内の各ワークフローを開始するトリガーを分析します。 たとえば、Service Bus トリガーを使用するワークフローの場合、キューの長さが継続的に長くなる場合、スケーラーはワーカー インスタンスを追加するアクションを実行し、より多くのメッセージの処理を可能にします。 同様に、要求トリガーを含むワークフローの場合、要求の待機時間が増加傾向にある場合、スケーラーはワーカー インスタンスの数を増やして、要求の負荷をより効率的に分散します。 ワーカー インスタンスの詳細については、「 Azure Logic Apps (Standard) - ランタイムの詳細」を参照してください。

• ワークフロー ジョブの実行遅延

  実行時には、ワークフロー アクションは、実行のためにキューに入れられている個々のジョブに分割されます。 ジョブ ディスパッチャーは、ジョブ キューを定期的にポーリングして、これらのジョブを取得して実行します。 ただし、これらのジョブを取得できるコンピューティング能力がない場合、ジョブはキュー内に長時間留まり、実行遅延が増加します。 スケーラーはこの状況を監視し、スケーリングの決定を行い、実行の遅延を制御できます。 ランタイムがジョブをスケジュールして実行する方法の詳細については、「 Azure Logic Apps (Standard) - ランタイムの詳細」を参照してください。

  また、スケーラーは、ワーカー インスタンスカウンターの最小構成と最大構成を考慮して、現在のワーカー インスタンス数の追加、削除、維持など、スケーリングの決定を行うかどうかを決定します。 通常、スケーラーはこれらの決定を約 15 ~ 30 秒の間隔で行います。 そのため、ピーク時の負荷を効果的に処理するために、このランプアップ時間とロジック アプリのスケーリング速度への影響を考慮してください。 たとえば、ワークロードでロジック アプリを 1 つのワーカー インスタンスから 100 個のワーカー インスタンスにスケーリングする必要がある場合、ランプアップだけで 25 ~ 50 分かかる場合があります。 シングルテナントの Azure Logic Apps スケーリングは、同じ Azure Functions スケーリング インフラストラクチャを共有します。

より高速なスケーリングのためにロジック アプリコンピューティングを構成する

• 複数のロジック アプリ間でワークロードを共有する。

  各ロジック アプリは個別にスケーリングできるため、複数のロジック アプリにワークロードを分散すると、スケーリング速度が大幅に高速化されます。 たとえば、2 つのロジック アプリは、1 つのロジック アプリと同じ期間にワーカー インスタンスの数の 2 倍にスケーリングできます。 ワークロードを複数のアプリに分割することで、スケーラビリティを効果的に乗算し、より迅速なスケーリング結果を実現できます。

• 事前ウォーミングされたインスタンスを使用します。

  シナリオの起動時間を短縮する必要がある場合は、事前ウォーミングされたインスタンスの使用を検討してください。 ピーク時の読み込み時間が決定論的な場合は、自動化タスクを使用して、スケジュールに従ってこれらの事前ウォーム インスタンスを調整できます。 詳細については、「 自動化タスク (プレビュー)を作成して Azure リソースを管理し、コストを監視する」を参照してください。

マルチテナント Azure Logic Apps には、5 分ごとに実行されるアクションの数に既定の制限があります。 既定値を maximum 値に上げるには、プレビュー段階の高スループット モードを有効にすることができます。 または、 単一のロジック アプリとワークフローに依存するのではなく複数のロジック アプリとワークフローにわたってワークロードを分散します。

ポータルで高スループットを有効にする

1. Azure portal のロジック アプリのメニューで [設定] の下から [ワークフロー設定] を選択します。

2. [ランタイム オプション]>[高スループット] で設定を [オン] に変更します。

   

Resource Manager テンプレートで高スループットを有効にする

ロジック アプリをデプロイするために、ARM テンプレートのこの設定を有効にするには、ロジック アプリのリソース定義の properties オブジェクトで、operationOptions プロパティを OptimizedForHighThroughputに設定した runtimeConfiguration オブジェクトを追加します。

{
   <template-properties>
   "resources": [
      // Start logic app resource definition
      {
         "properties": {
            <logic-app-resource-definition-properties>,
            <logic-app-workflow-definition>,
            <more-logic-app-resource-definition-properties>,
            "runtimeConfiguration": {
               "operationOptions": "OptimizedForHighThroughput"
            }
         },
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {},
         "apiVersion": "2016-06-01",
         "dependsOn": [
         ]
      }
      // End logic app resource definition
   ],
   "outputs": {}
}

ロジック アプリのリソース定義の詳細については、「概要: Azure Resource Manager テンプレートを使用して Azure Logic Apps のデプロイを自動化する」を参照してください。