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

AWS Lambda(Python)から直接画像を出力する方法（覚書）

# SVGを出力したい

特に何も考えずに `Content-Type` だけしっかり指定してあげればOK。

“`Python
return {
‘statusCode’: 200,
‘headers’: {
‘Content-Type’: ‘image/svg+xml’,
},
‘isBase64Encoded’: False,
‘body’: ‘svg version=”1.1″ xmlns=”http://www.w3.org/2000/svg”>…’,
}
“`

# PNGを出力したい

こっちが主題になります。
Pythonで画像を取り扱う場合、何らかのライブラリを使用することになると思いますが、今回はおそらく一番使われてるであろう[Pillow](https://github.co

Amazon API Gateway + Lambda統合をJavaで実装するメモ

## 対象読者
– 自分
– JavaでLambdaを実装する人
## API Gateway
REST APIで定義する。
メソッドの作成時、統合タイプが選択できる。この時Lambda関数が選択できるが、
– 「Lambda プロキシ統合の使用」にチェックを入れるとLambdaプロキシ統合のリクエスト・レスポンス形式に沿ってLambda（Java）の実装が必要
– Lambda プロキシ統合
– チェックを入れないとAPI Gateway側の「統合リクエスト – マッピングテンプレート」での定義が必要となる。
– API Gateway 内でリクエスト変換をするということ
– Lambda 非プロキシ統合

マッピングテンプレートの例：
“`text:マッピングテンプレート
#set($inputRoot = $input.path(‘$’))
{
“title” : $input.json(‘$.title’),
“body” : $input.json(‘$.body’),
“coverImageUrl” : $input.json

RDS Proxy を使って、AWS Lambda から接続してみた

# はじめに

AWS Lambda が良く語られますが、予測不可能なリクエストが来た時に、多くのインスタンスを横に並べてリクエストを捌く構成があります。AWS Lambda の場合は、1リクエスト1インスタンスとなるので、需要が高まったときには必然的に多くのインスタンスが立ち上がる構成になります。この時、インスタンス が RDS のコネクションを取得している場合、多くのデータベースコネクションを取得することにより、データベース側の負荷が高まってしまう課題がありました。

こういった問題を解決するための選択肢の一つとして、RDS Proxy と呼ばれるデータベースのコネクションをプールしてくれる機能があります。Amazon RDS に備わっている機能となっており、複数のインスタンス間でデータベースコネクションをプールしてくれます。

RDS Proxy を利用するメリットは次の通りです。

– アプリケーションのスケーラビリティ
– データベースのフェールオーバーに伴う、アプリケーション側のフェールオーバーにかかわる時間の短縮
– AWS IAM 認証により、クレデンシャル情報を Se

AWS Compute Optimizerを利用したコスト・パフォーマンス最適化

## はじめに
まず、AWS Compute Optimizerというサービスをご存知でしょうか？
AWS Compute Optimizerは簡単に言うとAWSコンピューティングサービスのメトリクスから
パフォーマンス及びコストを最適化の提案をしてくれるサービスです。

“`
AWS Compute Optimizer は、 AWS リソースの設定と使用率のメトリクスを分析するサービスです。
リソースが最適かどうかを報告します。また、コストを削減し、ワークロードのパフォーマンスを向上させるための最適化に関する推奨事項を生成します。
“`
https://docs.aws.amazon.com/ja_jp/compute-optimizer/latest/ug/what-is-compute-optimizer.html

## 対象リソース

AWS Compute Optimizerでは以下のリソースをサポートしています。

– Amazon Elastic Compute Cloud (Amazon EC2) インスタンス
– Amazon EC2 Auto Scaling

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)

te

【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