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

【AWS】AWS Lambdaで外部モジュール（ライブラリ）を含むPythonをzipデブロイする方法

## 背景
– [AWS Lambda](https://aws.amazon.com/jp/lambda/)で`Python`を実行する際、[pandas](https://pandas.pydata.org/)などの外部ライブラリは`Lambda`に事前に`install`されていないため、いずれかの方法で`Lambda`に外部ライブラリ等を`install`させる必要があります。
– 私が知る限りでは、[AWS Lambda](https://aws.amazon.com/jp/lambda/)で`Python`を実行する際に、外部ライブラリを使用できるようにする方法は以下の3つです。
1. [Lambda レイヤー](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/invocation-layers.html)を使用する方法。
2. [zip デブロイ](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/python-package.html)を用いる方法。

PyhonでChatGPTのLineBotを作る

### TL;DR
流行りに乗ってChatGPT(本当はOPENAIのgpt-3.5-turboエンジン)のWebAPIをたたくLineBotを作る
ほぼ、下記記事の劣化焼き直し
https://zenn.dev/umi_mori/articles/chatgpt-api-python
https://chatgpt-lab.com/n/n55257c082a9d

### OPENAIキーの発行方法
下記の通り。ただし、https://openai.com/api/はproductのページへリダイレクトされてしまう
https://platform.openai.com/account/api-keys などにアクセスする
https://zenn.dev/umi_mori/books/chatbot-chatgpt/viewer/how_to_use_openai_api#api%E3%81%AE%E7%99%BA%E8%A1%8C%E6%96%B9%E6%B3%95

### LineDeveloper登録
下記などを参考にする。
https://chatgpt-lab.com/

API Gateway JWT Authorizerメモ

## JWT Authorizerとは

* クライアントが API リクエストとともに送信する JWT を検証するAPI Gatewayの認証機能

* トークンの検証、およびオプションでトークン内のスコープに基づいてリクエストを許可または拒否する

## JWT Authorizer 認証の流れ


1. トークン発行者(認可サーバー)によって提供されるJWT形式のトークンを含んだHTTPリクエストが行われる

2. API Gatewayがリクエストを受信し、API Gatewayは検証のためにトークンをJWT Authorizerに渡す

* `identitySource` に指定されたトークンを取得する

* `identitySource`にはトークンのみを含めるか、`Bearer `

Chatwork上で会話できるChatGPTボットをAWS Lambdaだけで実現するとき、Elixirだと少し良いものができたお話

# はじめに

長いタイトルですが、最近流行りのOpenAI APIを使ってChatwork上で会話できるボットを、AWS Lambda単体で作ってみたところ、同じ手間でElixirだと少し良いものができたので、そのお話です。

# 作ってみる

## 材料

– OpenAIのAPI key
– Chatworkのアカウント（質問者のアカウントと、回答者（ChatGPT）のアカウント）
– 回答者（ChatGPT）のアカウントのAPIトークン
– Chatworkの[サービス連携]→[APIトークン]より取得できます。
– 回答者（ChatGPT）のアカウントのID
– Chatworkの[環境設定]→[Chatworkについて]より取得できます。
– ChatGPT用のグループチャットのルームID
– Chatworkでチャットを開いた時に表示されるURLの#!rid以降の部分を指します。たとえば、`https://www.chatwork.com/#!rid123`のルームIDは`123`です。

## AWS Lambdaの実装

まずは`mix new

メールに添付されたCSVファイルの取り込み→加工→転送をAWSのサーバレスで構築する方法の考察 part1 メール受信編

# やりたいこと
下記工程を人の手でやっていたところを自動化したいそう。
なんとなくAWSだけで構築できそうなので考えてみた
1. データが記入されたCSVファイルをメールで受け取る
1. 受けとったCSVファイルを確認する
1. 記入内容にミスが無ければサーバに格納
1. 記入内容にミスがあれば、記入列を色付けして返信

↑イメージこんな感じ。
を
↓こんな感じにしてみようかと。
1. SESでSCVファイルが添付されたメールを受信する
1. 受信したメールをS3に格納
1. S3格納をトリガーにLa

Lambda でPython のデコレーターが Cold Start に含まれるのか確認してみた

# はじめに

Lambda で Python を動かす際に、Lambda Handler にデコレーターを付けることができます。デコレーターを利用する理由は、ソースコードをクリーンにするために、冗長的な記述を共通化したり、ロジックを分離できる点などがあげられます。

今回の記事では、デコレーターが Python のコールドスタート、ウォームスタート部分にどのような影響が有るか X-Ray で確認していきます。次の 2 点の疑問を解消するための検証です。

– デコレーターで定義した関数に時間が掛かった場合、X-Ray の画面ではコールドスタートに加算されるのか？ウォームスタートの加算されるのか？
– デコレーターを定義したファイルで、グローバルスコープで import を行った場合、コールドスタートに加算されるのか？ウォームスタートの加算されるのか？

といいつつ結論から書くと、次の通りの結果になりました。

– デコレーターで定義した関数に時間が掛かった場合、**デコレーター部分の実行時間はウォームスタートに加算される**。
– デコレーターを定義したファイルで、グローバルス

ChatGPTをSlackから使う（gpt-3.5-turbo）

# 概要
2023年3月1日に[一般公開](https://openai.com/blog/introducing-chatgpt-and-whisper-apis)されたChatGPT API（gpt-3.5-turbo）をSlackから使ってみました。
今まで最も性能の高いモデルだったGPT3（text-davinci-003) と比較すると、
API経由で入力されたデータはデフォルトで学習しないので情報漏洩のリスクが軽減し、
利用価格は10分の1（英語の場合で約4000文字または750語あたり約0.27円）に削減されたようです。

# システム構成
`Slack/AWS Lambda/ChatGPT API` の3つです。
SlackからのリクエストをAWS Lambdaに送信する場合、API GatewayとAWS

Lambdaのcontext.fail()は即座に処理を中断するわけではないみたい

Lambda内でcontext.fail()を呼び出して処理を中断させようとしても、後続の処理が実行されてしまうことに気がつきました。

例:

“`js
exports.handler = function(event, context, callback) {
if (!event.id) {
context.fail(new Error(‘Invalid input: id is missing’));
}

// この行以降の処理が実行されてしまう
console.log(‘Success’);

const response = {
statusCode: 200,
body: JSON.stringify({message: ‘Success’})
};
callback(null, response);
};
“`

調べた記録と対処を書いておきます。

## stackoverflowの回答
stackoverflowで見つけた質問と回答を読んでみます。

[AWS Lambda function c

TwitterAPIをServerlessを使ってLambda + Pythonで動かしてAPIGatewayで呼び出せるようにしてみた

# 前提
Node.jsで動かしてみてしっくりこなかったのでPython3でTwitterAPIを動かして見たいと思います。

Node.jsの記事
https://qiita.com/tama0571046/items/2bd9c94bbe3474243bea

2023/03/03追記
TwitterAPIが有料化したため利用が難しくなりましたが、サーバーレス自体は利用できると思いますので参考にしてください。

# dockerのインストール
後述する**serverless-python-requirements**で必要になります
こちらのサイトからインストールできます
https://www.docker.com/

# AWSクレデンシャルの設定

アクセスキーとシークレットキーはAWSのユーザから取得してください

“`zsh
aws configure
> aws_access_key_id: ***
> aws_secret_access_key: ***
> region: ap-northeast-1
> output: json
“`

# serverl

AWS Lambda　ウォームスタートと/tmpディレクトリ

# はじめに
AWS Lambdaを使用していた際に、`/tmp`ディレクトリに置いたファイルが、次の実行に継承されていることに気がついたので、その仕組みをまとめる。

# 参考文献
https://www.keisuke69.net/entry/2020/09/29/131203

# AWS Lambdaの実行について
前提としてLambdaは、Lambda関数に対してリクエストが行われたとき、リクエストごとにインスタンス（実行環境）が生成され、そのインスタンスで処理が実行される。
このインスタンスの作成・実行の流れをもう少し詳しく分割すると以下のようになる。

>1.実行環境の作成
>2.デプロイパッケージのロード
>3.デプロイパッケージの展開
>4.ランタイム起動・初期化
>5.関数/メソッドの実行
>6.コンテナの破棄

この流れのうち、関数/メソッドの実行までの部分は、Lambda関数の設定を変更したり、コード内容を変えたりしない限りは毎回同じことを繰り返すことになり、非常に無駄の多い処理となってしまう。
このような無駄な処理を排除し、既に作成した実行環境を次回以降のリク

AWS ResourceExplorerを使って前日のリソース増減をTeamsに投稿したい

# はじめに
　[AWS Resource Explorer](https://aws.amazon.com/jp/blogs/news/introducing-aws-resource-explorer-quickly-find-resources-in-your-aws-account/)をご存じでしょうか。2022年12月に発表されたサービスで、複数のリージョンをまたいで、アカウントのAWSリソースを検索できるようなサービスです。
　今回は、このResource Explorerを使って、昨日増減したAWSのリソースをTeamsに通知するような仕組みを作るために考えたことや、（結局微妙な点が多くあまり活用できないかもしれないという結論になったのですが)現在残っている課題等を共有させていただきます。

# やりたかったこと
　今回やりたいことはシンプルで、毎日、昨日から今日にかけて作成あるいは削除されたリソースをTeamsに投稿できるようにすることです。
![yaritakatta.png](https://qiita-image-store.s3.ap-northeast-1

serverless deployしたLambdaとDynamoDBの接続で詰まったお話

# はじめに
serverless deploy後にLambdaとDynamoDBの接続で色々詰まった点をまとめてみます。ファイルに関しては数が多いため記載は一部にしています

# 前提
– Docker in Dcokerでserverless deploy
開発環境のコンテナの中でデプロイコマンド(sls deploy)を実行しています

– React+Rails+DynamoDB+APIGateway+Lambda
– フロント(React)からバックエンド(Rails)にパラメータを渡せている

# ディレクトリ構成(一部)
この記事の環境に関しては前回の続きになります

https://qiita.com/does_not_exist/items/a68570cd062f5ff991e5

“`
sample-project
┣ backend
┃ ┗ config
┃ ┗ aws.yml
┣ Dockerfile
┣ serverless.yml
┣ docker-compose.yml
“`

# 詰まった点
## フロントからパラメータを送ると、Dyn

【スクレイピング】Yahoo!天気予報をスクレイピングして定期ツイートする方法Part1【Python, AWS Lambda, Twitter API】

## はじめに
　今回、とある企業アカウントのTwitter運用をすることになったのですが、どう考えても単純作業部分をマンパワーで回すのは「非効率的すぎるなぁ」と思ったので、自動化できる部分は自動化してやろうと思い以下のようなプログラムを書くことにしました。

　他にも色々と自動化しちゃったのですが、今回お見せするのは“毎朝のご挨拶ツイート”を自動化している部分です。Part1ではプログラムの中心となるPythonコードを、Part2ではAWS Lambdaに載せて走らせる方法を書き記していきます。

　ここら辺の知識が欲しい駆け出しPythonエンジニアさんの参考になったら嬉しいです。

## ちなみに、、、
　スクレイピングという行為自体は違法ではないものの、それを禁止しているサイトに対して行なってしまうと、違法行為になってしまう恐れがあります。判例などもあるので、「ドメイン/robots.txt」を参照して、サイト運営者がスクレイピングを許可しているかどうかをよく調べてから行うようにしてください。

　幸い、Yahoo!天気予報はスクレイピングを禁止するなどの記述はないようなので

IoTボタンからTeamsへの自動投稿を行う(前半)

# TL;DR
– AWS IoTボタンからTeamsの自動投稿を行いたいが、そこに至るまでピタゴラスイッチ的パイプライン構築を行う
– 前半として、AWS IoTボタン登録からLambda実行、RSSフィード生成までを記載する

# 背景・モチベーション
自社のテレワークの前提として出社、休憩、退社時にTeamsでその旨を投稿する
わざわざそのために、自社PCにログインし、ワンタッチパスワードを発行し、仮想OSにログインし、Teamsを開く必要がある
このためパイプラインを構築し、その部分を自動化したかった

# 構成
最終的に下記の構成になった

AWS IoTボタン → Lambda → (自宅Webアプリ) → S3(RSSフィードxml配置) ← PowerAutomate → Teams

# Lambaの作成
後に登録するAWS IoTボタンと同じリージョンで下記のようなLambaを登録する
今回は、実際の処理部分は自宅のWebAPIサーバで行っており、Lamba側はリクエストを転送するのみにしている
(のちほどロジック部分のLambdaに移植する予定)

“` ha

MailCatcherでメールデータのバックアップを手軽に取得する方法

みなさん、開発時のメール送信の検証はどうしていますか？

弊プロダクトでは、MailCatcherというSMTPダミーサーバーを使用しており、メール送信検証は全てMailCatcherを使用しております。

https://mailcatcher.me/

開発環境だけではなく、ディレクターなども触る環境でもメール誤送信防止のため、MailCatcherを使用しているのですが、複数人で触るとたびたび…

「あ、メール間違って削除しちゃいました☆てへぺろ(・ω<)」 といった事故が... なので、事故っても良いように、MailCatcherのメールデータバックアップを取得するようにしてみました。 ## 成果物 https://github.com/yamachita0109/mailcatcher_backup ## 実装する前に... ### ググっても出てこない... Google先生に聞いてもMailCatcherのバックアップについて何も教えてくれない。。 じゃあ調査するしか ### MailCatcherのデータがどこに保存されているか調査 まず、Mail

【FastAPIサーバーレス】Github更新でLambdaを自動更新させるテンプレート

# 初めに

FastAPIを使いつつサーバーレスをAWSで構築します。
Githubの更新にActionsを利用して自動でLambdaへの反映を行うテンプレートを作成しました。

テンプレートレポジトリ: https://github.com/foasho/fastapi-lambda

## 動作手順

– レポジトリをダウンロード
– Local上でのAPIテストとPyTestの実行
– githubにPushし、Actionsを確認する
– IAMでAPIキーを取得し、GithubのRepository Secretsに設定
– Lambda作成とS3を作成後、main.ymlの編集
– APIGateway作成
– 接続確認

## ディレクトリ構成

“`commandline

|- .github/workflows/main.yml
|- pytests
|- __init__.py
– test_main.py

|- .gitignore
|- main.py

AWS Lambdaのハードコーディングを改善する

# はじめに
S3上のCSVファイルのデータをRDS上のMySQL DBに書き込むLambda関数を作成しました。
ハードコーディングを回避するためにしたことを書いていきます。

## システム構成
構成図は次のとおりです。メインの処理にかかわる部分は赤色の矢印にしています。
S3、RDS、Lambda以外のサービスは以下の用途で使います。
なお、今回は使用していませんが、LambdaとRDSを接続するときは、RDSプロキシを使うのがベストプラクティスです。
##### EC2
RDS上のDBにコマンドを流すために使います。テーブル構築と実行結果の確認に使用しました。
Lambdaのコードで同様のことができるのですが、コマンドを流すのが簡単で実行結果の視認性も高いため、EC2インスタンスを立てました。
##### Systems Manager

[AWS]APIGate+Lambdaで限定のAPIを作る

## 必要
– SAM(Serverless Achetecher Model)
– https://qiita.com/hayao_k/items/7827c3778a23c514e196
– AWSのアカウント

## UsagePlanは必須

API GatewayでAPIキーを使用してアクセス制御を行う場合は、Usage Plansが必要です。

– APIキーを作成する際、そのキーにどのようなルール（または制限）を適用するかをAPI Gatewayに指示する必要があります。このルールは「UsagePlan」と呼ばれます。
– UsagePlanとは、APIキーを何回使えるか（秘密のパスワードで何回ドアを開けられるか、というような）指示書のようなものです。
– リクエストがルールに従っていれば、API Gatewayはそのリクエストを通過させ、APIは想定された動作を行います。もしリクエストがルールに従っていない場合は、API Gatewayはそれをブロックし、通過させない。

“`yaml
AWSTemplateFormatVersion: ‘2010-09-09’
T

SAMを使用してCloudwatchアラームがアラーム状態になったらSlackに通知が行くようなシステムを構築する

本日はSAMを使い、Cloudwatchアラームが発生した場合Slackにメッセージが送信されるサーバレスアーキテクチャーを構築します。

AWS Serverless Application Model (AWS SAM) は、AWS でサーバーレスアプリケーションを構築するために使用できるオープンソースのフレームワークです。Lambdaだけでなく、SNS,S3、SES、Cloudwatchを使用したサーバレスなシステム構築を簡単に行うことができます。
SAMコマンドを使用し、Cloudformationのスタックのデプロイを行うことでシステムが簡単に構築されます。

環境についてはCloud9を使用してPythonで開発を行います。Cloud9を使用しない場合は、Python、SAMコマンドのインストールが必要です。Cloud9は必要なものが入っているので、私はこちらで開発を行っていきます。

1. Cloud9の環境作成
2. SAM initで構築を開始する
3. SARからコードを持ってくる
4. SAMコマンドでデプロイ

AWS CDK(Python)でコーディングしたAPIGateway×LambdaをSAMCLI Localで動作確認してからAWSにデプロイしてみた。

AWSは、`IaC`(Infrastructure as Code)で手軽にアプリケーションを構築するためのオープンソースのフレームワークを複数提供しています。
* `SAM`
* サーバーレスアプリケーション構築用のオープンソースフレームワーク
* `CloudFormation`より短い定義でいい感じに定義できる
* Lambda関数のバンドル処理やAWSへのアップロードもコマンドで手軽にできる
* ローカルでLambda関数＋αを起動させてデバッグができるツールも提供している
* `CDK`
* 特定のプログラミング言語でクラウドインフラストラクチャをコード化＋`CloudFormation`を通じてデプロイするためのオープンソースフレームワーク
* AWSにより最適化されたコンストラクト（通称：`L2 Layer`？）が提供されているため、複雑なコーディングなしでリソースを定義＋構築することができる（コーディングの負荷軽減）

昨今ではAWSリソースを`CDK`で管理していくのが主流になりつつありますが、`SAM`はサーバーレス