独自のインフラストラクチャでハイブリッドデプロイ用の標準ロジック アプリ ワークフローを作成する

適用対象: Azure Logic Apps (Standard)

独自のインフラストラクチャを使用、制御、管理する必要があるシナリオでは、Azure Logic Apps のハイブリッド デプロイ モデルを使用して Standard ロジック アプリ ワークフローを作成できます。 このモデルでは、ローカル処理、ストレージ、ネットワーク アクセスを必要とする部分的に接続された環境用の統合ソリューションを構築およびホストする機能が提供されます。 インフラストラクチャには、オンプレミス システム、プライベート クラウド、パブリック クラウドを含めることができます。 ハイブリッド モデルでは、Standard ロジック アプリ ワークフローは、Azure Container Apps 拡張機能の一部としてオンプレミスでホストされている Azure Logic Apps ランタイムによって提供されます。

Standard ロジック アプリ ワークフローがホストされ、部分的に接続された環境で実行される場所を示すアーキテクチャの概要については、Standard ロジック アプリ用にハイブリッド デプロイのインフラストラクチャ要件を設定するに関するページを参照してください。

このハウツー ガイドでは、アプリをホストするために必要なオンプレミス リソースを設定した後、ハイブリッド デプロイ モデルを使用して Standard ロジック アプリ ワークフローを作成してデプロイする方法を示します。

制限事項

次のセクションでは、ハイブリッド展開オプションの制限事項について説明します。

前提条件

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

• 次のオンプレミス リソース。これらはすべて、必要な接続のために同じネットワーク内に存在する必要があります。

  • Azure Arc に接続されている Azure Kubernetes Service クラスター
  • ワークフロー実行履歴、入力、および出力を処理用にローカルに格納する SQL データベース
  • ワークフローで使用される成果物をローカルに格納するためのサーバー メッセージ ブロック (SMB) ファイル共有

  これらの要件を満たすために、Standard ロジック アプリのハイブリッド デプロイをサポートするようにこれらのオンプレミス リソースを設定してください。

• Visual Studio Code で作業するには、関連する前提条件を備えた Visual Studio Code 用 Azure Logic Apps (Standard) 拡張機能が必要です。

  ヒント

  新しい Visual Studio Code のインストールがある場合は、独自のインフラストラクチャにデプロイする前に、基本的な Standard ワークフローをローカルで実行できることを確認してください。 このテスト実行は、Standard ワークフロー プロジェクトで存在する可能性があるエラーを分離するのに役立ちます。

Standard ロジック アプリを作成する

ハイブリッド展開のバージョン管理

ハイブリッド ホスティング オプションを持つ Standard ロジック アプリは、子ワークフローの変更を保存するたびに、Azure Container Apps のバージョン管理の概念である新しい "リビジョン" を自動的に作成します。 このリビジョンのアクティブ化には少し時間がかかる場合があります。つまり、変更を保存した後、ワークフローをテストするまでにしばらく待つ必要があります。

変更がまだワークフローに表示されていない場合は、リビジョンが存在するかどうかを確認できます。

1. Azure portal でリソースを開きます。 リソース メニューの [リビジョン] で、[リビジョンとレプリカ] を選択します。

2. [リビジョンとレプリカ] ページの [アクティブ リビジョン] タブで、新しいリビジョンが一覧に表示されるかどうかを確認します。

詳細については、次のリソースを参照してください。

• Azure Container Apps の変更を更新してデプロイする

• Azure Container Apps でリビジョンを管理する

パフォーマンス監視用に拡張テレメトリまたは OpenTelemetry を設定する

標準ロジック アプリの Application Insights で拡張テレメトリ収集を設定し、ワークフローの実行が完了した後に収集されたデータを表示できます。 この機能を使用すると、ワークフローに関する分析情報を簡単に取得でき、データ ソースでのイベントのフィルター処理をより細かく制御でき、ストレージ コストの削減に役立ちます。 これらの機能強化は、システムの正常性と動作に関する分析情報を提供するリアルタイムのパフォーマンス メトリックに焦点を当てています。

