AWSでデータ分析基盤を構築するとき、最初の候補になりやすいのが「Amazon S3にデータを保存し、AWS Glue Data Catalogでテーブルを管理し、Amazon AthenaからSQLで分析する」構成です。
サーバーを常時稼働させず、小さく始められる一方、データ量やクエリ数、利用者が増えると処理速度やコストが課題になることもあります。本記事ではS3・Glue・Athenaを基準に、分析基盤の移行先となるRedshift Serverlessを比較します。RDS／AuroraとDynamoDBについては、分析基盤の候補ではなく、用途が異なるデータベースとして違いを整理します。
S3をデータの中心に残し、用途に応じて分析サービスと業務データベースを使い分けることが、無理のないAWS構成につながります。
先に結論：分析基盤ならAthenaかRedshiftを軸にする
| サービス | 主な用途 | 得意な処理 | 苦手な処理 |
|---|---|---|---|
| S3＋Glue＋Athena | データレイク、アドホック分析 | S3上の大量データを必要なときだけ分析 | 高頻度・低遅延のクエリ |
| Redshift Serverless | データウェアハウス、BI | 複雑な集計、結合、反復的な分析 | 単純なキー検索、OLTP |
| RDS／Aurora | 業務システムのDB | 更新、トランザクション、整合性 | 巨大な履歴データの全件集計 |
| DynamoDB | Webサービス、イベント処理 | キーを指定した高速な読み書き | 自由な検索、JOIN、全件分析 |
| OpenSearch Serverless | ログ分析、検索 | 全文検索、時系列ログの探索 | 厳密なリレーショナル処理 |
この記事で分析基盤の選択肢として扱うのは、AthenaとRedshift Serverlessです。比較表にRDS／AuroraとDynamoDBも載せていますが、同じ候補として並べているわけではありません。両者は、分析元となる業務データを保存するデータベースです。
AWSの分析基盤は本当に2択なのか
厳密には、AthenaとRedshiftだけではありません。AWSは、SQLクエリサービスのAthena、データウェアハウスのRedshift、分散処理フレームワークを動かすAmazon EMRを、異なる用途のサービスとして案内しています。
- Athena：S3上のデータへ、必要なときにアドホックなSQLを実行したい
- Redshift Serverless：多数のテーブルを結合し、BIや定型レポートを安定して動かしたい
- EMR Serverless：Apache SparkやHiveを使い、SQLだけでは表現しにくい大規模な変換や分散処理を行いたい
- OpenSearch Serverless：ログや全文を短時間で検索したい
そのため「AWSの分析基盤は必ず2択」と言い切るのは正確ではありません。ただし、S3に蓄積したデータをSQLで分析する今回の条件なら、まずAthenaを改善するか、Redshift Serverlessへ広げるかを比較するのが自然です。EMR ServerlessはSpark処理が必要になった段階で検討します。
参考：AWS公式「When should I use Athena?」、AWS公式「What is Amazon EMR Serverless?」
列指向と行指向の違いを知る
Athena、Redshift、RDSの違いを理解するには、データを「列単位で読むか」「行単位で読むか」という視点が役立ちます。これは単なる保存形式の違いではなく、どの処理を速くしたいかという設計思想の違いです。
行指向は1件の読み書きに向いている
行指向では、1件のレコードを構成する値をまとめて保存します。たとえば注文番号、顧客ID、商品名、金額、注文日時を一つの注文として扱います。注文を1件登録する、顧客情報を1件更新する、といった処理では必要な値が近くにあるため効率的です。
MySQLやPostgreSQLを利用するRDS／Auroraは、このようなトランザクション処理を得意とします。一方、「過去3年分の全注文から、月別の売上金額だけを集計する」といった処理では、多数の行を読み取ります。分析用の重いSQLを業務DBへ直接実行すると、通常の注文処理まで遅くなる可能性があります。
列指向は大量データの集計に向いている
列指向では、同じ列の値をまとめて保存します。月別売上を計算するときは、注文日時と金額の列を中心に読み、商品説明や配送先などの不要な列を読み飛ばせます。同じ型の値が並ぶため、圧縮しやすいことも特徴です。
Redshiftは列指向のデータウェアハウスです。Athenaでよく利用するParquetやORCも列指向のファイル形式です。大量の履歴から一部の列を使ってSUM、COUNT、AVGなどを計算する処理に向いています。
| 比較項目 | 行指向 | 列指向 |
|---|---|---|
| 代表例 | RDS／AuroraのMySQL・PostgreSQL | Redshift、Parquet／ORCを読むAthena |
| 得意な処理 | 1件の追加・更新・検索 | 大量データの集計・分析 |
| 具体例 | 注文の登録、会員情報の更新 | 月別売上、行動ログの傾向分析 |
| 読み方 | 必要な行をまとめて読む | 必要な列をまとめて読む |
どちらかが常に優れているわけではありません。注文を受け付けるRDSと、注文履歴を分析するAthenaまたはRedshiftを分けると、それぞれが得意な処理に集中できます。ここでも、S3をデータの中心に残し、用途に応じて分析サービスと業務データベースを使い分けるという考え方が重要です。
現在の構成：S3＋Glue Data Catalog＋Athena
この構成では、CSV、JSON、ParquetなどのファイルをS3へ保存し、Glue Data Catalogにスキーマを登録します。AthenaはGlueに登録されたテーブル定義を参照し、S3上のデータへSQLを実行します。
メリット
- 分析用サーバーを管理しなくてよい
- クエリを実行するときだけ計算資源を利用できる
- S3に大量の履歴データを低コストで保管できる
- S3に置いたデータを移動せずにSQLで分析できる
- 形式の異なる生データを残しながら段階的に整備できる
デメリット
- ファイル構成が悪いと速度と料金の両方に影響する
- 小さなファイルが大量にあると非効率になりやすい
- 高頻度のダッシュボードでは応答時間が安定しにくい
- RDBのようなレコード単位の更新や削除は得意ではない
- パーティションやデータ形式の設計が必要になる
Athenaでは、読み取るデータ量を減らすことが重要です。日付などでパーティションを分け、WHERE句で対象を限定すると、処理時間とコストを抑えられます。また、CSVよりもParquetなどの列指向形式へ変換すると、必要な列だけを効率よく読み取れます。
選択肢1：Amazon Redshift Serverless
Amazon Redshift Serverlessは、クラスターのノードを事前に用意せずに利用できるデータウェアハウスです。負荷に応じて分析用キャパシティーが調整され、利用したキャパシティーに応じて課金されます。S3からデータをロードするほか、S3のデータレイクを参照する構成も可能です。
メリット
- 大規模な集計やテーブル結合に強い
- BIツールから繰り返しクエリする用途に向いている
- Athenaより応答時間を安定させやすい
- 複雑な分析SQLやデータマートを集約できる
- JDBC、ODBC、Data APIなどで接続できる
デメリット
- Athenaより設定と運用が複雑になる
- 小規模または低頻度な利用では割高になる可能性がある
- データのロードや変換処理を設計する必要がある
- 性能を引き出すにはテーブルとクエリの設計知識が必要
- 一般的な業務用RDBの代わりにはならない
同じ集計を何度も実行する、BIの表示が遅い、多数の利用者が同時接続する、大きなテーブル同士を頻繁に結合する、といった状況ではRedshift Serverlessが有力です。「たまに大量データを調べる」ならAthena、「多くの人が繰り返し分析する」ならRedshiftが一つの目安です。
比較のために知っておきたいRDS／Aurora
Amazon RDSやAuroraは、注文、顧客、在庫などの業務データを記録するOLTP処理に適しています。分析データベースの候補ではなく、トランザクションを使って業務データを正確に更新するためのデータベースです。
- メリット：SQL、JOIN、トランザクションを利用でき、レコード単位の追加・更新・削除が容易
- デメリット：大量データの全件集計は業務処理に影響しやすく、長期ログの蓄積ではストレージやインデックスが肥大化する
Aurora Serverless v2は負荷に応じてコンピューティング容量を自動調整しますが、サーバーレスだからデータウェアハウスになるわけではありません。最新の業務データをAuroraに保存し、履歴をS3へ連携してAthenaやRedshiftで分析する役割分担が適しています。
比較のために知っておきたいAmazon DynamoDB
DynamoDBは、主キーを使った高速な読み書きと大量アクセスへのスケーリングを得意とするサーバーレスなNoSQLデータベースです。分析データベースとして選ぶサービスではありません。
- メリット：DBインスタンスの管理が不要で、大量のリクエストを低遅延で処理できる。LambdaやDynamoDB Streamsを使ったイベント駆動構成とも相性がよい
- デメリット：JOINを前提にできず、アクセスパターンを先に決めてキーを設計する必要がある。自由な条件での検索や全件集計には向かない
DynamoDBのScanはテーブルまたはインデックス内の全項目を読み取るため、大規模分析に多用すべきではありません。DynamoDBにアプリケーションデータを保存し、必要なデータをS3へ連携して分析する構成が適しています。
ログ検索が目的ならOpenSearch Serverless
アクセスログ、アプリケーションログ、セキュリティログを検索したい場合はOpenSearch Serverlessも候補です。全文検索や時系列ログの探索に強く、キーワード、属性、時間範囲から対話的にログを掘り下げられます。一方、S3だけに保存する構成より費用が高くなりやすく、データ取り込みの仕組みも必要です。
現在のAthena構成を改善する5つのポイント
- CSVやJSONをParquetへ変換する：列指向形式と圧縮によって、スキャン量と保存容量を抑える
- 日付などでパーティションを分ける：検索対象のファイルだけを読み取れるようにする
- 小さなファイルをまとめる：大量の小規模ファイルによるオーバーヘッドを減らす
- raw、cleaned、curatedを分離する：生データ、整形済みデータ、分析用データの役割を明確にする
- 高頻度な集計だけ別サービスへ移す：BIや反復的な集計だけをRedshift Serverlessへ移す
おすすめの構成
業務システム
├─ RDS／Aurora
└─ DynamoDB
↓ データ連携・変換
Amazon S3
├─ raw
├─ cleaned
└─ curated
↓
Glue Data Catalog
↓
├─ Athena：調査、低頻度の分析
└─ Redshift Serverless：BI、高頻度・複雑な分析
最初からすべてのサービスを導入する必要はありません。S3をデータの中心に残し、Athenaで不足が生じた部分だけをRedshift Serverlessへ移す段階的な構成が現実的です。
まとめ
S3＋Glue Data Catalog＋Athenaは、低頻度な分析やデータレイクの入口として優れた構成です。Parquet化、パーティション設計、ファイルサイズの適正化を行えば、かなりの規模まで対応できます。
分析基盤として比較するのはAthenaとRedshift Serverlessです。クエリ頻度、同時利用者、結合処理、BIダッシュボードが増えた場合はRedshift Serverlessを検討します。RDS／AuroraとDynamoDBは分析元となる業務データを保持し、必要なデータをS3へ連携する役割です。
S3をデータの中心に残し、用途に応じて分析サービスと業務データベースを使い分けることが、無理のないAWS構成につながります。そのうえで、必要な応答時間、更新頻度、同時利用者数、コストを見ながらAthena、Redshift、RDS、DynamoDBを組み合わせましょう。
コメント