Redashのデータソース移行プロジェクト：Amazon AuroraからBigQueryへ

ツール導入前の課題

カンリーでは、CS業務におけるデータの可視化と分析にRedashを活用していましたが、本番DBであるAmazon Auroraに直接クエリを実行する構成であったため、以下の課題を抱えていました。

1. 大規模プロモーション時の負荷増大
   通常の運用時には問題はなかったものの、顧客店舗に関連するCM放映など大規模なプロモーションが実施されるとサービスへのアクセスが急増し、分析用の重いクエリが本番DBに負荷をかけ、サービスパフォーマンスに影響を及ぼすリスクがあった。

2. 分析業務への制約
   本番DBへの負荷を抑えるため、アクセスが集中する時間帯やプロモーション期間中には複雑なクエリや大量データの集計を避けざるを得ず、分析チームが必要なデータをタイムリーに取得できなかった。業務上の意思決定や改善施策を迅速に進めることが難しい状況であった。

こうした本番DBへの負荷問題と分析の柔軟性欠如が、改善すべき大きな課題として存在していました。

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

目指したのは、以下の状態です。

1. 本番DBへの負荷を大幅に軽減し、アクセス集中時でもサービスパフォーマンスを損なわないこと
2. 分析チームが必要なデータをタイムリーに取得でき、柔軟かつ高速に分析業務を実施できること
3. 単なる一時的な対処ではなく、将来的に他プロダクトにも適用可能な拡張性の高いデータ基盤を構築すること

このために、Redashのデータソースを本番DBから切り離し、負荷をかけずに大規模データを効率よく処理できる構成が求められました。
移行先としては、以下の理由からBigQueryを選定しました。

1. 既存のRedashクエリ資産を活かせること
2. 大規模データに対する高速なクエリ処理能力を備えていること
3. Google Cloudエコシステムとの連携が容易であること

最終的には、Amazon AuroraからエクスポートされたデータをS3経由でBigQueryに取り込み、日次で安定したデータ同期を行うことで、正確性を担保しつつ運用コストも最適化された状態を目指しました。

• Auroraリードレプリカを分析専用として増やし、カスタムエンドポイントを利用し、分析専用のリクエストを集約する方法
• 分析専用のDWHとしてのRedshiftの活用

今回のデータソース移行では、単に本番DBへの負荷を軽減するだけでなく、将来的に他プロダクトにも展開できる共通分析基盤を整えることを重視していました。
特に重要視したのは、"マルチプロダクトのデータを横断して利用できるかどうか" という点です。

サービスが増えるにつれて、各プロダクト単位で独立した分析基盤を構築すると、データのサイロ化が進み、横断的な集計や分析が困難になります。
そのため、複数プロダクトのデータを同一基盤上に集約し、プロダクトをまたいだデータ活用や分析が容易に行える仕組みが必要でした。

BigQueryは大規模データを効率的に処理できるだけでなく、データセット単位でのアクセス制御やプロダクト間でのデータ共有が容易であり、マルチプロダクト展開に適していると判断しました。

改善したかった課題はどれくらい解決されたか

本番DBへの負荷軽減は、ほぼ完全に解消されました。
Redashのクエリ実行先をBigQueryに切り替えたことで、分析クエリが本番Auroraに送られることはなくなり、プロモーション時などアクセスが急増するタイミングでもサービスパフォーマンスに影響が出ることは一切なくなりました。
また、負荷を気にしてクエリを制限する必要がなくなったことで、分析チームは必要なデータを好きなタイミングで取得できるようになり、運用上の制約もほぼ解消されています。

どのような成果が得られたか

分析基盤の安定性と柔軟性が大幅に向上しました。
特に、BigQueryへの移行により大規模データに対するクエリ処理速度が向上し、従来よりも高速に結果を得られるようになっています。

また、Parquet形式の採用によりデータ転送量が抑えられ、データ保有コストも削減されています。
さらに、今回構築したS3を経由したデータ転送基盤は他のプロダクトにも展開が進んでおり、すでに複数のサービスで同様の仕組みが活用されています。

これにより、各プロダクトにおいても安定したデータ分析環境が整い、複数サービスのデータを横断的に活用した高度な分析や、業務改善施策の精度向上といった新たなアウトカムが生まれています。
結果として、単一プロダクトにとどまらず、組織全体のデータ分析力を底上げする成果につながっています。