Amazon Athenaで実現する時系列データのパフォーマンス改善

ツール導入前の課題

FULL KAITENでは、ユーザーが売上・粗利・在庫などの指標を日別・週別・月別に可視化できる「マイチャート」機能を提供しています。これは、KPIの定点観測や探索的な分析を行うためのツールであり、BIツールに近い位置づけです。 しかし、この機能には以下のような課題がありました：

• 日次でのデータ再投入によるAuroraへの書き込み負荷の増加
• 大量データに対するクエリ応答の遅延
• 高頻度の読み書きによるI/Oコストの増大

マイチャートでは、さまざまな軸で柔軟な集計ができるように、非常に細かい粒度のデータを保持しておく必要があり、その結果、データ量の肥大化によりパフォーマンスが著しく劣化するという問題が顕在化していました。

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

この状況を改善すべく、我々が目指したのは以下のような状態です。

• データ量が多くても一定時間でレスポンスが返ってくる構成
• AuroraなどRDBへの過度な負荷を軽減し、I/Oコストと可用性の課題を解消
• バッチ処理を経由して、毎日一度データマートを安定的に更新できる仕組み

• Amazon Aurora (PostgreSQL) の継続利用

最終的にAthena + S3を選定した主な理由は以下のとおりです。

• Auroraよりも大規模データでの応答性能が安定していたこと
• S3への出力が既存のデータ基盤（Glue等）と親和性が高く、移行コストが低かったこと
• 日次の更新であればAthenaで十分なコスト・性能バランスが得られたこと

パーティション設計の工夫がパフォーマンスに直結

Athena を効果的に活用するためには、適切なパーティション設計によってスキャン対象を最小限に抑えることが非常に重要です。

たとえば、売上データが 1 億件ある場合でも、S3 上でデータを date=2025-04-01/, date=2025-04-02/, ... といった形で日付ごとにパーティション分割して保存することで、クエリ実行時にスキャン対象を絞り込むことができ、レスポンスの高速化につながります。

S3 ディレクトリ構成例:
└── date=2025-04-01/
    └── xx.parquet（15万件）
└── date=2025-04-02/
    └── xx.parquet（8万件）
└── date=2025-04-03/
    └── xx.parquet（20万件）

クエリ応答時間の大幅な改善

Athenaへの移行によって、データ量の多いアカウントでも常に安定した高速レスポンスが得られるようになりました。

実際に、従来Aurora（PostgreSQL / db.r6g.4xlarge）で処理していたKPI集計クエリを、Athena上で実行した際のレスポンス時間を比較したところ、以下のような改善が確認できました：

• Auroraでは、1,000万件未満のデータであれば非常に高速に応答しますが、それ以上になるとデータ量にほぼ比例する形でレスポンス時間が増加し、5,000万件のクエリでは20秒以上かかるケースも発生していました。
• 一方Athenaでは、レコード数が増加してもレスポンス時間の上昇が緩やかで、5,000万件規模でも平均3〜4秒台の応答時間を安定して維持しています。

Aurora側もサーバレス化しさらなるコスト最適化へ

Athena移行後、Auroraへの書き込み量が大幅に削減されました。これにより以前は日次の書き込みによりI/O量が多く、プロビジョニング構成でなければ逆にコストが高くなる状況でしたが、書き込み負荷が軽減されたことでサーバレス構成でも十分に対応可能となり、コスト最適化となりました。

Athenaは、主にS3上に蓄積されたデータマートやログデータに対してクエリを実行する構成を前提としたアーキテクチャです。そのため、即時反映が求められるリアルタイム処理には適していません。

一方で、業務用の分析ツールや定期バッチ処理のように、ある程度の再実行が許容されるユースケースでは、コスト効率や運用の簡便さに優れた非常に有効な選択肢だと考えています。