こんにちは。CS課の坂本です。
　サーバーワークスでは、技術ブログ執筆後のレビュー依頼を「Questetra」でおこなっています。通常は3人からOKが出ると「公開」できます。公開OKであっても、レビューしてくれた人から何かコメントが入っていることもあります。
　前回書いた記事のときは、こんなコメントがありました。

------- [2016-04-18 11:58]
良かと思います。EC2じゃなくてLambda使いたいなぁ…(ﾎﾞｿｯ)

　「EC2でスクリプトをcron実行している箇所についてLambdaにしたら？」という指摘です。やっぱり時代は「Lambdaでサーバーレス」のようです。

　確かにLambdaは昨年スケジュールベースでの実行が可能になりましたので、cronで実行しているスクリプトはLambdaに置き換えられそうです。

　ということで、今回は前回EC2でcron実行していた箇所をLambdaに置き換えたいと思います。

　※Lambdaの箇所以外は前回と同じですので、よろしければ以下の記事もご確認ください。
　前回記事：【そんなときどうする？】CloudWatchのデータを2週間以上残したい！
 

1. 今回の処理の流れ
2. スクリプトの準備
3. Lambdaの設定
4. 結果
5. まとめ

1. 今回の処理の流れ

　今回の処理の流れは以下のようになっています。処理の最初のLambdaの箇所がEC2から置き換えた箇所です。

　1. Lambdaからスクリプトを実行（今回の変更箇所）
　2. 本番のWebサーバー（www01）のCPUUtilizationの値をCloudWatchから取得
　3. 開発アカウントのDynamoDBに入れる

2. スクリプトの準備

1. スクリプト（cloudwatch-to-dynamodb.py）

　まずはスクリプトの準備をします。Lambdaは前回使っていたPHPが使えないので、Pythonでコードを書き換えます。

　以下が書き換え後の今回実行するスクリプトです。

　※処理内容については、前回の記事に補足説明があるので、よろしければそちらもご確認ください。

2. デプロイパッケージの準備

　スクリプトの準備はできましたが、デフォルトで使えるパッケージ以外をimportしたい場合は、デプロイパッケージを手元でつくってアップロードする必要があります。

　特にimportするパッケージがなく、1ファイルで完結するスクリプトであればLambdaのマネジメントコンソール上でペタッとコードを貼ることもできますが、今回は「pytz」というタイムゾーンを扱えるようにするパッケージを使っているので、準備が必要です。

　※「AWS SDK for Python (Boto3)」は標準で使えますので、SDKのデフォルトのバージョンを使う場合は、パッケージに含める必要はありません。今回使う「pytz」のみデプロイパッケージに含めます。

　まずは、以下のようにスクリプトを置いているディレクトリに「pytz」をインストールします。

pip install pytz -t /Users/kokeshi/cloudwatch-to-dynamodb

　次にコードを置いたディレクトリで、zipに圧縮します。このzipファイルをあとでLambdaのマネジメントコンソールからアップロードします。

cd /Users/kokeshi/cloudwatch-to-dynamodb
zip -r cloudwatch-to-dynamodb.zip *

　これで、Lambdaにアップロードするスクリプトの準備ができました。

3. Lambdaの設定

1. Blueprint「lambda-canary」を選択

　さて、だんだん記事が長くなってきましたが、次はLambdaの設定です。Lambdaで処理をスケジュールベースで実行するときの設定は、「スケジュールされたイベントでのAWS Lambdaの使用」に詳しい説明がありますので、今回は簡単にいきたいと思います。

　こちらの設定もこのときのようにLambdaのBlueprintを使います。Blueprintの「lambda-canary」を選択して、次の画面にいきます。

2. スケジュールの設定

　5分毎なら「rate(5 minutes)」、1時間ごとなら「rate(1 hour)」といった形で設定できます。cron形式でも設定できます。詳しい形式に関しても「スケジュールされたイベントでのAWS Lambdaの使用」に記載されていますので、使用する際はそちらもご確認ください。今回は毎時10分に実行するので、以下の画像のような形で設定します。

3. HandlerとRoleの設定

　次は「Handler」の設定です。「ファイル名.関数名」の形式で指定します。「Role」は今回の場合は事前に作成済みだったRoleを指定しています。このRoleは管理ポリシーで「AmazonDynamoDBFullAccess」と「AWSLambdaBasicExecutionRole」を指定して、インラインポリシーで以下の設定をしています。記事が長くなってきたので、この辺りの詳しい説明はまた別の機会に書きたいと思います。

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::XXXXXXXXXXXX:role/DevReadOnlyRole"
    }
}

　このページにある「Timeout」の設定はデフォルトで3秒と短かったので、適宜変更して次の画面へいきます。すぐにスタートする場合は「Enable event source」にチェックを入れて「Create function」ボタンを押せば完了です。

4. 結果

　スクリプト実行後にマネジメントコンソールをみると、以下のようにデータが入っていることを確認できます。

5. まとめ

　これでEC2でcron実行していた箇所をLambdaに変更することができました。いままで実行していたPHPのコードをPythonに変更したりと一手間必要ですが、いままでcronで実行していたスクリプトは今後Lambdaに置き換えていけそうですね。

　さて、次回です。今回もスクリプトをのせたものの、前回と同様、テーマと違う箇所には触れられませんでしたので、そちらについて書きたいと思います。

　いや〜、Lambdaって本当にいいものですね。