🥴

せや、AWS LambdaのハンドラをSQLにしたろ

2022/04/01に公開

AWS

SQL

Lambda

tech

はじめに

イマドキのAWS LambdaはハンドラをSQLで記述できます。

AWS LambdaのコンソールでこんなSQLを記述したとします。

実行するとこうなります。

SQLの結果が出力されていますね。

説明

冒頭のクエリを確認してみます。

index.sql

SELECT 'Hello World' body, 200 statusCode;

このクエリをAWS Lambdaのハンドラーに設定して実行すると、AWS Lambdaは次のJSON文字列をアウトプットします。

output

{
  "body": "Hello World",
  "statusCode": 200
}

SELECTしたキーとバリューを構造に持つJSON文字列がアウトプットされました。
JSON形式で返せるということは、イベントソースにAPI Gatewayを設定すれば簡単なWEB APIを作れるといっても過言ではありません。

これにより『SQLは書けるがプログラミング言語は利用できない』といった方でも簡単なLambda関数を作成できるようになり、求められるハードルがまた一つ低くなったのではないでしょうか。

なお、この記事が投稿されたのは4月1日であり、実際にはAWS LambdaにハンドラーをSQLで記述するといった機能は存在しません..........................

といったエイプリルフールネタを投稿したかった

昨年、2021年のエイプリルフールネタで『時代に即したMySQﾚの新機能：PLEASE句』というブログを拝見しました。

当時の私は上記ブログにとても関心を示し、似たようなネタを個人ブログにでも投稿したかったのですが、諸事情あって個人ブログは未開放にしていて実現できませんでした。

そこで情報共有コミュニティZennへの投稿を検討しましたが、利用規約にフェイクは許されないと記載されていました。（当たり前

第4条（禁止事項）

利用者は、本サービスの利用にあたり、以下の行為をしてはなりません。
10. 他の利用者および第三者を欺く虚偽の内容を記載する行為

では、この記事をどう投稿するか。
答えは簡単です。フェイクでなければ良いのです。嘘から出た誠にしてしまいましょう。
ということで、全てが誠となるように実際にSQLでハンドラを記述できる仕組みを作りました。

実際に作る

検討事項

実現させるにあたり次の項目を検討しました。

AWS Lambdaで任意の環境を使う
外部RDBMSサーバーを必要としないSQLの実装
AWS LambdaのEventをSQLから取得する仕組み

AWS Lambdaで任意の環境を使う

今回の目的はAWS LambdaのハンドラをSQLで記述することですが、
そもそもAWS Lambdaとは、コードを用意するだけでサーバーを意識せずにバックエンドを作成できるAWSのサービスです。基本的な使い方をするならAWSが提供するランタイム(言語やバージョン)を選択し、それに沿ってコードを記述する必要があります。
では、AWS LambdaではAWSが用意した言語やバージョンしか利用できないのでしょうか🤔

そんなことはありません。
AWS Lambdaには任意の環境を利用する仕組みが2種類あります。

カスタムランタイムを利用するパターン
Dockerイメージを利用するパターン

後者のDockerイメージを利用するパターンは、AWSで提供されていない言語を使いたい時に優先的に検討するべき一般的な選択肢です。

しかし、「Dockerイメージを使ってAWS LambdaでSQLを動かしました！！」と記事を投稿したとして閲覧者は何が面白いのでしょうか。「それってLambdaからSQL実行しているだけだよね？」とツッコミを入れられて終わるでしょう。
もちろん、実用的な記事としては十分価値がありそうですが、今回は実用性ではなくユニーク性を求めていたのでレギュレーションを設けることにしました。

まあ、そうですよね。
Dockerイメージで動くAWS Lambdaはマネジメントコンソールからコードが見えないのでハンドラをSQLで書いているようには見えません。
あたかもSQLだけで動いているかのように見せかけるため、今回はカスタムランタイムを使用することにしました。

カスタムランタイムを使用する

さて、カスタムランタイムを使用することにしましたが、カスタムランタイムを使用するにはまずランタイムAPIを自身で実装する必要があります。
ランタイムAPIとはAWS Lambdaがハンドラを呼び出す仕組みそのもので、以下のタスクで構成されています。

初期化タスク
- 設定の取得
- 関数の初期化
- 初期化エラーハンドリング
処理タスク
- イベントの取得
- トレースヘッダーの伝播
- コンテキストオブジェクトの作成
- 関数ハンドラの呼び出し
- レスポンスの処理
- 呼び出しエラーハンドリング
- クリーンアップ

カスタムランタイムを使用するにはこれらを任意の方法で実装した実行可能ファイルを用意する必要があります。
具体的にはこのような実装になります。

