Snowflake 3層アーキテクチャ徹底解説：なぜ無限にスケールするのか

「Snowflakeはなぜ、データ量が増えても同時アクセスが増えても破綻せずにスケールするのか」——その答えは、ストレージ・コンピュート・クラウドサービスという3つの層を物理的に分離したアーキテクチャにあります。本記事では、AWS上でSnowflakeがどう動くのかを、S3・仮想ウェアハウス・メタデータ管理の関係とともに、設計・運用の実務目線で解き明かします。

01なぜ「3層分離」がスケールの前提になるのか

従来のデータベースは、大きく2つの設計に分かれていました。ストレージを全ノードで共有する「共有ディスク（shared-disk）」型は管理がシンプルな一方でストレージがボトルネックになりやすく、データをノードごとに分割して持つ「シェアードナッシング（shared-nothing）」型は並列性が高い反面、ノード追加のたびにデータの再配置が必要でスケールが重くなります。Snowflakeはこの両者を組み合わせたハイブリッド構造を採り、公式ドキュメントでは「ストレージ層」「コンピュート層（クエリ処理）」「クラウドサービス層」の3層として説明しています。要点は、3つの層がそれぞれ独立してスケールできること。データはひとつの共有ストレージに置いたまま、計算資源だけを用途や負荷に応じて足し引きできる——これが「無限にスケールする」ように見える体感の正体です。

02ストレージ層：S3上のマイクロパーティションとカラムナ格納

ストレージ層は、テーブルの実データを「内部最適化された圧縮済みのカラムナ形式」で保持します。AWS上のSnowflakeではこれがAmazon S3に置かれますが、利用者はS3のファイルを直接触りません。Snowflakeは投入されたデータを自動的にマイクロパーティション——圧縮前で概ね50〜500MBの連続した格納単位——に分割し、その内部で列（カラム）ごとに独立して格納します。さらに各マイクロパーティションについて、最小値・最大値・件数などのメタデータと統計情報を自動収集します。この設計が効くのは、クエリが参照する列だけをスキャンでき、なおかつ「この範囲の値はこのパーティションには無い」と判断して不要なパーティション読み取りを丸ごと省略できる（プルーニング）からです。テラバイト級のテーブルでも、実際に読むのはごく一部で済みます。

03コンピュート層：仮想ウェアハウスと独立スケール

クエリを実際に処理するのがコンピュート層で、その実体が仮想ウェアハウスです。仮想ウェアハウスはMPP（超並列処理）方式のコンピュートクラスタで、AWS上ではEC2系のインスタンス群として動きます。サイズはXSから6XLまであり、1段階上げるごとに時間あたりのクレジット消費はおおむね倍になります。ここで重要なのは2つの独立性です。第一に、ウェアハウスを大きくしても、ストレージ側（S3のデータ）には一切手を加えません——リサイズはデータ移動を伴わないのです。第二に、各ウェアハウスは互いに影響しません。ある分析ジョブが重くても、別ウェアハウスで走るBIの応答は落ちません。なお各ウェアハウスはスキャンしたデータをローカルSSD（ウェアハウスキャッシュ）に保持し、以降のクエリを高速化しますが、ウェアハウスをサスペンドするとこのキャッシュは失われます。

04クラウドサービス層：メタデータと最適化を束ねる司令塔

クラウドサービス層は、Snowflake全体を協調させるサービス群です。公式ドキュメントは、認証・アクセス制御、メタデータ管理（SNOWFLAKEデータベースを含む）、クエリの構文解析と最適化、インフラ管理、トランザクション管理などを担うと説明しています。ユーザーがログインしてクエリを投げると、まずこの層がSQLを解析・最適化し、先ほどのマイクロパーティションのメタデータを使ってスキャン対象を絞り込み、そのうえで仮想ウェアハウスに処理を割り当てます。つまりコンピュートが動き出す前に「どこを読むべきか」がここで決まります。キャッシュもこの層に2種類あります。テーブルやパーティションの統計を保持するメタデータキャッシュと、直近24時間の同一クエリ結果を再利用する結果（リザルト）キャッシュです。いずれも全ウェアハウスから共有されます。

