「lambda」の記事 - Crieit

Lambda関数でDeadLetterQueue(DLQ)を試す

2021-05-13T23:16:42+09:00

AWSのLambda関数をイベントで起動した時、複数回エラーを起こしたら、DeadLetterQueue、すなわちDLQを飛ばしたい。DLQを試すもの。Cloudformation使う。DLQはSNSとSQSが指定できるが、今回はSNSを使う。

系

以下の系を試す。

CloudWatch -> Lambda -(error)-> SNS -> Email

やってみる

CloudWatchで1分ごとにLambda関数を起動するようなものを、Cloudformationｗと使って用意する。SNS Topicについては、コンソールから作成する。

SNS Topicを作る

コンソールからSNS Topicを作成する。名前は仮に DeadLetterQueueTopicとする。とりあえずEメールに飛ばすようにしておくと、確認しやすいと思う。

ディレクトリ構成

ディレクトリ構成は以下。__init__.pyは空。

.
├── __init__.py
├── hello_world_function
│   ├── __init__.py
│   ├── hello_world
│   │   ├── __init__.py
│   │   └── app.py
│   └── requirements.txt
├── samconfig.toml
└── template.yaml

という構成でやってみる。

template.yaml

TargetArn に SNS Topic のARNを入れる。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  sam-app

  Sample SAM Template for sam-app


Globals:
  Function:
    Timeout: 3

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello_world_function
      Handler: hello_world/app.lambda_handler
      Runtime: python3.8
      Policies:
        - AWSLambdaBasicExecutionRole
        - arn:aws:iam::aws:policy/AmazonSNSFullAccess
      Events:
        HelloWorld:
          Type: Schedule
          Properties:
            Schedule: rate(1 minute)
      DeadLetterQueue:
        Type: SNS
        TargetArn: arn:aws:sns:xxxxxxxxxxxxxxxxxx:DeadLetterQueueTopic

samconfig.toml

sam build –use-container の後に sam deploy –guided で作るとよい。以下のようになる。

version = 0.1
[default]
[default.deploy]
[default.deploy.parameters]
stack_name = "sam-app"
s3_bucket = "aws-sam-cli-managed-default-samclisourcebucket-1miie23rwqpqg"
s3_prefix = "sam-app"
region = "ap-northeast-1"
capabilities = "CAPABILITY_IAM"

requirement.txt

空でもいいけど。

requests
six
regex

hello_world/app.py

def lambda_handler(event, context):


    return True

DLQ

sam build --use-container

sam deploy

デプロイすると、1分間にLambda関数が起動する。で、このままだと正常に終了してDLQが飛ばないので、わざとエラーを起こす。そのためには、上記コードの raise Exception のエラーを外してデプロイする。しばらく待っていたら、DLQがSNSに飛ぶ。SNSのSubscriberにEmailを用意しておけば、すぐに確認できる。

後片付け

SNSのトピックは手動で作成したので、手動で消す。

忘れずにスタックを消す。消し忘れると延々とLambda関数が起動し続けることになってしまうので注意。
aws cloudformation delete-stack --stack-name sam-app

DLQ -> SNS -> Lambdaにした時のproperty

Slackとかに飛ばしたい時は、DLQのSNS経由でLambda関数に飛ばすことになる。Lambda関数のeventのpropertyをメモしておく。

{
  "Records": [
    {
      "EventSource": "aws:sns",
      "EventVersion": "1.0",
      "EventSubscriptionArn": "xxxxx",
      "Sns": {
        "Type": "Notification",
        "MessageId": "xxxx",
        "TopicArn": "xxxx"
        "Subject": None,
        "Message": "xxxxxxx",
        "Timestamp": "2021-05-13T03:02:52.129Z",
        "SignatureVersion": "1",
        "Signature": "xxxx",
        "SigningCertUrl": "xxxx",
        "UnsubscribeUrl": "xxxx",
        "MessageAttributes": {
          "RequestID": {
            "Type": "String",
            "Value": "xxxx",
          },
          "ErrorCode": {
            "Type": "String",
            "Value": "200"
          }
        }
      }
    }
  ]
}

