今回は、Standard Logic Apps を利用する際に抱える問題のひとつである Logic Apps デザイナーの推奨事項を回避して開発を行う方法を考えてみます。
Logic Apps デザイナーの推奨事項って？
公式ドキュメントでは Standard Logic Apps のデザイナーを使った開発上、応答性とパフォーマンスを最適なものにする方法として下記内容が記載されています。
デザイナーの応答性とパフォーマンスを最適なものにするには、次のガイドラインを確認してそのようにしてください。
- ワークフローごとに使用するアクションの数を 50 以下にします。 アクションの数がこれを超えると、デザイナーのパフォーマンスが低下する可能性があります。
- 必要に応じて、ビジネス ロジックを複数のワークフローに分割することを検討します。
- ロジック アプリ リソースあたりのワークフローの数を、10 から 15 個以下にします。
ロジック アプリのワークフローが多いほど、読み込み時間が長くなるリスクが高くなり、パフォーマンスに悪影響が及びます。
Azure portal を使用してサンプル Standard ロジック アプリ ワークフローを作成する # ベスト プラクティスと推奨事項
見て分かる通り、超過したら諸々のリスクが高くなります。
しかも、こちらの推奨事項に関しては CPU やメモリ使用率の高騰といった表現でも無いため、恐らくですが、下記 WS1 ~ WS3 までの全てに共通して問題が生じます。
Azure Logic Apps における使用量の測定、課金、価格のしくみについて説明します。…
ただ、従来のシステムを Standard Logic Apps に変換するとしても、アクション数 50 以下やワークフロー数 10 ~ 15 個以下なんてのは無理な話です。
アクション数については変数をひとつ宣言するだけでも 1 カウントされるので、基幹システム (多分 Java とか C 系統) を置き換えるだけでは確実に超過します。
また、ワークフロー数についても同様で、確認に推奨値を超過します。
推奨事項のちょっとした注意点
ひとつ、Logic Apps の推奨事項と理解が混ざりやすい内容があったので記載します。
一応、Logic Apps にも制約と構成に関する公式ドキュメントが存在するのですが、下記に記載のあるワークフロー数とアクション数の制限は推奨事項のことではなく、物理的に追加が出来なくなる制限のことを指しているので、注意してください。
推奨事項を回避する方法を考える
アクション数の制限回避について
まず、アクション数の制限回避策についてお話します。
こちらは下記の引用元にも既に記載されていますが、多すぎるアクションを複数の Logic Apps に分割することによって、問題解消するかと思います。
必要に応じて、ビジネス ロジックを複数のワークフローに分割することを検討します。
Azure portal を使用してサンプル Standard ロジック アプリ ワークフローを作成する # ベスト プラクティスと推奨事項
オブジェクト指向型プログラミング言語における「神クラスを作るな！」的なのと同義です。
少し制限厳しめですが、、、
やり方としては至ってシンプルで、まず呼び出す側 (親) と呼び出される側 (子) のワークフローを作成し、子ワークフローに “HTTP” トリガーをセットします。
その後、親ワークフローから子ワークフローのトリガーを呼び出せば分割完了です。
詳細については下記のドキュメントに記載があるので、ご確認いただければと。
Azure Logic Apps で HTTPS 経由の受信要求を受信するワークフローを作成します。…
ワークフロー数の制限回避について
こちらについては、私も「ワークフローの分割か……でもな、App Service 追加でレンタルするとなると費用が……」という感じで大いに悩みました。
悩みに悩んだ末の結論としては、App Service ではなく、Standard Logic Apps 単位で分割を実施することによって制限は回避できるという考えです。
どういうことかというと、Standard Logic Apps がホストされている App Service プランについては、当該 Standard Logic Apps の専用リソースになるという訳ではなく、他にも様々なリソースについてデプロイすることが可能となっております。
例えば、ひとつの App Service に Standard Logic Apps を 5 つ紐付けるといったことも可能です。
つまるところ、この仕様を使ってリソース単位で分割すれば追加で App Service の費用を払うことも無く、ただ「めんどくさい」だけで分割できるんです！
実際、引用したドキュメントにも「ロジック アプリ リソースあたりのワークフロー数」という記載はあっても、App Service についての記載は無いので、私の完全なミスリードです。
デザイナーの応答性とパフォーマンスを最適なものにするには、次のガイドラインを確認してそのようにしてください。
- ロジック アプリ リソースあたりのワークフローの数を、10 から 15 個以下にします。
Azure portal を使用してサンプル Standard ロジック アプリ ワークフローを作成する # ベスト プラクティスと推奨事項
ですので、開発前の方は設計書段階で分割を考慮していただければと思います。
実はまとまった回避策もある (非推奨)
そもそも論、当該の制限事項については Azure ポータル上の Logic Apps デザイナーを使用した場合に発生するものとなっております。
そのため、Logic Apps デザイナー以外の開発手法を取れば問題ない訳です。
例えば VS Code なんかでも開発自体は出来たりします。
Visual Studio Code でマルチテナント Azure Logic Apps を使って、ワークフロー定義を作…
しかしながら、ノーコード・ローコード製品の最大の利点である GUI のみを利用した開発を捨てているので、だったら最初からやらない方が良いと個人的には感じています。
そのため、私個人の意見としては VS Code を利用した開発は非推奨とさせていただきます。