05なぜ無限にスケールするのか：同時実行とマルチクラスタ

データ量の増加は、S3側でストレージが自動的に伸びるだけなので、そもそも設計の悩みになりにくいのがSnowflakeの強みです。難しいのは「同時実行」——多数のユーザーやクエリが一斉に来るケースです。単一のウェアハウスには同時実行の限界があり、それを超えるとクエリはキューに並びます。ここで効くのがマルチクラスタウェアハウスです。オートスケール（Auto-scale）モードでは、セッションやクエリが増えて待ち行列が発生すると、Snowflakeが自動的にクラスタを追加し（最大数まで）、負荷が下がると自動でクラスタを縮退させてクレジット消費を抑えます。追加時の積極性はスケーリングポリシー（StandardとEconomy）で制御できます。ポイントは、これらすべてが単一の共有ストレージの上で成り立つこと。コンピュートを増やしてもデータをコピーしないため、ストレージは1つ・コンピュートは用途と負荷に応じて自在に増減、という構図が「無限スケール」の体感を生みます。

06AWSサービスとの接続点：S3・IAM・PrivateLink・KMS

SnowflakeがAWS上で動くという前提は、周辺サービスとの接続設計に直結します。Amazon S3は内部ストレージであると同時に、外部ステージやIceberg用の外部ボリュームとしてデータ連携の窓口になります。S3へのアクセスはIAMのロール引き受け（ストレージ統合）で最小権限に制御するのが定石で、アクセスキーを直接持たせない構成が推奨されます。ネットワークはAWS PrivateLinkを用いれば、Snowflakeアカウントへの接続や内部ステージ・S3への通信を公衆インターネットを経由させずVPC内で完結できます。暗号化は既定でも有効ですが、KMSと連携させたキー管理（顧客管理鍵を組み合わせるTri-Secret Secure）で統制を強められます。さらにExternal Access Integrationを使えば、Snowpark/外部関数からLambda・API Gatewayや外部APIへ安全にアクセスでき、生成AI用途ではCortexのマネージドLLMやAmazon Bedrockとの連携も選択肢になります。3層アーキテクチャの外周は、こうしたAWSのセキュリティ部品で締めて初めて実務水準になります。

07検証で先に踏み抜いた落とし穴：スケールとコストの誤解

3層分離は強力ですが、独立してスケールするがゆえの落とし穴もあります。私たちはこれらをPoC・検証段階で先に踏み抜き、本番では未然に防ぐ運用にしています。第一に、アイドル時のクレジット消費です。検証環境で、AUTO_SUSPENDを無効化（または過度に長く）したまま放置すると、XSのような小さなウェアハウスでも起動しっぱなしでクレジットを消費し続けると確認できたため、本番ではAUTO_SUSPENDを短めに、AUTO_RESUMEを有効にする設計を標準化しました。第二に、マルチクラスタの設定ミスです。検証でMaximizedモード（最小=最大クラスタ数）にすると常時フル起動になりコストが跳ねると分かったため、本番はAuto-scaleモードで最大数と適切なスケーリングポリシーを設定します。第三に、性能見積りの誤り。結果キャッシュ前提で速いと錯覚しがちなため、検証ではキャッシュを避けた素の実行時間を計測します。第四に、「サイズを上げれば速くなる」という思い込み——同時実行の詰まりはサイズ（スケールアップ）では解けず、クラスタ追加（スケールアウト）で対処すべきだと検証で切り分けました。こうした落とし穴を本番前に潰しておくことが、重大障害ゼロを続ける前提になっています。

まとめると、Snowflakeが「無限にスケールする」ように見えるのは、ストレージ・コンピュート・クラウドサービスを分離し、それぞれを独立に伸縮させられるからです。AWS上ではS3が共有ストレージ、IAM・PrivateLink・KMSが外周のガードレール、仮想ウェアハウスとマルチクラスタが弾力の源になります。仕組みを正しく理解し、AUTO_SUSPENDやスケーリングポリシーといった要所を検証で押さえておけば、性能とコストを両立させながら安全に伸ばしていけます。