Azure Logic Apps の Standard プランを概観する
はじめに
2021 年 5 月開催の Microsoft Build 2021 に合わせて Azure Logic Apps の新しいリソースの種類である Standard が一般提供開始になりました。
Logic App Standard は、Azure App Service 上で Azure Functions の拡張的な機能として実行されます。そのため、App Service で利用可能な機能、例えば自動スケールやリージョン VNet 統合、仮想ネットワーク サービス エンドポイントなどの機能を利用できます。
本記事では、Logic App Standard の概観と主にネットワーク周りの設定についてざっくり見ていきます。なお、発表内容の詳細、そして機能の詳細については、以下のブログと公式ドキュメントをご覧ください。
Logic App Standard のデプロイ画面
まずは、デプロイの画面がどうなっているかを見ていきます。
Azure ポータルで Logic App の追加をクリックすると、「Standard」という項目があり、ここからデプロイを開始できます。以前の種類の Logic App は「従量課金プラン」からデプロイを開始できます。
作成画面の項目は Functions と非常に近しいものになっています。Logic App 名は URL エンドポイントの一部として使われるため、グローバルで一意になっている必要があります。
次のページではストレージ アカウント、プラン、SKU (スペック) を入力しますが、これも Function App とほぼ同様です。
なお、[プランの種類] の選択肢に「ワークフロー Standard」の他に「App Service プラン」がありますが、後者は現時点ではまだ利用できないようで、グレーアウトされています。
Function App と同様、Application Insights との連携もサポートされています。
スペック
スペックは 2021 年 5 月 31 日現在、WS1 / WS2 / WS3 の 3 つの価格レベルから選択できます。各価格レベルの違いは Azure Compute ユニットとメモリのサイズで、含まれる機能については違いがありません。スペックはデプロイ後に変更できます。
各スペックの価格は英語版の docs.microsoft.com の以下ページに記載がありました。日本語版の Docs 及び製品の価格ページ への反映にはタイムラグがあるようです。
Logic App Standard のデプロイ結果
デプロイの結果、以下のようなリソース群が作成されます。Function App とほぼ同じ構成ですね。
Logic App の概要画面は以下のような感じです。[ワークフロー] などを除いて、左側メニューも Function App とほぼ同じ構成です。
ワークフロー
[ワークフロー] の画面では、Logic App に紐づくワークフローの一覧を確認できます。ワークフローは、Function App の関数に相当し、1 つの Logic App に複数のワークフローを紐づけることができます。
ワークフローを追加する際に、ステートフルかステートレスかを選択します。ステートフルは名前が示す通り、各アクションとその状態の入出力を外部ストレージに保存するのに対し、ステートレスは各アクションとその状態の入出力をメモリ内にのみ保存します。
ステートレスの方が処理時間が短縮され、応答が速くなり、スループットが向上し、実行にかかるコストも少なくなる一方で、ワークフローの実行履歴は見られません。
ワークフローのデバッグ モードを有効にしている間は実行履歴を見ることができるので、動作確認時はデバッグ モードを有効にしておき、完了したらデバッグ モードを無効にする、といった運用を取ることもできます。
ステートフルとステートレスのどちらを選ぶべきかは以下のガイドに詳細がまとまっています。
何も設定していないワークフローの [概要] 画面です。今までの Logic App と似た作りになっています。Azure ポータルの左メニューの [コード] や [デザイナー] から処理を定義できます。また、VS Code を使用してローカルで開発することもできます。
[デザイナー] と [コード] の画面の作りは、従量課金プランと大きく変わりません。
ワークフローにトリガーとアクションを定義して保存し [概要] 画面に行くと、ワークフロー URL が発行されます。このワークフロー URL にアクセスすることで、ワークフローが起動されます。
なお、ステートレスの場合は起動しても実行履歴が記録されないため、実行履歴を記録したい場合は [デバッグ モードを有効にする] を選択します。デバッグ モードは有効、無効を切り替えられます。
実行履歴をクリックすると、ワークフローのアクション レベルの情報を見ることができます。
ステートフル、ステートレスのトリガーについて
ワークフローでは最初にトリガーを定義する必要がありますが、ステートフルでは Azure 及びビルトインのコネクターを選択でき、ステートレスではビルトインのコネクターのみを選択できます。
種類が Azure になっているものは、従量課金プランの Logic App でも利用可能な 400 以上のマネージド コネクターを指します。
ビルトイン コネクターのトリガーとアクションは Logic App Standard のランタイムでネイティブに実行されます。
Azure Service Bus や Azure Event Hubs、SQL Server、MQ などがサポートされており、今後も拡充されていく予定ですが、Azure のコネクターに比べると利用可能な数は少ないです。
(画像クリックで拡大)
ステートフル (Azure) | ステートフル (ビルトイン) | ステートレス (ビルトイン) |
---|---|---|
ネットワーク関連オプション
Logic App の左側メニューの [ネットワーク] からネットワーク関連のオプションが確認できます。Azure Functions の Premium プランなどと同様のオプションを利用できます。
Logic App Standard から VNet 内のリソースへのプライベート アクセス
Logic App Standard の VNet 関連のユースケースは色々あるかと思いますが、代表的なものとして、Logic App Standard から VNet 内のリソースにプライベート アクセスしたい というユースケースが考えられます。
例えば、VNet 内にある SQL Server on Azure VM や Azure SQL Managed Instance のプライベート エンドポイントにアクセスしたい、といったものです。このユースケースは、リージョン VNet 統合とビルトイン コネクターにより実現できます。
リージョン VNet 統合
App Service / Function App と同じ要領で、[ネットワーク] の [VNet 統合] から Logic App Standard を関連付ける VNet のサブネットを選択すれば OK です。
ビルトイン コネクター
Logic App Standard の一機能である リージョン VNet 統合を利用して VNet 内のリソースにアクセスするためには、ビルトイン コネクターを利用する必要があります。前述の通り、ビルトイン コネクターは Logic App Standard のランタイムでネイティブに実行されます。
種類 が Azure になっているコネクターは、従量課金プランの Logic App と同じように動作するため、プライベート通信をサポートしません。
(例) Azure SQL Managed Instance へのプライベート アクセス
例として、VNet 内にデプロイした Azure SQL Managed Instance (SQL MI) のプライベート エンドポイントにリージョン VNet 統合を経由してアクセスする場合、ビルトインの SQL Server コネクターを利用します。
ビルトインの SQL Server コネクターは、現時点で Execute Query (クエリの実行) のみをアクションとしてサポートしています。
接続名は任意の名前、接続文字列は以下の形式で入力します。
Server=tcp:<my-sqlmi.123456789012.database.windows.net>,1433;Initial Catalog=<test-db>;Persist Security Info=False;User ID=<user_name>;Password=<password>;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
任意のクエリを入力し、保存します。これでワークフロー URL を呼び出して成功すれば、設定完了です。
なお、接続情報は左メニューの [接続] の [サービス プロバイダー接続] から確認できます。
接続文字列は [構成] の [アプリケーション設定] に保存されます。
VNet 内のリソースから Logic App Standad へのプライベート アクセス
上記は通信の起点が Logic App Standard でしたが、それとは逆に、Logic App Standard へのアクセスをプライベート アクセスに限定したいというニーズもあると思います。
このニーズに応えるためには、プライベート エンドポイント、または仮想ネットワーク サービス エンドポイントを利用できます。
(例) Azure VM からのプライベート アクセス
例として、VNet 内にデプロイした Azure VM から Logic App Standard に仮想ネットワーク サービス エンドポイントを用いてアクセスしたいと思います。
[ネットワーク] で [アクセス制限の構成] を選択します。
[アクセス制限の編集] で接続を許可する VNet のサブネットを指定して保存します。
これにより、優先順位の最後に Deny all の規則が自動的に追加され、アクセスを許可した VNet のサブネット以外からのアクセスはできなくなります。
試しに、クライアントの PC からワークフロー URL を呼び出すと、次のような 403 の画面が表示されるはずです。
接続を許可した VNet のサブネット内の VM からワークフロー URL を呼び出すと 200 の結果が返ってくれば、サービス エンドポイントが正しく設定できています。
nakazax@vm-nakazax-logic-standard:~$ curl -I "https://logic-nakazax-standard-ejp.azurewebsites.net:443/api/http-req-res-stateless/triggers/manual/invoke?api-version=2020-05-01-preview&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=xxx"
HTTP/1.1 200 OK
Content-Length: 0
Request-Context: appId=cid-v1:364980c3-3d98-40b5-b9b0-06d42174d8fb
x-ms-request-id: :fe8a9218-a185-4e34-88f1-2bb531139b0e
Date: Mon, 31 May 2021 15:29:34 GMT
以上です。
Author And Source
この問題について(Azure Logic Apps の Standard プランを概観する), 我々は、より多くの情報をここで見つけました https://qiita.com/nakazax/items/b1758ba4e9b7511014bb著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .