Lambda関連のことを調べてみた

Lambda関連のことを調べてみた

【メモ】Labmdaの作成済みレイヤー

https://github.com/keithrozario/Klayers?tab=readme-ov-file

一にも二にもここ。

pythonのrequestsライブラリーひとつ、自分のローカル環境でpip install -t . してzipを作って、、ってやるのは大変面倒です。上のgithubでは作成済みのレイヤーが公開されています。その中から選んで、Lambdaのレイヤー設定「ARN を指定」で入力することで、必要なライブラリがセットアップされます。
有名ライブラリしか載っていませんが、かなり重宝します。

元記事を表示

DynamoDBストリームって何?

# はじめに
DynamoDBのストリームについて学ぶ機会があったので、備忘録として記事を書きます。

# DynamoDBストリームとは
DynamoDBストリームとは、DynamoDBの機能の一つで、**テーブルのデータ変更(アイテムの作成、更新、削除)をリアルタイムにキャプチャし、それに基づく処理をトリガーするためのものです**。
DynamoDBストリームを有効にすると、テーブル内のアイテムに対する変更がストリームに記録されます。これにより、変更の内容を順次取得して、様々な用途に利用することができます。
「Stream」の「流れ」という意味の通り、**テーブル内のデータ変更(作成、更新、削除)の連続的な流れをキャプチャし、保存する機能**ということです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2613586/0645c6f1-66b3-381d-f771-6da345c11f69.png)

https://docs.aws.amazon.com/ja_jp/amazo

元記事を表示

ECS タスク定義ファミリーの古いリビジョンを削除

# issue
* タスク定義のリビジョンが溜まりすぎている

# 対策
* ライフサイクルがないようでまたもやLambda出動

# Lambda
“`python:lambda_handler Python3.12
import json
import time
import boto3

def list_all_task_definitions(ecs_client):
paginator = ecs_client.get_paginator(‘list_task_definitions’)
task_definitions = []

for page in paginator.paginate(status=’ACTIVE’):
task_definitions.extend(page[‘taskDefinitionArns’])

return task_definitions

def list_task_definition_revisions(ecs_client, task_definition_family)

元記事を表示

Google Cloud Run と AWS Lambda のコールドスタート時間を言語別に観察してみる

![plot_256.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/95370/1b04e167-0378-dfc1-dd0c-dbaea3b9d6ac.png)

コンテナを**リクエスト処理時間ベースの料金体系**で実行できるサーバレス環境としては、Google の Cloud Run([2019年11月GA](https://cloud.google.com/run/docs/release-notes#November_14_2019))と AWS Lambda([2020年12月にコンテナに対応](https://aws.amazon.com/jp/blogs/news/new-for-aws-lambda-container-image-support/))が特に有名でしょう。

これらの環境は、一度起動したコンテナインスタンスをしばらく生かしておき、その後のリクエストに使いまわします。しかし、生きているインスタンスが足りない場合は新たなコンテナの起動から始めるいわゆる「コールドスタート」と

元記事を表示

mockito.MockedStatic を使うときの書き分け 2つ

# はじめに

`mockedStatic` あんまり使ったことがなく、『エラーが何で起きてるか分からん!』と質問されたときに即答できなかったのが悔しかったので備忘。

# もくじ

– [mockito.MockedStatic の書き方2つ](#mockitomockedstatic-の書き方2つ)
– [サンプルコード](#サンプルコード)
– [メソッド参照を使う場合](#メソッド参照を使う場合)
– [ラムダ式を使う場合](#ラムダ式を使う場合)
– [使い分け](#使い分け)
– [参考](#参考)

# 実行環境

– Java8 以降
– JUnit5
– Mockito 4.11.0

“`gradle:build.gradle
dependencies {
testImplementation(‘org.mockito:mockito-core:4.11.0’)
testImplementation(‘org.mockito:mockito-inline:4.11.0’) // 3.4.0以降でないと使えない
}
“`

※ `mo

元記事を表示

AWS SAP対策#3 LambdaからAuroraへの接続をより効率よく行う

AWS SAP試験対策 #3

# 問題(ざっくり)
あるWebアプリケーションは、Lambda関数でAurora MySQLデータベースをクエリします。データベースは複数のリードレプリカで構成されています。アクセスが集中する期間では、アプリケーションのパフォーマンスが低下します。アプリケーションが多くのデータベース接続を行うために遅延が発生している模様です。パフォーマンスを向上させるにはどうすればいいですか?

