FaaS基盤からRDBMS接続における注意点と接続パターン追加の4回目 Amazon RDS Aurora Serverless DataAPI

summary

AWS Lambdaに代表されるFaaS基盤は原則ステートレスでありDBへの接続も注意が必要です。この記事では３回連載で接続パターンのベストプラクティスをまとめます。

その1：FaaS基盤からRDBMS接続における注意点と接続パターン RDS Proxy

その2：FaaS基盤からRDBMS接続における注意点と接続パターン Object-Relational Mapping（ORM） / Prisma

その3：FaaS基盤からRDBMS接続における注意点と接続パターン DataAPI/DataAppとTiDB Serverless Driver

この記事は三回連載で記載したFaaS基盤からRDBMSへ接続する様々な方法と注意点の追加の４回目です。

過去三回の記事では以下を紹介してきました。

RDS Proxy
Prisma / ORM
DataAPI / TiDB DataApp と serverless Driver

３回目の記事ではAurora用DataAPIの紹介だけは行いましたが、ハンズオンのやってみるパートではエッジFaaS基盤でよく利用されるTiDB Serverless と Serverless Driver をLambdaから接続するサンプルを作成しました。

この追加記事ではAurora 用 Data API をLambdaから呼んでみます。

さっそくやってみる

1. Amazon Aurora Serverless v2 MySQL + Data API の起動

Data APIはAurora Serverlessのみの機能です。もともとはServerless v1のみが利用可能でしたが、その後のアップデートでv2 でも利用可能となっています。

まずはAurora Serverless V2 MySQL クラスターを作っていきます。

DataAPIはMySQLバージョン3.07移行で利用可能です。デフォルトバージョン(3.05.2)では利用できませんので注意してください。

Data APIはデータベース呼び出しにIAM認証を用います。クレデンシャルをAWS Secret Manager で管理し、管理されているクレデンシャルへのアクセス権を持つIAMロールがアタッチされている環境のみがデータベースへのアクセスが可能となります。

例えばデータベースへのアクセスに用いるパスワードなどを環境変数で管理している場合と比較して考えてみます。

Lambda開発者がAWSへのログインに用いているIAMユーザーのクレデンシャルが不正に奪取されてしまえば、管理者画面にアクセスすればその環境変数は値を読み取られてしまいます。ソースコードの中に直接パスワードを記載することよりは安全であることは間違いないですが、Lambdaの開発に必要な権限とSecret Managaerが管理している値を解読可能な権限を分離させておくことでより堅牢なデータベースアクセス権限の保護を実現可能になっています。

インスタンスはServerless v2 を選択します。

RDS Data APIの有効化、にチェックをつけ起動します。

しばらく待つとAuroa Serverless v2 クラスターがHTTPエンドポイント付きで起動します。クラスターが起動すると 接続とセキュリティ タブで以下の通りData APIが有効化されていることが確認できます。

2.Query Editor からのデータ操作

AuroraはData APIが有効化されているクラスターは、マネージメントコンソールのQuery Editorからデータ操作が可能となっています。

接続パラメータで新しく作成されたSecret ManagerのARNを入力します。

接続出来たらまずはデフォルトで用意されているSQLを実行してみます。

では簡単にテスト用スキーマとテーブルを作成してデータを挿入しておきます。

CREATE DATABASE simple_db;
USE simple_db;

CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(50)
);

INSERT INTO users (name) VALUES ('Alice'), ('Bob'), ('Charlie');

3. Lambda 関数の作成

それでは、いよいよLambdaからData APIを通じてこのデータを読み取る関数を作成していきます。

コードは以下の通りです。

import { RDSDataClient, ExecuteStatementCommand } from "@aws-sdk/client-rds-data";

const client = new RDSDataClient({ region: process.env.AWS_REGION });

const DATABASE_NAME = "simple_db";
const CLUSTER_ARN = process.env.CLUSTER_ARN;
const SECRET_ARN = process.env.SECRET_ARN;

export const handler = async () => {
    try {
        const command = new ExecuteStatementCommand({
            resourceArn: CLUSTER_ARN,
            secretArn: SECRET_ARN,
            database: DATABASE_NAME,
            sql: "SELECT * FROM users;"
        });

        const response = await client.send(command);

        return {
            statusCode: 200,
            body: JSON.stringify(response.records)
        };
    } catch (error) {
        console.error("Error executing query:", error);
        return {
            statusCode: 500,
            body: JSON.stringify({ error: "Failed to fetch data" })
        };
    }
};

importしている @aws-sdk/client-rds-data はLambdaのNode環境には18移行標準で入っていますので、ローカルであらかじめインストールしたパッケージを作成する必要はなくそのままコードをLambdaのマネージメントコンソールに張り付ければOKです。

Deployをクリックして保存できたら、環境変数を設定します。

CLUSTER_ARN は少し勘違いしやすいです。RDSのエンドポイントではなく、ARNを入力します。

次にアクセス権限からロールをクリックしてIAMロールに必要なポリシーをアタッチします。LambdaがSecret Manager の値を読み取る権限とSQLをData APIに発行可能な権限が必要となるためです。必要なのは以下です。

SecretManagerへの読み取り権限(secretsmanager:GetSecretValue )
RDS Data APIに対する実行権限（SQL発行権限）（rds-data:ExecuteStatement )

RDS Data API起動時に自動で生成されるSecretManagerのARNは以下の様に[!]マークが入ります。これがIAM Policyでは動作しないので、以下の様に設定します。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": [
				"rds-data:ExecuteStatement"
			],
			"Resource": "arn:aws:rds:ap-northeast-1:917561075114:cluster:database-1"
		},
		{
			"Effect": "Allow",
			"Action": "secretsmanager:GetSecretValue",
			"Resource": "arn:aws:secretsmanager:ap-northeast-1:917561075114:secret:rds*"
		}
	]
}

最後にテストを行いUsers テーブルの中身が見えれば完成です！

{
  "statusCode": 200,
  "body": "[[{\"longValue\":1},{\"stringValue\":\"Alice\"}],[{\"longValue\":2},{\"stringValue\":\"Bob\"}],[{\"longValue\":3},{\"stringValue\":\"Charlie\"}]]"
}