はじめに
朝こんな記事を見かけました。
早速AIに要約してもらおう！
2024年9月26日、Amazon AuroraのMySQL互換エディションに、Aurora Serverless v2とAuroraプロビジョニング済みデータベースインスタンス向けの再設計されたRDS Data APIのサポートが追加されました。
主なポイントは以下の通りです：
セキュアなHTTPエンドポイントを通じて、データベースドライバーやコネクション管理なしでSQLステートメントを実行可能になりました。
以前はAurora Serverless v1の単一インスタンスクラスターのみで利用可能で、1秒あたり1,000リクエスト（RPS）の制限がありましたが、新設計ではこの制限が撤廃されました。
接続プーリングによりアプリケーションのスケーラビリティが向上しました。
AWS SDKとCLIを通じて利用可能で、AWS AppSync GraphQL APIを介したアクセスも可能です。
Aurora Serverless v1用のData APIとの後方互換性があり、アプリケーションの移行が容易です。
Aurora MySQL 3.07以上のバージョンで、14のリージョンでサポートされています。
現在Aurora Serverless v1のData APIを使用している顧客には、再設計されたData APIの利点を活用するためにAurora Serverless v2への移行が推奨されています。
この更新は、データベースアクセスの簡素化とスケーラビリティの向上を目指しており、特にサーバーレスアーキテクチャを採用している顧客にとって有益です。
今までLambdaでAuroraへ接続する際には、VPCに配置する一手間があったので、何かやり方が変わるのかなと思い、簡単にですが検証してみました！
まずは、環境構築！
Aurora MySQLを立てる。
検証用なので、適当にAuroraクラスターを一つ立ち上げます。
無駄に何度か作り直してしまったのですが、いくつか条件があるので注意です！
- Aurora MySQL 3.07から対応です！
2024/09/29時点では、デフォルトのバージョンが3．07ではないので注意です！
- SecretsManagerでID／Passを管理する必要があります。
RDS Data APIには、SecretsManagerのArnを指定する形だからです。
- インスタンスサイズにも条件があります。
詳しい条件まで調べていませんが、db.t3.mediumではRDS Data APIを有効にできません。
db.r5.largeだと問題なく、作成できました。
この時点で、今の業務では利用できない感じなのでちょっと残念。
（開発系がdb.t3.mediumを使っている。）
RDS Data APIを有効にする。
RDS Data APIが利用できる条件が整うと、クラスターの「接続とセキュリティ」のところに、以下の項目がでてきて、ここから有効にできます。
あとは実践！
なお、これから記載するCLIはCloudShellで実施したのですが、-bash: !cluster: event not foundのエラーに少し躓いたので、先にset +Hを投入しておくと良いです。
データベースの作成
$ aws rds-data execute-statement \
--resource-arn "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:cluster:database-data-api" \
--secret-arn "arn:aws:secretsmanager:ap-northeast-1:xxxxxxxxxxxx:secret:rds!cluster-2190bd4e-94d6-48ca-a041-ae8624af0447-4woN1O" \
--sql "create database mydb"
{
"numberOfRecordsUpdated": 1,
"generatedFields": []
}
テーブルの作成
$ aws rds-data execute-statement \
--resource-arn "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:cluster:database-data-api" \
--secret-arn "arn:aws:secretsmanager:ap-northeast-1:xxxxxxxxxxxx:secret:rds!cluster-2190bd4e-94d6-48ca-a041-ae8624af0447-4woN1O" \
--database "mydb" \
--sql "CREATE TABLE users (id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE);"
{
"numberOfRecordsUpdated": 0,
"generatedFields": []
}
レコードの挿入
$ aws rds-data execute-statement \
--resource-arn "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:cluster:database-data-api" \
--secret-arn "arn:aws:secretsmanager:ap-northeast-1:xxxxxxxxxxxx:secret:rds!cluster-2190bd4e-94d6-48ca-a041-ae8624af0447-4woN1O" \
--database "mydb" \
--sql "INSERT INTO users (username) VALUES ('johndoe');"
{
"numberOfRecordsUpdated": 1,
"generatedFields": []
}
テーブルの参照
$ aws rds-data execute-statement \
--resource-arn "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:cluster:database-data-api" \
--secret-arn "arn:aws:secretsmanager:ap-northeast-1:xxxxxxxxxxxx:secret:rds!cluster-2190bd4e-94d6-48ca-a041-ae8624af0447-4woN1O" \
--database "mydb" \
--sql "SELECT * FROM users WHERE username = :username" \
--parameters "[{\"name\": \"username\", \"value\": {\"stringValue\": \"johndoe\"}}]"
{
"records": [
[
{
"longValue": 1
},
{
"stringValue": "johndoe"
}
]
],
"numberOfRecordsUpdated": 0
}
まとめ
簡単にでは...ですが、VPCの外（CloudShell）からCLIを使ってAurora MySQLに接続できることは確認できました。
バージョンや、インスタンスサイズの制約で、今の会社の環境にすぐ適用・・・とはなりませんが、今後のアーキテクトの参考にしていきたいと思います！
少なくとも、LambdaでRDSに接続する必要ができてきた時に、必ずVPCに配置しないといけない・・・ということではなくなった模様です。