① ゲートウェイロードバランサーを作成して、Auroraリードレプリカ間で接続を分散する。
② Auroraサーバーレスデータベースクラスターで自動スケーリングを使用する。
③ RDS Proxy接続プールをAuroraデータベースのクラスターエンドポイントに接続する。
④ データベース接続を開くためのLambda関数コードをイベントハンドラーの外に置く。

\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*

# 回答
**④ データベース接続を開くためのLambda関数コードをイベントハンドラーの外に置く

元記事を表示

S3 Object Lambdaを利用したOn-Demandイメージ変換サービスの紹介

こんにちは。ムシンサ・コミュニティ開発チームのバックエンドエンジニア、チョ・ユシンです。 今回はAWS S3 Object Lambdaを利用してオンデマンドイメージ変換サービスを構築した事例を共有したいと思います。

### イメージ変換サービスとは?
一般的にサーバーでイメージを提供するためには、オリジナルイメージよりも小さいサイズのイメージを提供する方がサーバーのリソースおよびトラフィックコストを節約できます。最近ではスマートフォンの発展により、スマートフォンのカメライメージのサイズが基本的に10MB前後で保存されるため、100枚のイメージを提供するだけで1Gbpsのネットワーク帯域を占有してしまいます。また、イメージサイズが大きい場合、クライアント側でもイメージをレンダリングするのに時間がかかり、ユーザーエクスペリエンスにも悪影響を与える可能性があります。

従来のイメージ変換および提供方法は、AWSチュートリアルにも記載されているように、S3の保存イベントを通じてリサイズされたイメージを保存し提供する方式です。変換されたイメージがオリジナルイメージと同様にストレージに保存され

元記事を表示

コンテナイメージからLambda関数をデプロイする

## はじめに
コンテナイメージからLambda関数のデプロイにトライ。
(コンテナイメージからのデプロイ自体は2020年のアップデート)

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/python-image.html

## コンテナイメージからLambdaをデプロイする
コンテナイメージからLambda関数をデプロイすることでデプロイ可能なMaxのサイズが10GBになる。当時のre:Inventの動画を見ても機械学習などパッケージが大きいケースでもLambdaを使いやすく、というのが念頭に置かれている印象。

2020年の記事

https://aws.amazon.com/jp/blogs/news/new-for-aws-lambda-container-image-support/

zipファイルアーカイブからLambda関数をデプロイする方法では、解凍後のzipファイルのサイズが250MBまでに制限される

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/g

元記事を表示

【AWS×Webアプリ】CloudFrontのキャッシュ削除(Terraform)

## 目的
・AWS上の静的Webサイトホスティングを有効にしたS3をCloudFrontで公開。
・S3のコンテンツを更新した際に、CloudFrontのキャッシュ削除を行うLambdaを実装。

## 前提条件
・Terraformを使用してAWS上にリソースを作成する。
・Pythonを使用してLambdaを実装する。
・作成する内容は以下と同様

https://qiita.com/Haruki-N/items/f9e8fb32fd20285b57ad

## TFファイル
“`aws_s3.tf(前回からの追加箇所のみ抜粋)
resource “aws_s3_bucket_notification” “WebBucket_notification” {
bucket = aws_s3_bucket.WebBucket.id

lambda_function {
lambda_function_arn = aws_lambda_function.DeleteCache.arn
events = [“s3:ObjectCreat

元記事を表示

ECSタスクをスケジュール管理してコスト削減する方法

サービスのデプロイ先をLambdaからECS on Fargateに変更するにあたり、本番環境以外にかかるコストをできるだけ削減しようと、いろいろ試みてきました。
– vCPUとメモリを最小構成(0.25 vCPU, 0.5 GB)にする
– Fargate Spotを使用する

ECS側の設定で工夫できるのはこれくらいだったのですが、1時間あたりのvCPUとメモリ単位でコストがかかる料金体系ということで、LambdaとEventBridgeで業務時間外だけECSタスクを停止するような仕組みをつくりました。

Lambda関数のコードやEventBridgeのTerraform設定などをそのまま記載するので、コピペしてコスト削減に活用していただければ幸いです。

https://aws.amazon.com/jp/fargate/pricing/

# Lambda関数
EventBridgeとの組み合わせでスケジュール実行できるため、ECSタスクの停止と起動処理の実行環境にはLambdaを選びました。

単一責任の原則(Single responsibility principle)

元記事を表示

CloudFormationでlambdaのソースコードを更新する方法

# 背景
CloudFormation(以降、cfnと記載)を使用して、lambdaソースコードの更新を行いたい時があると思います。
cfnでは、テンプレートファイルに変更があれば更新してくれますが、lambdaのソースコードをS3にアップロードしている場合、lambdaのS3BuketやS3Keyは変化しないので、テンプレートファイルには変更が起きず、結果的にcfnでの更新ができません。
“`
Resources:
layer:
Type: AWS::Lambda::LayerVersion
Properties:
Description: ‘pacakge deploy test layer’
LayerName: ‘PacakgeDeployTestLambdaLayer’
Content:
S3Bucket: Hoge
S3Key: Layer.zip // Layerの内容を更新してもここの値は一定