気になるのは event.Sns.Message だが、これはシリアライズされたJSON。json.loads()でデシリアライズすると以下のようになる。

{
"version": "0",
"id": "xxxx",
"detail-type": "Scheduled Event",
"source": "aws.events",
"account": "xxxx",
"time": "2021-05-13T02:47:42Z",
"region": "xxxx",
"resources": [
"xxxx",
],
"detail": {}
}

resourcesとidから、エラーを起こした元のLambda関数を辿ることができる。

AWS Lambdaのロギングを考える

2021-01-26T03:25:25+09:00

ロギングをどうするかで困っていた。AWS Lambdaでは、プリント出力したものがCloudWatchに保存されてとても便利なのだが、考えもなしにとりあえずポンポン入れていたところ、確かに情報はあるので追えないことはないんだが、地道に時間にあたりをつけて検索するなど、非常に泥臭い作業が要求され、なにかとつらかった。

APIのコール回数など集計したいという要件も出てきて、重い腰をあげてロギングについて頑張って考えました、という話。

ユースケースを考える

AWS Lambdaで、何も考えずにとにかく必要そうなのをログ出力しているが、フォーマットも何も整っていないため、ほしい情報を探し当てるのも一苦労だ。

ログをjson形式に構造化させてやると、CloudWatch Insightsでクエリを投げて検索・集計することができる。ということで、ユースケースに対応できるように、ログ出力について考えたい。

ユースケースとして以下を考慮。

ERRORだけ抜き出す
ユーザー別に叩いたAPIについて集計する
詳細な検索ができるように、ハンドラに渡された情報は全部取っておく

前提条件として、node.jsを使っていたりPythonを使っていたりする。そのため、特定の言語のライブラリに依存した解決はあまり好ましくない。

参考リンク

この記事は、開発中のWebサービスQnQで草稿を作りました。よかったら見ていってね（宣伝）。

Lambda関数のロギング設計を考える | QnQ

その他、参考にさせていただいた記事です。ありがとうございました。

AWS Lambdaでcx_Oracleを使ってOracleDBへ接続する

2020-04-21T13:51:26+09:00

前書き

Pythonで書かれた Lambdaファンクションから、OracleDBへ接続する方法を記載します。

LambdaファンクションからMySQLへの接続はたくさん記事があるんだけど、OracleDBへの接続はあまり記事がなく、実現まで結構時間がかかったので、自分用の備忘録に。

結論

LambdaファンクションからOracleDBに接続する時には、cx_Oracleのモジュールだけではなく、Oracle Instant Clientのモジュールも、デプロイパッケージに入れてあげる必要がある。
すべてのモジュールを一つのデプロイパッケージに入れると、大きすぎてAWS Lambdaのインラインエディタで編集できなくなる。なので、cx_OracleとOracle Instant Clientのモジュールはレイヤに分けると良い。

手順

前提

2020年4月時点で、使用した環境は下記の通りです。
python3のインストールまで完了している状態で、後続の作業を開始します。

Amazon Linux 2（AWS EC2上で作業）
python3.7
cx_Oracle7.3
Oracle Instant Client 19.6

手順の流れ

必要なモジュールをインストールする
デプロイパッケージを作る
Lambdaファンクションを作成する
レイヤ用のデプロイパッケージを作成する
Lambdaファンクションにレイヤを適用する

1. 必要なモジュールをインストールする

Oracle Instant Client

まずは、Oracle Instant Client から。
最新版のOracle Instant Clientを公式サイトからダウンロードします。作業環境が Amazon Linux 2 なので、Linux用の64ビット版を使います。
* Oracle Instant Client
* Instant Client Downloads for Linux x86-64 (64-bit)

インストールしたのは、とりあえずbasicとsqlplusのふたつだけ。LambdaファンクションからのDB接続だけを考えるなら、sqlplusは不要かも。

$ sudo yum -y localinstall ./oracle-instantclient19.6-basic-19.6.0.0.0-1.x86_64.rpm
$ sudo yum -y localinstall ./oracle-instantclient19.6-sqlplus-19.6.0.0.0-1.x86_64.rpm

