寄稿：三菱UFJフィナンシャル・グループの DX を牽引する Japan Digital Design、Aurora DSQL の採用で DB コストを約 87% 削減し、運用負荷ほぼゼロを実現

本稿は、Japan Digital Design 株式会社 佐藤様による「三菱UFJフィナンシャル・グループの DX を牽引する Japan Digital Design、Aurora DSQL の採用で DB コストを約 87% 削減し、運用負荷ほぼゼロを実現」に関する寄稿記事となります。

こんにちは。Japan Digital Design 株式会社 Technology & Development Division で Technical Project Manager を務めている佐藤です。

Japan Digital Design 株式会社は「金融の新しいあたりまえを創造し人々の成長に貢献する」というミッションのもと、AI・CX・Tech の各領域を組み合わせて三菱UFJフィナンシャル・グループの DX を支援しています。私が所属する Technology & Development Division では、システムの開発・運用からプラットフォーム構築、アーキテクチャ設計までを担っています。

今回、ドキュメント検索システムを新規構築するにあたり、データベースとして Amazon Aurora DSQL を採用しました。パートナーを介さず自社開発チームのみで導入を完了し、結果として Aurora Serverless 比で約 87% のコスト削減と DB 運用負荷ほぼゼロを実現できています。本記事では、私たちが Aurora DSQL を選定した背景、開発時に直面した課題とその対処、そして導入後に得られた効果をご紹介します。これから DSQL の採用を検討される方の参考になれば幸いです。

対象システム

Aurora DSQL は、Japan Digital Design 株式会社が運営するドキュメント検索システムの一部である文書管理データベースとして利用しています。
本システムは、夜間バッチ連携される PDF や Web サイトの情報を取り込み・加工し、ユーザーが取込履歴や取込データ一覧を CSV としてダウンロードできる機能を提供しています。

アーキテクチャ

本システムは 2 つのワークロードで構成されています。

• 夜間バッチ処理: 翌朝の Web アプリケーションの開局時間までに全ての取り込み・加工処理を終わらせる必要があるため、AWS Step Functions にて約 1,800 の Amazon ECS タスク（EC2 上で稼働）を並列起動。上流から取り込んだデータを各タスクが処理して、取込結果を Aurora DSQL に書き込む
• Web アプリケーション: Amazon CloudFront + ALB + Amazon ECS で構成された Web アプリケーションから Aurora DSQL のデータを読み取り、取込データ一覧を CSV として提供

夜間バッチでは、ピーク時に 1 晩あたり 10 万件超のファイル／レコードを処理します。バッチはユーザーが利用しない夜間にのみ稼働し、日中の Web アプリケーションからの読み取りとは時間帯が分離されています。

データベース選定の背景

本システムは新規開発だったため、システムの特性に合わせてデータベースをゼロベースで検討できました。私たちがデータベースに求めた要件は以下の 3 点です。

1. 複数環境運用におけるコスト効率
本番・ステージング・開発など複数環境を運用するため、未使用環境にも固定費が発生するインスタンス課金型 DB ではコストが見合わないという課題がありました。

2. スパイクワークロードへの対応
夜間に約 1,800 の ECS タスクが並列書き込みを行うスパイクワークロードへの対応が必要でした。書き込みが夜間に集中する特性上、スケーラブルなアーキテクチャが望ましいと考えていました。

3. 将来のデータ拡大への備え
将来的にデータ量を 10 倍規模に拡大する計画があり、その都度性能調査・性能試験を行う工数は避けたいと考えていました。

Aurora DSQL を選択した理由

他の候補として Aurora Serverless、Aurora、DynamoDB を比較検討し、以下の理由から Aurora DSQL を選択しました。

サーバーレス・従量課金

夜間バッチ時のみコストが発生し、未使用環境の固定費を解消できます。Aurora Serverless では、コールドスタートを避けるために最小 ACU を 0.5 に設定すると環境ごとに固定費が発生しますが、DSQL では利用しない環境にほとんど料金がかかりません。

