どうして同時実行数に制限を設ける必要があるのか、下記 2 つの観点で考えてみます。
- リソースの競合を防ぐ
- データの整合性を保つ
1. リソースの競合を防ぐ
Logic Apps における CPU やメモリの過負荷についての例を出してみます。
例えば従量課金制ではなく、Standard プラン (シングルテナント) の Logic Apps を利用される場合ですと、ひとつのサーバー (App Service) を貸し切る訳ですから CPU やメモリにも明確な上限が存在します。
最も安価な契約プランである WS1 だと、CPU 1 コアにメモリ 3.5GB ですね。
Azure Logic Apps における使用量の測定、課金、価格のしくみについて説明します。…
当然、こちらの App Service に Logic Apps ワークフローをひとつだけ配置するなんてことはなく、複数のワークフローを共存させるという使い方をされると思います。
複数のワークフローを含めるという利用については Azure 公式情報にも記載がありますしね。
次の表は、従量課金ロジック アプリ ワークフローと Standard ロジック アプリ ワークフローの違いをまとめたものです。 ロジック アプリ ワークフローをデプロイ、ホスト、実行するための “シングルテナント” 環境と、”マルチテナント環境” および “統合サービス環境 (ISE)” との違いも分かります。
ロジック アプリ (Standard)
1 つのロジック アプリに、複数の “ステートフル” と “ステートレス” のワークフローを含めることができます。Standard シングルテナント ロジック アプリと従量課金マルチテナント ロジック アプリの違い # ロジック アプリ ワークフローの種類と環境
そのため、ひとつのワークフローが大量の同時実行を行って、他のワークフローが実行する分のシステムリソースまで食い潰してしまったらいけない訳です。
こういった CPU やメモリの過負荷を回避する為に、同時実行数に制限を設けることもあります。
2. データの整合性を保つ
Logic Apps では、「○○を受信時に起動」といった内容のトリガーがチラホラ存在します。
(今回は「添付ファイルがあるメールを受信時に起動」にしましょう)
こういったトリガーから派生するワークフローに Azure Storage の読み取りや更新 / 削除といったアクションを組み合わせると、メールを複数同時に受信してしまった時に問題が生じます。
例えば、Storage に格納されているファイルと同名のファイルを受信した時に、古いものを削除して新しいものに置き換えるというワークフローがあり、同名のファイル名が添付されたメールをほぼ同時刻に 2 通受信したとします。
この時、メールを処理する実行 1 と実行 2 がある訳です。
実行 1 と 2 はほぼ同時刻に開始されるので、どちらも同じ古いファイル名を参照して削除しようとしますが、実行 1 がコンマ数秒の差で先に処理が終了します。
すると残された実行 2 の方は、削除しようと参照していたファイルが無くなったので、「○○というファイルを削除しようとしましたが、見つかりませんでした」といったエラーが出力される訳です。
こういった競合……カッコつけていうとコンフリクトについては頻出の問題で、私自身も何度か対応したことがあるくらいですので、同時実行数に制限をつける理由になります。