インストール完了後、SQL*PLUSでDBに接続できることを確認しておきます。
なお、Oracle Instant Clientを使用する分には、ORACLE_HOMEなどの設定は不要らしいです。

$ sqlplus /@:/
SQL*Plus: Release 19.0.0.0.0 - Production on xxx xxx xx xx:xx:xx xxxx
Version 19.6.0.0.0
Copyright (c) 1982, 2019, Oracle.  All rights reserved.
Last Successful login time: xxx xxx xx xxxx xx:xx:xx +09:00
Connected to:
Oracle Database 12c Standard Edition Release 12.1.0.2.0 - 64bit Production

SQL> select TNAME from tab;
TNAME
--------------------------------------------------------------------------------
SAMPLE_EMP

SQL> select * from SAMPLE_EMP;
EMPNO      EMPNAME                                              GENDER_F
---------- -------------------------------------------------- ----------
0000000001 EMP_A                                                       1
0000000002 EMP_B                                                       2
0000000003 EMP_C                                                       1

SQL> quit
Disconnected from Oracle Database 12c Standard Edition Release 12.1.0.2.0 - 64bit Production

サンプルで作っておいたテーブルの中身が見えており、Oracle Instant Clientのインストールは完了です。

cx_Oracle

PythonでOracleDBに接続するために、cx_Oracleもインストールしておきます。

$ sudo pip3 install cx_oracle

EC2からcx_Oracleを使ってOracleDBへ接続する

ここまで完了したら、pythonでOracleDBへ接続できるようになっているはずなので、簡単なサンプルでOracleDBに接続できるか確認します。例えば下記のような感じ。ファイル名はdbconnect_oracle.pyとします。

import json
import cx_Oracle

def lambda_handler(event, context):
    # TODO implement

    # cx_oracleバージョン確認
    verOraCli = cx_Oracle.clientversion()
    print( verOraCli )

    # oracle接続
    print( "DB connect" )
    connection = cx_Oracle.connect("", "", "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=) (PORT=))(CONNECT_DATA=(SID=)))")

    # select実行
    print( "select execute" )
    try:
        cursor = connection.cursor()

        sql = "select * from sample_emp"
        cursor.execute( sql )

        result = cursor.fetchall()
        print( result )

    finally:
        cursor.close()
        connection.close()

    return {
        'statusCode': 200,
        'body': json.dumps( 'cx_oracle clientversion = ' + str(verOraCli) )
    }

本来はハンドラの中でDB接続処理を行わない方が良いけど、まあとりあえずということでひとつ。早速実行してみます。

$ python3 -c "import dbconnect_oracle; dbconnect_oracle.lambda_handler(0,0)"
(19, 6, 0, 0, 0)
DB connect
select execute
[('0000000001', 'EMP_A', 1), ('0000000002', 'EMP_B', 2), ('0000000003', 'EMP_C', 1)]

Oracle Instant Client 19.6 を使用してOracleDBでselectを実行できていることが確認できました。

2. デプロイパッケージを作る

EC2上での動作は確認できたので、AWS Lambdaの関数として定義するためにデプロイパッケージを作成します。

デプロイパッケージ構成

Lambdaファンクションで外部ライブラリのimportを行う場合、外部ライブラリを含んだデプロイパッケージを作る必要があります。今回はさらに、cx_OracleがOracle Instant Clientを利用するので、Oracle Instant Clinentもデプロイパッケージに含める必要があります。

というわけで、目指すべき構成は下記の形。作業ディレクトリは/tmp/dbconnect_oracle_packとします。

/tmp/dbconnect_oracle_pack
 ├ dbconnect_oracle.py
 ├ cx_Oracle.cpython-37m-x86_64-linux-gnu.so
 ├ cx_Oracle-7.3.0.dist-info
 │  ├ INSTALLER
 │  ├ METADATA
 │  ├ RECORD
 │  ├ WHEEL
 │  └ top_level.txt
 └ lib
    ├ libaio.so -> ./libaio.so.1
    ├ libaio.so.1
    ├ libclntsh.so -> ./libclntsh.so.19.1
    ├ libclntsh.so.19.1
    ├ libclntshcore.so -> ./libclntshcore.so.19.1
    ├ libclntshcore.so.19.1
    ├ libipc1.so
    ├ libmql1.so
    ├ libnnz19.so
    ├ libocci.so -> ./libocci.so.19.1
    ├ libocci.so.19.1
    └ libociei.so