これらを実装していくと分かりますが少々手間がかかります。
この手間を解消するため、ランタイムAPIを実装しやすくするフレームワークaws-lambda-custom-runtime-kitを作成しました。aws-lambda-custom-runtime-kitを使うとGo言語で簡単にカスタムランタイムが実装できるようになります。

使い方は簡単で、次のインターフェースを満たす構造体を作成してaws-lambda-custom-runtime-kitの提供するエントリーポイントへ渡すだけです。

type AWSLambdaRuntime interface {
	Setup(env *AWSLambdaRuntimeEnvironemnt) error
	Invoke(event []byte, context *Context) (interface{}, error)
	Cleanup(env *AWSLambdaRuntimeEnvironemnt)
}

aws-lambda-custom-runtime-kitはこのようなアーキテクチャになっています。
Custom runtime kitより右側が実装者の担当する領域になります。

ランタイムAPIを実装するのに必要な処理がグっと減ったのが分かりますね。

なお、aws-lambda-custom-runtime-kitはGitHubにて公開していますので、ご覧になっている方もこちらを使ってクレイジーなカスタムランタイムを是非実装してみてください。

外部RDBMSサーバーを必要としないSQLの実装

次にSQLを解釈する方法です。
はっきり言ってジョーク記事のためにオレオレパーサーは作りたくなかったのでSQLiteを採用し、素直にmattnさんのgo-sqlite3を利用することにしました。
https://github.com/mattn/go-sqlite3

先ほど紹介したaws-lambda-custom-runtime-kit上で構築すると次のようなアーキテクチャになります。

AWS LambdaのEventをSQLから取得する仕組み

最後にEventを取得する仕組みです。
これがなければ実行時における動的なインプットがなく、常に同じ結果を返すことになってしまい実用性がありません。
実用性は求めないと記述した気がしますが気のせいです。

では、どうするか。
他にも案はありましたが、今回はSQLiteのUDFで実装することにしました。

UDFはUser-Defined Functionの略称で、SQLiteに限らず様々なRDBMSで実装されている『ユーザーがプログラミング言語で定義した任意の関数をSQLで使用する』機能です。go-sqlite3では次のように記述できます。

// 関数を定義
eventUDF := func(path string) string {
  if path == "" {
    return string(event)
  }
  value := gjson.Get(string(event), path)
  return value.String()
}

// 関数を登録
sql.Register(driverName, &sqlite3.SQLiteDriver{
  ConnectHook: func(conn *sqlite3.SQLiteConn) error {
    if err := conn.RegisterFunc("event", eventUDF, false); err != nil {
      return err
    }
    return nil
  },
})

今回はgjsonを利用してevent関数に渡されたJSONキーの値を取得するようにしてみました。
https://github.com/tidwall/gjson

では、SQLからEventを利用する方法をみてみましょう。
例として、遠足に持っていけるおやつをチェックするAPIをSQL Lambdaで実装するとします。

Lambdaのハンドラーに登録するSQL

SELECT
  CASE
    WHEN
      event('おやつ') = 'バナナ' THEN 400
    ELSE 200
  END statusCode,
  CASE
    WHEN
      event('おやつ') = 'バナナ' THEN 'バナナを持ってきた人は遠足に連れていきません'
    ELSE '300円までならOKです'
  END body;

上記ハンドラに次のEventを渡して実行すると・・・

遠足に持っていくおやつ.json

{ 
  "おやつ": "バナナ"
}

このようにEvent情報を利用した分岐処理が確認できます。

レスポンス

{
  "statusCode": 400,
  "body": "バナナを持ってきた人は遠足に連れていきません"
}

完成

最後に、ここまで紹介したコードをビルドしてLambdaレイヤーとして登録することで・・・
完成です🎉

ソースはこちらに公開しています。最新のリリースからビルドされたバイナリを取得できるのでSQLでAWS Lambdaを動かしてみたい方はそちらを利用してみてください。セキュリティは一切考慮されていないので絶対に遊び以外では使用しないでください。

さいごに

今回ランタイムAPIを実装したことによってAWS Lambdaについて勉強になりました。

例えばNode.jsランタイムを使用する際に初期化処理はハンドラーの外で実行することが推奨されていましたが、これは初期化タスクでハンドラソースをrequire()でインポートし、その後ハンドラを呼び出す関数がイベントのキューを常にポーリングし続けているためなんだろうと具体的に想像できました。

もう一度紹介しますが、是非皆さんもクレイジーなカスタムランタイムを実装してみてください。CloudFormationの記述で動いたりしたら面白そうです・・・。

参考