三菱UFJグループ会社、DBコストを87％削減――なぜ「Aurora Serverless」ではなく「Aurora DSQL」を選んだ？：同じサーバレスでも何が違った？

三菱UFJフィナンシャル・グループのグループ会社、Japan Digital Designは、ドキュメント検索システムのデータベースに「Amazon Aurora DSQL」を採用した。「Amazon Aurora Serverless」と比較して、データベースのコストを約87％削減できたという。その違いはどこにあるのか。

[＠IT]

　三菱UFJフィナンシャル・グループ（MUFG）のグループ会社でDXを支援するJapan Digital Design（JDD）は、新規構築したドキュメント検索システムのデータベースに、サーバレス分散SQLデータベース「Amazon Aurora DSQL」（以下、Aurora DSQL）を採用した。

　JDDは2026年7月30日、Amazon Web Services（AWS）のブログで、Aurora DSQLを採用した経緯や、他のデータベースサービスとの比較、導入によって得られた効果などを明らかにした。「Amazon Aurora Serverless」を採用した場合と比較して、約87％のコスト削減と、データベース運用負荷のほぼゼロ化を実現したという。なぜこれほどの差が生まれたのか。

なぜ「Aurora DSQL」で87％もの大幅コスト削減？　DB選定を左右した条件

　JDDは2026年7月30日、Amazon Web Services（AWS）のブログで導入事例を公開した。これによれば今回のデータベース選定でポイントの一つになったのが、ドキュメント検索システム特有の負荷の偏りだ。

　システムは、PDFやWebサイトから取り込んだ情報を夜間にまとめて処理する。翌朝までに処理を終えるため、約1800の「Amazon Elastic Container Service」（Amazon ECS）タスクを並列に実行し、それぞれの処理結果をAurora DSQLに書き込む。ピーク時には1晩で10万件を超えるファイル／レコードを処理する。一方、日中はWebアプリケーションからのデータの読み取りが中心となる。

　加えて、本番、ステージング、開発など複数の環境を並行して運用する。常時利用しない環境にも固定費が発生するデータベースでは、環境を増やすほどコストが膨らむことになる。

　将来の拡張も考慮する必要があった。JDDはデータ量を10倍規模に拡大することを計画しており、そのたびに性能調査や性能試験、データベースの再設計を実施することは避けたいと考えた。

　そこでJDDは、負荷の増減に対応しながら、利用していないときのコストを抑制でき、将来データ量が増えても拡張しやすいことを採用するデータベースの要件とした。Aurora Serverlessの他、「Amazon Aurora」や「Amazon DynamoDB」などとも比較してAurora DSQLを選んだ。

同じ「サーバレス」でも何が違う？　Aurora DSQLを選んだ理由

　比較対象の一つとなったAurora Serverlessも、アプリケーションの負荷に応じてデータベースの処理能力を自動的に調整できる。

　ただし今回のシステムでは、利用していない時間帯や環境のコストをどこまで抑えられるかが鍵になった。Aurora Serverlessは、処理能力の単位である「ACU」（Aurora Capacity Unit）を0まで下げて一時停止できるものの、再開時には待ち時間が発生する。この待ち時間を避けるためにACUの最小値を0.5に設定すると、本番、ステージング、開発といった環境ごとに固定的なコストが発生する。

　一方のAurora DSQLでは、長期間利用されなければリソースをゼロまで縮小し、再び接続すると自動的に稼働状態に戻るという運用ができる。JDDは、利用しない環境のコストを抑えながら、必要なときにはすぐに利用できる点を評価した。

　この違いは、複数の環境を持ちながら、夜間に処理が集中する今回のシステムと相性が良かった。結果として、Aurora Serverlessでコールドスタートを避けるため最小ACUを0.5に設定した場合と比較して、データベースのコストを約87％削減できたという。

コストだけでは決められない　「DynamoDB」ではなくDSQLを選んだ理由

　利用していない時間帯のコストを抑えられるという点では、Aurora DSQL以外にも選択肢があった。その一つが、サーバレスのNoSQLデータベースであるDynamoDBだ。

　JDDによれば、DynamoDBでも今回のシステムを構築すること自体は可能だった。ただし、対象は業務システムとして一定の複雑性がある。想定するアクセス方法に合わせてデータ構造を設計するNoSQLよりも、SQLを使って必要な処理を表現できるRDB（リレーショナルデータベース）の方が適していると判断した。

　開発チームがSQLに習熟しており、既存のRDB開発で培った知見を生かせることも判断材料になった。採用前には、同一レコードへの同時更新がないことや、分析、集計を主目的としないことなど、今回のワークロードがAurora DSQLの特性に適合することも確認した。

「大規模向け」だけではない　データ10倍でもチューニング不要

　JDDは、2025年5月末のAurora DSQLのGA（一般提供開始）を受けて検討を始め、同年8月の事前検証、10月からの設計、開発を経て2026年1月に本番稼働を開始した。

　導入後は、インスタンスの容量拡張やコールドスタートを回避するための処理といった作業が不要になり、データベースの運用工数はほぼゼロになったという。開発環境を起動、停止するためのバッチ処理やスクリプトも不要になった。

　さらに、データ量を約10倍に拡大した際にも、データベース側の設定変更や性能チューニングは実施せず、性能劣化も発生しなかったとしている。

　JDDがAurora DSQLを評価した理由は、大規模な分散処理に対応できることだけではない。社内向けの今回のシステムは最大ユーザー数が限定されており、当初から大規模な処理能力が必要だったわけではない。むしろJDDが着目したのは、小規模な状態から利用を始め、データ量や処理量が増えてもデータベースを再設計せずに拡張できる点だった。

　Aurora DSQLは完全サーバレスのため、利用が少ないときにはリソースを縮小できる一方、処理量が増えれば自動的に拡張する。JDDは、こうした特性から、間欠的で比較的小規模なワークロードでもAurora DSQLを選択肢にできるとしている。