概要
Lambdaで開発する時に、「あれどうだっけな」ってなった時のメモです。
Lambda関数の種類
- 同期呼び出し
- ストリームベース
- Kinesis Streams
- DynamoDB Streams
- それ以外
- Cognito
- Echo
- Lex
- API Gateway
- ストリームベース
- 非同期呼び出し
- S3
- SNS
- CloudFormation
- CloudWatchLogs
- CloudWatchEvents
- SES
- CodeCommit
- Config
イベントソース
ストリームベースのイベントソース
- 通常のイベントソースはイベントソースがLambda関数を呼び出す。
- ストリームベースのイベントソースは、Lambdaがストリームに対してポーリングを行ない、変更や新しいイベントの存在を検出したらレコードを取得し、Lambda関数を実行する。
アクセス権限
アイデンティティベースのポリシー
- IAMユーザー、IAMグループ、IAMロールに対してアタッチするポリシー
リソースベースのポリシー
- Lambdaに対してアタッチされるポリシー
- Lambdaにイベントソースをセットアップして、サービスまたはイベントソースに対して、Lambda関数を呼び出すアクセス権限を付与する。
- ポリシーの付与には、AWS CLIかAWS SDKを用いて指定する。
クロスアカウントアクセス
- Lambda関数を所有するアカウントとそれを呼び出すアプリケーションやイベントソースのアカウントが別でも呼び出せる。
テスト
- ユニットテストはローカルで実行、これ以外はクラウド上で実行する。
- ユニットテストは比較的手元で実行したい事が多いテストだから。
- Lambda関数をローカルで実行するた為に必要なもの
- ローカルで呼び出す為のエントリポイント
- イベント
- contextオブジェクト
エントリポイント
- ローカル環境で実行する際の呼び出しをどの様に行うか。
- 実行関数を作って、if文で制御して普通に実行する。
イベントデータ
- 静的に作成してします。
- 各イベントソースがが生成するイベントデータをJSON形式で記述する。
- 各イベントソースが生成するイベントデータは公式にサンプルがある。
contextオブジェクト
- contextオブジェクトには実行中のLambda関数のランタイム情報が格納されている。
- ハンドラ内部からcontextオブジェクトの各プロパティならびにいくつかのメソッドにアクセスが可能。
- 極論、ランタイム情報へのアクセスが不要であれば、ローカル実行時は特にエミュレートしなくとも良い。
- 言語毎に用意されているプロパティ名やメソッド名は異なる
VPC
- Lambda関数からVPC内にあるパブリックなIPを持っていないAWSリソースにアクセスする事が可能。
- VPC内のみの接続にしてあるRDSの接続も可能
- インターネットからアクセスがサポートされていないElastiCacheの様なサービスでも呼び出し可能
アクセス制御
- EC2やRDSのLambda制御を行いたい場合は、セキュリティグループで行う事ができる。
レイテンシ
- VPC内のリソースへのアクセスはレイテンシ増の原因となりやすい為、アクセスは最低限にするべき。
- ENIの作成に時間がかかる。
ENIのレイテンシ
- ENI は新規のリクエストや久しぶりのリクエストが発生した場合自動的にLambdaによって作成される。
- 初期化処理に時間がかかる。(10~30秒)
- 2回目以降は普通のレイテンシ
RDSとの接続の場合
- RDSにLambdaから直接レコードを書き込むのではなく、一旦DynamoDBにレコードを書き込み、その時点でレスポンスしてします。
- その後、DynamoDB ストリームとLambdaを利用して、非同期にRDSへとデータを反映する。
環境変数
- 関数からアクセス可能な環境変数を定義する事が可能。
- コードの変更なく動的に設定した値を渡せる。
- 無駄なハードコーディングが不要になる。
- 環境変数へのアクセスは言語毎に変わる。
環境変数の利用制限
- 合計サイズが4KB
- 文字で始める
- 英数字とアンダースコアのみ
- AWS Lambdaが予約する特定のキーセットは利用不可
Lambda関数自体が利用する環境変数
- 予約語のうち、更新可能なものと更新不可のものがある。
環境変数の暗号化
- キーと値はAWS KMS で自動的に暗号化されて保存される。
- 独自のサービスキーを利用することも可能。
- 別途IAMロールに対してポリシーが必要。
- 独自のサービスキーを利用することも可能。
エラーハンドリング
- 処理が異常終了した場合の振る舞いは、イベントソースのタイプと呼び出しタイプによって異なる。
- 関数の実行がタイムアウト
- 関数の呼び出しがスロットリング
- 関数の処理でエラーor例外が発生
ストリームベースのイベントソースの場合
- Amazon Kinesis StreamsもしくはDynamoDB Streamsがイベントソースの場合
- レコードの有効期限が切れるまで再試行され続ける。
- その間、エラーの発生したシャードからの読み取りはブロックされ、そのレコードのバッチの有効期限が切れるか処理が成功するまで、新しいレコードの読み込みは行われない。
- レコードの処理順序が保証される。
ストリームベース以外のイベントソースの場合
同期呼び出しの場合
- 呼び出し元にエラーが返される。
- 呼び出し元はそのエラーを受け取り、必要に応じてリトライの処理を実装する。
非同期呼び出しの場合
- 2回自動的にリトライされる。
- 3回処理が失敗した場合、デッドレターキューが構成されていれば、そのイベントはデッドレターキューとして指定されているSQSのキューもしくはSNSのトピックに送信される。
- これにより、障害発生時のイベントを取りこぼす事がなくなる
- デッドレターキューが構成されていなければイベントは破棄される。
デッドレターキュー
- デッドレターキューは、関数を非同期で呼び出す場合において、2回のリトライ、つまり3回の試行にも関わらず処理が正常終了しなかった場合にそのイベントを指定されたSQSもしくはSNSへと送る仕組み。
- コードのロジックエラー
- スロットリング
- Lambdaでデッドレターキューを設定する前に、キューもしくはトピックを作成しておく必要がある。
終わり
今後も仕様が変わる度にしっかりキャッチアップしていきたいですね。