【AWS経験者向け】RedshiftとBigQuery：データウェアハウスのアーキテクチャと料金体系
はじめに：データウェアハウスの比較、再び
皆さん、こんにちは！「30日間でGCPをマスターするAWSエンジニアの挑戦」シリーズ、15日目へようこそ。
AWSでのデータ分析において、Amazon Redshiftは代表的なデータウェアハウスサービスです。ペタバイト規模のデータを効率的に分析できるその性能は、多くのデータアナリストやデータエンジニアに愛用されてきました。
GCPには、これに対応するサービスとしてBigQueryがあります。しかし、BigQueryはRedshiftとは全く異なる、サーバーレスというユニークな設計思想を持っています。Redshiftに慣れたエンジニアがBigQueryを触ると、「クラスターの概念がない？」「クエリを投げた分だけ課金される？」といった違いに戸惑うことがあります。
この記事では、AWS Redshiftの知識を前提に、GCP BigQueryの以下のポイントを徹底的に比較し、理解を深めていきます。
- アーキテクチャ：クラスターベース vs サーバーレス
- 料金体系：時間課金 vs 処理データ量課金
- パフォーマンス特性：スケーリング方式とレスポンス時間の違い
- 実践ハンズオン：BigQueryのクエリのシンプルさを体験
この記事を読めば、GCPでのデータ分析基盤の設計が明確になり、よりコスト効率の高いシステムを構築できるようになります。
アーキテクチャの比較：クラスター vs サーバーレス
RedshiftとBigQueryの最も大きな違いは、そのアーキテクチャです。
AWS Redshift：クラスターベースのアーキテクチャ
Redshiftは、複数のノードで構成されるクラスターをプロビジョニングして利用する、MPP（Massively Parallel Processing）アーキテクチャです。
特徴：
-
コンピュートとストレージの関係性:
- dc2/ds2インスタンス: コンピュートとストレージが密結合（従来型）
- ra3インスタンス: コンピュートとストレージが分離（S3ベース）
- ノードの管理: ユーザーは、クラスターのサイズ（ノード数）やインスタンスタイプを事前に決定する必要があります
-
スケーリング:
- 垂直スケーリング: インスタンスタイプの変更（ダウンタイムあり）
- 水平スケーリング: ノード数の追加/削除（リバランス処理が必要）
- Redshift Serverless: 2022年に導入されたサーバーレスオプション
メリット：
- 予測可能なパフォーマンス
- 専用リソースによる安定した実行時間
- 複雑なETL処理に適している
デメリット：
- リソースの事前プロビジョニングが必要
- 使用しない間も課金が継続
- スケーリングの手間とコスト
GCP BigQuery：サーバーレスなアーキテクチャ
BigQueryは、計算リソース（コンピュート）とストレージが完全に分離された、フルマネージドのサーバーレスデータウェアハウスです。
特徴：
- コンピュートとストレージの完全分離: データを保存するColumnar Storageと、クエリを実行するDremelエンジンが独立
- 真のサーバーレス: ユーザーはサーバーやクラスターを一切意識不要。データを入れるだけで即座に分析可能
-
動的スケーリング:
- Slot（処理単位）の自動割り当て: クエリの複雑さとデータ量に応じて自動調整
- 並列処理の最適化: 数千のワーカーノードによる大規模並列実行
- リソース使用量の最適化: 複数ユーザー間でのリソース効率的共有
メリット：
- インフラ管理不要
- 瞬間的なスケーリング
- 使った分だけの課金
- メンテナンス作業が不要
デメリット：
- クエリ実行時のパフォーマンスが予測しにくい場合がある
- 大量の継続的なクエリ実行では高コストになる可能性
料金体系の比較：固定費 vs 従量課金
両者の料金体系は、アーキテクチャの違いを反映しています。
| 項目 | AWS Redshift | GCP BigQuery |
|---|---|---|
| コンピュート料金 |
時間単位で課金 （クラスター稼働時間） 例：ra3.xlplus = $3.26/時間 |
処理データ量単位で課金 オンデマンド： ＄6.25/TB フラットレート：$2,000~/月（100スロット） |
| ストレージ料金 | ＄0.024/GB/月（ra3） ＄0.085/GB/月（dc2/ds2） |
アクティブ: $0.023/GB/月 長期保存: $0.016/GB/月（90日以上未更新） |
| データ転送料金 | AWS内は無料、外部への転送は有料 | GCP内は無料、外部への転送は有料 |
| 最適なユースケース | 継続的なワークロード 予測可能な利用パターン |
バースト的なワークロード アドホック分析 |
コスト比較シナリオ：
-
月1TB、100クエリの分析ワークロード
- Redshift: 約＄2,350（ra3.xlplus 24時間×30日）
- BigQuery: 約＄650（1TB×100クエリ×$6.25/TB）
-
月10TB、1000クエリの分析ワークロード
- Redshift: 約＄4,700（ra3.4xlarge）
- BigQuery: 約＄6,500（10TB×1000クエリ×$6.25/TB）
パフォーマンス特性の比較
| 特性 | AWS Redshift | GCP BigQuery |
|---|---|---|
| 初回クエリ実行 | 高速（専用リソース） | やや時間がかかる場合あり（コールドスタート） |
| 継続的クエリ | 安定したパフォーマンス | スロット競合により変動の可能性 |
| 大量データ処理 | ノード数に依存 | 自動で大規模並列処理 |
| キャッシュ機能 | Result caching | Intelligent caching（24時間） |
実践ハンズオン：BigQueryでクエリを実行する
BigQueryのサーバーレスな体験と、処理データ量課金がどのように機能するのかを実際に見てみましょう。
Step 1: BigQueryコンソールにアクセス
- GCPコンソールで「BigQuery」を検索し、BigQuery Studioを開きます
- 左側のナビゲーションで、プロジェクトが選択されていることを確認
Step 2: 公開データセットの追加
- 「データを追加」→「公開データセットを探索」を選択
- 検索窓で
stackoverflowと入力し、bigquery-public-data.stackoverflowを追加
Step 3: データ探索クエリの実行
クエリ1: データ量の確認
SELECT
COUNT(*) as total_posts,
COUNTIF(post_type_id = 1) as questions,
COUNTIF(post_type_id = 2) as answers
FROM `bigquery-public-data.stackoverflow.posts_questions`
WHERE creation_date >= '2023-01-01'
クエリ2: 人気タグの分析
SELECT
tag,
COUNT(*) as question_count,
AVG(score) as avg_score
FROM `bigquery-public-data.stackoverflow.posts_questions`,
UNNEST(SPLIT(tags, '|')) as tag
WHERE creation_date >= '2023-01-01'
AND tag IN ('python', 'javascript', 'java', 'go', 'rust')
GROUP BY tag
ORDER BY question_count DESC
Step 4: クエリコストの確認
- 各クエリ実行前に、右下の「このクエリは約 XXX GBを処理します」を確認
- 実際の処理データ量 × $6.25/TB で概算コストを計算
Step 5: クエリ最適化の体験
-- 非効率なクエリ（全カラムスキャン）
SELECT * FROM `bigquery-public-data.stackoverflow.posts_questions` LIMIT 10;
-- 効率的なクエリ（必要カラムのみ指定）
SELECT id, title, score, creation_date
FROM `bigquery-public-data.stackoverflow.posts_questions`
LIMIT 10;
処理データ量の違いを比較し、カラム指定がコストに与える影響を確認してみてください。
まとめ：RedshiftとBigQuery、選択のポイント
| 観点 | AWS Redshift | GCP BigQuery |
|---|---|---|
| アーキテクチャ | クラスターベース（MPP） | サーバーレス |
| 料金体系 | 時間課金 | 処理データ量課金 |
| スケーリング | 手動スケーリング（Serverless除く） | 自動スケーリング |
| 運用負荷 | クラスター管理が必要 | 運用負荷ほぼゼロ |
| 適用シーン | 継続的・予測可能なワークロード | アドホック分析・バースト的ワークロード |
選択指針：
Redshiftを選ぶべき場合：
- 既存のAWSエコシステムとの密な連携が必要
- 継続的で予測可能なワークロード
- レスポンス時間の一貫性が重要
- 複雑なETL処理が中心
BigQueryを選ぶべき場合：
- 運用コストを最小化したい
- アドホック分析やデータ探索が中心
- 急激なデータ量増加に対応したい
- 分析チームのセルフサービス化を進めたい
次回予告
次回は、BigQueryの真の力を体験します。機械学習機能（BigQuery ML）を使って、SQLだけで予測モデルを構築する方法を実践してみましょう。Redshiftでは実現が困難な、BigQuery独自の価値を実感していただけるはずです。
この記事が役に立ったという方は、ぜひ「いいね」や「ストック」をお願いします！
シリーズ記事一覧
- [【1日目】はじめの一歩！AWSエンジニアがGCPで最初にやるべきこと]
- [【2日目】GCPのIAMはAWSとどう違う？「プリンシパル」と「ロール」の理解]
- [【3日目】VPCとVPCネットワーク：GCPのネットワーク設計思想を理解する]
- [【4日目】S3とCloud Storage：オブジェクトストレージを徹底比較]
- [【5日目】RDSとCloud SQL：マネージドデータベースの運用管理の違い]
- [【6日目】EC2とCompute Engine：インスタンスの起動から課金モデルまで]
- [【7日目】1週間のまとめ：AWSとGCP、それぞれの得意なことと設計思想]
- [【8日目】EKSとGKE：Kubernetesのマネージドサービスを比較体験！]
- [【9日目】Dockerイメージをどこに置く？ECRとArtifact Registryを比較]
- [【10日目】LambdaとCloud Functions：イベント駆動型サーバーレスの実装]
- [【11日目】API GatewayとCloud Endpoints：API公開のベストプラクティス]
- [【12日目】Cloud Run：サーバーレスでコンテナを動かすGCPの独自サービスを試してみよう]
- [【13日目】AWS FargateとCloud Run：コンテナ運用モデルの根本的な違い]
- [【14日目】2週間のまとめ：GCPのコンテナ・サーバーレス技術はなぜ優れているのか？]
- [【15日目】RedshiftとBigQuery：データウェアハウスのアーキテクチャと料金体系]（この記事）
- [【16日目】BigQueryをハンズオン！機械学習機能でSQLだけで予測モデルを構築]