- 1. AWS Lambda プロビジョニング済み同時実行を設定する
- 2. AWS API Gateway バージョンやエイリアスを指定して Lambda 関数を呼び出す
- 3. LINEbotに画像を送信すると、その画像をS3に保存
- 4. LambdaEdgeを利用したcognitoのトークン検証
- 5. React応用 – PartX – React > Netlify > Lambda > Python > MySQLどこまでいけるんだろう
- 6. AWS Lambdaで使いたい環境変数をAWS SAM CLIでどうするか
- 7. 爆速でモックAPIを構築する
- 8. AWS CLIのインストールからLambda作成までの流れ
- 9. CloudWatch LogsInsightsでLambdaの速度を計測してみよう
- 10. CloudFormationの更新なしでLambdaをデプロイする
- 11. AWS初学者がちょっとした分析基盤作ってみたのでメモ
- 12. LambdaでS3の.glbファイルのオフスクリーンレンダリング【Python,Docker,OSmesa】
- 13. ECRへのレプリケーションをトリガーにECSのサービス更新を実行
- 14. AWSリソースの削除漏れを日次通知するSAMテンプレートを作成した
- 15. AWS LambdaをRubyのコンテナで動かしてみる
- 16. API Geteway と Lambda の使い方
- 17. diesel-rs(mysql)をlambda上で動かすときにlibmysqlclientをスタティックリンクする
- 18. Python3: 加算をする API
- 19. [検証]性能観点でパラメータ情報はAWSサービスのどこに保存するのが良い？
- 20. S3へのレプリケーションをトリガーにCloud Frontのキャッシュ削除を実行
AWS Lambda プロビジョニング済み同時実行を設定する
# プロビジョニング済み同時実行とは
コールドスタートを防ぐ機能です。コールドスタートとは Lambda 関数の呼び出し時にインスタンスを初期化してから関数を実行することです。プロビジョニング済み同時実行数に 0 より大きな値を設定することで追加料金が発生します。# 設定手順
「新しいバージョンを発行」をクリックします。
「発行」をクリックします。
「設定タブ」$\to$「プロビジョニングされた同時実行」$\to$ 「編集」の順にクリックします。
「発行」をクリックします。
logger.setLevel(logging.INFO)
from linebot import (
LineBotApi, WebhookHandler
)
from linebot.models import (
MessageEvent, Te
LambdaEdgeを利用したcognitoのトークン検証
通常、認証確認処理はwebサーバーでやることが多いと思いますが、
グローバルサイトでかつ同時に多量のアクセスが考えられる場合、lambdaEdgeで認証チェックを実装すると
静的なサイト全体に認証がかけられ、かつWEBサーバーにアクセス負荷をかけずに認証確認処理を実装できます。今回は、cognitoから発行されたid_tokenをでコードして検証するコードをご紹介します。
#Lambda関数でのnpm moduleの利用法
今回、実装するにあたって– jsonwebtoken
– jwk-to-pemこれら２つのモジュールを利用しています。これらはnpmでinstallを行うのですが、Lambdaコンソール上ではもちろんnpmは実行できません。
このため、まずはlambdaのコンソールからアクション>関数のエクスポートでデプロイパッケージをDLしてください。
DLできたら解凍し、そこにpackage.jsonを追加するなどしてnpm installで上記の２つのモジュールをinstallしてください。開発についてもローカル環境でエディタを使って行う方が圧倒的に効率的だ
React応用 – PartX – React > Netlify > Lambda > Python > MySQLどこまでいけるんだろう
# タイトルの件
妄想してみました。
どこまで出来るか試してみたいと思います。# React ⇒ Netlify
いつものように`create-react-app`
“`
npx create-react-app プロジェクト名 –template typescript
“`いつものように`yarn start`でReact初期画面を`localhost:3000`で表示されることを確認します。
“`
cd プロジェクト名
yarn start
“`gitにコミット＆プッシュ
※git@github.comXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXは、後述のGitHubで新しいリポジトリ作成の際に表示されるものを入力します。“`
git init
git remote add origin git@github.comXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
git push -u origin master
“`Githubで新しいリポジトリを作成した際に表示されるURLみたいなやつ。
を参照ください。)
### 構成
構築する環境はAPI Gateway + Lambdaとなります。
今回は以下前提にて構築します。
– pythonインストール済み
– Lambdaに付与するロールは事前作成済み（ロールの自動生成は使わない）
– AWS CLIの設定済み### 構築
何はともあれ作っていきます。1. chalice インストール
“`
pip install chalice
“
AWS CLIのインストールからLambda作成までの流れ
# はじめに
GCP好きですが、わけあってAWSを使う必要がでてきました。
そんなAWS初心者のメモです。# AWS CLIインストール
macOSの手順は以下にまとめられています。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv2-mac.html色々書いていますがユーザーインターフェースを使用したインストールが楽そうだったので、最新バージョンのAWS CLIをダウンロードしてインストールしました。
## インストールの検証
以下のコマンドで確かめます。“`shell
$ which aws
/usr/local/bin/aws
$ aws –version
aws-cli/2.1.29 Python/3.7.4 Darwin/18.7.0 botocore/2.0.0
“`# AWS CLIのセットアップ
手順は以下にまとめられています。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configu
CloudWatch LogsInsightsでLambdaの速度を計測してみよう
隙あらばCloudWatch LogsInsightsで速度集計したりしています。（自己紹介）
本記事はCloudWatch LogsInsightsでやってみよう記事第2弾です。前回の記事はこちら。
https://qiita.com/zom/items/310b7995135b3edcc093
第2弾としてLambdaの速度計測をします。
## Lambdaのログの基本（デフォルトの設定の場合）と余談
私自身、Lambdaに出力されるログをいじったことがないので、そもそもデフォルト以外のログが存在するのか把握しておりません。
Lambda関数内でログを仕込んでおけば話は別ですが。CloudWatch Logs上には `/aws/lambda/$Lambda関数名` といったロググループで出力されます。
そしてログの中身としてはこのようになります。 `$` の部分は適宜置き換えて読んでください。“`
START RequestId: $request_id Version: $$version
END RequestId: $request_id
REPORT R
CloudFormationの更新なしでLambdaをデプロイする
特にCIでのテストをスムーズにするのに使いたいですね。
# Serverless Flamework
`serverless deploy function -f Lambda名`
https://dev.classmethod.jp/articles/serverless-deploy-aws-whats-going-on/`
https://www.serverless.com/framework/docs/providers/aws/cli-reference/deploy
# CDK
`cdk deploy –hotswap`
https://github.com/aws/aws-cdk/blob/master/packages/aws-cdk/README.mdほかは見つけたら随時更新
AWS初学者がちょっとした分析基盤作ってみたのでメモ
# はじめに
AWSをほとんど使ったことがなかった私がAWS上でちょっとしたものを作る際に、
`考えていたこと`や`調べたサイト`などをメモ書きとして残します。⚠︎自分用のため読みづらかったらすみません。。# 作りたいもの
定期的に特定のアプリのAppStoreレビューをスクレイピング => 整形 => データ格納 => 集計 => 可視化をAWS上でできるように構築したい# 作る前注意点
`AWS 高額請求`や`GCP 高額請求`で検索するとやらかした話が思った以上に出てくる。。– [10日間 で AWS Lambda 関数を 28億回 実行した話](https://blog.mmmcorp.co.jp/blog/2019/12/25/lambda-cloud-bankruptcy/)
– [BigQueryで150万円溶かした人の顔](https://qiita.com/itkr/items/745d54c781badc148bb9)
– [AWS 高額請求 |クラウド利用の注意点！高額請求事例と対策方法](https://www.3sss.co.jp/tis/medi
LambdaでS3の.glbファイルのオフスクリーンレンダリング【Python,Docker,OSmesa】
# はじめに
LambdaでPyrenderを使ってオフスクリーンレンダリングをしたいのですが、レイヤを作るだけではOpenGLが使えないので使えません。OpenGLの機能をGPUの無いLambdaで実行するためにOSmesaというライブラリを使ってCPUでレンダリングします。自分用メモです。
# 前提
– AWSアカウントを持っている
– Dockerの実行環境# やったこと
レイヤだけでは対応できないのでDockerイメージを作ってコンテナでデプロイします。Lambdaのベースイメージでは(自分がやった限りでは)うまくいかなかったので、Ubuntuのベースイメージを使います。フォルダ構成は以下の通りです。
“`
.
│ app.py
│ Dockerfile
│ env.txt
| entry.sh
└─ requirements.txt
“`Dockerfileは以下の通りです。
“`Dockerfile:Dockerfile
FROM ubuntu:18.04ARG FUNCTION_DIR=”/function”
RUN mkdir -p
ECRへのレプリケーションをトリガーにECSのサービス更新を実行
## 以下の記事を参照して頂ければと思います
https://note.com/shift_tech/n/n24e42bcce1f6**※Qiitaの記事は全て個人的な記載であり、所属する組織団体とは無関係です**
## 補足
ソースコード全体は以下です。https://github.com/yuta-katayama-23/ecs-update-service
AWSリソースの削除漏れを日次通知するSAMテンプレートを作成した
# 構成図
# 概要
Configでサポートされているリソースに限り、削除漏れのリソースを通知します。
リソースが作成されたらDynamoDBにアイテムが保存され、削除したらアイテムも削除されます。
指定された通知日時までに削除されなかったリソースのみ、Slackに通知される仕組みです。
通知間隔は1日で設定していますが、EventBridgeのスケジュールルールで起動しているので変更可能。# 事前準備
## SlackのWebhook URLの取得
こちらの記事が分かりやすかったです。
https://qiita.com/suo-takefumi/items/738793e2e426f52d7d42
## SlackのWebhook URLをSSM Parameter Storeに格納
コンソールからでいい
AWS LambdaをRubyのコンテナで動かしてみる
AWS Lambdaをコンテナで動かしてみました。言語は特に理由はないのですがRubyで試しました。
手順
1. ソースコード
2. Lambda作成
3. Lambda実行
4. ソースコード更新# ソースコード準備
ファイルは以下の3つを用意します。
`app.rb`
“`app.rb
module LambdaFunction
class Handler
def self.process(event:,context:)
p “Hello from Ruby 2.7 container image!”
p event
end
end
end
“``Dockerfile`
“`Dockerfile
FROM public.ecr.aws/lambda/ruby:2.7# Copy function code
COPY app.rb ${LAMBDA_TASK_ROOT}# Copy dependency management file
COPY Gemfile ${LAMBDA_TASK_ROOT}
API Geteway と Lambda の使い方
こちらのプログラムを改造してみました。
[Web ページから、AWS Lambda の関数に引数付きでアクセスする](https://qiita.com/ekzemplaro/items/62dd9c17255c6145fe63)
html と js のみを変更しました。実行例
“`html:index.html
<
diesel-rs(mysql)をlambda上で動かすときにlibmysqlclientをスタティックリンクする
# やりたかったこと
aws Lambda上でdiesel-rsというORMを使いmysqlにアクセスする# 前置き
これは以下の記事の一部分に書いてあったことをもうすこしだけ詳しく説明したものです。ちなみにかなり乱文かと思いますがほぼ自分用なのでご容赦ください。https://qiita.com/alivelime/items/19a5902c72720fd6e0a6
# 詰まったこと
僕はお試しで[このようなコード](https://github.com/s3pt3mb3r/diesel_on_lambda/blob/master/src/bin/read_user.rs)を書いたのですが、dieselはそもそもlibmysqlclient.soというダイナミックリンクライブラリに依存しており、これが無い環境では動きません。
またlambdaはシングルバイナリを実行するだけ(多分) + アップロードできるzipのサイズの上限があるので.soファイルを突っ込めません。そのため、libmysqlclient.soを**スタティックリンク**する必要がありました。
なので`
Python3: 加算をする API
AWS APIGateway と Lambda を使って加算をするプログラムを作成します。
Lambda のプログラム
“`py:sumup_function.py
# -*- coding: utf-8 -*-
#
# sumup_function.py
#
# Sep/25/2021
#
# ——————————————————————–
import sys
import json# ——————————————————————–
def lambda_handler(event, context):
sys.stderr.write(“*** lambda_handler *** start ***\n”)
print(“Received event: ” + json.dumps(event, indent=2))
print(“event[‘aa’] = ” + str(
[検証]性能観点でパラメータ情報はAWSサービスのどこに保存するのが良い？
こんにちは
某SIerでソリューションアーキテクトをしております、たくまです。
Lambdaなどの処理で実行するパラメータ等の情報はどこに格納していますか？
SSMパラメータストア？S3？DynamoDB？色々なサービスがあると思いますが、それぞれの性能観点。主にレイテンシーを考えた時に各サービスに違いはあるのか？という事が気になり検証してみました。
比較したサービスは、以下サービスです。
– AWS Systems Manager Parameter Store (以降SSMパラメータストア)
– AWS Systems Manager Parameter Store KMSを有効にした場合
– AWS Secrets Manager
– Amazon S3（以降S3）
– DynamoDBそれぞれのサービスでの性能に関わるマニュアルは以下辺りです。
####AWS Systems Manager Parameter Store
特に上限についての記載は見当たりませんでしたが、スループットの引き上げが可能な様です。
[Parameter Store のスループットを
S3へのレプリケーションをトリガーにCloud Frontのキャッシュ削除を実行
## 以下の記事を参照して頂ければと思います
https://note.com/shift_tech/n/n4834b01fe4dc
**※Qiitaの記事は全て個人的な記載であり、所属する組織団体とは無関係です**
## 補足
ソースコード全体は以下です。https://github.com/yuta-katayama-23/cloudfront-create-invalidation
