エブリーが、Aurora DSQL の採用でデータベースコストを 90% 以上削減とメンテナンス運用からの解放も実現

株式会社エブリーは、「前向きなきっかけを、ひとりひとりの日常にとどける。」というミッションのもと、デリッシュキッチン、retail HUB、トモニテ、MOMENTH といった BtoC・BtoB を横断するメディアやサービスを展開しています。同社では、小売事業者向けサービス retail HUB におけるピッキングサービスの新規開発にあたり、データベースとして Amazon Aurora DSQL を採用しました。本ブログでは、お客様の開発チームに伺った Aurora DSQL 採用の背景、導入の取り組み、そして導入後に得られた効果についてご紹介します。

対象システム

今回 Aurora DSQL を採用したのは、retail HUB 事業のネットスーパーサービスにおけるピッキングサービスです。

retail HUB は、お客様が提供する小売事業者向けの DX ソリューションです。店頭サイネージによるレシピ提案、デジタルチラシ、ネットスーパーアプリの提供、店頭運営の効率化、CRM によるロイヤルカスタマー育成まで、小売事業者の販促プロセス全体をデジタル化し、業務効率化ときめ細やかな顧客アプローチを実現しています。

retail HUB 事業のネットスーパーサービスでは、店舗側が売り場から注文商品をピックアップする作業が発生しますが、従来この運用は紙のリストで行われており、商品を探すのに時間がかかることや習熟度による作業スピードのばらつきなどにより人的ミスの防止が難しく、誤ピックによる取り直しが発生するといった課題がありました。この問題を解決するため、ピッキングアプリ「retail HUB Picker」の開発が求められました。

アーキテクチャ

ピッキングサービスのアーキテクチャは、ピッキングアプリ（Android アプリ）から Amazon ECS + ALB で構成された API サーバーに接続し、担当者の認証管理には Amazon Cognito を利用しています。バックエンドのデータベースとして Aurora DSQL を採用し、ピッキング対象の商品情報やピッキング状態、担当者情報の格納・参照に使用しています。

ピッキングサービスのシステムアーキテクチャは以下のとおりです。今回新規に開発したピッキングシステムは既存のネットスーパーシステムとは分離しており、注文データを連携する箇所のみで結合しています。

データベース選定の背景

今回のピッキングサービスは新規開発であり、データベースの選定にあたってはシステムの特性に合わせた検討が行われました。データベースに求められる要件は以下でした。

安定性と可用性

ピッキング作業中にシステムが停止すると店舗のピッキング業務に影響を与え、導入店舗数が増えるほどその影響範囲も大きくなるため、安定性と高い可用性が重要な要件でした。また、小売店舗は土日も稼働しているため、運営側の都合でメンテナンス時間を設定しにくいというビジネス上の課題も考慮する必要がありました。

低コストによるスモールスタート

初期フェーズではリクエスト数が限定的であり、構築・運用にあまりコストをかけたくないという要望がありました。一方で、今後サービスの成長に伴いトラフィックの増加も想定されるため、高いスケーラビリティを備えたデータベースであることが望ましいと考えていました。

運用負荷の軽減

メンテナンスウィンドウに伴う運用負荷が課題となっていました。新規サービスでは、こうした運用負荷を極力下げたいという考えがありました。

Aurora DSQL を選択した理由

お客様では当初、既存システムで利用している Amazon RDS for MySQL や Amazon Aurora MySQL の導入を想定していました。しかし、上記の要件を踏まえて検討を進めた結果、サーバーレスの分散データベースである Aurora DSQL が採用されました。その理由は以下の通りです。

• 安定性と可用性 — シングルリージョン構成で 99.99%（マルチリージョン構成では 99.999%）の可用性を備えたサーバーレスの分散データベースであり、インフラ管理が不要。ピッキング作業中のシステム停止リスクを低く抑えられる
• 低コストによるスモールスタート — 従量制の課金モデルで初期コストを抑えつつ、将来のサービス成長に伴うトラフィック増加にも自動スケールで対応できる
• 運用負荷の軽減 — パッチ適用がダウンタイムなしで自動的に行われるため、関係者との調整や作業工数が不要になる

加えて、Aurora DSQL が PostgreSQL との互換性を備えていたことで、社内の既存知見を活かしながら導入できる点も後押しとなりました。また、お客様の開発チームには分散データベースへの技術的な関心が高く、Aurora DSQL を通じて得られる知見が今後の技術選定の指標になるという期待も大きく、採用の決め手の一つとなりました。

Aurora DSQL とは

Aurora DSQL は、AWS が提供するサーバーレスの分散 SQL データベースです。従来のデータベースのようにクエリ処理・ストレージ・トランザクション管理が密結合した構成ではなく、それぞれが独立したコンポーネントに分かれています。各コンポーネントがワークロードに応じて個別にスケールするため、特定の処理がボトルネックになりにくく、低レイテンシーで強固な一貫性を実現しています。また、PostgreSQL との互換性を備えており、既存の PostgreSQL の知見やツールを活かして開発を進めることができます。

お客様が選定の理由に挙げた以下の 3 つについて、Aurora DSQL の特性を簡単に説明します。

安定性と可用性

