ノイジーネイバー：「自分のクエリは軽いのに、なぜ詰まるのか」

「9時の社内ダッシュボードがいきなり開かない。自分のクエリは何も変えてないのに、なぜ？」── データ基盤運用で最頻出のトラブル。原因は自分ではなく「うるさい隣人」（noisy neighbor）であることが多い。

起きる仕組み

共有スロット制（BigQuery 旧 on-demand / Snowflake Standard Warehouse / Redshift） の DWH（Data Warehouse） では、計算リソースが「全社共通プール」になります。誰かが TB 級の集計を走らせると、別の人の小さなクエリも待ちが発生します。

• BigQuery on-demand：プロジェクト単位の slot 制限。スポットで足りない時に他クエリが PENDING に
• Snowflake：同一 warehouse に複数クエリが queue されると、warehouse のサイズ次第で詰まる
• Aurora / RDS：CPU・IOPS・コネクション数が共有。ETL（Extract, Transform, Load） ジョブが本番 OLTP に影響
• dbt（data build tool） run の長時間化：他チームの aggregate ジョブが裏で走ってる

調査手順

SELECT  user_email,  query,  total_slot_ms,  total_bytes_processed / POW(10, 12) AS tb_processed,  TIMESTAMP_DIFF(end_time, start_time, SECOND) AS duration_sec,  start_timeFROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_ORGANIZATIONWHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)  AND total_slot_ms > 60 * 1000  -- 1分以上ORDER BY total_slot_ms DESCLIMIT 50;

SELECT  query_id, user_name, warehouse_name, execution_status,  total_elapsed_time/1000 AS sec,  bytes_scanned/POW(10,9) AS gb_scanned,  start_timeFROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORYWHERE start_time > DATEADD(hour, -1, CURRENT_TIMESTAMP)  AND total_elapsed_time > 60000ORDER BY total_elapsed_time DESCLIMIT 50;

• 容疑者の特定：同時刻帯に大量 slot/credit を消費しているクエリと user を出す
• 時系列の偏り：朝9時・正午・夕方17時など定時集計の集中を確認
• 重複クエリ：同じ集計が複数チームから別々に投げられていないか（DRY 原則違反）
• dbt run のオーバーラップ：staging と marts と incremental が同 warehouse でぶつかっていないか

短期対処

• ダッシュボード用 warehouse を分離：BI（Business Intelligence） 用と ETL 用で warehouse を独立させる（Snowflake は即対応可、BigQuery は予約スロットで類似可）
• `SET QUERY_TAG`：誰のクエリか追跡可能にし、責任範囲を明示
• 当日の重いクエリを停止：管理者権限で `SYSTEM$CANCEL_QUERY` / BigQuery の jobs.cancel
• マテリアライズ・キャッシュ：頻繁に叩かれる集計を view → table に格上げ（`CREATE TABLE AS`）

中長期対策

• ワークロード分離：ELT（Extract, Load, Transform） 用 / BI 用 / アドホック分析用を warehouse・スロット単位で分ける
• Reservation / Slot 予算：BigQuery の予約スロットでチーム別予算枠
• ジョブの時刻分散：cron が9:00:00 集中しないよう jitter（±10分）を入れる
• コスト・アロケーション：QUERY_TAG / labels で誰が使ってるかを可視化
• 自動スケール：Snowflake の Multi-cluster Warehouse / Auto-scale で混雑時のみ拡張
• Materialized View / dbt 中間モデル：重複集計の元を絶つ

ふくふくの進め方（受託案件の場合）

ノイジーネイバー診断は2週間でできます：① 1週間ぶんのクエリログを集計し容疑者をスコア化、② コスト・遅延・頻度の3軸で priority 付け、③ 切替コストの低い対策から着手（warehouse 分離 → 集中時刻のジッター → マテビュー化）。「重いクエリ・トップ10 リスト」+ 即効対策の PR をご提案します。お困りなら無料相談へ。