デプロイパッケージ作成

デプロイパッケージにcx_Oracleを含めるため、作業ディレクトリへcx_Oracleを持ってきます。作業ディレクトリへのインストールなので、今回はsudoは不要です。

$ pip3 install cx_Oracle -t /tmp/dbconnect_oracle_pack

Oracle Instant Clientのモジュールは、インストール先からコピーします。libaio.so.1だけは、/usr/lib64/から持ってきます。

なお、記事を書く際に再度確認したら、libaio.so.1はシンボリックリンクで、実体はlibaio.so.1.0.1でした。
下記の通りでも動作はしますが、気になる方は、libaio.so.1.0.1をコピーしてそこからシンボリックリンクを作成する方が良いかもしれません。

$ mkdir /tmp/dbconnect_oracle_pack
$ cp /usr/lib/oracle/19.6/client64/lib/libclntsh.so.19.1 /tmp/dbconnect_oracle_pack/lib
$ cp /usr/lib/oracle/19.6/client64/lib/libclntshcore.so.19.1 /tmp/dbconnect_oracle_pack/lib
$ cp /usr/lib/oracle/19.6/client64/lib/libipc1.so /tmp/dbconnect_oracle_pack/lib
$ cp /usr/lib/oracle/19.6/client64/lib/libmql1.so /tmp/dbconnect_oracle_pack/lib
$ cp /usr/lib/oracle/19.6/client64/lib/libnnz19.so /tmp/dbconnect_oracle_pack/lib
$ cp /usr/lib/oracle/19.6/client64/lib/libocci.so.19.1 /tmp/dbconnect_oracle_pack/lib
$ cp /usr/lib/oracle/19.6/client64/lib/libociei.so /tmp/dbconnect_oracle_pack/lib
$ cp /usr/lib64/libaio.so.1 /tmp/dbconnect_oracle_pack/lib

最初に挙げたデプロイパッケージ構成に不足している部分を、シンボリックリンクで作成します。
デプロイパッケージのサイズ上限は250MBのため、絞れるところは絞りましょう。

$ cd /tmp/dbconnect_oracle_pack
$ ln -s ./libaio.so.1 libaio.so
$ ln -s ./libclntsh.so.19.1 libclntsh.so
$ ln -s ./libclntshcore.so.19.1 libclntshcore.so
$ ln -s ./libocci.so.19.1 libocci.so

ここまで完了すると、デプロイパッケージ構成通りの状態となっているはずです。zip圧縮して、デプロイパッケージを作成します。圧縮後のファイルは70MB弱くらいになると思います。
シンボリックリンクを含んでいるので、--symlinksオプションを忘れないように。また、圧縮対象は/tmp/dbconnect_oracle_packディレクトリではなく、その配下であることに注意してください。

$ cd /tmp/dbconnect_oracle_pack
$ zip -r --symlinks dbconnect_oracle_sample.zip ./dbconnect_oracle.py ./cx_Oracle.cpython-37m-x86_64-linux-gnu.so ./cx_Oracle-7.3.0.dist-info ./lib

ですが、作成したデプロイパッケージが50MBを超えているため、Lambdaファンクションとして直接アップロードを行う事ができません。一旦S3上にアップロードした後、LambdaファンクションにS3からアップロードする形になります。なお、Lambdaファンクションのサイズ上限は諸々含めて250MB。cx_OracleとOracle Instant Client だけで200MBを超えていて、結構カツカツです。

Lambdaファンクションとしてのアップロードが完了すると、インラインエディタで確認ができる…のが通常なのですが、サイズが大きすぎてインラインエディタでは編集できない旨の警告が表示されます。実行はできるようなので、良しとしておきます。

