Lambda＋Node.jsを使ったサービスを実装した際のTipsを雑多に書きます
※公式のドキュメントに書いてあることがほとんどです
ファイルを一時的に置くためのディスク領域(/tmp)が用意されている
プログラム内でファイル出力をしたい場合は、/tmpにファイルを置いておくことができる
一時ディスク容量 ("/tmp" スペース) 512 MB
公式ドキュメント
AWS Lambda の制限
http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/limits.html
※注意
LambdaはAWSのコンテナで動作するらしく同じLambdaファンクションであればコンテナを使いまわすことがあるようで、/tmpも使いまわされる
・前の処理で/tmpに配置したファイルが残ったまま、次のLambdaが起動して意図しない動作になる
・/tmpの容量制限512MBはコンテナごとの容量制限なので、ファイルが残ったままだと一時ディスク容量制限をオーバーしてしまう
といったことが起きるのでご注意を
ログの出し方
標準出力させると、cloudwatchにログが出力されます
※cloudwatchにログを出力するためには、Lambdaに「Lambdaへのフルアクセス権限」を与える必要があります
Node.jsの例
Lambdaファンクションが起動すると、cloudwatchに「Lambdaが起動しました」と表示するだけの例
exports.handler = (event, context, callback) => {
console.log("Lambdaが起動しました");
}
環境変数
Lambdaでは環境変数を利用することが出来ます
AWSコンソールのLambda関数画面の設定タブ内の「環境変数」で設定できます
設定例
↑の環境変数を、プログラム内で利用する例(Node.js)
const env = process.env.NODE_ENV;
ストリーム(Amazon DynamoDB ストリーム、kinesisストリーム)をトリガーにする時に気を付ける事
ストリーム(Amazon DynamoDB ストリーム、kinesisストリーム)をトリガ―にする場合とストリーム以外(S3、SNSなど)をトリガーにする場合で、リトライ処理の挙動に違いがあります
-
ストリーム以外(S3、SNSなど)をトリガーにする場合
エラーが発生した場合、呼び出しが 2 回自動的に再試行される
→エラー発生後2回再試行すれば止まる -
ストリーム(Amazon DynamoDB ストリーム、kinesisストリーム)をトリガ―にする場合
AWS Lambda はデータの有効期限 (Amazon Kinesis Streams の場合 7 日間) が切れるまで、レコードのエラーが発生したバッチを試みる
→エラー原因が解消されない限り、有効期限がくるまで延々とバッチを繰り返すので無駄なお金がかかる
公式ドキュメント
エラー時の再試行
http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/retries-on-errors.html
終了コード
Lambdaの終了コードを指定することが出来ます
- succeed
成功
- fail
失敗
- done
実行完了(引数でエラーと成功を出し分け出来る)
以下はNode.jsでの終了コード指定方法例
const env = process.env.NODE_ENV;
exports.handler = (event, context, callback) => {
if (env === "product") {
console.log("本番環境です");
context.succeed(); // 正常終了
} else {
console.log("本番環境ではありません");
context.fail(); // エラー終了
}
}
doneは使いどころがよく分かってません
メモリとタイムアウトについて
Lambdaファンクション設定時に、メモリとタイムアウトを設定することが出来ます
メモリを大きくするとCPU性能もそれに見合っただけ上昇します
cloudwatchのログに実際に使用したメモリ容量と処理時間が出力されるので、ファンクションを実際に動かしてみて最適な設定値を決めましょう
メモリを大きくするとコストも上がるので、最初から最大値にしておくということは避けましょう
メモリとタイムアウトが設定値を超えた場合、エラー判定となります
細かいこと
トリガーを有効化して初めてLambdaを起動する場合、初期化に時間がかかります(数分？)
すぐにログが出なくても焦らず待ちましょう