さらに、Aurora DSQL はアイドル状態が長期間続いても接続時の遅延が極めて小さく抑えられます。Aurora DSQL のクラスターライフサイクルでは、一定期間アイドル状態が続くとリソースを縮小（Idle 状態）し、さらに長期間接続がないとリソースをゼロにスケール（Inactive 状態）しますが、接続するだけで自動的に Active 状態に復帰します。一方、Aurora Serverless の自動一時停止機能（0 ACU へのスケーリング）では、再開時に通常約 15 秒、24 時間以上の一時停止後は 30 秒以上の待機が発生します。Web システムでこの遅延を許容できない場合、最小 ACU を 0.5 以上に維持する（＝固定費が発生する）か、定期的な ping 処理でウォームアップを維持する必要があります。DSQL ではこうした考慮が大幅に軽減され、週に 1 回程度しか動かないようなワークロードでも実用的な応答速度で利用できます。

メンテナンスゼロ

パッチ適用やキャパシティ管理が不要で、DB 運用負荷を最小化できます。

SQL 互換性 — DynamoDB ではなく DSQL を選んだ理由

DynamoDB も検討しましたが、テーブル設計の特性と SQL 互換性を重視して Aurora DSQL を選択しました。

本システムは業務システムとしてある程度の複雑性を持ちます。DynamoDB でも構築は可能ですが、アクセスパターンに合わせたテーブル設計が求められる NoSQL のアプローチよりも、やりたいことを素直に SQL で表現できる RDB の方が健全なシステムを構築できると判断しました。開発チームの SQL への習熟度が高く、これまでの RDB の知見をそのまま活かせることも大きな要因でした。

そのうえで、RDB の選択肢の中でコスト面で最も優れていたのが Aurora DSQL でした。

スモールスタートから大規模まで、再設計なしに拡張できる

本システムは社内の利用者が使うためのシステムのため、最大ユーザー数は限定的です。Aurora DSQL は GA 当初、マルチリージョンの大規模スケーラビリティが注目されがちでしたが、私たちはむしろ「小さく始められ、必要に応じて再設計なしに大規模まで成長できる」点を評価しました。完全サーバーレスでゼロまでスケールダウンできるため、間欠的・小規模なワークロードでも無理なく利用でき、その後データ量やスループットが拡大しても、同じデータベースの特性・体験のまま使い続けられます。

Aurora DSQL に向いているワークロードかを見極める

採用にあたっては、本システムのワークロード特性が DSQL の設計思想に合致するかを、以下の 3 つの観点で事前に評価しました。DSQL の導入を検討されている方にも、そのまま使える判断基準だと思います。

この 3 条件を満たすワークロードであれば、Aurora DSQL の特性を最大限に活かせると判断し、採用を決定しました。

開発スケジュール

2025 年 5 月末の Aurora DSQL GA（一般提供開始）を受けて検討を開始し、以下のスケジュールで開発を進めました。

GA から約 3 ヶ月で事前検証を経て開発に着手し、約 3 ヶ月の開発期間で本番ローンチを迎えることができました。

開発時の取り組みとハマりどころ

私たちはパートナーを介さず、すべて自社開発で Aurora DSQL を導入しました。AWS 公式ドキュメントを主な技術情報源とし、約 3〜4 ヶ月で習熟に至っています。

PostgreSQL 互換とはいえ DSQL 固有の制約はいくつかあり、開発中に検討した内容、および直面した課題と対処法を共有します。

ORM として SQLAlchemy、マイグレーションツールとして Alembic を採用

DSQL を利用する際の ORM とマイグレーションツールの選定前に、ORM とマイグレーションツールによる各 DB 操作で実施できるもの・できないものを一通り確認していきました。その上で、最終的に SQLAlchemy + Alembic を採用しました。

SQLAlchemy については、AWS が公開している aws-samples リポジトリに利用例が掲載されていることが決め手となりました。
https://github.com/aws-samples/aurora-dsql-samples/tree/main/python/sqlalchemy
また、SQLAlchemy、Alembic のいずれも必要に応じて生 SQL の実行をサポートしている点も採用理由の一つでした。

大量データのフェッチとメモリ制限

十数万レコードを CSV 化する要件に対して、当初 LIMIT OFFSET 構文による分割取得を試みたところ、トランザクションあたりのワークメモリ上限 128 MiB の制約に抵触しました。LIMIT OFFSET の仕組み上、不要な OFFSET 分のデータもすべて取得してから最終的な結果を返すためです。

対処法: Primary Key として UUIDv7 や連番など一意で時系列なキーを採用しました。データ取得方法についても Keyset Pagination（WHERE 句で前回取得した ID 以降のデータを抽出）に切り替えることで解決可能です。

トランザクションサイズの制限

Aurora DSQL には、トランザクションブロックで変更できるテーブル行の最大数 3,000 件、書き込みトランザクションで変更されるデータの最大サイズ 10 MiB といった制限があります。

