Azure Functionsは、サーバーレスのイベント駆動型コード実行サービスである。ストレージにデータが投入されたといったイベントをトリガーにして、インスタンスを中心とする実行環境が構築され、コードを実行。処理が終わると実行環境を削除する。
2017年5月号で取り上げたが、2018年9月に「Azure Functions 2.0」という新バージョンが一般提供になった。従来バージョンの1.xも引き続き利用できるが、2.xの利用が米Microsoftにより強く推奨されている状況だ。
今回はAzure Functions 2.xについて1.xからの差分を中心に解説する。さらに、Azure FunctionsとSlackを連携させることで、Azure SQL DatabaseのユーザーインタフェースをSlackにするアーキテクチャーパターンを紹介する。
検証では、実行環境として割り当てられる最大のメモリーサイズ、インスタンスの起動時間について確かめる。
Functions 2.xでJavaに対応
Azure Functionsでの改善点は大きく四つある。（1）対応言語、（2）最長実行時間、（3）バインディングである。以下で順に紹介する。
（1）対応言語
まず、2.xでは対応言語が増えた（表1）。1.xでは未対応だったJavaに対応した（2019年2月28日時点でプレビュー提供）。1.xでは試験段階だったPythonにも対応している（同）。
ただし、JavaはWindowsのみの対応、PythonはLinuxのみの対応である。さらにPythonについては、バージョン3.6.xのみをサポートしていることに留意してほしい（いずれも2019年2月28日時点）。
C#とF#のフレームワークが.NET Frameworkから.NET Coreへ変更されたことも大きなトピックである。2.xでは.NET Frameworkは使えない。
これに関連して、「開発環境がWindowsのみ」という1.xの問題が解消された。.NET Frameworkから.NET Coreに切り換えたことで、2.xではWindows、macOS、Linuxのどれでも、ローカル環境での開発とデバッグが可能になった。
しかし1.x系では試験段階だったPHP、.cmd、.bat、Bash、PowerShellが、2.xでは未対応になっている。MicrosoftのAzure Functionsのロードマップにも追加の方針は示されていない状態である。
これらのプログラム言語を使うには、Azure Functionsの設定からランタイムバージョンを1.xへ更新する必要がある。
（2）最長実行時間
Azure Functions 2.xでの二つめの改善点は、従量課金プランでの最長実行時間が5分から10分に延長されたことだ。
Azure Functionsには大きく二つのプランがある。呼び出されるたびにインスタンスを起動してコードを実行する従量課金プランと、あらかじめ確保されたインスタンスのリソースを使う定額のApp Serviceプランだ。
このうち従量課金プランでは、1.xの場合、1回の起動ごとに5分までという実行時間の制限がある。5分経つと処理が強制終了する。2.xでもデフォルト設定では5分だが、設定変更により最長10分に延ばせる。
なお従量課金プランではAzure Functionsが呼び出されたとき、当該コードを実行したばかりのアクティブなインスタンスがあればそれを利用する。インスタンスは、処理終了後の20分間にわたってすぐ実行可能な状態で待機し、その後に削除される。
インスタンスが削除された後、あるいは新規でインスタンスを立ち上げることを「コールドスタート」と呼ぶ。コールドスタートでは、アクティブなインスタンスが存在する場合より、起動時間が長く掛かる。どれだけ長く掛かるかについては、検証2で確かめる。
（3）バインディング
バインディングは、コードを記述することなく、Azureの各種サービスやTwilioのような他社のクラウドサービスなどとAzure Functionsを連携させる機能だ。バインディングによる連携対象には、トリガー（コード実行の開始イベント）、インプット（データ入力元）、アウトプット（データ出力先）の三つがある。
2.xでは、Microsoft Graphへのバインディングが追加された（表2）。これが三つめの改善点だ。
半面、外部ファイルや外部テーブル、Mobile Apps、Notification Hubs、Webhookのバインディングが廃止されている。
