2015.11.16

AWS LambdaのScheduled Eventを使ってバッチ実行してみた

shimo

先日ハードコアのライブに行ってきて、耳がまだおかしい下條です。やはり耳栓は必須です。

さて、話は変わるが、最近私が関わっているプロジェクトでは、比較的単純なWebアプリケーションでも日次などで簡単なバッチ処理をしたいという状況は意外と多い。

弊社では、これまでバッチの定時実行にはRundeckなどのジョブ管理ツールや、場合によってはcronを使ってきた。しかしこれらには以下のような問題がある。

ジョブ管理ツール: 複雑なジョブ管理が可能だが、環境構築・メンテナンスに工数がとられる。
cron: 非常に簡易に設定できるが、バッチ実行結果を監視するためにはZabbixなどの監視ツールを使用するといった工数がとられる。

そこで、以下の条件を満たすようバッチの実行方法について検討を行い、最近公開されたAWS LambdaのScheduled Eventを利用した仕組みを作ってみた。なお、比較的簡単なWebアプリケーションで、アプリサーバ上でバッチを実行し、バッチ専用サーバなどは用意しない前提である。

環境構築・メンテナンス工数を削減すること。
バッチの実行状態を監視できること。

具体的には以下のような仕組みとした。

バッチを実行するサーバに、バッチ実行用のHTTPSエンドポイントを用意しておく。
AWS LambdaのScheduled Eventを利用し日次で上記エンドポイントを叩き、バッチを実行する。
AWS Lambdaでバッチ実行結果が格納されたHTTPSレスポンスをハンドリングし、Slackに通知する。
バッチ用HTTPSエンドポイントはインターネット上に公開する状態になっている想定であり、誰でもバッチを叩けるということがないように、何らかのトークンをHTTPSリクエストに付与することで認証をかける。

Lambda側のソースコードはざっくりと以下のような感じである。せっかくなのでPythonにした。
なお、slackwebモジュールはデフォルトでLambda側に入っていないため、ローカルで作業ディレクトリにインストールし、lambda_function.pyと含めてzipファイルに圧縮してアップロードする必要がある。

# -*- coding: utf-8 -*-
import urllib
import urllib2
import slackweb

SLACK_URL="SlackのWebHook URL"
BATCH_URL="バッチ実行用エンドポイント"
BATCH_TOKEN="バッチ実行用認証トークン"

def lambda_handler(event, context):
    try:
        values = { 'token': BATCH_TOKEN }
        data = urllib.urlencode(values)
        req = urllib2.Request(BATCH_URL, data)
        response = urllib2.urlopen(req)
        result = response.read()

    except:
        slack = slackweb.Slack(url=SLACK_URL)
        slack.notify(text='batch api call error')
        return

    slack = slackweb.Slack(url=SLACK_URL)
    slack.notify(text=result)

Webアプリケーション側ではバッチの実行結果をHTTPのレスポンスに格納し、それをLambdaからそのままSlackに通知しており、毎日結果の監視ができる。

ただし、AWS Lambdaの関数実行時間は最長5分であり、5分以上かかるようなバッチでは上記の方法はそのままは採用できない。また、複雑な依存関係などを持ったバッチ処理では、やはりジョブ管理ツールの導入は必要になると思う。
ただ、簡単なバッチであれば上記のような仕組みで実現できた。

AWS Lambdaを使ってみて

私はAWS Lambdaをきちんと触ったのは初めてだったのだが、個人としての感想を少し書いてみる。

最近、サーバレスアーキテクチャという言葉を耳にするようになってきた。その背景としてはAWS Lambdaの登場が大きく、AWSの各種フルマネージドサービスをAWS Lambdaでつなぎ込むことで、自前でサーバを一切管理することなしにかなり様々なことができるようになっている。

AWS Lambdaを触ってみて、その敷居はあまり高くないと感じたし、さくっとスクリプトを書いてサーバレスで様々なことができる手軽さ・柔軟さは非常に魅力的だと思った。開発者としても、プログラミングをするのとはまたひと味違う楽しみ方もできる。このサービスとこのサービスを組み合わせればこんなこともできるじゃないかといったパズルのような楽しみである。

しかし一方で、重要なビジネスロジックが入っているサーバーサイドのアプリケーションをAWS Lambdaを中心としたフルマネージドサービスを核にして実現するとなると、ベンダーロックインの懸念が発生してくるのも確かである。したがって、実際のプロジェクトにおいて、AWS Lambda(およびフルマネージドサービス)をどこまで使うかは、時と場合に応じて判断していくことになると思う。例えば、今回ご紹介したバッチ実行システムのような本質的にビジネスロジックと関係なくベンダーロックインの懸念が小さい箇所だったり、あまり長期運用しないサービスやプロトタイプなどを素早く作りたいといった場合、AWS Lambdaは非常に有効なツールになると思った。

お客様にとって最適な形のシステムをスピーディーにご提供するため、使い所を考えながら有効活用していきたいと考えている。

Lambdaなどクラウドネイティブなアーキテクチャを活用したシステム構築やアプリケーション開発をご検討の企業様は、是非MMMにご相談下さいませ！

#AWS Lambda

AUTHOR