部分的に接続されたオンプレミスのシナリオでは、特定の環境に対して定義した OpenTelemetry でサポートされる アプリ設定に基づいてテレメトリを出力するように Standard ロジック アプリを設定できます。 既定では、このテレメトリ データは Application Insights に送信されます。 詳細については、「 Azure Logic Apps の標準ワークフローの Application Insights で拡張テレメトリを有効にする」を参照してください。

Azure portal で vCPU とメモリの割り当てを変更する

Standard ロジック アプリ リソースの vCPU とメモリの設定を編集できます。 これらの変更は、Standard ロジック アプリワークロードの 課金料金 に影響します。

1. Azure portal で、Standard ロジック アプリ リソースを開きます。

2. リソース メニューの [設定] の下で、[コンテナー] を選択します。

3. [コンテナー] ページのツール バーで、[編集とデプロイ] を選択します。これにより、[コンテナーの編集] ペインが開きます。

4. [プロパティ] タブの [コンテナー リソースの割り当て] で、シナリオに合わせて次の値を変更します。

   プロパティ	値	説明
   CPU コア	- 既定値: 1 - 最小: 0.25 - 最大: 2	コンテナー インスタンスに割り当てる vCPU コアを決定します。 この値は、最大値まで 0.25 コアずつ増やすことができます。 このロジック アプリのすべてのコンテナー インスタンスでの合計数は、2 コアに制限されています。
   メモリ	- 既定値: 2 - 最小: 0.1 - 最大: 4	コンテナー インスタンスに割り当てるメモリ容量をギビバイト (GiB) 単位で決定します。 この値は、最大値まで 0.1 GiB 増やすことができます。 このロジック アプリのすべてのコンテナー インスタンスの合計容量は、4 GiB に制限されています。

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

Azure portal でレプリカ スケーリングを変更する

トリガー イベントに応答してデプロイするレプリカの範囲の自動スケーリングを制御できます。 "レプリカ" は、ロジック アプリ リソースのリビジョンまたはバージョンの新しいインスタンスです。 この範囲の最小値と最大値を変更するには、スケール ルールを変更して、スケーリングをトリガーするイベントの種類を決定できます。 詳細については、「Azure Container Apps でスケーリング ルールを設定する」を参照してください。

1. Azure portal で、Standard ロジック アプリ リソースを開きます。

2. リソース メニューの [設定] の下で、[スケール] を選択します。

3. [スケール] ページの [スケール ルールの設定] で、シナリオに合わせて次の値を変更します。

   プロパティ	値	説明
   最小レプリカ数	- 既定値: 1 - 最小: 0 - 最大: 1000	特定の時点でリビジョンに許可されるレプリカの最小数を決定します。 この値はスケール ルールをオーバーライドし、レプリカの最大数未満でなければなりません。
   最大レプリカ数	- 既定値: 30 - 最小: 0 - 最大: 1000	特定の時点でリビジョンに許可されるレプリカの最大数を決定します。 この値はスケール ルールをオーバーライドします。

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

Azure portal でロジック アプリへの受信トラフィックを制御する

イングレスを有効にすることで、ロジック アプリをパブリック Web、仮想ネットワーク、環境内の他のロジック アプリに公開できます。 Azure では、ロジック アプリへの外部トラフィックと内部トラフィックのルーティングを制御する一連の規則によってイングレス設定が適用されます。 イングレスを有効にすると、Azure Load Balancer、パブリック IP アドレス、またはその他の Azure リソースを作成しなくても、受信 HTTPS 要求または TCP トラフィックを有効にすることができます。 詳細については、「Container Apps でのイングレス」を参照してください。

1. リソース メニューの [設定] の下で、[イングレス] を選択します。

2. [イングレス] ページで、[イングレス] の横にある [有効] チェックボックスを選択します。

