Lambda関連のことを調べてみた2020年06月08日

Node.js: Lambda で MariaDB のデータを削除 (Delete)

フォルダー構造 “`text $ tree -a . ├── .env ├── function_update.sh ├── index.js └── test_local.js “` “`js:maria_delete/index.js // ————————————————————— // maria_delete/index.js // // Jun/07/2020 // // ————————————————————— var mysql = require(‘mysql2/promise’) // ————————————————————— async function main(id_in) { console.error(“id_in = ” + id_in) const host = `${proc

Node.js: Lambda で MariaDB のデータを更新 (Update)

フォルダー構造 “`text $ tree -a . ├── .env ├── function_update.sh ├── index.js └── test_local.js “` “`js:maria_update/index.js #! /usr/bin/node // ————————————————————— // maria_update/index.js // // Jun/07/2020 // // ————————————————————— var mysql = require(‘mysql2/promise’) // ————————————————————— function get_current_date_proc () { const today = new Date () var

Node.js: Lambda で MariaDB のデータを読む (Read)

フォルダー構造 “`text $ tree -a . ├── .env ├── function_update.sh ├── index.js └── test_local.js “` “`js:maria_read/index.js // ————————————————————— // maria_read/index.js // // Jun/08/2020 // // ————————————————————— ‘use strict’ // ————————————————————— async function read01 (mysql,host,user,password,data_base) { try { console.error (“*** read01 *** start ***”)

Node.js: Lambda で MariaDB のデータを作成 (Create)

フォルダー構造 “`text $ tree -a . ├── .env ├── function_update.sh ├── index.js └── test_local.js “` “`js:maria_create/index.js // ————————————————————— // maria_create/index.js // // Jun/07/2020 // // ————————————————————— var mysql = require(‘mysql2/promise’) // ————————————————————— function dict_append_proc (dict_aa,id_in,name_in,population_in,date_mod_in) { var uni

AWS LambdaとDynamoDB, CloudWatchを使用してQiitaでストックした記事をSlackに定期通知する

## 概要 – AWSサービスを触って学びたい – 毎週土曜日にメールで通知されるQiitaの「今週ストックした記事」をSlackに通知したい ## 使用するもの |サービス|用途| |—|—| |**[AWS Lambda](https://aws.amazon.com/jp/lambda/)**|Qiita APIからストックした記事を取得してSlackに通知する用| |**[Amazon DynamoDB](https://aws.amazon.com/jp/dynamodb/)**|Qiita APIから取得した記事には「いつストックしたか」の情報がないため通知情報が重複してしまう。これを防ぐために前回通知した情報を保持しておく| |**[Amazon CloudWatch](https://aws.amazon.com/jp/cloudwatch/)**|Lambdaの定期実行用| |**[AWS SAM（サーバレスアプリケーションモデル）](https://aws.amazon.com/jp/serverless/sam/)**|ローカルで構築したアプリケーショ

Vue.js＋APIGateway＋LambdaでCORSに詰まったからまとめる

#はじめに 業務でブラウザからサーバーにPOSTリクエストを投げ、 処理した結果をブラウザ上に表示するなどの処理を実装 しようとした時にCORSというものに長い時間 悩まされたので自分のためにもまとめておこうと思います。 自分なりの解釈なので間違っていたら指摘をお願いします。 またこうしたら分かりやすいよ〜などの意見もありましたら コメントしていただけると嬉しいです。 と言いつつQiita初投稿なのでお手柔らかにお願いします。 #CORSとは CORSとはCross Origin Resource Sharingの略で、 XMLhttpRequestによって、 異なるオリジンからのリソース取得に制限をかけることにより、 リソースを提供するサーバーのセキュリティを向上するものです。 この説明だけでもわからないことが結構出てきますよね。。。 そこでCORSを知る上で必要なキーワードをまとめました。 #XMLhttpReuestとは？ Javascriptによりサーバーからデータを取得することで、 ページ全体を更新しなくても、ページの部分を更新できるもの。 Ajaxプログラミングにより

Slack API×AWS Lambda×Node.jsで作るチャットボット開発

# Slack API×AWS Lambda×Node.jsで作るチャットボット開発 Slack APIをLambdaと組み合わせると、様々なことができます。 「スマホからも操作できるSlackで、Lambda関数を実行できる」というだけで、その応用範囲は多岐にわたります。 今回、SlackとLambdaを使ってチャットボットのサンプルを作る機会があったため、そこで得た知識をまとめ、手順化してみました。 この内容を理解することで、以下のようなことができます。 – Slackのワークスペースにボットを配置する。 – ボットにDMを送ると、AWSのLambda関数を実行するように設定する。 – Lambda関数の処理で、Slackのワークスペースにメッセージを投稿する。 細かく手順を作ったので、初心者も手を付けやすいと思います。 ぜひここで基礎部分を学んでから、自分のやりたいことに応じて調べてみてください。 第9節までありますが、基礎の部分は4節までですし、アカウント作成などが無ければ1章あたり20分くらいでできると思います。 # 目次 – [概要](#概要) – [シス

Node.js の Lambda 関数を ローカルでテストする （その２）

AWS のコンソールから、ダウンロードして解凍した index.js を実行する方法です。  フォルダー構造 “`text $ tree example01/ example01/ ├── index.js └── test_local.js “` “`js:index.js exports.handler = async (event) => { // TODO implement console.error(“***** start example01 PM 18:49 ***”) var rvalue = {} rvalue[‘key1’] = parseInt(event[‘key1’],10) rvalue[‘key2’] = parseInt(event[‘k

Lambda 関数から Lambda 関数を呼び出す (Node.js)

次のページを参考にしました。 [AWS lambdaでハマったこと (lambdaからlambdaを呼び出す)](https://took.jp/post-1037/) メインプログラム “`js:callSample/index.js const AWS = require(‘aws-sdk’); const lambda = new AWS.Lambda(); exports.handler = function(event, context) { console.error(“*** start callSample PM 18:57 ***”) const event_aa = { “key1”: 118, “key2”: 216, “key3”: 314 } const payload = JSON.stringify(event_aa) const params = { FunctionName: ‘example01’, InvocationType: ‘RequestResponse’,

AWS SAMを今さらながら使ってみる

CloudFormationはそれなりに書けるし、Lambda関数も書いたり動かしたり調査したり色々やってきたが、本職のデベロッパーでない悲しさか、AWS SAMは実は一度も触ったことがない（触る必要に迫られたことがない）。 苦手なままでは先々苦労しそうなので、このあたりで一度ウォークスルーしてみることにする。 ### やりたいこと – AWS SAMをインストールする。 – 試し打ちしながら、できることを自分なりに整理してみる。 ### インストール まずはインストール。 詳しくは[公式](https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/serverless-sam-cli-install-mac.html)を参照。 ローカル開発したい場合はDockerも必要らしい。 Dockerはもう入れてあるので、やることは以下。 “` % brew tap aws/tap % brew install aws-sam-cli “` 入った。 “` % sam

Serverless FrameworkでBasic認証を実装する

# はじめに Serverless Frameworkを使用していく中で、検証環境には 簡易な認証（例えば基本認証など）を設けたい場合がありました。 Lambdaを用いるため、Apacheなどのミドルウェアレイヤーで基本認証が設定できないとすればどこで設定するのが良いか検討した。 今回はlambdaでFlaskのようなPythonフレームワーク(WSGIベース)を動かす場合を考える。 # Basic認証の実装方式について Lambdaを使用する場合、「API Gateway+Lambda」構成にするか、「ALB+Lambda」構成のいずれかが考えられる。 それぞれどこで認証を設定できるか、どこが良いのかという結論として以下のようになると考えた。  ###ALBを経由する場合について（評価△） 現在はWSGIベースのフレームワークはALB経

Node.js の Lambda 関数を ローカルでテストする

Node.js の AWS Lambda 関数をローカルでテストする方法です。 テストで使う　Lambda 関数 “`js:iot_aa.js // ————————————————————— // iot_aa.js // // Dec/08/2017 // // ————————————————————— ‘use strict’ // ————————————————————— console.log(‘Loading function’) exports.iot_aa_handler = (event, context, callback) => { //console.log(‘Received event:’, JSON.stringify(event, null, 2)) console.log

API Gateway with CloudFormation

AWS CloudFormationを用いて、API GatewayからLambdaを同期・非同期で呼び出します。 CloudFormationテンプレートと、Lambdaソースは以下のような構成にしました。構成を変える場合、LambdaのCodeUriでディレクトリを、Handlerでファイル名を変更できます。 “`shell | |–apigateway.yml |–Makefile #なくても構わないです。コマンドを毎回打つのが面倒なので作っただけです。 |–Lambda |–test test.py “` “`makefile:Makefile .PHONY: deploy deploy: $(call blue , “Lambda package & deploy”) @aws cloudformation package –template-file apigateway.yml –s3-bucket ご自身のS3バケット名 –output-template-file packaged-templat

Amazon SESの通知結果をAmazon SNS、Lambdaを使用してDynamoDBに保存する

AmazonSESの送信結果を取得するために、今回はAmazonSNSをトリガーとして、LambdaからDyanamoDBに保存する仕組みを作っていきたいと思います。

この方法はAWSのサポートでもありましたので、今回はそれを試してみます。

https://aws.amazon.com/jp/premiumsupport/knowledge-center/lambda-sns-ses-dynamodb/

前提として、AmazonSE

AWS Lambdaの利点、欠点

#Lambdaとは ユーザーはコードだけ書いてくれれば、サーバー管理はAWS側でしますよってサービス。データの変更に応じてコードを実行したり、HTTPリクエストに応答してコードを実行したりしてくれる。 #Lambdaの利点 ####サーバー管理が不要 Lambdaとはでも書いた通り、サーバー管理をAWS側でしてくれる。 ####継続的スケーリング 自動的にアプリケーションをスケーリングしてくれる。 重たい処理には多くのリソースを割り当てて、軽い処理には少しだけリソースを与える。 ####ミリ秒単位の課金 コードが実行される100 ms(= 0.1秒)ごとに課金される。 コードが実行されてない時は課金されないから料金は安く済む。 ####安定したパフォーマンス それぞれの処理に適切なメモリサイズを割り当てるからコード実行時間を最適化できる。 2桁のミリ秒以内に応答するようにハイパー対応することも可能。 #Lambdaの欠点 ####サーバー管理ができない メリットでもあったけど、自分で管理したい時はそのままデメリットになる。 #最後に AWSについて学習中のメモ代わりに残して

Cloud9にLambdaで動くFlaskアプリを構築する

# はじめに 運用レスのインフラ基盤でアプリ動かしたいと考え、 Flask（pythonのフレームワーク）を使った簡単なアプリをLambdaで動かしてみた。 ※ すでにpython3.6がインストールされている前提（Cloud9は初期から入っている） ※ すでにNode.jsがインストールされており、npmコマンドが打てる前提（Cloud9は初期から入っている） # 所要時間 本手順は30分ほどで完了する想定です。（60分あれば十分なハズ） # モジュールのインストール ここではCloud9でserverless frameworkを用いてLambdaにFlaskをデプロイする方法を載せます。 – npmがインストールされていることを確認 “` $ npm –version “` – npmのバージョンアップ “` $ npm update -g “` – serverless frameworkのインストール “` $ npm install -g serverless “` – labmdaでflaskを使用するためのモジュールをインストール “

Vue.js、AWS Amplifyおよびboto3でサンプルアプリを作ってみる（第三回：axiosでAPIコール編）

第二回で、Amplify CLIを使ってバックエンドリソースを作成し、CICDを回してVueアプリを外部公開するところまで辿り着いた。 今回は、さらにAPIとLambda関数を用意し、Vue.jsからaxiosで呼び出すところまでをトライ。これができれば、「Vue.jsでフロントエンドを作ってAWSサービスを叩いてみる」という当初の目的を達成できたことになる。 前回の内容はこちら。 [Vue.js、AWS Amplifyおよびboto3でサンプルアプリを作ってみる（第二回：Amplifyとバックエンドリソース編）](https://qiita.com/itsuki3/items/21925a1afb256dd8b935) ## （今回）やりたいこと – axiosをセットアップする – APIとLambda関数を作る – Vue.jsからaxios経由でAPIを呼び出す ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/609876/3317fc2b-185b-ab87-1a5f-31

【AWS】LambdaとSNSでスマホにSMSを送る

## 概要 – 電話番号でメッセージを送るSMSを使いたいなと思って調べてみたらAmazonSNSで実現できると分かったので試してみました – API Gateway – Lambda – SNS を連携させてAPI化させてみました – 当然ですが指定した電話番号に本当にSMSを送れてしまうので、**悪用しない/されないようにご注意ください** – ちなみに日本の場合は一通辺り$0.07451のようです – https://aws.amazon.com/jp/sns/sms-pricing/ ## 構成 – 今回作る構成です ## 雛形生成 – 今回はServerlessFrameworkを使います – Lambdaのコードだけ見

AWSのロードバランサーにLambdaを使ってWEBサーバーを自動追加

#目的：アクセス集中時のみWEBサーバーを追加・負荷分散しコストダウン 　AWSのロードバランサー(ELB)を使っているサイトも多いかと思われます。ELBにはオートスケール機能があり、負荷率の上昇などをトリガーとしてスケールアウト(WEBサーバーの追加)を設定することができます。 　しかし、Auto Scalingを利用して負荷が上がってからWEBサーバーを立ち上げて追加したのでは時間がかかり、手遅れになる可能性が高いです。障害が出る前にサーバーを増設したいと思うでしょう。 　私の会社が開発しているソーシャルゲームでも、イベント開催時や広告プロモーション時には、普段の十数倍のアクセスになります。こういう負荷上昇が見込まれる場合は、あらかじめEC2インスタンスを立ち上げてELBに追加しておくことが有効でしょう。 　Lambdaのスケジュール機能を使い、アクセスの見込まれる必要な時刻にEC2インスタンス(WEBサーバー)をELBに自動的に追加し、ある程度の時間が過ぎたらELBから切り離す。これだけでは負荷分散はできてもコスト削減はできません。コスト削減のためには、EC2インスタンスを

AWS Lambda関数の通信先を制御してみる。

(記事を書いた2019/12/21に公開するのを忘れ半年遅れで公開となりました） ### はじめに 皆さんは AWS Lambda でどのような処理を実装されていますか？ AWS サービスの API （例えば、 Systems Manager の Parameter Store の API や Amazon EC2 の API ）、外部のサービスにアクセスさせたりしていますか？ 企業向けシステムを構築する際には、「通信先」について情報漏洩リスクにもつながるため、関心事として高いです。 当記事では、AWS Lambda 関数を利用してアプリケーションを実装する際、どのように通信先を制御を**「強制するか」**紹介していきたいと思います。 ### サマリ – デフォルトの Lambda 関数構成（VPC内リソースにアクセスしない）の場合、Lambda 関数に Security Group も NACL も設定できず、Lambda 関数からの通信を Lambda 関数の外で制御することができない。 – VPC 内リソースにアクセス可能なLambda関数として構成することで、 VPC