こんにちは。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. 今回の処理の流れ
今回の処理の流れは以下のようになっています。処理の最初の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"
}
}
4. 結果
スクリプト実行後にマネジメントコンソールをみると、以下のようにデータが入っていることを確認できます。