3. シナリオに基づいて、残りのオプションを構成します。

   詳しくは、次のドキュメントをご覧ください。

   • Azure Container Apps でアプリのイングレスを構成する
   • Azure Container Apps で IP のイングレス制限を設定する

マネージド API 接続の認証を設定する

Azure Arc 対応 Kubernetes クラスターでホストされている Standard ロジック アプリ ワークフローでマネージド API 接続を認証するには、Microsoft Entra ID を使用して独自のアプリ登録を作成する必要があります。 その後、このアプリ登録の値を Standard ロジック アプリ リソースの環境変数として追加して、代わりに API 接続を認証できます。

Microsoft Entra ID でアプリ登録を作成する

Azure Portal

1. Azure portal で、「クイック スタート: Microsoft ID プラットフォームにアプリケーションを登録する」に従ってアプリ登録を作成します。

2. 作成が完了したら、ポータルで新しいアプリの登録を見つけます。

3. リソース メニューで [概要] を選択し、後で接続認証に必要となる次の値を保存します。

   • クライアント ID
   • テナント ID
   • クライアント シークレット

4. オブジェクト ID については、次の手順に従います。

   1. [概要] ページで、次に示すように、アプリ登録の [ローカル ディレクトリでのマネージド アプリケーション] リンクを選択します。

      

   2. 開いたページで、[オブジェクト ID] 値をコピーして保存します。

      

5. ここで、Standard ロジック アプリ リソースに保存された値を環境変数として追加します。

Azure CLI（Azure コマンドライン インターフェイス）

1. アプリの登録を作成するには、az ad sp create コマンドを使用します。

2. すべてのプロパティを確認するには、az ad sp show コマンドを使用します。

3. 両方のコマンドからの出力で、後で接続認証に必要となる次の値を見つけて保存します。

   • クライアント ID
   • オブジェクト ID
   • テナント ID
   • クライアント シークレット

4. ここで、Standard ロジック アプリ リソースに保存された値を環境変数として追加します。

Standard ロジック アプリにアプリ登録の値を追加する

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

2. リソース メニューの [設定] で、[コンテナー] を選択し、[環境変数] タブを選択します。

   アプリ設定とホスト設定の詳細については、アプリ設定とホスト設定を編集するに関するページを参照してください。

3. ツール バーで、[編集とデプロイ] を選択します。

4. [コンテナーの編集] ペインで、[環境変数] を選択し、[追加] を選択します。

5. 次の表から、指定した値と一緒に各環境変数を追加します。

   環境変数	値
   WORKFLOWAPP_AAD_CLIENTID	< my-client-ID>
   WORKFLOWAPP_AAD_OBJECTID	< my-object-ID>
   WORKFLOWAPP_AAD_TENANTID	< my-tenant-ID>
   WORKFLOWAPP_AAD_CLIENTSECRET	< my-client-secret>

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

クライアント ID とクライアント シークレットを格納および参照する

クライアント ID とクライアント シークレットの値をシークレットとしてロジック アプリ リソースに格納し、代わりに [環境変数] タブでそれらの値を参照できます。

1. Azure ポータルで、ロジック アプリのリソースに移動します。

2. リソース メニューの [設定] の下で、[シークレット] を選択します。

3. ツールバーで、 追加を選択します。

4. [シークレットの追加] ペインで、シークレットごとに次の情報を指定し、[追加] を選択します。

   鍵	値
   WORKFLOWAPP_AAD_CLIENTID	< my-client-ID>
   WORKFLOWAPP_AAD_CLIENTSECRET	< my-client-secret>

既知の問題とトラブルシューティング

次のセクションでは、現在既知の問題と、一般的な問題のトラブルシューティングに関するガイダンスについて説明します。

環境のセットアップまたはポータルのデプロイに関する一般的な問題

環境の構成またはポータルのデプロイエラーに関する問題の診断とデバッグに役立つよう、ハイブリッド展開オプションに用意されている troubleshoot.ps1 PowerShell スクリプトを実行してみてください。