OracleDBに限らず、DBに接続するLambdaファンクションにはIPアドレスの付与が必要です。VPC設定を行い、VPC設定、サブネット、セキュリティグループを指定します。

また、初回実行に限り、そこそこの時間がかかります。デフォルトのタイムアウト値は3秒となっていますが、10秒程度に増やしておいたほうがよいでしょう。

上記の設定を完了したら、テスト実行を行います。サンプルは引数不要のイベントハンドラなので、空のテストイベントを作成してテストを行いましょう。

ヨシ！　ちゃんと、Oracle Instant Client 19.6が使われているようです。
初回は時間がかかりましたが、2回目からは1秒かからずに実行されます。時間がかかるのは、IP付与によるものかしら。

4. レイヤ用のデプロイパッケージを作成する

当初の目的である、cx_Oracleを使ってOracleDBへ接続するLambdaファンクションの作成は、ここまでで実現できました。

ただ、インラインエディタでの編集ができないのはちょっといただけません。サイズが大きい原因はcx_OracleとOracle Instant Clientなので、この部分をcx_Oracleレイヤとして切り出せば良いのではないか？

cx_Oracleレイヤ用のデプロイパッケージ構成

AWS Lambda レイヤー

関数コードからランタイム依存関係を移動するには、それらをレイヤーに配置します。Lambda ランタイムには、関数コードを使用して、レイヤーに含まれるライブラリにアクセスできることを確認する、/optディレクトリのパスが含まれます。

ライブラリをレイヤーに含めるには、ランタイムでサポートされているいずれかのフォルダにそれらを配置します。
* Python – python、python/lib/python3.8/site-packages（サイトディレクトリ）

レイヤ用のデプロイパッケージを作る場合、pyhon関連のライブラリはpython配下に、配置します。なので、cx_Oracle関連のモジュールはこちらに置きます。

AWS Lambda 環境変数の使用

予約されていない環境変数
(略)
LD_LIBRARY_PATH – システムライブラリのパス
(/lib64:/usr/lib64:$LAMBDA_RUNTIME_DIR:$LAMBDA_RUNTIME_DIR/lib:$LAMBDA_TASK_ROOT:$LAMBDA_TASK_ROOT/lib:/opt/lib)。

Oracle Instant Clientのモジュールについては、LD_LIBRARY_PATHで指定されたパスに配置する必要があります。Lambdaファンクションの設定で編集しても良いのですが、デフォルトで指定されたパス/opt/libがあるので、そちらを使いましょう。レイヤに含まれるライブラリは/opt配下に配置されるとのことなので、lib配下です。

というわけで、レイヤ用デプロイパッケージの構成は下記の通りになります。作業ディレクトリは/tmp/dbconnect_oracle_pack/layerとします。

/tmp/dbconnect_oracle_pack/layer
 ├ python
 │ ├ cx_Oracle.cpython-37m-x86_64-linux-gnu.so
 │ └ cx_Oracle-7.3.0.dist-info
 │     ├ INSTALLER
 │     ├ METADATA
 │     ├ RECORD
 │     ├ WHEEL
 │     └ top_level.txt
 └ lib
    ├ libaio.so -> ./libaio.so.1
    ├ libaio.so.1
    ├ libclntsh.so -> ./libclntsh.so.19.1
    ├ libclntsh.so.19.1
    ├ libclntshcore.so -> ./libclntshcore.so.19.1
    ├ libclntshcore.so.19.1
    ├ libipc1.so
    ├ libmql1.so
    ├ libnnz19.so
    ├ libocci.so -> ./libocci.so.19.1
    ├ libocci.so.19.1
    └ libociei.so

レイヤ用デプロイパッケージ作成

配置ができたらzip圧縮し、レイヤ用デプロイパッケージを作成します。ファイル名は何でも良いですが、oraclelib.zipとしてみました。

$ cd /tmp/dbconnect_oracle_pack/layer
$ zip -r --symlinks oraclelib.zip ./python ./lib

5. Lambdaファンクションにレイヤを適用する

レイヤを作るため、AWS Lambdaの左側メニューから「レイヤー」を選択し、レイヤの作成を行います。

