ひょんな事から kenakamuさんとお話しする機会があり、自分なりに整理できたのでメモ。
背景
Azure functionsにも慣れ「これがサーバーレスかー！おもろー！」とコードを書きまくって動かしていたところ、コードの行数が200行を超え、コードから呼び出すためにfunctionsにUPするモジュール(Azure Powershell)なども増え、コードとモジュールの管理が必要となる。「これってバッチサーバー上で動かしているのと、何が違うんだろう…?」と思ったのが、考えるきっかけです。
また、LogicAppsとFlowの違いを説明することが多いので、まとめようと思いました。
比較表
| – |
バッチサーバー |
Azure functions |
LogicApps |
Flow |
| 料金 |
○無料 |
○無料 |
×有料 |
○無料 |
| 簡易さ |
×コード |
×コード |
○GUI |
○GUI |
| 自由度 |
◎自由 |
○自由 |
△サービスの制約あり |
×サービスの制約あり |
| 時間制限 |
○なし |
×あり |
○なし |
○なし |
| 基盤 |
×IaaS |
○PaaS |
○PaaS |
○PaaS |
| 安定性 |
○高 |
△中 |
×低 |
×低 |
| 権限 |
○管理者 |
○管理者 |
○管理者 |
×ユーザー |
料金
LogicAppsはステップ毎に課金が発生。バッチサーバー、Azure functions、Flowはあえて”無料”と書かせていただきましたが、バッチサーバーはサーバー費用、Azure functionsは実行回数とCPU時間による課金、Flowは500回/日の回数制限があります。
ただ、ちょっと動かすだけならfunctionsとFlowは無料で使え、バッチサーバーも環境がある場合(ほとんどある)は、実質無料で使えます。
簡易さ / 自由度
LogicAppsとFlowはGUI、バッチサーバーとAzure functionsはコードで動かす必要がある。GUIの場合、設計書がなくてもある程度意味が分かるのが大きなメリット。つーかお客さんが設計書なしでもOKと言ってくれる。もちろん、作成の背景を記した要件定義書は残しておいた方がよいが…。一方、コードの場合、プログラムができない顧客に引き渡すとき & 自社管理用にプログラム設計書はほしい。GUIなら気軽に変更でき、それが設計書となることから、Logic Apps、Flowの方が、気軽にあれこれいじれるメリットはある。
その簡易さと引き換えにコードには自由度がある。バッチサーバーはIaaS環境を自分でいじれるので自由度◎、Logic AppsはAzure functionsと連携できるので自由度△としました。
時間制限
これはAzure Functionだけの制約で、1回の実行時間が5分(工夫すれば10分)となる。5分あればある程度の処理は出来るが…。一方他は実質時間制限なし。
基盤
バッチサーバーはIaaSとなり、基盤の再起動タイミングなどを考慮して設計することが必要。
安定性
LogicAppsやFlowは(実績ベースだと)起動に失敗し、うまく動かないことがある。一方、IaaS上でタスクスケジューラーやJP1で動かす場合、ほぼ確実にプログラムがキックする。…という意味で、こういう評価にさせてもらいました。Azure functionsの実績は手元にないので、とりあえず”中”にしました。
権限
Flowだけがユーザー権限であり、ユーザーが自分が出来る範囲のタスクをFlowで実装するもの。よってLogicAppsが元になっているとはいえ、自分ができないことはFlowにも出来ないです。(本当に抜け道がないか自分で確認したわけではないけど、設計思想はそう。)
なので「Flowでいろいろできちゃうかもしれないから、禁止しよう！」はナンセンス。まぁ中には、手動で私用のGmailにメールを送るのはいいが、自動転送はシステム的に禁止する、などのナンセンス運用の企業もあるが…。
管理者が実行するスクリプトのための比較表なので、〇管理者 / ×ユーザーとしてしまったけど、ユーザー権限だから逆にいいこともあり、一概には言えません。
ユースケース
Office 365 ライセンス付与、初期ユーザー設定バッチ
Office 365の運用ではほぼ確実に必要なバッチであり、サーバーレスの概念の登場前はバッチサーバーで動かしていたのがほとんどと思われる。これは引き続きバッチサーバーで動かした方がよいのではないか、と思えてきました。
まず、管理者業務なのでFlowは除外。1ユーザー毎に発行するコマンドが多く、LogicAppsで処理すると処理が長くなりそうな事。AzureADのユーザー属性によって処理内容を変化させる必要があり、分岐のパターンによってはコードで実装したほうがスマートであること。コマンドが通らなかった場合の、エラーハンドリングが必要なこと(例外処理が多い)など。
ログ監視バッチ
一定期間毎にクラウドサービスのログにアクセスしてデータをエクスポートする。これはコマンドは単純ですが、ログが大量の場合、APIからの戻り時間が不安なため、バッチサーバーで実行したほうがいいかもしれません。
使い分け基準
1. 管理者が実施するアクションか、ユーザーが実施するものか
これでFlowかそれ以外かを分けられます。
※ ただし、本来管理者が実施する業務だが、無料のFlowを使いたいため、システムアカウント権限でFlowを動かす方法はあり。”本来すべきではない”かもしれないけど。
2. タイマージョブか、そうではないか
もしタイマージョブ以外、例えばHTTPトリガーの場合、バッチサーバー上で動かすプログラムをHTTPトリガーで動かすのは面倒であるため、バッチサーバーは使わない方がよいと考える。
3. 短時間で終わるかどうか
もし5分以内に終わらない、あるいは終わらない可能性があれば、自動的にAzure functionsは候補から外れる。
4. ミッションクリティカルなアクションであるか
1度くらい失敗して、それに気づかなくてもよいかどうか。もしそれがNGなら安定性の高いバッチサーバー or Azure functionsで動作させるべきである。1回失敗しても、翌日に成功 or ユーザーリトライでOKだったらLogic Appsでよい。
5. Logic Appsの標準パーツで大半のフローを実現可能かどうか?
例えばExchange Onlineのユーザー設定は現状GraphAPIも用意されておらずPowerShellからしか行えないため、多数のコマンドを発行するならLogic Appsを使う意味は少ない。
6. 2～5で判断がつかない場合
タイマージョブで、そこそこ短時間で終わり、1回失敗しても翌日リトライすればOK、Logic Appsと2,3のAzure Functionsを組み合わせれば実現可能の場合。その場合にどの製品を使用するかは会社の開発ポリシーによります。例えば、Azure FunctionsはLogic Appsの部品としてのみ使用を許可、それ単体では動かさない、よって20行以上のコードを書くのは禁止する、など。
おそらく社内にコーディング規約的があるとすると1つの関数に実装する機能は1つまでなど、ある程度のポリシーがあるはずです。それと同じことをクラウド製品でも検討する必要があると思います。
まとめ
kenakamuさんがおっしゃっていたのは「なんでもできるからこそ、製品が生まれたニーズを知り、最適な使い方をする必要がある。」とのこと。
私自身、これだけサーバーレスだiPaaSだともてはやされていたとしても、コードを書いて、バッチサーバーで動かす方がいい場合もあると思いました。