Lambda:
Type: AWS::Lambda::Fu

元記事を表示

[Lambda]Pythonライブラリをアップロードする

## まとめ

“`bash
mkdir hoge
cd hode
pip3 install ライブラリ名 -t .
“`

## 経緯

– Slackに記事のURLが投稿された時、その記事の要約をPerplexity APIを使用して投稿したい
– AWS Lambdaに置くか
– pythonのライブラリ必要やん!
– ほな入れよか

“`zsh
pip3 install requests /rss_summary

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try brew install
xyz, where xyz is the package you are trying to
install.

If you wish to install a Python library that isn’t in Homebr

元記事を表示

python-lambda-local を使って AWS Lambda 関数をローカル環境で実行する

# はじめに
Lambdaのプログラムをテストする際、毎回 Lambda 関数を更新して実行するのは面倒ではないですか?
そこで良い方法ないかなと調べていたところ、 **python-lambda-local** というツールを知りました。

https://github.com/HDE/python-lambda-local

# 仕様
Python 3.7+
今回試した環境のバージョンは 3.9.6 でした。
“`bash:バージョン
$ python3 –version
Python 3.9.6
“`

# インストール
pip でインストールすれば完了です。

“`bash:インストール
$ pip install python-lambda-local
“`

# オプション
使い方とオプションは以下になります。

“`bash:使い方
$ python-lambda-local [-h] [-l LIBRARY_PATH] [-f HANDLER_FUNCTION]
[-t TIMEOUT] [-a ARN_ST

元記事を表示

MacでLambdaレイヤーARMアーキを作成

# はじめに
 ***arm64でLambda関数をデプロイせざるを得ないケースで、Layerを追加したい場合向け。*** imageデプロイを使えばどうとでもなるのだが、それは根本解決にはならない。前に一度やったのだが、やり方を失念してしまったため、備忘として記録する。
Cloud9やEC2を使ってLayerを作成する方法もあるが、***AWSが提供するdocker imageを使えばローカル環境であらゆるLayerを作成できるし、インタラクティブにやりたい***ので、本記事ではその方法について記述する。

# 環境
– 言語: python3.12
– OS: macOS Sonoma14.5
– RAM: 64GB
– Docker: 25.0.3

# 手順
この[Docs](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/python-layers.html#python-layer-compatibility)で推奨されている通り、Amazon Linuxベースコンテナイメージに基づくDocker環境に依存関係をイン

元記事を表示

CDK×Lambda×golang×Dynamoでアプリを作ってみる DynamoDB処理のLambda実装編PUT&DELETE(第五回)

さて、今回は更新と削除のメソッドを作成していきたいと思います!
とは言っても構造体などはgetItemやputItemに似ているので非常に分かりやすかったです。

とりあえず全体像は以下の通りになります。
“`
package main

import (
“encoding/json”
“net/http”

“github.com/aws/aws-lambda-go/events”
“github.com/aws/aws-lambda-go/lambda”
“github.com/aws/aws-sdk-go/aws”
“github.com/aws/aws-sdk-go/aws/session”
“github.com/aws/aws-sdk-go/service/dynamodb”
“github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute”
)

var (
tableName = “MyDynamoDB”
dynamoDb = dynamodb.New(session.Must(sess

元記事を表示

【Python】Lambda Layerの作成方法

# Lambda Layerを作成したいがめんどくさい
Lambda LayerはAWS Lambdaに標準で用意されていないライブラリや自分で作成した関数などを取り込む際に利用します。
一見zipファイルを作成してアップロードするだけなんですが、いくつか落とし穴があります
– Amazon Linuxで作成する必要がある(場合がある)
– LambdaはAmazonLinuxで動いている
– macOSなどでインストールしたものがAmazonLinuxで動かない場合があるため
– 求められるディレクトリ構造が実はある
– apiでのzipアップロードはファイルサイズの制限がある

などなどで躓いたのでやり方をまとめておきます

## AmazonLinuxでのpython実行環境の用意
構築方法は別記事にまとめました。ローカル環境(macOSやWindows)でインストールしたライブラリをアップロードすると、動くときもありますが動かないときもあります。仮に動いたとしても、基本的にはAmazonLinuxで作成するほうが良いでしょう。
pythonはLambdaで使用す

元記事を表示

【Lambda】Parameter Storeの値を取得する処理を共通化する

## まとめ

処理をmjsファイルに記述してレイヤー登録する

例として、supabaseを使用するためのパラメータを登録・取得してみます
lambdaからsupabaseをいじいじする記事は[こちら](https://qiita.com/akitika/items/3ef5aeb279ac5e9fc97d)

## 1. ファイルの用意

“`bash
touch getParameters.mjs
“`

## 2. 処理をmjsファイルに記述

以下のように記述してみます

“`js:getParameters.mjs
import { SSMClient, GetParameterCommand } from “@aws-sdk/client-ssm”;

const client = new SSMClient({ region: “ap-northeast-1” });

export async function getParameter(name) {
const params = {
Name: name,
WithDecrypt

元記事を表示

【Lambda】Supabaseに接続する

## まとめ

zip化したnodejsをレイヤーとして使う

## 1. Node.jsランタイムを使用する

当初はpythonを使用するつもりだったのですが、pythonでsupabaseライブラリを使うのが結構面倒だったので、nodeを使用しました

## 2. レイヤーとして使用するnodejsを用意 -> デプロイ

“`bash
# nodejsディレクトリを作成
mkdir nodejs
cd nodejs

# supabaseライブラリをインストール
npm init
npm install supabase

# zip化
cd ../
zip -r hogehoge.zip nodejs
“`

:::note alert

注意1: 作成するディレクトリ名は必ず**nodejs**という名前にすること

注意2: ファイルではなく**nodejsディレクトリ自体をzip化する**こと

:::

zipファイル自体の名前はなんでもOKです
作成したzipをlambdaのレイヤーとしてデプロイしましょう

レイヤー登録のわかりやすい手順は[こちら](http

元記事を表示

【ALB・CloudWatch・Lambda】サーバーダウン等の異常をALBで検知した際にSlackに通知する

## 自己紹介
はじめまして、はる([@lemonade_37](https://twitter.com/lemonade_37))と申します。
駆け出しエンジニアとして働き始めて約3ヶ月が経過しました🐣

## 概要
サーバーダウンにいち早く気づき、異常の対処や再起動ができるために、
ALBの異常を検知した際に、Slackに通知を送る機能を実装します。
下記の構成でEC2にデプロイされており、ロードバランサー(ALB)で1分毎にHTTPリクエストを送信し、サーバーが起動しているか確認する機能はすでに導入されている前提とします。

今回のインフラ構成図のイメージです。
![Qiita記事用.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3471604/4ef7cf57-ad9b-7141-0c5a-298fee473b65.png)

### 環境
– Docker
– Ruby 3.2.3
– Rails 7.1.3
– PostgreSQL

:::note warn
間違っている箇

元記事を表示

GithubActionsでECRのImageをもとにLambdaをデプロイする方法

## 概要
– GithubActionsと ECRのイメージをもとにLambdaをデプロイするCICDを構築したため、記録として残しておく。
– 本記事を通して、下記が実現できるように記載していく
– ローカルでコード編集
– Commitして、GithubへPush
– GithubActionsが実行
– 編集後のコードをLambdaに自動デプロイする
– 最終的な構成として、キャプチャのよう流れとなる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3531653/416025ea-2643-0084-e630-25d3625f83bd.png)

## 前提
– Githubの操作(CommitやPushなど)経験があること
– AWSのアカウントがあること
– この記事内ではオレゴンリージョンを使用しているため、リージョンコードが `us-west-2`で進めています。なので、東京リージョンなどを使用する際は適宜書き換えてください
– C

元記事を表示

OTHERカテゴリの最新記事