2025.09.09 コラム
【テックコラム】Amazon RedshiftからBigQueryへの安全なデータ移行
はじめに
こんにちは、笹沼です。
今回は、社内のセキュリティポリシー上、AWSアクセスキーの発行が許可されないという状況下で、Amazon RedshiftからGoogle BigQueryへデータを安全に移行した経験についてお話しします。
Storage Transfer Service (STS) を活用しましたので、具体的な手順とともに紹介します。
移行パスの選定：BigQuery Data Transfer Service (BQ DTS) はなぜ使えないのか？
Google Cloudは、RedshiftからBigQueryへのデータ移行を支援する多様なサービスを提供しています。
Redshiftからのデータ移行サービス概要
- BigQuery Data Transfer Service (BQ DTS) ：Redshiftからの自動バッチ転送を可能にするフルマネージドサービスです。一般的な選択肢ですが、転送にAWSアクセスキーが必須となります。Redshiftへのコネクタが存在するためアクセスキー不要と思われがちですが、データは一旦中間ストレージとしてS3を経由するため、S3接続にアクセスキーが必要になります。
- Storage Transfer Service (STS) ：Amazon S3からCloud Storageへのデータ転送に特化したフルマネージドサービスです。大規模データセットを迅速かつ確実に転送できます。RedshiftからS3へのデータ抽出後のステップとして有効です。
- BigQuery Omni ：BigQueryのクエリエンジンを他のクラウド上で実行するマルチクラウド分析ソリューションです。データを物理的にBigQueryに移動させることなく、AWS S3などに格納されたデータを直接分析できます。今回の「データの物理的な複製と永続的なBigQueryストレージへの格納」という要件には直接的な移行ツールとは見なされませんでした。
- カスタムパイプライン ：
gcloudやbqコマンド、クライアントライブラリ、あるいはCloud Composer（Apache Airflow）やDataflow、Cloud Data Fusionなどのサービスを組み合わせて構築するアプローチです。高い柔軟性を提供しますが、実装コストが発生します。
今回の移行におけるサービス選定
上記の選択肢の中から、今回の「AWSアクセスキーを使わない」 という制約をクリアするため、「Redshift → S3 → Cloud Storage」という経路を選択し、S3からCloud StorageへのデータコピーにStorage Transfer Serviceを利用することにしました。
静的なアクセスキーが抱えるリスクとフェデレーション連携の仕組み
従来のクラウド間連携では、AWSアクセスキーIDとシークレットアクセスキーを使用するのが一般的でした。しかし、これらの静的な認証情報は、漏洩や不正利用のリスク、および定期的なローテーションといった管理負荷を伴います。
AWS自身も、長期間有効なアクセスキーの代わりに、一時的な認証情報を使用するIAMロールを推奨しています。
フェデレーション連携による一時的な認証情報利用
今回の移行で鍵となるのが、Storage Transfer Serviceが採用するフェデレーション連携です。これは、AWSの AssumeRoleWithWebIdentity という機能を利用する仕組みです。
簡単に言うと、GCPのサービスアカウントが発行するIDトークンを、AWS Security Token Service (STS) が一時的なAWS認証情報（アクセストークン）と交換するというプロセスです。これにより、静的なAWS認証情報を使用することなく、AWSリソースに安全にアクセスできます。
この信頼関係を一度構築してしまえば、鍵の生成やローテーション、失効といった管理作業から解放され、セキュリティを大幅に向上させることができます。
データ移行のステップバイステップ
それでは、具体的な移行手順を見ていきます。
1. 事前準備
Redshiftはすでに構築済みであることを前提とします。準備する内容は以下の通りです。
- S3バケットの作成: RedshiftのUNLOADデータの抽出先となる中間ストレージです。
- Redshift用IAMロールの作成: UNLOADコマンド実行権限を持たせ、Redshiftクラスターにアタッチします。
- STS用IAMロールの作成: Storage Transfer Serviceからのアクセスを許可するIAMロールを作成します。これには、後述する
subjectIDとのフェデレーション連携設定が含まれます。
2. RedshiftからS3へのデータ抽出
RedshiftのデータをS3に抽出するには、UNLOADコマンドを使用します。今回はParquet形式を採用し、パーティション分割を行いました。
UNLOAD ('SELECT * FROM your_table')
TO 's3://your-bucket/your-path/'
IAM_ROLE 'arn:aws:iam::account-id:role/your-redshift-role'
PARTITION BY (dt)
FORMAT AS PARQUET
ALLOWOVERWRITE
;
-- S3出力のイメージ
-- s3://your-bucket/your-path/dt=yyyy-mm-dd/part-00000.parquet
UNLOADコマンドの ALLOWOVERWRITE オプションは、同じパスへの出力ファイルを上書きする際に便利です。差分連携を考慮して、日付ごとにパスを分ける場合はこのオプションは不要です。
3. Storage Transfer Serviceの設定とフェデレーション連携
GCPコンソールからStorage Transfer Serviceを開き、転送元に「Amazon S3」、転送先に「Google Cloud Storage」を選択します。認証方式には「ID 連携のためのAWS IAM ロール」を選択し、事前に作成したIAMロールのARNを指定します。
この際、フェデレーション連携には subjectID と呼ばれる特別な識別子を発行する手順が必要です。詳細な設定手順は、Google Cloud公式ドキュメント を参照してください。
STSは、一度取り込んだファイルを記憶し、前回の実行からの差分ファイルのみを取得する自動判定機能を持っています。これにより、上位のパスを指定しても効率的な差分連携が可能です。
4. Cloud StorageからBigQueryへのデータロード
Cloud Storageに転送されたデータは、 bq load コマンドを使ってBigQueryにロードします。今回は、スキーマの自動検出機能と、Hiveパーティション分割データの読み込み機能を利用しました。
bq load \ --source_format=PARQUET \ --autodetect \ --hive_partitioning_mode=AUTO \ dataset.table \ "gs://your-bucket/table/*.parquet"
これにより、手動でのスキーマ定義を省略し、効率的にデータを取り込むことができます。
移行後の注意点
データ型とSQL構文の互換性
RedshiftとBigQueryでは、データ型やSQL構文に互換性のない部分が少なからず存在します。今回はスキーマ自動検出を利用しましたが、意図しないデータ型マッピングが発生する可能性があるため、移行後には必ずデータ型の差異を確認し、必要に応じて変換を検討しましょう。
移行後について
また、本記事では取り扱いませんが、SQL構文の互換性、データ品質問題、パフォーマンスなどがデータ移管後に発生する可能性があります。データ移行して終わりでなく、その後のトラブルシューティングも加味して計画することをお勧めします。
まとめ
僕の指示が悪いのか、生成AIに質問すると「BQ DTSでアクセスキーなしでも接続できる」と誤った回答が返ってくるのでこのコラムを書きました。 現時点では、セキュリティを重視する場合、S3を中間ストレージとして利用したSTSによるフェデレーション連携が最も有効な手段です。将来的には、BQ DTSがより柔軟な認証方式に対応し、アクセスキー不要の直接連携が実現することを期待しています。
終わりに
自社に専門人材がいない、リソースが足りない等の課題をお持ちの方に、エンジニア領域の支援サービス（Data Engineer Hub）をご提供しています。 お困りごとございましたら是非お気軽にご相談ください。
本件に関するお問い合わせは下記にて承ります。
株式会社DataCurrent
info@datacurrent.co.jp