初期から最後まで使えるコスパ良しのサーバーレスSQL DB

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

レビュー投稿日の情報になります

Terra Drone株式会社 / 万年道半ばんちゅ

テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名

最終更新日2025/12/19投稿日2025/12/19

利用プラン	利用機能	ツールの利用規模	ツールの利用開始時期	事業形態
ACU 0~8	データ永続化のためのメインDBとして	101名〜300名	2023年9月	B to B

利用プラン	ACU 0~8
利用機能	データ永続化のためのメインDBとして
ツールの利用規模	101名〜300名
ツールの利用開始時期	2023年9月
事業形態	B to B

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャの意図・工夫

このアーキテクチャでは、3つのAurora Serverless v2との接続について記載しています。

VPC外Lambdaからの直接参照パターン ... VPC外部にAPIサーバーとしてLambdaを置き、プライベートサブネット内のAurora Serverless v2 (DB) にData APIを使って直接アクセスする方法です。
APIサーバーとして使用しているLambdaしかDBを参照できないようにIAM Roleで制限をかけるので、世界中の誰もがData API経由でデータを取得できるというわけではないのでセキュアになっています。
また、VPCエンドポイントやNATゲートウェイなど起動時間毎に課金されるリソースを使わないため従量課金で済むという点でコストを抑えることができます。
元々※Lambda + DynamoDBなどで簡単なアプリケーションを作っていて、それに対して複雑な検索条件が増えてきた、といったようなユースケースでは選択肢に入るかなと思います。
※...NoSQLからのテーブル作成がやや工数が高そうですが😰
VPC Lambdaと直結パターン ... APIサーバーとして利用しているLambdaをVPCの中に入れてしまい、DBと※直接ドライバーで連結する方法です。
1のような構成ではインターネットにエンドポイントを露出させてしまっているので怖い、という方向けです。Data APIを使用していないので外部からのアクセスは不可能となります。
ただしDBの情報を返すだけの簡単な処理なら上記図の構成でも可能ですが、外部APIを叩きたい等の要件がある場合にはNATゲートウェイ(またはNATインスタンス)をパブリックサブネットに用意しなければいけないのでコストはやや高めにかかってしまいます。
もともとLambdaでAPIサーバーを作っていて、安全性の要件が強くなってきたという場合の選択肢かなと思いますが過渡期対応な側面がある構成となっております。
※...LambdaからDBへのアクセスが増える場合はRDS Proxyを使用して接続数を減らす必要があります
ECSと直結パターン ... ※パブリックサブネットにおいたECSとDBを直接結ぶ方法です。
作成中のアプリケーションの代替の利用人数や、インフラにお金をかけられる場合はこちらの構成がおすすめです。Lambda特有の癖を無くすことができますし、Data API経由ではないのでレイテンシーの若干の遅さも気になりません。
また、図のようにECSの前段にロードバランサーを置けば急なスパイク的なアクセスもうまく捌いてくれます。
※...ECSはプライベートにおいた方がセキュアではありますが、その分NATゲートウェイを使う分のコストが膨らみます

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

DynamoDBを使用していたが複雑な検索(2、3軸検索など)が実装しにくくなってきていた
Amazon RDSなどを使っていたが、コストを下げるためにはリザーブドインスタンスの購入をするしかなく2、３年の間の使用が計画通りにいくかは不明だった

どのような状態を目指していたか

なるべく安く、複雑検索に耐えられる構成
インスタンスの性能調整(管理)などはなるべく行いたくない

比較検討したサービス

DynamoDB
Amazon RDS (PostgreSQL)

比較した軸

SQLを発行できるか？
未使用時にコストを0まで下げられるか？
アクセス数がスパイク的に増えた際にリアルタイムでスケールアップしてくれるか

選定理由

SQLによって操作できる(それによって柔軟な検索に対応)
開発環境などで使わない時間に0 ACUにスケールダウンできるので無駄なコストがかからない
Aurora Serverless v1と違いミリ秒単位でのスケールアップが行われるので急なスパイクにも耐えられる

導入の成果

改善したかった課題はどれくらい解決されたか

PostgreSQLのエンジンでSQLを発行できるようになったため複雑な検索やページネーションなどが楽になりました。また、APIサーバーはGo言語で書かれているのですが、そのORMであるGORMも、Amazon RDSを使っていた時と変わらず使用できてRDS → Aurora Serverless v2への移行はとてもスムーズでした。（DynamoDBからの移行はデータの加工必須という面では、工夫する必要がありましたが...）

どのような成果が得られたか

実装面でいうと主にAPIサーバー実装などのバックエンドアプリケーション側で検索ロジックを実装しやすくなったことなどが挙げられます。費用についてですと、開発環境ではAmazon RDSと比べると夜間非稼働分だけコストカットできたかなと思います。

導入時の苦労・悩み

以下の2点で苦労しました。

APIサーバーとしてLambdaを使っているとVPC内のAuroraとの接続に一工夫必要なこと -> VPC内にLambdaを設置し、Data APIを用いてhttp経由でアクセスすることにしました
Secret ManagerによるDBへのアクセス -> 普通のAmazon RDSのようにユーザー名やパスワードを使わないので、慣れるまでに時間がかかりました

導入に向けた社内への説明

上長・チームへの説明

以前からDynamoDBを使っていたのですが、そのまま使い続けると複雑な検索のユースケースに耐えられなくなることを説明しました。

活用方法

柔軟な検索が必要とされるプロダクトの開発環境と本番環境で使用しております。 LambdaからData API経由でAurora Serverless v2にアクセスできるので、DynamoDBでメインDBを作ってたプロジェクトの乗り換え先としては（NoSQLからRDBMSへデータ変換しなけばいけない工数はありますが）選択肢に入りやすいかなと思います。元々DynamoDBを使っていて複雑な検索の要件が増えてきたプロジェクトのDBとして活用していたりします。一方でData API経由の特性としてDBとのコネクションがクエリごとに切れてしまうという特徴があり、故に毎回の接続分のレスポンスの遅さがあります。検索結果の速度を0.1秒でも縮めたい要件ではLambdaとの構成ではなく、ECSからの接続などに切り替えるようにしてします。

よく使う機能

Data API接続
AWS コンソール上のクエリエディター
ACUの調整

ツールの良い点

面倒なインスタンスの性能調整をしなくて済む
クエリエディターでテーブル内部を閲覧できるので、別で踏み台サーバーやデータ閲覧用サーバーを用意する必要がない
開発環境での夜間における自動スケールダウン(0 ACU)

ツールの課題点

高頻度で使われ続けると利用料が高くなる
全てのエンジンでData APIをサポートしているわけではない
0 ACUまでスケールダウンした後の起動(0 → 0.5 ACUにスケールアップする時)は10～15秒ほどの待ち時間が発生する

ツールを検討されている方へ

Aurora Serverless v1の印象でサーバーレスは使い勝手が悪いと思われている方もいらっしゃると思いますが、V2になり色々な部分が改善されたので自前でRDSを用意するよりも管理工数を含めるとコスパ的には選択肢に入りやすくなりました。特に開発環境、ステージング環境、リリース前確認環境など環境を多く分けている企業様にとってはコスト削減の恩恵を受けやすいかなと思います。高頻度、高負荷で使われすぎた時のコストアップを気にされる場合はリリース前確認環境と本番環境だけ(Serverlessではない)、通常のAurora PostgreSQLにしたりなどそのような構成も考えられることがAuroraシリーズの強みかなと考えます。