先程と同様に、S3経由でアップロードする形になります。また、「互換性のあるランタイム」には、作業環境であるAmazon Linux 2にインストールしたのと同じ Python3.7 を指定します。

レイヤの作成が完了したら、Lambdaファンクションにレイヤを適用します。

作成したLambdaファンクションの画面から「レイヤーの追加」を行う事ができます。
Lambdaファンクションのランタイムを「Python3.7」にした上で、「レイヤーの追加」を行ってください。

選択できるレイヤーは、Lambdaファンクションで設定しているランタイムを「互換性のあるランタイム」で指定したレイヤーだけです。

こうしておくと、Lambdaファンクションそのものは、今回のサンプルのdbconnect_oracle.pyだけにしても大丈夫です。インラインコード編集も可能となります。

動作も問題ありません。

後書き

一番わからなかったのは、Oracle Instant Client 19 だとどのlibをデプロイパッケージに含めればよいのか、ということです。今回記事に残そうとしたのも、それが要因です。

それにしても、Oracle Instant Client だけで200MBオーバーなんだけど、そのうちOracle Instant ClientだけでLambdaのサイズ制限を超えてしまうのではないだろうか。

参考サイト

Lambda から RDS にアクセスする方法 (python)
AWS Lambda (Node.js-v4.3.2)からOracleに接続する(ORA-21561への対応)
Lambda, Python, and Oracle

その他、検索に引っかかったフォーラムの記事とか色々参考にしました。

Puppeteer on AWS Lambda のスクリーンショットで文字が豆腐になるので、ウェブフォントと絵文字フォントをインストール

2018-12-28T19:11:14+09:00

状況

現在開発中の https://poiit.me で puppeteer のスクリーンショットを使って動的OGPをつくっています。
CSSで動的な画像をデザインできるし、一つ lambda 関数を作っておけば、いろんなところで応用ができるのでいいですね。

が、今回は絵文字が、豆腐になってしまったのでその対処法。

参考記事

ベースはこちらの記事を参考にしました。
https://qiita.com/zyyx-matsushita/items/c33f79e33f242395019e

基本は参考Qiita をベースに対応できましたが、絵文字フォントがどこにあるのか結構探したので、備忘録的にメモ。

絵文字フォントダウンロードと設置

Google の Noto Color Emoji はこちらからダウンロードできました。
https://www.google.com/get/noto/#noto-emoji-zsye-color

他のダウンロード可能な絵文字フォントを知っていたら、是非ダウンロード場所教えてください！

で、ダウンロードしたファイルを解答し /.font/NotoColorEmoji.ttf に設置

WEBフォント

こちらは絵文字以外のフォントについては、WEBフォントをつかっています。

screenshot を撮る前に head に追加してやれば反映されるはず。

        await page.evaluate(() => {
            var style = document.createElement('style')
            style.textContent = `
                @import url('//fonts.googleapis.com/css?family=M+PLUS+Rounded+1c|Roboto:300,400,500,700|Material+Icons');
                div, input, a, p{ font-family: "M PLUS Rounded 1c", sans-serif; };`
            document.head.appendChild(style);
            document.body.style.fontFamily = "'M PLUS Rounded 1c', sans-serif";     
        })

その後、長めに wait させたないとフォントが反映されていないことがあるので注意

        await page.waitFor(3000);

こちらの記事を参考にしています。
https://qiita.com/chimame/items/04c9b45d8467cf32892f

関数実行

lambada で呼び出す関数で、フォントをサーバーにインストールする fc-cache コマンド実行してから、
puppeteer の screenshot などを実行すれば、ちゃんと絵文字が反映されているはずです。

アップロードすれば終了です。

めでたし！

serverless を使ったベーシックな puppeteer on lambda は github に置いてあるので必要あれば。
https://github.com/yahsan2/puppeteer-example-on-serverless-lambda

この記事のフォント反映バージョンも要望あればで公開しますので、コメントください〜！

poiit というサービスつくっています！

この記事がもし参考になれば、50円からサポートお願いします〜！

https://poiit.me/yahsan2/