Lambda関連のことを調べてみた2022年02月25日

Lambdaの実行環境について(コールドスタートとウォームスタート)

### はじめに
* 昨年、awsブログにてOperating Lambdaシリーズの翻訳版が公開された。
* **Lambdaを使う開発者にとっては知っておくべきことが詰まったこのブログ**、3本から構成されています。今回はその内容から一部抜粋してLambdaのコールドスタートとウォームスタートについて取り上げまとめてみましたという記事です。

#### コールドスタートとレイテンシー、そしてウォームスタート
下記の図は、Lambdaの関数実行のrequestを受け取ってから、ハンドラ関数実行までの流れを表しています。
Lambdaは、Lambda APIを介して関数実行された時次のような動作をします。

1: S3バケットから実行するコードのダウンロードを行ったり、コンテナパッケージを使用している場合はECRよりダウンロードします。
2: 指定されたメモリ、ランタイム及び各種設定に基づいた環境を作成します。
3: Lambdaのハンドラ関数外の初期化コードを実行します。
4: Lambdaのハンドラ関数の実行

![スクリーンショット 2022-02-24 22.07.28.png

AWS Lambda Layersを使ったPythonライブラリーの追加

# はじめに

Lambda関数でサードパーティのライブラリーを使用したいときは、下記のいずれかの方法を使って、対象のライブラリーを追加する必要がある。
– 追加したいライブラリーを含んだパッケージデプロイ
– Lambda Layersを使って追加

今回は「**Lambda Layersを使って追加**」についてまとめていく。

# Lambda Layersを使った追加方法
## 環境
– Windows / Mac
– Dockerが使えること。
– ここではDockerのインストール方法は省略するが、ローカルの場合はDocker Desktopを使うと簡単。
– Linuxサーバー等にインストールする場合は下記記事記事を参照。
– https://qiita.com/subretu/items/549bc720165004bca3c3
## やってみて分かったこと
– Layerにアップロードするライブラリーは、AmazonLinux環境で作成しないと読み取ってくれないことが分かった。
– WindowsやMacのローカル環境で、pip

Nature Remo Cloud API + Lambdaで温度を記録して折れ線グラフを表示する自分ち専用のAndroidアプリを作った

Nature Remo Cloud API + Lambdaで温度を記録して折れ線グラフを表示する自分ち専用のAndroidアプリを作りました。
# 経緯

– 我が家ではNature Remoというスマートリモコンを使っており、Alexaやスマホアプリ経由でいろんな家電を操作できるようにしている
– そのNature Remoでは[Nature Remo Cloud API](https://swagger.nature.global/)というものが提供されており、HTTPで簡単に情報が取れるらしい
– 最近エアコン暖房がついててもたいしてあったかくない気がする
– Nature Remoに搭載されている温度センサーの値と、エアコンの稼働状況をAPIから定期的に取得し、保存して見える化すればエアコンが本当に調子が悪いのかわかるのでは？
– 単純に室温の変化が見えたら面白そう
– [気象庁ホームページのリニューアルでアメダスのデータも簡単に取れるようになったらしい](https://mindtech.jp/?p=1754)のでついでに外気温も取得してみよう

# つくった

AWS Step Functions Localでモックテストをする

# はじめに

AWS Step Functions Local にモックテストができる機能が1/31に追加されました。
[AWS Step Functions でローカルなワークフローを模擬的にテストすることが可能に](https://aws.amazon.com/jp/about-aws/whats-new/2022/01/aws-step-functions-support-workflows/)

私はこのモック機能でStep Functions Localのことを知ったわけですが、2019年の2月には出ていた機能になります。
[AWS Step Functions ワークフローをローカルで開発してテストする](https://aws.amazon.com/jp/about-aws/whats-new/2019/02/develop-and-test-aws-step-functions-workflows-locally/)

[弊社](https://www.milogos.co.jp/)にはStep Functionsを軸として複数のLambdaを呼ぶシステムがあるため、

sls deployでThe stack service name 〜〜 is not valid. と出た時の対処法

# 概要
`sls create`して作ったサービスをデプロイしようとした時、
コマンド`sls　deploy`で`The stack service name 〜〜 is not valid. `というエラーが出たので、解決方法を書きます。

# エラー

> The stack service name “sls_go_project-dev” is not valid. A service name should only contain alphanumeric (case sensitive) and hyphens. It should start with an alphabetic character and shouldn’t exceed 128 characters.

エラー文を読むとサービス名の制約が書かれていました。
* サービス名はアルファベットとハイフンだけである。
* アルファベットで始まり、128文字を超えないこと。

serverless.ymlの設定を見直しました。

# 原因
serverless.ymlの`service: `以降にアンダ

【メモ】AWS LambdaでのPythonのレイヤー作成方法参考記事

https://stackoverflow.com/questions/63931402/runtime-importmoduleerror-unable-to-import-module-lambda-function-no-module

AWS SAMでDocker + Lambdaで環境変数が渡せない

なぜか公式ドキュメントでも情報が少ないのでこちらで共有しておきます。

## 困ったこと
Dockerイメージ環境変数を渡したいけどできない!?
ラムダレイヤーなどと同じ扱いで、ビルド済みのコンテナに環境変数は渡せなさそう
(いい方法あったら教えてください。)

## 結論
**DockerBuildArgs**
を使ってdcoker build 引数に環境変数を追加する

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-using-build.html#build-container-image

“`template.yml
Resource:
Function:
Type: AWS::Serverless::Function
Properties:
PackageType: Image
MemorySize: 512
Metadata:
DockerTag: p

CFnでSNSアクセスポリシーを自動追加する【Lambda-backedカスタムリソース】

# 背景
例えばEventBridgeから既存のAWS SNSトピックをパブリッシュするルールを作成するとき。
**1. AWSコンソール上から手動でEventBridgeを作成した場合**
→ パブリッシュ先SNSのアクセスポリシーにも自動的にEventBridgeの許可ルールが追加されます。
**2. 一方、CLIやCFnから同様にEventBridgeを作成した場合**
→ SNSにアクセス許可が自動追加されることはありません。そのままではEventBridgeからのパブリッシュがSNS側で拒否されてしまいます。

そのため、EventBridgeからの許可ポリシーもCFnで自動追加できないかなーと思いました。
（手動でポチポチ追加しても良いけど、現場では多数のAWSアカウントを管理しているため、簡単に追加できるよう自動化したい。要は楽したい。）

# 解決策1と懸念点
[クラメソさんの記事](https://dev.classmethod.jp/articles/event-bridge-notify-sns/#toc-6)にヒントをもらって、Lambda-Backedカスタム

クラスメソッド(Classmethod)の(DevelopersIO)記事を参考にしてPhysicalResourceIdを雑に扱ってAWSカスタムリソースを作るとおかしいことになるのでAWS公式のドキュメントをちゃんと見よう

# 先行研究

CDKではないけど参考になる

– https://qiita.com/willco21/items/534436ba89a3c6f217ac

# TL; DR

– PhysicalResourceId はちゃんと指定しよう。何も考えずに `context.logStreamName` をそのまま使うのはやめよう。

“`JavaScript:custom_resource_lambda.js
function sendResponse(event, context, responseStatus, responseData) {
var responseBody = JSON.stringify({
Status: responseStatus,
Reason: “See the details in CloudWatch Log Stream: ” + context.logStreamName,
// ↓ ここをちゃんと管理しないとカスタムリソースのDELETEが無駄に発生するので、
//

Lex使用時、Lambdaでできるテクニック

#はじめに
LexとLambdaでできる応用テクニック？を書き留めます。

事前にこちらでLambdaとLexを設定しました。

https://qiita.com/holdout0521/items/58f524be7cc5d9ca2093

# LexとLambdaでできること色々
以下のスロット値の入力のコードについて、できることをまとめます。
[フルのコードは、こちらです](https://qiita.com/holdout0521/items/58f524be7cc5d9ca2093#python%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3)

Lexの流れは、以下の通りに聞かれます。
`発話 → telephoneNumber(電話番号) → date（日付） → age（年齢） → 確認 → yes/no`

“`py
if slots[‘telephoneNumber’] is None:
return elicit_slot(‘telephoneNumber’, intent_name, slots)
else

【Serverless Framework】Lambda爆速開発

## なぜServerless Frameworkなのか


私自身、LambdaのコードをGitで管理するためにTerraform + GitHub ActionsでCI/CD構築していましたがデプロイに時間がかかり開発効率が非常に悪いことやTerraformの記述量が多くなってシンプルに管理できないことがデメリットに感じていました。しかし、今回のServerless Frameworkを使うことで爆速かつシンプルに開発することができます。

# 開発手順

## AWS CLIのセットアップ

この記事では深く解説しないのでこちらの記事を参考に設定してください。

https://qiita.com/n0bisuke/items/1ea245318283fa118f4a

## Serverless Frameworkをインストール

“

API Gateway + Lambda(Python) の REST API でステータスコード管理をする

# 背景
API Gateway + Lambda(Python) の REST API があったのですが、えいやで作ったのでエラーハンドリングを全然していませんでした。
全てステータスコード200で返してパラメータでエラーかどうかを設定する方法のが簡単そうでしたが、やっぱり個人的に気持ち悪さを感じるのできっちりステータスコードを使い分けようと思いました。
AWS初心者の私には結構複雑だったのでメモっておきます。
自分的ベストプラクティスのつもりですが、一般的なベストプラクティスがあればぜひコメントください。

# 結論
先にざっくりと結論から。

### API Gateway の設定
– [メソッドレスポンスにステータスコードを追加する](#メソッドレスポンスにステータスコードを追加する)
– [総合レスポンスにステータスコードに対応するマッピングを追加する](#総合レスポンスにステータスコードに対応するマッピングを追加する)

### Lambda でやること
– [マッピングに該当する”errorMessage”を返却する](#マッピングに該当するerrormessageを返却

Mangumを用いたFastAPI製APIのSAM Local実行方法 メモ

* Fast APIで作成したAPIをSAM Localで実行する方法についてメモする。

# Mangum

* ASGI(Asynchronous Server Gateway Interface)アプリをAWS Lambdaで動作させるためのアダプター
* FastAPIなどで実装したASGIアプリを、Lambda + API Gateway構成でサーバレスにWebアプリケーションとして動かす事が可能
* FastAPI利用者であれば、Lambda特有の文法を覚えずLambda利用をスモールスタートできる

## 手順

### 1.サンプルSAMプロジェクトを作成

“`shell
sam init
“`

※ランタイムはPython3.8を選択

* “template.yml`

* Hello World Exampleを利用する。
* 特に内容は変更しない。

* `requirements.txt`

“`
requests
mangum
uvicorn
fastapi
“`

※Mangum,FastAPIを利用する

Lambdaで（定期実行）スクレイピングの初期段階の構築をしてみた

# はじめに
AWS Labmdaで、Pythonでスクレイピングするアプリの基礎部分の構築をまとめた
CloudWatchで毎時実行する設定も組み込んだ
※LabmdamCloudWatchは永久無料で使用できるため、お気軽にご利用ください
　　↓詳細はこちら

https://aws.amazon.com/jp/free/?all-free-tier.sort-by=item.additionalFields.SortRank&all-free-tier.sort-order=asc&awsf.Free%20Tier%20Types=tier%23always-free&awsf.Free%20Tier%20Categories=*all

# モジュールのインストール
下記をローカルで(Macの人はターミナルで）1行ずつコマンド実行してください

“`
mkdir packages
cd packages
pip install requests -t ./
pip install beautifulsoup4 -t ./
touch lambda_function.py
“

CloudwatchのEC2自動復旧をlambdaで自動一括設定

Cloudwatchの機能を使ってEC2の自動復旧（オートリカバリー）を設定することができますが、管理しているEC2が増えてくるとアラーム設定自体がとても面倒で、かつ設定漏れのリスクも出てきます
そこで、EC2自動復旧の自動一括設定ができるようにします

#前提条件
+ 自動復旧がサポートされているEC2インスタンスタイプであること
[サポートされているEC2を確認](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html)
+ Cloudwatch利用

#lambdaを使ってEC2のオートリカバリーを自動設定する
Cloudwatchで、EC2の「StatusCheckFailed_System」を検知し自動再起動する設定ができます
lambdaを使って、特定のタグを設定したEC2に対して、オートリカバリーのCloudwatchアラームを自動一括設定できるようにします

##まずは、lambdaを作成します
python 3.9でlambda関数を作成しました

`

Visual Studio Codeを用いたLambda関数ローカルデバッグ方法メモ

* vscodeでLambdaをデバッグする方法についてメモする。

## 事前準備

* SAMプロジェクト作成

* ひな形作成

“`shell
sam init
“`

※ランタイムはPython3.8を選択。

## 手順

**1.vscodeでSAMプロジェクトを開く。**

**2.Lambda関数`app.py`を開き、テスト用にコメントアウトを外す。**

“`python
import json
import requests

def lambda_handler(event, context):
“””Sample pure Lambda function

Parameters
———-
event: dict, required
API Gateway Lambda Proxy Input Format

Event doc: https://docs.aws.amazon.com/apigateway/latest/develope

NATインスタンス を用いて、VPC内でLambdaを実行

# はじめに
APIサービスを利用するにあたり固定のIPにする必要があったため、Lambda + 固定IPのNATインスタンスを構築しましたので、まとめます。
NATゲートウェイの方が、運用は楽ですが、サービスが小規模かつ、コスト面でNATインスタンスの方が安いため、こちらを利用しました。

##コスト
NATゲートウェイ：稼働時間料金で46 USD/月、+ データ処理および転送料金
NATインスタンス：稼働時間料金で10 USD/月(t3.micro)、+ 転送料金

# 完成図


# 事前構築
VPCやサブネットは以下のように作成しましょう。

![スクリーンショット 2022-02-14 22.41.56.png](https://qiita-image-store.s3.ap-nort

【AWS lambda】Terraformでlambda関数を作成してみよう【Terraform】

# Terraform で AWS Lambda Function を作成してみよう

Terraform で AWS Lambda 関数(Hello,Lambda!)を 一番簡単な構成で作成してみます

## バージョン

試してみたバージョンは以下の通りです

| Name | Version |
| ——— | ——- |
| terraform | 1.1.5 |
| aws | 4.0 |

## 構築リソース

– lambda function
– IAM role

IAMロールはlambdaがAWSリソースに変更を与えるために必要になります
今回はHello,Lambdaを表示するだけなのでほぼ何も権限を付与してません

## 手順

### 1. IAMロールを定義

IAMロール作成は`Module`を使います

IAMロールをterraformで作成するには、
`aws_iam_role`, `aws_iam_policy`, `aws_iam_role_policy_attachment`
の3つを定義する

Svelte から AWS Lambda を API Gateway をトリガーに呼び出す

Svelte で書かれた、氏名とメールアドレスを入力する欄があるだけのシンプルなフォームの Submit ボタンが押されたとき、AWS Lambda 関数を呼び出す場合を考えます。

## Svelte プロジェクト作成

以下のコマンドを実行して、プロジェクトを作成し、バリデーションの[felte](https://felte.dev/)をインストールします。``は、任意の名前です。

“`bash
$ npx degit sveltejs/template $ cd $ npm install
$ npm install –save felte yup @felte/validator-yup
“`

ちなみに`npm install`は`npm i`に、`npm –save`は`npm -S`に置き換えられます。

`src`直下にある`App.svelte`を以下に書き換えます。felte を読み込んでいます。

“`svelte:App.svelte