対処法: 設計段階からトランザクションサイズを意識し、処理を分割する方式を採用しました。後から気づくと手戻りが大きいため、設計初期にこの制約を織り込んでおくことをお勧めします。

列の変更対応

DSQL では DROP COLUMN、ALTER COLUMN、NOT NULL カラムの追加といった列定義の変更ができません。変更が必要な場合は、別テーブルを用意してデータを移行する対応が必要でした。

ローカル開発環境の整備

現時点では、Aurora DSQL の制約まで再現したローカルエミュレータは存在しません。PostgreSQL コンテナで代替すると、DSQL 固有の制約にローカルでは気づけないケースがありました。

対処法: 制約に抵触しやすい開発モジュールについては、ローカル環境から直接 DSQL に接続して開発する手法を取り入れました。

振り返って：AWS への早期相談は有効

私たちは自社開発のみで導入を完了しましたが、振り返ると、開発段階から AWS アカウントチームに相談していれば、DSQL 固有の制約やノウハウ（フェッチの取り方など）をより早く把握でき、改善要望も早期に提出できたと感じています。AWS 側でも DSQL の制約に関するナレッジを蓄積しており、開発段階から共有いただける体制があるとのことです。これから導入を検討される方には、開発の早い段階でのアカウントチームへの相談をお勧めします。

導入後の効果

コスト約 87% 削減

Aurora Serverless（コールドスタート回避のため最小 ACU を 0.5 に設定した場合）比で、約 87% のコスト削減を実現しました。多数の環境を運用するエンタープライズ案件では、利用しない環境にほとんど料金がかからない DSQL の料金体系により、環境数に比例したコスト増加を回避できています。稼働していなければ放置しても課金が発生しないため、開発環境の上げ下げを管理するバッチ処理やスクリプトも不要になりました。

運用工数ほぼゼロ

キャパシティ管理・パッチ適用が不要となり、DB 運用工数がほぼゼロになりました。他のシステムでは、開発環境の上げ下げのバッチ作成、インスタンスの容量拡張、コールドスタート回避のための ping 処理など、細かな運用タスクがどうしても発生します。DSQL ではこれらがすべて不要です。DB 周りの運用管理にリソースがほぼ発生しなくなり、チームは開発や上流工程のタスクに集中できるようになりました。

小規模なシステム、たとえば週に 1 回程度しか動かないようなワークロードでも、コールドスタートなしで即座に応答できる点は、運用の手間を大きく削減してくれています。

データ 10 倍拡大も設定変更・性能チューニングなし

データ量を約 10 倍（現在数十 GB 規模）に拡大した際も、DB 側の設定変更や性能チューニングは一切不要でした。DSQL 側には何も影響がなく、性能劣化も発生していません。今後もデータ格納量やバッチ利用時のスループットは拡大していく見込みですが、性能調査や性能試験に時間を取られることなく、DSQL の自動スケーリングで対応できる見通しです。

Multi-AZ 標準装備

デフォルトで Multi-AZ が担保されており、追加設定なしで AZ 障害耐性を確保できています。

総括すると、コストと運用負荷の削減が Aurora DSQL 導入の最大のメリットでした。環境数がかなり多い本システムでは、利用しない環境にほとんど料金がかからない DSQL の料金体系がマッチしていました。データ量を約 10 倍に拡大した際も、DB 周りは追加の設定変更なく対応できています。

最後に

データ格納量やバッチ利用時のスループットは今後も継続的に拡大していく見込みであり、Aurora DSQL の強みを引き続き有効活用していく方針です。また、三菱UFJフィナンシャル・グループ各社への AI 活用展開に向けて、Amazon Bedrock をはじめとする AWS の AI 関連サービスの拡充にも期待しています。

Aurora DSQL 自体に対しては、クエリログ（監査ログ）の実装や ALTER TABLE/COLUMN 対応による列定義変更の柔軟性向上を期待しています。

本記事が、Aurora DSQL の採用を検討されている方の一助になれば幸いです。

執筆者

佐藤 慎 Japan Digital Design 株式会社 Technology & Development Division テクニカルプロジェクトマネージャ Japan Digital Design 株式会社にて金融機関向けシステム・AI導入案件のプロジェクトマネージャを担当。 Amazon Aurora DSQLをはじめとするクラウドネイティブ技術を活用したプロダクトの本番導入に取り組んでいる。