初めに
お久しぶりです。ぼちぼちブログ投稿を再開していきたいと思います。今回は、LogicApps(Standard)からコネクタを使用してTableStorageへアクセスができないトラブルにハマっていました。私の知見不足が原因で、その点についてSRへ確認しましたのでその情報をここで共有できればと思います。
今回の構成は？
以下、プライベート通信を想定した構成となっています。
■ LogicAppsの構成
- Standard構成
- Vnet統合
- 割当てロール（ストレージアカウント共同作成者、ストレージテーブルデータ共同作成者）
■ StorageAccountの構成
- ファイアーウォールは有効
- プライベートエンドポイントを作成
- 「信頼されたサービスの一覧」からの通信を許可
どんなエラーが発生したか
状況：ロジック アプリ (Standard)でAzureTableStorageのコネクタの使用時に、テーブルの選択でエラーが表示される。同じ手順で、ロジックアプリ(従量課金)使用時にはエラーは発生しない。
使用したコネクタ：Azure Table Storage(エンティティの取得 (V2))
エラー内容：以下
Error executing the API - https://management.azure.com/subscriptions/(サブスクリプションID)/resourceGroups/(リソースグループ名)/providers/Microsoft.Web/sites/(LogicApps名)/hostruntime/runtime/webhooks/workflow/api/management/dynamicInvoke 詳細な診断情報: x-ms-client-request-id は 'XXXXXX'です。
解消方法
組み込み (built-in) コネクタの [Azure Table Storage] コネクタを使用することで回避可能。
設定方法については以下参考にしてください
MS公式ブログ | built-in (組み込み) タイプのコネクタを利用する
参考資料では「アプリ内」と記載されていますが私の環境では「In-app」と記載されていました。
なぜエラーが発生したのか
コネクタには主に「built-inタイプのコネクタ」と「Azureコネクタ」の２種類があります。プライベートネットワークでの通信を使用してリソースへアクセスする際は、コネクタの選択に注意する必要があります。各コネクタの特徴を以下にまとめておきます。
- built-inタイプのコネクタ：今回の前提のように、Vnet統合を使用して実行する場合はプライベートネットワーク経由でTableStorage等のリソースにアクセスをする場合に使用。種類がAzureコネクタと比較して少ないので注意
- Azureコネクタ：パブリック経由での通信を行うLogicAppsの構成をとる場合はを使用可能。種類が豊富
それぞれのコネクタの実行環境の違いが、根本の要因です。
以下各コネクタを使用した通信時のイメージ図になります。
- (青線)built-inコネクタはAzureLogicAppsホストランタイムと同じ環境で実行されます。そのため、プライベートネットワーク経由での通信が可能です。
- (緑線)Azureコネクタは共有環境で実行されます。そのため、マネージドコネクタの送信IPアドレスを介してパブリックネットワーク経由で通信が必要です。
なぜ従量課金プランでは通信できたのか
従量課金プランのLogicAppsからパブリックネットワーク経由でアクセスしていたTableStorageへの通信は、StorageAccountの以下ネットワーク設定によってスルーされており通信ができていました。
「信頼されたサービスの一覧」からの通信を許可
従量課金プランでは「Microsoft.Logic」というリソースタイプで通信をします。このリソースタイプは「信頼されたサービスの一覧」に含まれます。一方でStandardプランの場合は、「Microsoft.Web」というリソースタイプで通信をしますが、こちらは「信頼されたサービスの一覧」には含まれておらず、StorageAccountのファイアーウォールで拒否された形となっておりました。
まとめ
Vnet統合を使用しているLogicAppsについては、基本的にbuilt-Inコネクタを使用しましょうという学びとなりました。また、Standard構成は基盤としてWebappsが動いているということが今回のリソースタイプの一件で良く伝わったかと思います。
参考文献
MSLearn | Azure Logic Apps (Standard) での組み込み操作と Azure コネクタの違い