第2章: 3層分離アーキテクチャを理解する
第1章で「Snowflake はストレージとコンピュートを完全に切り離すところから始まった」と書いた。本章ではその設計を技術的に分解する。
Snowflake のアーキテクチャは3層で語る。
graph TB
subgraph Cloud Services Layer
Auth[認証 / RBAC]
Meta[メタデータ管理]
Opt[クエリ最適化]
Tx[トランザクション]
Cache1[Result Cache]
end
subgraph Compute Layer (Virtual Warehouses)
VW1[VWH<br/>ETL用]
VW2[VWH<br/>BI用]
VW3[VWH<br/>ML用]
VW4[VWH<br/>Cortex用]
end
subgraph Storage Layer
S[(micro-partition<br/>S3 / Blob / GCS)]
end
User[ユーザー / アプリ] --> Auth
Auth --> Opt
Opt --> VW1
Opt --> VW2
Opt --> VW3
Opt --> VW4
VW1 --> S
VW2 --> S
VW3 --> S
VW4 --> Sポイントは：
- **同じデータ（Storage）**に、**互いに独立した複数の処理クラスター（Compute）**が干渉せずアクセスできる
- 各 VWH の SUSPEND / RESUME / 拡縮はミリ秒〜秒単位で可能
- ユーザーは インデックスもパーティション設計も意識しなくていい（Cloud Services層が裏で全部やる）
これが Redshift / BigQuery / Databricks にはない Snowflake 固有の組み合わせだ。順に各層を見ていく。
Storage Layer（ストレージ層）
データは内部最適化されたカラムナ形式に変換され、micro-partition という不変単位に自動分割される。
| 項目 | 内容 |
|---|---|
| micro-partition のサイズ | 圧縮前 50〜500 MB |
| 分割の単位 | テーブルへの INSERT 順に自動 |
| 圧縮 | 列ごと独立、自動で最適アルゴリズム選択 |
| 暗号化 | 列ごと独立、AES-256 + key rotation |
| メタデータ | 列の min/max、distinct count、null count などを保持 |
| 物理保管 | AWS S3 / Azure Blob / Google Cloud Storage |
| テーブル種別 | 標準テーブル / Apache Iceberg / Hybrid Tables（OLTP） |
メタデータが豊富だから、クエリの実行時に 「この WHERE 条件に該当する micro-partition だけ読めばよい」 というプルーニング（不要パーティションのスキップ）が効く。これが列指向 + メタデータ駆動のクラシックな高速化原理。
ユーザーが CREATE TABLE するときに PARTITION BY を書く必要はない。勝手に分割される。手動で介入できるのは「Clustering Key」（後述）だけで、それも巨大テーブルの一部にしか効かない。
3種類のテーブル
| 種別 | 用途 | 特徴 |
|---|---|---|
| 標準テーブル | DWH の主役 | Snowflake 内部形式、性能最大 |
| Apache Iceberg テーブル | オープンレイクハウス | Snowflake 外（S3 等）で Iceberg として共有可、Spark/Trino と相互運用 |
| Hybrid Tables | OLTP 用途 | 行ロック・PK制約あり、トランザクションワークロード |
Iceberg ネイティブ対応は2024-10にGAし、第6章でもう一度扱う。
Compute Layer（コンピュート層）─ Virtual Warehouse
Snowflake のコンピュート単位は Virtual Warehouse（VWH） と呼ばれる。独立した MPP クラスターで、各 VWH は他の VWH と計算リソースを共有しない。
サイズ
VWH のサイズは「Tシャツサイズ」で表現される。サイズが1つ上がるとクレジット消費は2倍になる。
| サイズ | クレジット/h | 用途の目安 |
|---|---|---|
| X-Small | 1 | 開発・テスト、軽量クエリ |
| Small | 2 | 小規模BI、軽量ETL |
| Medium | 4 | 中規模ETL、ダッシュボード |
| Large | 8 | 中〜大規模ETL、定常BI |
| X-Large | 16 | 大規模クエリ、本番ELT |
| 2X-Large | 32 | 超大規模ETL |
| 3X-Large | 64 | 大量データの一括処理 |
| 4X-Large | 128 | 巨大データセットの一括処理 |
| 5X-Large | 256 | 例外的に大規模、AWS / Azure 全リージョンGA |
| 6X-Large | 512 | 特殊用途、AWS / Azure 全リージョンGA |
重要：「とりあえず大きいほうが速い」と思ってXLを常時起動すると、月末に巨額請求が来る（第8章で扱う代表アンチパターン）。タスクに合った最小サイズが大原則。
Multi-cluster warehouse（Enterprise+）
同サイズのVWHを自動で水平に追加して同時実行スパイクを吸収する機能。
-- ✅ Enterprise 以上で使える書き方
CREATE OR REPLACE WAREHOUSE bi_wh
WAREHOUSE_SIZE = 'MEDIUM'
MIN_CLUSTER_COUNT = 1
MAX_CLUSTER_COUNT = 5
SCALING_POLICY = 'STANDARD' -- 応答性優先 / 'ECONOMY' = コスト優先
AUTO_SUSPEND = 60
AUTO_RESUME = TRUE;MIN_CLUSTER_COUNT = 1で待機時のコストを最小化MAX_CLUSTER_COUNT = 5で BI のピーク負荷を吸収SCALING_POLICY = STANDARDは「混雑したら即増設」、ECONOMYは「混雑が継続したら増設」
Gen2 Warehouse（2025）
2025年に AWS / Azure / GCP 全クラウドで GA した次世代ハードウェア層。Gen1 比でクエリ性能が向上し、課金は変わらない。新規作成のVWHはデフォルトでGen2になっている。
Auto-suspend / Auto-resume
VWH は秒課金（最低60秒）で動く。だから使わないときは即停止するのが基本。
-- ❌ よくある危険な設定
CREATE WAREHOUSE etl_wh
WAREHOUSE_SIZE = 'X-LARGE'
AUTO_SUSPEND = NULL -- 停止しない = 24/7 課金
AUTO_RESUME = TRUE;
-- ✅ 推奨
CREATE WAREHOUSE etl_wh
WAREHOUSE_SIZE = 'X-LARGE'
AUTO_SUSPEND = 60 -- 60秒アイドルで停止
AUTO_RESUME = TRUE -- クエリ着信で自動起動
INITIALLY_SUSPENDED = TRUE;用途別の推奨：
| 用途 | AUTO_SUSPEND |
|---|---|
| インタラクティブ（アドホック） | 60〜300秒 |
| バッチ ETL | 60秒 |
| BI（Result Cache 維持目的） | 600秒以上 |
第7章で詳しく扱う。
Cloud Services Layer（クラウドサービス層）
Cloud Services は Snowflake の「脳」だ。ユーザーが直接触ることはほぼないが、以下を一手に担う：
- 認証 / 認可（RBAC、SSO、OAuth、Key-Pair）
- メタデータ管理（FoundationDB バックエンド、テーブル統計、micro-partition インデックス）
- クエリ最適化（コスト最適化型 + 統計駆動）
- トランザクション管理
- Result Cache 提供
- アクセス制御 / ポリシー（行レベル / 列マスキング）
ここがあるおかげで、ユーザーは：
- インデックスを設計しなくていい
- パーティションを切らなくていい
- 統計情報を更新しなくていい
- バキュームコマンドを実行しなくていい
Cloud Services の使用量は Compute credit の10%まで無料、超過分のみ課金。複雑な小クエリを大量に投げ続けると10%上限を超える ─ これも第8章のアンチパターンで触れる。
キャッシュ階層 ─ なぜ Snowflake は速いのか
Snowflake のクエリは、データの「遠さ」によって応答時間が変わる。3階層のキャッシュがある。
graph LR
Q[Query] --> C1{Result Cache?}
C1 -- HIT --> R1[~130 ms]
C1 -- MISS --> C2{Local Disk Cache?}
C2 -- HIT --> R2[~1.2 s]
C2 -- MISS --> R3[Remote Disk<br/>~20 s]| キャッシュ | 場所 | TTL | 速度の目安 |
|---|---|---|---|
| Result Cache | Cloud Services 層 | 24時間（再実行で延長、最大30日） | ミリ秒 |
| Local Disk Cache | VWH の SSD | VWH 起動中のみ | 1〜数秒 |
| Remote Disk | S3 / Blob / GCS | 永続 | 10〜数十秒 |
Result Cache を活かす書き方
-- ❌ 非決定的関数でキャッシュが破壊される
SELECT *, CURRENT_TIMESTAMP() FROM orders WHERE order_date >= '2026-04-01';
-- ❌ SELECT * でキャッシュキーが大きくなり、列追加で即無効化
SELECT * FROM orders WHERE order_date >= '2026-04-01';
-- ✅ 必要な列だけ指定、関数を排除
SELECT order_id, order_date, total_amount
FROM orders
WHERE order_date >= '2026-04-01';BI ワークロード用 VWH の AUTO_SUSPEND を10分以上にすると、Local Disk Cache が温まった状態を保ちやすい。Result Cache + Local Disk Cache の組合せでBIダッシュボードを劇的に速くできる。
なぜこの3層分離が決定的なのか
他DWHとの違いを最後に整理する。
| アプローチ | 例 | 同じデータに同時アクセス | コンピュート柔軟性 |
|---|---|---|---|
| Shared-disk | 古典的RDBMS | ○ | ✕（単一クラスタ） |
| Shared-nothing | Redshift（旧）/ Hadoop | ✕（クラスタごとにデータコピー） | ○ |
| Snowflake 3層分離 | Snowflake | ◎ | ◎ |
**「同じデータに、性能を分離した複数のVWHが同時にアクセスできる」**ことで：
- ETL 中に BI ダッシュボードが遅くならない
- ML ワークロードと Cortex AI ワークロードを別 VWH で分離できる
- 部署別 VWH で課金を可視化できる
- 緊急のアドホック分析を別 VWH で立ち上げて捨てられる
これらは2025-2026年に「ワークロード分離（workload isolation）」というキーワードで再評価されている。第7章でベストプラクティスとして詳しく扱う。
本章の要点
| # | 要点 |
|---|---|
| 1 | Snowflake は Storage / Compute / Cloud Services の3層分離。同じデータに複数の Virtual Warehouse が干渉なく同時アクセス可能 |
| 2 | Storage は micro-partition（圧縮前50-500MB、不変、列指向、メタデータ豊富）。S3/Blob/GCS 上に保管 |
| 3 | テーブル種別は標準 / Apache Iceberg / Hybrid（OLTP）の3種 |
| 4 | Virtual Warehouse は X-Small〜6X-Large、サイズが1つ上がるとクレジット消費2倍。最小サイズから始めるが原則 |
| 5 | Multi-cluster warehouse（Enterprise+）で同時実行スパイクを自動吸収 |
| 6 | Gen2 Warehouse は2025年に全クラウド GA、新規VWHはデフォルトでGen2 |
| 7 | キャッシュ階層は Result Cache → Local Disk Cache → Remote Disk の3段。Result Cache はミリ秒、Local は秒、Remote は数十秒 |
| 8 | この3層分離こそが他DWHとの最大の差別化。Redshift（shared-nothing）/ BigQuery（slot共有）にはない構造 |
効いている根本原理
本章は 原理1（3層分離） そのものを技術的に分解した。VWH の秒課金は 原理2（Consumption-based Pricing） の現出であり、micro-partition の不変性は次章で扱う 原理3（コピーを作らない） の物理的基盤になる。次章では、その不変性を活かした Snowflake 独自のコア概念（Time Travel・Zero-Copy Cloning 他）を見ていく。