Azure Antennaハンズオン（2018/10/10）の参加報告
Azure Antennaでは、毎週水曜日午後にハンズオンを開催しています。今回、2018/10/10に開催されたハンズオン「Azure Functions と キューで構築するNoOpsスケーラブルバッチ処理基盤」に参加してきましたので、かなり遅れましたが、その内容をまとめます。
ハンズオンの概要
ハンズオンでは、Azure Queue Storage、Azure FunctionsとCosmos DBを使って、大量のデータをバッチ処理できる、サーバレスな構成を実際に構築して習得しました。
大まかな処理の流れは以下の通りで、シンプルで分かりやすいです。
- バッチ処理の発行元からQueue Storageにデータを投入する
- キューイングをトリガーにAzure Functionsでデータを処理する
- 処理結果をCosmos DBに投入する
- 処理の状況は、Application InsightsやAzureモニターで監視する
Functionsは自動的にスケールするので、大量のデータが来ても捌くことができます。また、Functionsで処理した結果を格納する先にCosmos DBを使うことで、大量のリクエストを処理した場合でもDB側もスケールできるように構成されています。
所感
Queue StorageとFunctionsでサーバレスのバッチ処理を構成する方法が分かりやすいと思いました。
ここでは詳細は割愛しましたが、バッチ処理のプログラミングも、FunctionsのTrigger/Bindingを使うことでがシンプルに書けていたと思います。
Queue StorageとAzure Functionsの組み合わせの利点
Azure FunctionsがQueueのトリガーを持っていて、Queueの状態を監視するループを持たなくてよい点、
またCosmos DBもバインディングがあり、出力が簡単に記述できる点がメリットだと感じました。
また、処理量が増えてもプラットフォームだけで調整できる点もメリットだと思います。
サービスプラン
今回のハンズオンでは、App ServiceプランのFunctionsを利用したので突然のリクエスト増加にも耐えられるのですが、
固定費用で、費用がそれなりにかかってしまうのが難点かと思いました。
呼び出し回数と実行時間・メモリ使用量に応じて課金される従量課金プランは安価ですが、コールドスタートの問題があり、
一定時間（20分間ほど）呼び出しがないと、その次に呼び出しで10秒ほど待たされてしまいます。
バッチ処理の場合、その処理頻度と処理時間の制約によっては対応策を考えないといけなさそうです。
ServiceBusキューとの違い
Queue Storageのほかにも、Event Hubs、Event Grid、Service BusがあってFunctionsでそれぞれサポートされています。
これらのサービスは、バッチ処理の機能要件・非機能要件に応じて、選択が必要だと思います。