Aurora DSQL では、すべての書き込みトランザクションを分散トランザクションログにコミットし、コミットされたすべてのログデータを 3 つのアベイラビリティーゾーンにあるストレージレプリカに同期レプリケーションします。これにより、Aurora の Multi-AZ 構成と同等の 99.99% の可用性を実現しています。以下の図は、Aurora DSQL の可用性に関する特性を示しています。

低コストによるスモールスタート

課金はリクエスト数やデータ量に応じた従量制で、リクエスト数が少ない段階ではコストを低く抑えられます。アーキテクチャを変更することなく自動的にスケールするため、小規模な構成から始めて、トラフィックの増加に応じてシームレスにスケールすることができます。以下の図は、Aurora DSQL のコストモデルを示しています。

運用負荷の軽減

サーバーのプロビジョニングやパッチ適用、インフラのアップグレードといった管理作業が不要です。パッチ適用やセキュリティアップデートはダウンタイムなしで自動的に処理されるため、メンテナンスウィンドウの調整や計画停止が不要です。以下の図は、Aurora DSQL と従来のデータベースにおけるメンテナンスの違いを示しています。

開発時の課題

開発スケジュール

開発スケジュールは以下のとおりです。

Aurora DSQL を用いた開発にあたっては、PostgreSQL との互換性に関していくつかの課題がありました。

スキーマ変更の制約

Aurora DSQL ではカラム追加時にデフォルト値を指定する構文がサポートされていないことが開発中に判明しました。PostgreSQL では一般的に使用される構文であるため、既存の知見をそのまま適用できないケースでした。対処として、カラムのみを追加し、デフォルト値や NOT NULL 制約はソフトウェアレベルで保証する実装としました。なお、サービスリリース前であったため、最終的にはテーブルを再作成することで問題を回避しました。このように、事前のドキュメント確認だけでは把握しきれず、実際の操作を通じて発見される差分もありました。

ローカル開発環境との互換性

当初ローカル開発では PostgreSQL のコンテナを使用していましたが、CREATE INDEX を CREATE INDEX ASYNC に変更する必要があるなど、Aurora DSQL との互換性がない部分が判明したため、ローカル環境でも Aurora DSQL を使用する方式に切り替えました。

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

Aurora DSQL にはトランザクションデータ件数に制限があるため、大量のデータを一括で処理する実装には工夫が必要でした。この制限を回避するため、大量のデータ投入処理においては全体を 1 トランザクションにまとめず、処理を分割する設計としました。具体的には、データ量が大きい投入処理ではトランザクションを使わずに実行し、途中でエラーが発生しても何度でもやり直せる設計としました。その上で、整合性の担保が必要な少量のデータ更新処理だけをトランザクション内で実行するようにしました。

こうした課題を一つずつ解消しながら開発を進め、ピッキングサービスは無事にローンチを迎えました。

ローンチと導入後の効果

2025 年 9 月中旬にローンチしてから数ヶ月が経過していますが、大きな問題は発生しておらず、安定した稼働を続けています。

導入後に得られた効果は以下のとおりです。

コスト削減

Aurora PostgreSQL（Provisioned）で想定していたインスタンスサイズと比較すると、コストは 90% 以上低くなっています。従量制のコストモデルにより、初期フェーズにおいて大幅なコスト削減を実現しました。

以下は、今回のワークロードを想定したコスト比較の試算です。Aurora PostgreSQL（Provisioned）を 100 とした場合の相対コストを示しています。

安定稼働とメンテナンスフリー

サービス導入後は安定して稼働しており、パフォーマンス上の問題も発生していません。メンテナンスウィンドウが不要であるため、基盤のメンテナンス作業そのものだけでなく、それに伴う小売事業者やサービス利用者との調整業務も不要となりました。既存システムでは 3 ヶ月ごとのパッチアップデートのたびに、メンテナンス時間帯の調整、影響範囲の洗い出し、小売事業者や関係部署への連携が必要でしたが、Aurora DSQL ではこうした業務コストがゼロになり、運用負荷が大きく削減されました。

スケーラビリティの確保

現時点でのリクエスト数の変動については特に大きな問題は発生していません。今後のサービス成長に伴うトラフィック増加についても、検証の結果スケーリングに問題がないことを確認しており、今後のトラフィック増加にも不安なく運用できる見通しです。

お客様の声

お客様に Aurora DSQL の導入効果について伺ったところ、次のように述べています。

スケーラビリティと安定性の要件が高いシステムにおいて Aurora DSQL を選択する利点は高いと考えています。

– 内原 章 氏　株式会社エブリー 開発本部 開発2部 部長

今後の展望

お客様では、今回のピッキングサービスでの導入実績を踏まえ、スケーラビリティの要件が高いシステムにおいて Aurora DSQL を選択肢として検討していく方針です。新規開発だけでなく、既存システムのリプレースにおいても Aurora DSQL の活用を視野に入れています。

また、Aurora DSQL のさらなる進化への期待として、PostgreSQL との互換性向上を挙げています。特に RLS（Row Level Security）のような機能がサポートされることで、より幅広いユースケースに対応しやすくなると考えています。

Aurora DSQL は、高い可用性とスケーラビリティを必要とするシステムにおいて、運用負荷とコストの低減が期待できるデータベースです。本ブログが、同様の課題を持つお客様にとって参考になれば幸いです。