さくらのVPSで動かしていた cron の処理を AWS Lambda で実行してみた

会社の忘年会で、卓球、ビリヤード、ダーツの3種目の総合得点でまさかの優勝をした（組んだペアに優勝させてもらった？）佐々木です。
今回は、AWS Lambda について、気をつけるべき点のまとめです。

AWS Lambda で実行してみようと思ったポイント

毎日株価をあるサイトからスクレイピングして取得してきて、自分で設けた基準を満たしているかどうかをチェックし、その結果をメールと Slack へ通知するスクリプトを作成して、個人的に使用しているさくらのVPSにて、cron で実行している。

今、さくらのVPSではそのスクリプトぐらいしか動いていない。
元々別の用途で使っていたのだが、現状では cron でスクリプトを動かすためだけに年間1万円ちょっと支払っている。
そのスクリプトを AWS Lambda に移行してみた。
試しにそっちで動くかやってみて、うまく行ったら費用も削減できる！と思って試してみた次第である。

今回、移行しようと思ったポイントは下記の3点。

• スクリプトを運良く、python で書いていた
• AWS Lambda でスケジュールイベントが設定できるようになった
• AWS Lambda が python をサポートしている

AWS Lambda に移行した際に、気をつけないといけない点がいくつかあったのでまとめてみた。

pip install でインストールしたモジュール

pip install で各種のモジュールをインストールして使用したい場合は、事前に該当のスクリプト等が入っているディレクトリにインストールする必要がある。
下記は、 requirements.txt に記載されている pip モジュールをインストールしたい場合。
-t . でカレントディレクトリにインストールしているところに注意。

$ cd test_script
$ pip install -r requirements.txt -t .

zip で圧縮

その上で、zip で固めてアップロードする。
ここでも注意が必要。カレントディレクトリ配下のファイルをそのまま圧縮すること。ディレクトリも含めてしまうとエラーになる。

$ cd test_script
$ zip -r /tmp/test_script.zip .

Handler の設定

例えば、test_script.py が下記のようなものだとすると。

def hello():
    print("Hey wat'z up yo!")

Handler の欄としては、test_script.hello のように、<ファイル名>.<メソッド名> を記入する。

引数

また、AWS Lambda にて実行する際に、event と context の2つの引数を渡して実行するので、

def hello(event, context):
    print("hey wat'z up yo!")

のように、引数を受け取れるように修正が必要。
その対応が抜けていると、下記のようなエラーになる。

TypeError: hello() takes no arguments (2 given)

Role

Lambda の実行権限を設定する。
AWS の他のリソースなど使わず単純に実行するだけであれば、Basic execution role を選べばよい。

S3でのイベントをトリガーとする場合や、処理実行結果等をS3にアップロードする場合などは、S3を扱う権限がある Role の S3 execution role を選択する。
（Role がない場合は、ここで作成することが出来る）

メモリと CPU などのリソース

割り当てるメモリとしては、最小で 128MB から、最大で 1536MB が選択できる。

FAQ にも記載されているが、メモリの量と比例した CPU などが割り当てられるので、実際に試してみて、最適なもの選択するのが良いかもしれない。

【参考URL】
よくある質問 - AWS Lambda | AWS

Q: コンピューティングリソースはどのように AWS Lambda に割り当てられるのですか?

AWS Lambda のリソースモデルでは、お客様が関数に必要なメモリ量を指定するとそれに比例した CPU パワーとその他のリソースが割り当てられます。たとえば、256 MB のメモリを指定すると約 2 倍の CPU パワーが Lambda 関数に割り当てられます。128 MB のメモリを指定した場合と比較すると CPU パワーは倍となり、512 MB のメモリを指定した場合と比較すると半分になります。メモリは 128 MB から 1.5 GB まで、64 MB ごとに増加できます。

タイムアウト時間設定

AWS Lambda のタイムアウト設定は、最小1秒から、最大で5分の間（デフォルトは3秒）で設定が可能。
ここも、前述した割り当てるメモリによって、実行時間が変わってくると思うので、何度か実行してみて適切な値を設定する必要がある。

イベントソース(Event sources)の設定

cron で設定する時間は、UTC であることに注意。

書き方としては、例えば下記のように書くことが出来る。

【参考URL】
ウォークスルー 5: Lambda 関数を使用したスケジュールイベントの処理 (Python) - AWS Lambda

ログ

ログは、サクッと終わるスクリプトなら下部に出る。
そうでなければ、Cloudwatch のログを確認する必要がある。

実行時間や使用したメモリなども表示されるので、ここを見て割り当てるメモリをいくつにするか検討できる。

簡単にサーバーレス環境ができた

以上、簡単ではあるが AWS Lambda を使うにあたって気をつけるべき点をまとめてみた。
以前弊社の下條が、こちらの記事（AWS LambdaのScheduled Eventを使ってバッチ実行してみた | MMMブログ）でも述べていたが、非常にお手軽・簡単にサーバーレスな環境が出来てしまった。
サーバー構築など面倒なことをせずに、サクッとスクリプトを動かせる環境が出来てしまう点は素晴らしい。
今回、AWS Lambda で実行してみようと思ったのは、費用の削減がきっかけではあるが、それ以上に AWS Lambda のお手軽さが良いと感じた。

実行時間に5分という制限があるものの、例えば処理を分割して実行、実行結果をS3にアップロード、そのS3アップロードされたイベントをきっかけにして次の処理を動かす、などの工夫も出来るかと思う。
サーバーの構築、保守・運用などは、意外と手間や工数がかかったりすることもあるので、そういった工数を削減できるのであれば、状況に応じて業務でも積極的に使っていくべきかな、と今回 AWS Lambda を使ってみて感じた。

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

gene