大規模調査を支えるアンケートシステムのためのBigQuery活用

参考になった

レビュー投稿日の情報になります

株式会社エモーションテック / 谷口慶一郎

メンバー / バックエンドエンジニア

最終更新日2025/10/08投稿日2025/10/09

利用プラン	ツールの利用規模	ツールの利用開始時期	事業形態
オンデマンド	11名〜50名	2023年11月	B to B

利用プラン	オンデマンド
ツールの利用規模	11名〜50名
ツールの利用開始時期	2023年11月
事業形態	B to B

アーキテクチャ

アーキテクチャの意図・工夫

アンケートごとに通常のテーブルとマテリアライズドビューのテーブルがあるのがポイントです。詳細は後述しますが、テーブルを分離することで回答データの書き込みのパフォーマンスを担保しつつ、集計・分析の利便性も損なわないようにしています。

データセット

本アンケートシステムには組織という概念があります。ざっくり言うと企業を表す概念で、それごとにデータセットを分けています。アンケートが作成されるとそれぞれのデータセット内にテーブルが作られます。

テーブル構造

アンケートごとにテーブルが2つあり、_rawと_analysisというサフィックスをつけています。

`_raw`テーブル

アンケートの設定によらず固定された構造のテーブルです。書き込みにはDataflow + Storage Write APIを利用しており、大量の回答データを安定して書き込むことができています。回答データはJSON形式で送られており、これが回答JSONカラムというJSON型のカラムにそのまま入ります。

本システムでは、アンケートの設定は回答が入ってきたあとも質問の追加や削除といった操作を行えます。分析を考えると列指向のメリットを活かせる上にSQLが書きやすいため質問ごとにカラムが分かれているテーブルが望ましいのですが、この要件がある中ではパフォーマンスを担保しつつカラムに分けて書き込むのが難しかったためこのようにしています。

また、パフォーマンスのためにStorage Write APIのat least onceで書き込んでいるため重複した回答データが入っている可能性があります。

`_analysis`テーブル

前述したとおり、分析を行う上ではテーブルは質問ごとにカラムが分かれている必要があります。そのためのテーブルが _analysisテーブルです。回答データ一覧の確認でもこのテーブルを参照しています。

_analysisテーブルは_rawテーブルを参照するマテリアライズドビューです。BigQueryのマテリアライズドビューは、ベーステーブルのすべての増分データを自動的に反映してくれるため、最新データの反映をこちらで制御する必要がないのがうれしいポイントです。

また、_analysisテーブルはアンケートをインターネットに公開したタイミングで、その時点のアンケート設定を反映したマテリアライズドビューに更新しています。

※ 本アーキテクチャの設計は弊社のエンジニアの太田原が主に考えています。

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

もともとレガシーなアンケートシステムがあり、そのリニューアル（作り直し）が決まっている背景があります。そのレガシーなシステムでは以下の課題を抱えていました。

アンケートの回答数に比例して集計・分析処理時間が増加する
- 場合によっては処理が完了しないことも起きていた
アンケートへのアクセス数、アンケートの回答数に比例してインフラコストが大きく増加する

今回の新システムでは、今後の発展性も鑑みて数千リクエスト/秒の回答データの書き込みに耐えられることを目指しました。

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

アンケートへのアクセスが集中したときでも安定して回答データの書き込みができること
アンケートの回答数が増加しても集計・分析処理時間に大きな影響を与えないこと
アンケートへのアクセス数、アンケートの回答数の増加に伴うインフラコストの上昇を緩やかにすること

比較検討したサービス

BigTable

比較した軸

回答データの集計・分析処理のしやすさと処理速度
保存しておく回答データ量によるコスト
大量の回答データの書き込み速度と安定性

選定理由

データ量が増加しても集計・分析処理の時間に大きな影響を与えないこと
SQLによる集計処理ができること
データのストレージ料金の安さ
Storage Write APIによる高スループットかつ低レイテンシなデータ書き込み

導入の成果

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

「導入検討された背景と当時の状況」で述べた以下の事柄をすべて解決できました。

アンケートへのアクセスが集中したときでも安定して回答データの書き込みができること
アンケートの回答数が増加しても集計処理時間に大きな影響を与えないこと
アンケートへのアクセス数、アンケートの回答数の増加に伴うインフラコストの上昇を緩やかにすること

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

アンケートへの大量アクセスがある場合でも安定して回答データの書き込みができるようになった
回答データに対する安定した集計時間
アンケートへのアクセス数、アンケートの回答数の増加に伴うインフラコストの削減

また、当初は考慮していませんでしたが、BigQuery Sharing（旧 Analytics Hub）を使って顧客のBigQuery環境に安全に回答データを共有するサービスも提供できるようになりました。

導入に向けた社内への説明

上長・チームへの説明

既に別プロダクトでBigQueryを活用していたこともあり、集計・分析の利便性やデータ量に対するコストに関しては特に説明することはありませんでした。一方で秒間あたり大量データを書き込む要件は初でした。そこでアンケートへのアクセスおよび回答をするシナリオの負荷試験を行い大量データの書き込みも期待通りできることを検証し、要件を満たせることを説明しました。