1. Azure Logic Apps GitHub リポジトリ (scripts/hybrid フォルダー) に移動します。

2. troubleshoot.ps1 ファイルを、ロジック アプリのデプロイと同じオンプレミスの場所にあるフォルダーにコピーします。

3. PowerShell を使用してスクリプトを実行します。

Arc 対応 Kubernetes クラスター

まれに、クラスターのメモリ占有領域が大きくなる場合があります。 この問題を回避するには、スケールアウトするか、ノード プールの自動スケーリングを追加します。

関数ホストが実行されていない

Standard ロジック アプリをデプロイしたら、アプリが正しく実行されていることを確認します。

1. Azure portal で、ロジック アプリ リソースを開きます。

2. リソース メニューで [概要] を選択します。

3. [概要] ページの [アプリケーション URL] フィールドの横で、リソース URL を選択します。

   アプリが正常に実行されている場合は、ブラウザー ウィンドウが開き、次のメッセージが表示されます。

   

   そうではなく、アプリでエラーが発生している場合は、AKS ポッドが正しく実行されていることを確認します。 Windows PowerShell で、次のコマンドを実行します。

   az aks get-credentials {resource-group-name} --name {aks-cluster-name} --admin
   kubectl get ns
   kubectl get pods -n logicapps-aca-ns
   kubectl describe pod {logic-app-pod-name} -n logicapps-aca-ns 
   

   詳しくは、次のドキュメントをご覧ください。

   • az aks get-credentials
   • コマンド ライン ツール (kubectl)

クラスターに十分なノードがない

前のコマンドを実行したときに、次の例のような警告が表示された場合、クラスターには処理に十分なノードがありません。

Warning: FailedScheduling  4m52s (x29 over 46m)  default-scheduler  0/2 nodes are available: 2 Too many pods. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod.

ノードの数を増やし、自動スケーリングを設定するには、次の手順に従います。

1. Azure portal で Kubernetes サービス インスタンスに移動します。

2. インスタンス メニューの [設定] で、[ノード プール] を選択します。

3. [ノード プール] ページのツール バーで、[+ノード プールの追加] を選択します。

詳しくは、次のドキュメントをご覧ください。

• Azure Kubernetes Service (AKS) のクラスターでノード プールを作成する
• Azure Kubernetes Service (AKS) のクラスターでノード プールを管理する
• Azure Kubernetes Service (AKS) でのクラスターの自動スケーリングの概要
• Azure Kubernetes Service (AKS) でのクラスター オートスケーラーの使用

SMB Container Storage Interface (CSI) ドライバーがインストールされていない

前の kubectl describe pod コマンドを実行した後、次の警告が表示されたら、SMB ファイル共有の CSI ドライバーが正しくインストールされているかどうかを確認します。

Warning FailedScheduling 5m16s (x2 over 5m27s)  default-scheduler 0/14 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/14 nodes are available: 14 Preemption is not helpful for scheduling.

Normal NotTriggerScaleUp 9m49s (x31 over 14m) cluster-autoscaler pod didn't trigger scale-up: 3 pod has unbound immediate PersistentVolumeClaims

確認するには、Windows PowerShell で次のコマンドを実行します。

kubectl get csidrivers

表示される結果の一覧に smb.csi.k8s.io が含まれていない場合は、Windows コマンド プロンプトから次のコマンドを実行します。

helm repo add csi-driver-smb
helm repo update helm install csi-driver-smb csi-driver-smb/csi-driver-smb --namespace kube-system --version v1.15.0

CSI SMB ドライバー ポッドの状態を確認するには、Windows コマンド プロンプトから次のコマンドを実行します。

kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=csi-driver-smb" --watch

詳細については、「Azure Kubernetes Service (AKS) の Container Storage Interface (CSI) ドライバー」を参照してください。

関連するコンテンツ

• 独自のインフラストラクチャで Standard ロジック アプリ デプロイの要件を設定する
• Azure Logic Apps で Application Insights for Standard ワークフローで拡張テレメトリを有効にする