仮想マシンなどをあらかじめ用意せずコードを実行できるようにする「サーバーレス化」に取り組むユーザー企業が増えている。メリットはサーバーの運用管理の手間やコストを軽減できることだ。

 このサーバーレス化の取り組みで重要な役目を担うのが、イベント駆動型コード実行サービスだ。ストレージにデータが書き込まれる、あらかじめ設定した時刻になるなどのイベントをトリガーとして、プログラムコードを自動実行する。クラウドベンダーのサービスでは米Amazon Web Services(AWS)の「AWS Lambda」や、米Microsoftの「Azure Functions」などがある。

 基本的には実行時間に応じた課金のため、仮想マシンと違ってアイドル状態なのにコストが発生するという無駄を省ける。イベント発生時のみサーバーが起動する仕組みなので、運用や保守コストの軽減につながる。

 このサーバーレス化、画期的な取り組みのように思えるが、実現はそう簡単ではないようだ。

正常に動作しない場合の対策がキモ

 注意すべき点は、正常に動作しない場合の対策をどうするかだ。イベント駆動型コード実行サービスの代表格であるLambdaの場合、同時に実行できる処理の数や実行時間に制限がある。標準ではLambdaファンクション(Lambdaに自作コードを登録したもの)の同時実行数は100で、最長実行時間は5分だ。制限を超えると処理が実行されなくなる。

 Azure Functionsの場合、従量課金プラン(ダイナミックプラン)と定額のApp Serviceプラン(クラシックプラン)があり、それぞれでコード実行の制限や特性が異なる。従量課金プランはLambdaと同様に、実行時間と総実行回数に基づいて課金される。実行時間の制限は最長5分で、それ以上掛かるとタイムアウトでエラーになる。

 App Serviceプランは、アプリケーション実行のPaaS(Platform as a Service)である「Azure App Service」を契約し、それによって確保したリソースを使ってコードを実行するものだ。まあこちらのプランは「サーバーレス」とはいえない。App Serviceの契約に基づく定額プランのため、実行時間の制限はない。

 企業システムでイベント駆動型コード実行サービスを使う場合は、こうした処理数や実行時間についての制限を回避する工夫が必要になる。Lambdaの実行制限を回避しながらシステムを開発した好例として、毎日放送(MBS)の事例を紹介しよう。