- 1. Slack連携による生産性向上の施策（その２）〜Slack App編〜
- 2. Lambdaで定時刻に呟くDiscord Botを作る
- 3. #AWS S3にアップロードされたZIPファイル自動解凍
- 4. Lambdaで実装するIotトピックのSubscriberとPublisher
- 5. LambdaからEventBridge Schedulerを作成してみた
- 6. LambdaでGoのHelloWorldをやってみた
- 7. AWS Lambda関数作成入門してみます。
- 8. AWSとGoogle Cloudで、とりあえず簡単にRAGを構築してみたい！（API呼び出しもあるよ）
- 9. 難しいことはわからんが、とりあえずRAGを構築してみたい！（AWS編）
- 10. CloudFrontがLambda Functions URLへのOACに対応！ の何がすごいか
- 11. AWS Lambda Function URLs（関数URL）がCloudfrontのOACに対応したので試す
- 12. #AWS アラーム通知実装パターンについて
- 13. #AWS EC2、Fargate、RDS指定時間帯稼働用Lambda
- 14. サーバごとかつ日ごとに不定の時刻でEC2インスタンスを自動起動停止するLambda関数
- 15. LINEメッセージをAWS Lambdaで送受信してみたお話
- 16. Slack連携による生産性向上の施策（その１）〜Workflow Builder編〜
- 17. AWS Lambda LayersでError importing numpy: you should not try to import numpy from its source directory
- 18. GitHub Actions + SQS + Lambda で main ブランチへ merge してから15分後に cloudfront キャッシュを削除する
- 19. Slack API の url_verification に Lambda + Python で応える
- 20. API GatewayでLambdaと接続したREST APIを作成する(Bedrockの呼び出し結果の取得)
Slack連携による生産性向上の施策（その２）〜Slack App編〜
# はじめに
こちらの記事は三部構成になっております。
– [Slack連携による生産性向上の施策（その１）〜Workflow Builder編〜](https://qiita.com/oc-arimura/items/ff4c194c617a9d309d9c)
– Slack連携による生産性向上の施策（その２）〜Slack App編〜
– Slack連携による生産性向上の施策（その３）〜AWS Lambda編〜また、全ての記事の内容を含んだ動画も用意しております。
動画で確認したい方は[コチラ](https://www.youtube.com/watch?v=JE7ZVJ9yE9Q)まで。
※動画開始50分頃からの内容になります。# Slack App登録の前に
Slack Appから呼び出されるAPIの準備をします。
## Lambda関数作成
1. AWSのコンソール画面でサービス名に `lambda` と入力し、サービス一覧から【Lambda】をクリック
↑こちらの画面のToken発行ボタンから取得するものです。
※Botのアイコン画像は[ぷしおメーカー](https://vps1-net000.sfc.keio.ac.jp/pushiomaker/)様で作成しました。# 1. 関数の作成
1. Lambdaコンソールを開く
1. 「
#AWS S3にアップロードされたZIPファイル自動解凍
# S3にアップロードされたZIPファイル自動解凍について：
Cloudfrontに繋いでいるS3へのファイルアップロードを簡素化するため、Zipファイル格納用S3に新しいZipファイルのアップロードが検知されたら、対象Lambdaが有効化され、Zipファイル格納用S3からZipファイルをダウンロードして解凍し、Cloudfront用S3にアップロードします。本記事はそれを実現するlambdaを紹介いたします。
# 処理フロー:
1. Zip格納用S3にZipファイルのアップロードが検知された
↓
2. 自動解凍＆アップロードLambdaを呼び出す
↓
3. (Lambda) Zip格納用S3から対象Zipファイルをダウンロードする
↓
4. (Lambda) 対象Zipファイルを解凍する
↓
5. (Lambda) 解凍した資材一式をCloudfront用S3にアップロードする
↓
終了# Lambda作成：
以下の手順を踏んで作成します1. AWSコンソール画面の上部にある検索欄から「Lambda」を入力し、検索する
2. Lambda詳細画面の左メニューの「関数」を
Lambdaで実装するIotトピックのSubscriberとPublisher
# はじめに
最近、過去に業務で設計・実装したAWS IotトピックのSubscriberとPublisherのインフラコードを整理してみました。これを機に、アーキテクチャや実装した内容について記事で紹介しようと思います。ソースコードは下記repoをご参照ください。
※今回紹介する内容は汎用的なものであり、実際業務で実装したアーキテクチャやアプリのロジックの記載はありません。https://github.com/to-fmak/iot-topic-subscriber-publisher-demo
# やりたいこと
– Iotデバイス等からIotトピックに送られたメッセージをsubscribeし、DynamoDBに書き込みたい
– 特定のDynamoDBにアイテムが作成or更新or削除された際に、そのイベントの詳細をIotトピックにpublishし、Iotデバイス等で受信したい# アーキテクチャ
## Subscriber
を元に整理します> Amazon EventBridge スケジューラはサーバーレススケジューラで、一元化されたマネージドサービスからタスクを作成、実行、管理できます。EventBridge スケジューラは拡張性が高く、270 を超える AWS サービスと 6,000 を超える API オペレーションを呼び出すことができる何百万ものタスクをスケジュールできます。EventBridge スケジューラでは、インフラストラクチャをプロビジョニングして管理したり、複数のサービスと統合したりすることなく、スケジュールを大規模に配信してメンテナンスコストを削減できます。
– マネージド
LambdaでGoのHelloWorldをやってみた
GoはシングルバイナリでLambdaと相性が良いらしい・・・といったレベルの初心者なので、まずは公式のドキュメントのとおりにやってみる。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/golang-handler.html
“`go mod init main“`して、“`go.mod“`を作成し、“`main.go“`に例示されたコードを張り付ける
“`go
package mainimport (
“context”
“fmt”
“github.com/aws/aws-lambda-go/lambda”
)type MyEvent struct {
Name string `json:”name”`
}func HandleRequest(ctx context.Context, event *MyEvent) (*string, error) {
if event == nil {
return nil, fmt.Errorf(“received nil event”)
}
AWS Lambda関数作成入門してみます。
# FaaS(Function as a Service)：Lambdaとは
Lambda（ラムダ）とは、AWSのサービスの1つです。
小さな計算をサーバーなしで実行するためのサービスで、サーバレスなコンピューティングサービスなどと言う紹介のされ方が一般的です。関数の種類としては所謂イベントドリブン型と言われるやつで、特定のイベントでトリガーされ、関数が動くという仕組みです。ざっくり過ぎてすみません。## Lamdaの料金体系
無料枠について。
アカウント作成時はLambdaの場合「1,000,000リクエスト/月」無料で使用可能です。個人開発の範囲であれば越えることはまずないと思います。## 関数の作成
へ対応する技術です。最近話題になっているので、いちど試してみたい！と思っている方も多いのではないでしょうか？
しかし、試してみたいと思っても使うモデルや技術・サービス・手法等々いろいろな情報が溢れていて結局何をどう使えばいいのかわからん…ということになりがちです。この記事では、「難しいことはわからんが、とりあえずRAGというものを構築してみたい」という方向けに、AWSおよびGoogle Cloud上に少なめの準備でRAGを作って試す手順を紹介します。
とりあえず作ってみて、難しいことは後で考えればいいじゃない！という精神でRAG＋API呼び出しの構築を進めてみて、実際に動作させた感触やかかった利用料などを紹介できればと思います。なお、この記事を書いている私自身、RAGの手法や精度向上にまったく詳しくないけどとりあえず構築してみた人間のひとりです。
#
難しいことはわからんが、とりあえずRAGを構築してみたい！（AWS編）
## この記事について
この記事は、[AWSとGoogleCloudで、とりあえず簡単にRAGを構築してみたい！（API呼び出しもあるよ）](https://qiita.com/ckw-1227/items/d8f89757349b90e35fa7)のAWS編として、AWSでの構築手順をまとめたものになります。
GoogleCloud編や、AWSとGoogleCloudの比較を見たい方は親記事からどうぞ。## 0. 使用するサービス
AWSではAmazon Bedrockのナレッジベースを使用します。（先日まではメニューが英語で「KnowledgeBase」と書かれていた気がするんですが、いつの間にかコンソールが変わってカタカナ表記になっていたので、この記事でもカタカナ表記にします）ナレッジベースで外部から与える情報源と使いたいデータベースサービスを指定すると、RAGを構築できるようになっています。
## 1. S3にテキストファイルを配置する
Bedrockに触れる前に、まずは外部情報となるテキストファイルをS3に配置します。テキストファイルの作成については親記事で触れてお
CloudFrontがLambda Functions URLへのOACに対応！ の何がすごいか
# はじめに
CloudFrontのOrigin Access Control（OAC）がLambda Functions URLに対応しました。
つまり、Functions URLとCloudFrontのインテグレーションが実現できるようになりました！うおおおお！https://aws.amazon.com/jp/about-aws/whats-new/2024/04/amazon-cloudfront-oac-lambda-function-url-origins/
と、このアプデの何がすごいの？ という点がいまいち伝わってない人向けに、この記事ではもろもろの経緯とユースケースを紹介します。
## 経緯
### Functions URLs、その課題
2022/4にLambdaの組み込みエンドポイントとしてLambda Functions URLが利用できるようになりました。
https://aws.amazon.com/jp/blogs/news/announcing-aws-lambda-function-urls-built-in-https-endpoint
AWS Lambda Function URLs（関数URL）がCloudfrontのOACに対応したので試す
# はじめに
AWS LambdaのFunction URLs（関数URL）は、Lambda単体でHTTPSのURLを発行し、HTTPリクエストをトリガーにLambdaを実行出来るようになる、非常に便利な機能です。
API Gatewayと統合せずともLambdaのみでWebAPIを構築出来るようになり、プロトタイピングやマイクロサービスに有用です。## 関数URLの制限
ところで、関数URLの実行の認可は、IAMを用いた方法しかありませんでした（IAMロールベースの認可か、認可なししか無かった）。
Cloudfrontをリバースプロキシ的に前段に配置し、関数URLと繋ぐことで、ドメインを当てたりキャッシュを活用したり、便利な訳ですが、その際に上記が問題となります。というのは、CloudfrontからIAMベースのリクエストを行うには、Lambda@Edgeを利用するしかありませんでした（オリジンリクエストをIAMロールを付与したLambda@Edgeに任せる）。全てのリクエストでLambda@Edgeが実行されるとコストがかかりますし、せっかく関数URLはシンプルなのに、無
#AWS アラーム通知実装パターンについて
# AWSアラーム実装パターンについて：
AWS環境内に各種リソースを監視するためにアラームを実装する必要があります。監視リソース種類に応じてアラームの実装パターンもいくつか存在していて、リソース種類は大きく以下のように分類できるかと思います。
A. メトリクス系（CPU使用率、メモリ使用率、コンテナ台数など）
B. ログ系（エラーログ、ヘルスチェックログなど）下図のように実際AWSコンソールも非常にわかりやすく、それぞれのグループに分けられています。
メトリクス系は基本CPUやメモリなど使用率が想定値より超えたことを通知するだけなので、煩雑な設定をしないでCloudWatch Alarmをそのまま使用したほうが便利です。
ログ系は
#AWS EC2、Fargate、RDS指定時間帯稼働用Lambda
# EC2、Fargate、RDS指定時間帯稼働について：
下記コスト削減、セキュリティ保護などの理由で、AWS環境に稼働しているEC2、Fargate、およびRDSなどのリソースを特定の時間帯のみ稼働させる必要があります。
- ・ コスト削減：
- 特定の時間帯にのみリソースを利用することで、クラウドサービスのコストを削減できます。例えば、夜間や週末には利用者が少ない場合、サーバーの稼働を停止したり、リソースをダウンスケールすることで、不要なコストを抑えることができます。
- ・ セキュリティ保護：
- 特定の時間帯にのみシステムを稼働させることで、潜在的なセキュリティリスクを最小限に抑えることができます。また、リソースの不正利用を防ぐために、特定の時間帯にのみアクセスを許可することもあります。
- ・ リソース最適化：
- 特定の時間帯に高い負荷が予想される場合、それに応じてリソースをスケールアップすることができます。たとえば、特定の時間帯にWebサイトへのアクセスが急増す
サーバごとかつ日ごとに不定の時刻でEC2インスタンスを自動起動停止するLambda関数
# 作成経緯
まず筆者が下記のLambda関数を作成するに至った経緯を記す。対象となっているサーバはベンダーが作業時に使う踏み台サーバである。
踏み台用のAWSアカウントを切り出し、SSMセッションマネージャーのポートフォワードで
ベンダーには踏み台サーバへアクセスしてもらっている。この踏み台サーバの稼働時間は、ベンダーの作業によって変わるため一定ではない。
そのため、EventBridgeでサーバごとにルールを作成し、都度実行時間を更新するのは
手間がかかりすぎるため、EC2インスタンスの起動停止時間を可変にする仕組みを考えた。
折角作ったので備忘としてここに残す。（正直EC2インスタンスに起動用タグ・停止用タグを付与し、
タグを対象に月〜金の9時〜18時といった固定時間でEventBridgeルールを作成。
ベンダーにはこの運用ルールを伝え、人間をルールに合わせて作業させればいいと思う。
これができるなら本記事を読む必要はない）# 概要
EC2インスタンスの起動停止を行うLambda関数を作成し、
この関数をEventBridgeで毎日毎時実行する。
対象とな
LINEメッセージをAWS Lambdaで送受信してみたお話
## はじめに
業務にてLINE MessagingAPIを利用したLINEでのコミュニケーションツールを作成したので、技術共有と自分の備忘録もかねて書いていきます。
流れとしては、[公式LINEアカウントへのログイン処理をAWS Lambda経由で実装してみた](https://qiita.com/inacyc_k/items/8337489e3e148db1f9e5)の続きの実装になります。あわせてぜひ読んでいただければと思います。## LINE MessagingAPI ってなに
みなさん、LINEの公式アカウント利用していますか？（私はよく佐川急便とかUNIQLOの公式アカウントをよく利用しています）LINEの公式アカウントをユーザーに友だち登録いただくことでメッセージが届いたり、チャット上で会話形式の質問に回答したりとWebサイトやメルマガよりも気軽に情報発信することができます。このようにMessagingAPIは、
・さまざまなメッセージをユーザーへ送信
・ユーザーが送ったメッセージを受信
そして
・ユーザープロフィールの取得（アイコン画像やユーザー名）
・アカウ
Slack連携による生産性向上の施策（その１）〜Workflow Builder編〜
# はじめに
こちらの記事は三部構成になっております。
– Slack連携による生産性向上の施策（その１）〜Workflow Builder編〜
– Slack連携による生産性向上の施策（その２）〜Slack App編〜
– Slack連携による生産性向上の施策（その３）〜AWS Lambda編〜また、全ての記事の内容を含んだ動画も用意しております。
動画で確認したい方は[コチラ](https://www.youtube.com/watch?v=JE7ZVJ9yE9Q)まで。
※動画開始50分頃からの内容になります。# 事の経緯
:
“`Keith’s Layers (Klayers) のnumpyをレイヤーに追加して解決する。
## numpyのARNを確認
### Klayersへ遷移
https://github.com/k
GitHub Actions + SQS + Lambda で main ブランチへ merge してから15分後に cloudfront キャッシュを削除する
# 処理の概要
1. GiHub Actions から、AWS SQS にメッセージを送信
2. SQS がメッセージ受け取ったら、15分後に Lambda を呼び出す
3. Lambda が aws create-invalidation コマンドを利用し、CloudFront キャッシュ削除を行う# 何故そんな回りくどい事をするのか？
普通に GitHub Actions から create-invalidation を利用していましたが、AWS ECS を利用しているため古いタスクが終了し新しいタスクに切り替わる前に再度ユーザーがアクセスし、古いタスクのキャッシュが生成されるという状態になっていました
main ブランチへの merge から10分程度で ECS のタスクが切り替わっているので、余裕を持って15分後くらいにはキャッシュを削除させたかった
# 全体図
:
# Slack API からのリクエストボディを取得
body = json.loads(event[‘body’])# URL Verification Challenge か？
if “challenge” in body:
# challenge の値を取得
challenge = body[‘challenge’]# レスポンスを作成
response = {
“statusCode”: 200,
“body”: json.dumps({“challenge”: challenge})
}# レスポンスを返す
return response# レ
API GatewayでLambdaと接続したREST APIを作成する(Bedrockの呼び出し結果の取得)
[Supership](https://supership.jp/)の名畑です。2024春アニメ開幕の季節がやってきましたが、[うる星やつらの最終クールのPV](https://www.youtube.com/watch?v=4hMO9mkM7Ac)ですでに涙腺が。
## はじめに
以下2つの過去記事では[Lambda](https://qiita.com/nabata/items/36a642597a92f0ece9d8)を経由して[Bedrock](https://aws.amazon.com/jp/bedrock/)の**Claude 3**を叩きました。
– [LambdaでBedrockのClaude 3を呼び出してみた](https://qiita.com/nabata/items/5bcc3beb76182f626040)
– [BedrockのナレッジベースでRAGを実装し、資料を元にした回答をClaude 3にLambda経由でしてもらった(ベクトルストアはAurora)](https://qiita.com/nabata/items/36a642597a92f
