【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だけで予測モデルを構築]