- 1. 別のLambdaを同時に呼び出して実行する方法【備忘録】
- 2. Docker+AWS Lambdaのローカルテスト環境を作成する
- 3. Presigned URLの発行と取得したURLを使用して画像ファイルをGET/PUTする。
- 4. LambdaPermissionとは何か
- 5. Cloud Watch Alarm + SNS + LambdaでECS・Fargateのリソース状態をSlack通知する（Terraform）
- 6. Lambda(Node.js)で別アカウントのECSサービス情報を取得する
- 7. Amplify Lambdaのトリガーでミスした件
- 8. Lambdaでデプロイしたのに反映されない？と思ったらエイリアスを確認
- 9. AWS Lambda(Python)から直接画像を出力する方法（覚書）
- 10. Amazon API Gateway + Lambda統合をJavaで実装するメモ
- 11. RDS Proxy を使って、AWS Lambda から接続してみた
- 12. AWS Compute Optimizerを利用したコスト・パフォーマンス最適化
- 13. Lambdaの実行環境について(コールドスタートとウォームスタート)
- 14. AWS Lambda Layersを使ったPythonライブラリーの追加
- 15. Nature Remo Cloud API + Lambdaで温度を記録して折れ線グラフを表示する自分ち専用のAndroidアプリを作った
- 16. AWS Step Functions Localでモックテストをする
- 17. sls deployでThe stack service name 〜〜 is not valid. と出た時の対処法
- 18. 【メモ】AWS LambdaでのPythonのレイヤー作成方法参考記事
- 19. AWS SAMでDocker + Lambdaで環境変数が渡せない
- 20. CFnでSNSアクセスポリシーを自動追加する【Lambda-backedカスタムリソース】
別のLambdaを同時に呼び出して実行する方法【備忘録】
## 背景
Lambdaを使って日付ごとにデータをスクレイピングすることがあった。
大量のデータであったが、繰り返し文で日付を変えながら行うプログラムとしていたため、非常に時間がかかった。そこで、①実行指示Lambdaと②スクレイピングLambdaに分けてプログラムを作成し、①にて変数を入れ替えながら②に指示するような構成にすることで、Lambdaの同時実行が可能になったので、備忘録として記載する。
参考記事については複数層に分けて大量のLambda実行を可能としているが、今回はわかりやすさ優先で、（親）と（子）の2層構造でLambdaを同時実行してみる。
## イメージ
## 親Lambda
“`Python:parent
import json
import ioclient = boto3.client(‘lambda
Docker+AWS Lambdaのローカルテスト環境を作成する
## 概要
Lambdaのローカルテスト環境をDockerで作成しました。本記事ではPythonで書いています。
公式ドキュメントを読んでも上手くいかなかったので、記事にします。https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images-create.html
## 用意するもの
– Dockerコマンドを実行できる環境
## 構築手順
### ディレトリ構成
“`
（プロジェクトルートディレクトリ）/
├── Dockerfile
├── requirements.txt (不要なら作成しなくて良い)
└── app.py
“`
### ファイル作成“`Dockerfile:Dockerfile
FROM public.ecr.aws/lambda/python:3.8COPY app.py ${LAMBDA_TASK_ROOT}
COPY requirements.txt .RUN pip3 install -r requirements.txt –target “${LAMBDA_TA
Presigned URLの発行と取得したURLを使用して画像ファイルをGET/PUTする。
## 目的
コンテンツをサーバー上にアップロード・ダウンロードして配信するというユースケースがある。コンテンツを保持しておくサービスとして、AWSにS3というサービスがあるのでそれを利用する。## 環境
– AWS Lambda Python 3.9## Lambdaコード
“`python
# — coding: utf-8 —
import boto3
from botocore.client import Config
import osREGION_NAME = os.environ[‘REGION_NAME’]
S3_BUCKET_NAME = os.environ[‘S3_BUCKET_NAME’]
DURATION_SECONDS = os.environ[‘DURATION_SECONDS’]
KEY_NAME = os.environ[‘KEY_NAME’]s3 = boto3.client(‘s3′, config=Config(signature_version=’s3v4’))
def lambda_handler(event, cont
LambdaPermissionとは何か
# はじめに
Former2でCloudformationテンプレートを作っていたらLambdaPermissionなるものが生成された。
“`yaml
LambdaPermission:
Type: “AWS::Lambda::Permission”
Properties:
Action: “lambda:InvokeFunction”
FunctionName: !GetAtt LambdaFunction.Arn
Principal: “apigateway.amazonaws.com”
SourceArn: “**************”
“`
身に覚えがないぞ。# 結論
* コンソールから手動で作成するときは自動で生成されるもの。
* Lambda関数にトリガーをセットする際、トリガーからのInvocateを許可するリソースベースポリシー。つまりこいつがないとトリガーが機能しない。## 公式を確認
_The AWS::Lambda::P
Cloud Watch Alarm + SNS + LambdaでECS・Fargateのリソース状態をSlack通知する（Terraform）
# 本要件の流れ
1. Cloud Watch Alarm発動
2. SNSへメッセージを送信
3. トリガーを検知しLambdaが起動
4. LambdaからSlackへ通知を送信# 前提
– ECSでなにかしらのアプリケーションを構築済み
# Webhookの取得
まずは実装の前にwebhookが必要なので、事前設定を行います。
[https://slack.com/apps](https://slack.com/apps) へアクセスし、
アプリを検索する > カスタムインテグレーション > Incoming Webhook
で設定の編集を行い、webhookを追加するslackのチャンネルを登録してください。
するとwebhookのurlが発行されるので、それを控えておきます。
「対象のチャンネルにWebhookを追加し、URLを取得する」ということができれば良いです。
色々と記事は出回っているのでググってもらえれば助かります。
# 実装
最初に取得したwebhookのurlは変数で渡せるようにしておきましょう。
develop/variables
Lambda(Node.js)で別アカウントのECSサービス情報を取得する
# はじめに
Node.jsを使ってスイッチロールして別アカウントのECS情報を取得する際に実装方法が分からなかったので、備忘として残しておきます。
Lambda＋Node.jsの情報少なすぎひん…？# 設定内容
## 権限設定
Lambdaを作成する前に以下の設定だけ先にやっておきます。
色々試しながらだったので、もしかしたら漏れがあるかもしれません。* アクセス元のIAMロールにAssumeRole権限追加
* アクセス先のIAMロールにECSへのアクセス権限追加(ECSFullAccess)
* アクセス先のIAMロールの信頼関係にアクセス元のIAMロールを追加## Lambda実装
初めてNode.js書くので不要な実装とか含まれているかもしれませんが、実際に実装したプログラムは以下です。
普段Pythonしか書かないのでcallbackとか全然頭に入ってこなかった。。“`
const AWS = require(‘aws-sdk’);
const sts = new AWS.STS({apiVersion:’2011-06-15′,region:’ap-
Amplify Lambdaのトリガーでミスした件
# Amplify Lambdaのトリガーでミスした件
## はじめに
Amplify CLIでS3にLambdaトリガーを設定した際に、トリガーが永続的に発火しLambdaの請求額が上がってしまったので再発防止+覚えておくように書きます。## 概要
AWS Amplifyで開発をしています。以下に簡単な概要を記述します。
クライアントは、ある特定のファイルをAmplifyで作ったStorage(S3)にプットします。それと同時にAPIでDynamoDBにレコードを挿入します。この際にS3にプットされたファイルオブジェクトが正しいデータが否かを確認するためにLambdaトリガーをAmplifyで設定します。
このLambdaはDynamoDBにそのファイルのデータがあるかを確認し、あればそのままファイルをS3に保存し、ない場合はそのS3オブジェクトを削除するというものです。
## ループまで
Amplify cli で storageにトリガーを設定し、プッシュしました。“`
$ amplify update storageSelect from one of
Lambdaでデプロイしたのに反映されない？と思ったらエイリアスを確認
# Lambdaのデプロイが反映されない
最近ジョインしたプロダクトの開発環境にて、修正したLambda関数をサクッと確認してみようとしたところ「あれ？ デプロイしたのに反映されていない……？」となったので以下対応メモします。## 事象
既にCloudformationその他で構築され問題なく動作しているAWS環境にて、Lambdaのソース(Python3.7)を修正して動かしてみたところ、明らかにソースが反映されていない(修正前のコードで動いている)という事象が発生。デプロイのやり方としてはとてもシンプルで、Lambdaのチュートリアルとかでもよくある「コンソール画面でソースを修正して、『Deploy』クリック」するという方法。
↓画像の「Deploy」をクリック
その後別のデプロイ方法(zipフ
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のハンドラ関数の実行というものが提供されており、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カスタム
