> [!abstract] 概要 > 我々は分散コンピューティングの黄金時代に生きている。パブリッククラウドプラットフォームは今や事実上無制限のコンピュートとストレージのリソースをオンデマンドで提供する。同時に、Software-as-a-Service(SaaS)モデルは、これまでコストと複雑さのために手が届かなかったユーザーにもエンタープライズクラスのシステムをもたらす。しかし、従来のデータウェアハウジングシステムはこの新しい環境に適応するのに苦労している。第一に、それらは固定リソース向けに設計されており、クラウドの弾力性を活用できない。第二に、複雑な ETL パイプラインと物理チューニングへの依存は、クラウドの新しい種類の半構造化データと急速に進化するワークロードが要求する柔軟性・新鮮さと相容れない。 > 我々は根本的な再設計が必要だと判断した。我々のミッションは、クラウド向けのエンタープライズ対応データウェアハウジングソリューションを構築することだった。その成果が Snowflake Elastic Data Warehouse、略して「Snowflake」である。Snowflake はマルチテナント・トランザクショナル・セキュア・高いスケーラビリティと弾力性を備えたシステムであり、完全な SQL サポートと半構造化・スキーマレスデータ向けの組み込み拡張機能を持つ。本システムは Amazon クラウド上で従量課金サービスとして提供されている。ユーザーは自分のデータをクラウドにアップロードし、なじみのあるツールとインターフェースを使って即座にそれを管理・クエリできる。実装は2012年末に開始され、Snowflake は2015年6月から一般提供されている。今日、Snowflake は成長を続ける多数の中小・大規模組織で本番運用されている。本システムは複数ペタバイトのデータに対して日々数百万件のクエリを実行している。 > 本論文では、Snowflake の設計とその新規なマルチクラスタ・シェアードデータ・アーキテクチャを説明する。本論文は Snowflake の主要な特徴——極端な弾力性と可用性、半構造化・スキーマレスデータ、時間旅行、エンドツーエンドのセキュリティ——をハイライトする。最後に得られた教訓と今後の展望で締めくくる。 ## 論文情報 - **タイトル**: The Snowflake Elastic Data Warehouse - **著者**: Benoit Dageville、Thierry Cruanes、Marcin Zukowski、Vadim Antonov、Artin Avanes、Jon Bock、Jonathan Claybaugh、Daniel Engovatov、Martin Hentschel、Jiansheng Huang、Allison W. Lee、Ashish Motivala、Abdul Q. Munir、Steven Pelley、Peter Povinec、Greg Rahn、Spyridon Triantafyllis、Philipp Unterbrunner(いずれも [[Snowflake Computing]]) - **媒体**: SIGMOD/PODS'16(San Francisco, CA, USA)、Proceedings of the 2016 International Conference on Management of Data, pp. 215–226 - **発表年**: 2016 - **DOI**: [10.1145/2882903.2903741](https://doi.org/10.1145/2882903.2903741) - **原本**: `.raw/papers/2026_Unknown_The_Snowflake_Elastic_Data_Warehouse.pdf`(12 ページ) > [!note] 書誌情報について > 入力ファイル名は `2026_Unknown_The_Snowflake_Elastic_Data_Warehouse.pdf` だったが、本文の copyright 表記(`SIGMOD/PODS'16 June 26 - July 01, 2016`)・DOI・ページ番号(215–226)から SIGMOD 2016 論文と確定した。ファイル名のヒント(2026年・著者不明)は取り込み時に誤りと判明したため、source ページの命名・frontmatter は本文から確定した書誌情報(2016年・SIGMOD)を採用している。 ## 概要 Snowflake は、コンピュート(Virtual Warehouse)とストレージ(Amazon S3)を独立してスケール可能な疎結合サービスに分離した「マルチクラスタ・シェアードデータ・アーキテクチャ」を採用するクラウドネイティブなデータウェアハウジングシステムである。Hadoop・PostgreSQL 等の既存基盤に依拠せず、処理エンジンを含む大部分をゼロから開発した。Cloud Services(ブレイン)・Virtual Warehouses(マッスル)・Data Storage の3層からなるサービス指向アーキテクチャを持ち、ANSI SQL・ACID トランザクションのフルサポートに加えて、半構造化データ(JSON/Avro)向けの VARIANT 型・自動スキーマ推論・時間旅行・クローン・エンドツーエンド暗号化を特徴とする。 ## 問題設定 - **入力**: ユーザーがアップロードする構造化・半構造化(JSON/Avro/XML)データ、SQL クエリ(標準インターフェース: Web UI・ODBC・JDBC・Python PEP-0249) - **前提条件**: Amazon Web Services(AWS)上での稼働。ユーザー側にサーバ購入・DBA 雇用・ソフトウェアインストールの必要がない、純粋な SaaS 提供形態 - **必要なデータ**: なし(スキーマ定義・チューニングパラメータ・インデックス作成をユーザーに要求しない no-tuning-knobs 設計) ## 提案手法 ### アーキテクチャ: ストレージとコンピュートの分離 従来のシェアードナッシングアーキテクチャは、各クエリプロセッサノードが専用ローカルディスクを持ち、テーブルを水平パーティショニングして各ノードがそのローカルディスク上の行のみを担当する設計であり、star-schema クエリでのスケーラビリティとコモディティハードウェア利用に優れる。しかし、この設計はコンピュートリソースとストレージリソースを密結合させるため、クラウド特有の4つの課題を抱える。 - **ヘテロジニアスなワークロード**: バルクロード(高 I/O 帯域・軽量コンピュート)向けに最適なハードウェア構成と、複雑クエリ(低 I/O 帯域・重量コンピュート)向けの構成はトレードオフになり、平均利用率の低いハードウェア構成を強いられる。 - **メンバーシップ変更**: ノード障害や意図的なリサイズでノード集合が変化すると、大量データの再シャッフルが発生し、弾力性と可用性を制限する。 - **オンラインアップグレード**: ソフトウェア・ハードウェアのアップグレードは最終的に全ノードに影響するため、密結合かつ均質前提のシステムではダウンタイムなしのローリングアップグレードの実装が困難。 - クラウドではノード障害・性能変動が「例外」ではなく「常態」であり、EC2 の多様なノードタイプの活用にも柔軟な構成が要求される。 Snowflake はこれらの課題に対し、コンピュートを Snowflake 独自のシェアードナッシングエンジン、ストレージを Amazon S3(原理的には他の任意の blob store でも可)で提供する疎結合設計を採用した。各コンピュートノードはネットワークトラフィック削減のためテーブルデータをローカルディスクにキャッシュする。ローカルディスクはコールドな全ベースデータの複製には使わず、一時データとホットなキャッシュ専用に使うことで SSD 等の高性能ストレージデバイスの利用に適している(Figure 1)。 **アーキテクチャの3層**(Figure 1): **Figure 1: Snowflake のマルチクラスタ・シェアードデータ・アーキテクチャ** ![[_attachments/2026_Unknown_The_Snowflake_Elastic_Data_Warehouse/fig01-architecture.png]] (Figure 1. Cloud Services 層(Authentication and Access Control・Infrastructure Manager・Optimizer・Transaction Manager・Security・Metadata Storage)、複数の Virtual Warehouse(各自キャッシュ付き)、Data Storage 層(S3)の3層構成。) - **Data Storage**: S3 を使いテーブルデータとクエリ結果を格納する。S3 は HTTP(S) ベースの PUT/GET/DELETE のみをサポートし、ファイルの部分書き込み・追記ができないブロブストアであるため、テーブルは巨大な不変(immutable)ファイルに水平パーティショニングされ、ファイル内では列ごとの値をグループ化・圧縮する PAX(hybrid columnar)方式を採用する。各ファイルヘッダには列オフセットが記録され、S3 の範囲 GET によりクエリはヘッダと必要な列のみをダウンロードできる。メタデータ(カタログ・ファイル一覧・統計・ロック・トランザクションログ)はスケーラブルなトランザクショナル key-value ストアに格納される。 - **Virtual Warehouses**: EC2 インスタンスのクラスタ(「T シャツサイズ」で抽象化)。ユーザーは worker node の個数や種類を意識しない。VW は純粋なコンピュートリソースであり、作成・破棄・リサイズがデータベース状態に影響を与えない。 - **Cloud Services**: 「頭脳」に相当する層。アクセス制御・クエリオプティマイザ・トランザクションマネージャ等はマルチテナントで長寿命・共有される。個々のサービスノード障害はデータ損失やシステム全体の可用性喪失を引き起こさない。 ### エラスティシティとアイソレーション VW はオンデマンドで作成・破棄・リサイズ可能であり、これがデータベース状態に影響を与えない。各クエリは単一の VW 上で実行され、VW 間で worker node を共有しないため強い性能アイソレーションが得られる(ただし論文は worker node 共有を将来の重要な作業領域として認めている)。すべての VW は同じ共有テーブルに、データを物理コピーせずアクセスできる。ユーザーは組織単位ごとに複数の VW を持ち、常時稼働の VW とオンデマンドのバルクロード用 VW を併用する運用が一般的である。elasticity のもう一つの利点として、同程度のコストでノード数を増やせば劇的に短い時間でジョブを終えられる例(4ノードで15時間かかるロードが32ノードで2時間)を挙げ、コンピュート時間課金の下ではコストがほぼ同じでもユーザー体験が劇的に変わることを論拠に、VW の弾力性を Snowflake の最大の差別化要因の一つと位置づけている。 ### ローカルキャッシュと file stealing 各 worker node はテーブルファイル(の一部)のキャッシュをローカルディスクに保持し、LRU 置換ポリシーで管理する。キャッシュヒット率向上と重複キャッシュ回避のため、クエリオプティマイザはテーブルファイル名に対する一貫性ハッシュ(consistent hashing)で入力ファイルセットを worker node に割り当てる。Snowflake の一貫性ハッシュは lazy であり、worker node の集合が変化してもデータを即座には再シャッフルせず、LRU 置換に任せて徐々にキャッシュ内容を置き換える。これにより、シェアードナッシングシステムが必要とする即時の大規模データシャッフルを回避し、可用性を高めている。 スキュー対策として「file stealing」を導入している。ある worker process が担当ファイルセットのスキャンを完了すると、ピアに追加ファイルを要求する。要求を受けたピアは残ファイルがあれば、そのクエリのスコープ限定でファイルの所有権を要求元に一時移譲する。要求元は S3 から直接ファイルをダウンロードする(ピア経由ではない)ため、file stealing がストラグラーノードへの追加負荷にならない設計になっている。 ### 実行エンジン Snowflake は独自のカラムナ(columnar)・ベクトル化(vectorized)・プッシュベース(push-based)の SQL 実行エンジンを新規実装した。 - **カラムナ格納・実行**: CPU キャッシュと SIMD 命令の効率的利用、軽量圧縮の機会増大の観点で行指向より優位。 - **ベクトル化実行**: MapReduce 型と異なり中間結果をマテリアライズせず、数千行単位のバッチをカラム形式でパイプライン処理する(VectorWise/MonetDB/X100 に着想)。I/O 削減とキャッシュ効率向上に寄与する。 - **プッシュベース実行**: 演算子が結果を下流演算子にプッシュする方式(古典的な Volcano 型 pull モデルと対照的)。タイトループから制御フローロジックを除去してキャッシュ効率を高めるほか、木構造だけでなく DAG 形状のプランを効率的に処理でき、中間結果の共有・パイプライン化の機会を増やす。 テーブルファイルが不変であるため実行時のトランザクション管理が不要であり、バッファプールも持たない(大量データをスキャンするクエリが多いため、テーブルバッファリングよりメモリを演算に割く方が有利という判断)。join・group by・sort 等の主要演算子はメモリ枯渇時にディスクへスピル・再帰処理できる。 ### Cloud Services: クエリ管理・並行性制御・プルーニング - **クエリ管理・最適化**: Cascades 型のトップダウン・コストベース最適化を採用。インデックスを持たないため探索空間が小さく、結合のデータ分散方式など多くの決定を実行時まで遅延させることで、悪い決定のリスクを減らし性能をより予測可能にしている(ピーク性能はわずかに犠牲になる)。 - **並行性制御**: 分析ワークロード(大量の読み取り・バルク/トリクル挿入・バルク更新が支配的)向けに Snapshot Isolation(SI)を MVCC 上で実装している。テーブルファイルが不変であることは MVCC 実装の直接的帰結であり、書き込み操作(insert/update/delete/merge)はファイルの追加・削除によりテーブルの新バージョンを生成する。ファイルの追加・削除は key-value ストアのメタデータで追跡される。同じ MVCC スナップショットが時間旅行・クローンの基盤にもなる。 - **プルーニング**: インデックス(B+-tree 等)を使わず、ファイルごとの min-max 統計(zone maps / small materialized aggregates / data skipping と同種の技法)によりクエリに無関係なファイルをスキャン対象から除外する静的プルーニングを行う。半構造化データ内の自動検出カラムも対象に含む。動的プルーニングとして、hash join のビルド側で結合キー分布の統計を収集しプローブ側のファイルスキップに利用する。パス述語(`WEEKDAY(orderdate) IN (6, 7)` 等の複雑な式を含む)に対しては、値そのものではなくパスに対する Bloom filter をファイルメタデータとして保存し、パスが存在しないファイルを安全にスキップする。 ### 実装上の工夫: 継続的可用性 **Figure 2: マルチデータセンター構成の Snowflake** ![[_attachments/2026_Unknown_The_Snowflake_Elastic_Data_Warehouse/fig02-multi-datacenter.png]] (Figure 2. Data Storage(S3、複数 AZ にレプリケーション、Infinite)・Virtual Warehouses(常時稼働の Cloud Services と On Demand の VW 群)・Load Balancer からなる耐障害構成。Cloud Services のメタデータストアも複数 AZ に分散・レプリケートされる。) Data Storage 層(S3)は複数 AZ にレプリケートされ、99.99% の可用性・99.999999999% の耐久性を保証する。Cloud Services 層はステートレスなノード群にロードバランサで負荷分散するため、単一ノード障害や AZ 障害全体が起きてもシステム全体には影響しない(接続中のユーザーの一部クエリ失敗のみ)。一方 Virtual Warehouse は性能上の理由(AZ 内のネットワークスループットが AZ 間より大幅に高いため)から AZ をまたいでは分散しない。worker node 障害時はクエリを透過的に再実行し、事前確保した standby ノードプールで高速に置換する。AZ 全体が失われる稀なケースでは、そのAZ上のVWで実行中の全クエリが失敗し、ユーザーが別 AZ で VW を再プロビジョンする必要がある(論文はこれを唯一許容している部分的可用性喪失シナリオと明記する)。 **Figure 3: オンラインアップグレード** ![[_attachments/2026_Unknown_The_Snowflake_Elastic_Data_Warehouse/fig03-online-upgrade.png]] (Figure 3. Load Balancer 配下で Version 1・Version 2 の Cloud Services が同じ Metadata Storage を共有しながら並行稼働し、各バージョンの Virtual Warehouse がそれぞれのキャッシュを保持する様子。) 全サービスがステートレスであり全ハードステートがトランザクショナル key-value ストアに集約されているため、Cloud Services・VW とも複数バージョンを並行デプロイできる。アップグレードはまず新バージョンを旧バージョンと並行デプロイし、ユーザーアカウントを段階的に新バージョンへ切り替える。旧バージョンで実行中のクエリは完走まで許可され、全ユーザーが移行し終えたら旧バージョンのサービスを終了する。両バージョンの VW は同じ worker node とキャッシュを共有できるため、アップグレード後にキャッシュを再構築する必要がない。論文執筆時点で週次の全サービスアップグレードを実施しており、これにより機能リリースの高速化と、重大バグ発見時の即座なダウングレード・ホットフィックスが可能になっている。 ## 新規性 論文は §5(Related Work)で以下の既存システムとの差異を論じている。 - **Amazon Redshift**(ParAccel 由来、クラシックなシェアードナッシング): スケーラブルだがコンピュートリソースの増減にデータ再配置を要する。Snowflake のマルチクラスタ・シェアードデータ・アーキテクチャはデータ移動なしに独立したスケールアップ・ダウン・一時停止を可能にする。また Redshift は半構造化データを VARCHAR として取り込むのに対し、Snowflake は列指向格納を含むネイティブサポートを持つ。 - **Google BigQuery**(Dremel の公開実装): JSON・ネストデータのサポートは Snowflake のインスピレーション源の一つだが、ANSI SQL からの逸脱があり、テーブルは追記専用でスキーマ定義を要する。Snowflake は完全な DML(insert/update/delete/merge)・ACID トランザクションを提供し、半構造化データにスキーマ定義を要求しない。 - **Microsoft Azure SQL DW**: 同様にストレージとコンピュートを分離するが、同時実行クエリ数の上限が32に制限される。Snowflake は Virtual Warehouse による完全に独立したワークロードスケーリングを許す。PolyBase による非リレーショナルデータへのクエリはサポートするが、VARIANT 型に相当するネイティブな半構造化データサポートは持たない。 - **ドキュメントストア(MongoDB・Couchbase・Cassandra)**: スケーラビリティ・シンプルさ・スキーマ柔軟性で人気だが、単純な key-value/CRUD API では複雑なクエリの表現が難しく、N1QL・CQL のような SQL 風言語が生まれた。Snowflake はスキーマ推論・楽観的変換・列指向格納を組み合わせ、これらのシステムの柔軟性とリレーショナル列指向データベースの格納効率・実行速度を両立する。 - **Cloudera Impala(Parquet)・Google Dremel**: 半構造化データの列指向格納が可能であることを示したが、列指向格納のために完全なテーブルスキーマの事前提供をユーザーに要求する。Snowflake は型推論と列指向格納を自動化した新規アプローチで、スキーマレスな柔軟性と列指向の性能を両立させる。 ## 実験設定 - **実験環境**: Snowflake 上の medium standard warehouse(少数の安価な EC2 インスタンスから構成、詳細な価格・ハードウェア情報は非公開) - **データセット**: TPC-H ライクなデータ生成器・クエリを用いた SF100(100GB)・SF1000(1TB)のクラスタ化(ソート済み)データセット。JSON 形式で格納(日付は文字列化) - **比較対象**: (1) 通常のリレーショナル TPC-H スキーマ、(2) 全テーブルが単一 VARIANT カラムからなる「スキーマレス」スキーマの2種を用意し、スキーマレス側には型・クラスタリングに関するヒントを一切与えなかった - **評価指標**: 22 種の TPC-H クエリそれぞれの実行時間(秒)。ウォームキャッシュ下で3回の実行の平均を取り、標準誤差は無視できる小ささのため結果から省略した - 脚注で、実験結果は TPC-H データ生成・クエリの忠実な実装によるものだが TPC による検証を受けておらず公式ベンチマーク結果を構成しない旨明記されている ## 実験結果 **Figure 4: TPC-H SF100・SF1000 性能比較(リレーショナル vs. スキーマレス)** ![[_attachments/2026_Unknown_The_Snowflake_Elastic_Data_Warehouse/fig04-tpch-performance.png]] (Figure 4. 22クエリそれぞれについて、リレーショナルスキーマとスキーマレス(VARIANT 単一カラム)スキーマの実行時間(秒)を棒グラフで比較。左が SF100(最大約15秒)、右が SF1000(最大約200秒)。) - SF100・SF1000 いずれも、大半のクエリでスキーマレス格納・処理のオーバーヘッドは約10%程度に収まった。 - 例外は SF1000 の Q9・Q17 で顕著な性能劣化が見られ、原因を調査した結果、distinct value 推定の既知のバグに起因する準最適な結合順序であることが判明した。論文は今後もメタデータ収集とクエリ最適化の改善を継続すると述べている。 - 総括として、比較的安定・単純なスキーマを持つ半構造化データ(実務上の機械生成データの大半が該当)に対するクエリ性能は、ユーザー側の追加作業なしに、列指向格納・列指向実行・プルーニングの恩恵をほぼそのまま享受しつつ、従来のリレーショナルデータに対する性能とほぼ同等であるとまとめている。 ## 半構造化・スキーマレスデータのサポート(詳細) Snowflake は標準 SQL 型システムを VARIANT・ARRAY・OBJECT の3型で拡張する。VARIANT は任意のネイティブ SQL 型値に加え可変長 ARRAY・文字列から VARIANT へのマップである OBJECT(文献上「ドキュメント」とも呼ばれる、MongoDB・Couchbase 的な概念)を格納できる。内部表現は自己記述的なコンパクトバイナリシリアライゼーションであり、高速な key-value ルックアップ・型テスト・比較・ハッシュをサポートするため、VARIANT カラムは結合キー・グルーピングキー・ソートキーとして他の列と同様に使える。 VARIANT 型により、Snowflake は従来の ETL(Extract-Transform-Load)ではなく ELT(Extract-Load-Transform)的な使い方ができる。JSON/Avro/XML を変換なしに直接 VARIANT カラムへロードでき、パース・型推論は Snowflake 側が担う(「schema later」)。これによりスキーマ変更時の部門間調整コスト(従来 ETL では数か月かかりうる)を情報生成者と消費者の分離により回避する。ELT のもう一つの利点として、必要な変換を後段でフル機能の並列 SQL データベース(結合・ソート・集約・複雑述語を含む)で行える点、JavaScript 構文の procedural UDF による ETL タスクの Snowflake への統合が挙げられる。 - **Post-relational 演算**: フィールド名(OBJECT)・オフセット(ARRAY)によるデータ要素抽出を SQL 関数記法と JavaScript ライクなパス構文の両方で提供する。子要素は親要素内部へのポインタであり、コピー不要で高速。ネストしたドキュメントを複数行にピボットする flattening は SQL の lateral view で表現され、再帰的に適用できる。逆操作の aggregation 用に ARRAY_AGG・OBJECT_AGG 等の新規集約・分析関数を導入している。 - **列指向格納・処理**: 単一テーブルファイル内のドキュメント集合に対し統計分析を自動実行し、型推論と頻出パスの検出を行う。該当カラムはドキュメントから切り離され、リレーショナルデータと同じ圧縮列形式で個別格納される。これらのカラムに対してもプルーニング用マテリアライズド集約を計算する。スキャン時に各カラムは単一の VARIANT カラムへ再構成可能だが、多くのクエリは元ドキュメントの一部カラムのみを必要とするため、プロジェクション・キャスト式をスキャン演算子まで下方プッシュし、必要なカラムのみをアクセス・キャストする。この最適化はテーブルファイルごとに独立して行われ、スキーマ進化下でも効率的な格納・抽出を可能にする一方、パス述語に対するプルーニングでは、あるパスが多くのファイルに存在するが一部ファイルにしかメタデータとして残らない場合の扱いが課題になる。Snowflake はこれを、値ではなくパスに対する Bloom filter をファイルメタデータとして保存・プローブすることで、必要なパスを含まないファイルを安全にスキップする形で解決している。 - **楽観的変換(Optimistic Conversion)**: date/time のようなネイティブ SQL 型が JSON/XML では文字列として表現される問題に対し、書き込み時に自動型変換を行いつつ変換結果と元の文字列の両方を(完全に可逆な変換でない限り)別カラムに保持する「楽観的データ変換」を行う。数値に見えて実は先行ゼロ付き文字列の商品 ID のようなケースでの情報欠落を防ぎつつ、未使用カラムはロード・アクセスされないため二重格納の性能影響は最小限とする。 ## 時間旅行とクローン 書き込み操作(insert/update/delete/merge)によるテーブルの新バージョン生成はファイルの追加・削除として実現される。新バージョンにより削除されたファイルは設定可能な期間(執筆時点で最大90日)保持され、`AT`/`BEFORE` 構文による時間旅行(過去バージョンの効率的な読み取り)を可能にする。タイムスタンプは絶対・現在時刻からの相対・過去のステートメント ID からの相対のいずれでも指定でき、単一クエリ内で同一テーブルの複数バージョンを結合することもできる。同じ基盤メタデータの上に、誤って削除したテーブル・スキーマ・データベースを復元する `UNDROP` キーワードも実装している。 クローン機能(`CLONE` キーワード)は、ソーステーブルのメタデータのみをコピーして新テーブルを作成する。クローン直後は両テーブルが同じファイルセットを参照するが、以後は独立に変更できる。クローンはテーブル単位だけでなくスキーマ・データベース単位でも使え、大規模更新前や探索的データ分析前のスナップショットとして有用と位置づけられている。`CLONE` は `AT`・`BEFORE` と組み合わせて事後的なスナップショット作成にも使える。 ## セキュリティ Snowflake は二要素認証・(クライアント側)暗号化されたデータインポート/エクスポート・セキュアなデータ転送/格納・データベースオブジェクトへのロールベースアクセス制御(RBAC)を実装する。データはネットワーク送信前・ローカルディスク/S3への書き込み前に常に暗号化される。 **Figure 5: 暗号鍵階層** ![[_attachments/2026_Unknown_The_Snowflake_Elastic_Data_Warehouse/fig05-key-hierarchy.png]] (Figure 5. root key → account key(アカウントごと)→ table key(テーブルごと)→ file key(ファイルごと)の4階層。各階層の鍵が下位階層の鍵をラップ(暗号化)する。) AWS CloudHSM に根ざす AES 256-bit 暗号化の階層的鍵モデルを持ち、root/account/table/file の4階層からなる(Figure 5)。上位階層の鍵は下位階層の鍵をラップし、階層が下がるほど1つの鍵が保護するデータ範囲が縮小する。マルチテナントアーキテクチャにおいて、アカウントごとに個別の account key を持つことでユーザーデータの分離を保証する。table key と file key の関係は他の階層と異なり、file key は table key にラップされるのではなく table key とファイル名の組合せから暗号論的に導出される。これにより、数十億ファイルを扱う Snowflake が個々の file key を作成・管理・受け渡しする必要がなくなる(table key が変わればそれに紐づく file key もすべて変わり該当ファイルが再暗号化される)。 **Figure 6: テーブル鍵のライフサイクル** ![[_attachments/2026_Unknown_The_Snowflake_Elastic_Data_Warehouse/fig06-key-lifecycle.png]] (Figure 6. table key(k1v1→k1v2→k1v3、月次 rotate)を使い作成された5つの table file が、1年経過後に rekey により新しい table key(k2v1〜k2v3)で再暗号化される様子を、2014年・2015年のタイムラインで示す。) 鍵は生成・運用(暗号化/復号)・運用後・破棄の4フェーズを経る。**key rotation**(例: 月次)は鍵の新バージョンを作り旧バージョンを retired にする(retired 鍵は復号のみ可能)ことで originator-usage 期間を制限し、**rekeying**(例: 年次)は retired 鍵で暗号化されたデータを active 鍵で再暗号化することで recipient-usage 期間を制限する。Figure 6 は、2014年4〜6月に k1v1〜k1v3 で作成された5つの table file が、2015年に1年周期でそれぞれ対応する k2v1〜k2v3 に rekey される様子を示す。account key・root key についても同様の rotation・rekeying スキームが実装されている。account key・root key の rekeying は直下の階層のみの再暗号化で済み、上位ほど再暗号化コストが小さくなる。ストレージとコンピュートの分離により、rekeying はクエリを実行しないバックグラウンドの worker node で行われ、ユーザーワークロードに影響を与えない。旧ファイルはすべての進行中クエリが完了した後に削除される。 root key の生成・格納・利用は AWS CloudHSM(仮想プライベートクラスタ内の耐タンパー性ハードウェアセキュリティモジュール)上でのみ行われ、root key が HSM デバイスの外に出ることはない。account/table レベルの鍵生成もこの HSM で行い、高可用性構成でサービス停止リスクを最小化している。これに加え、S3 へのアクセスポリシーによるストレージ分離、アカウント内 RBAC、クラウドプロバイダ(Amazon)にデータを平文で見せない暗号化インポート/エクスポート、二要素・フェデレーション認証によるアクセス制御を組み合わせている。 ## 考察・強み・弱点・課題 ### 強み - ストレージ・コンピュートの疎結合と全サービスのステートレス化を核とする単一の設計原理から、弾力性・継続的可用性・オンラインアップグレード・時間旅行・クローンという一見異なる機能群が導出されている点は、本論文の設計としての一貫性を示している。 - 週次アップグレードという高頻度なリリースサイクルを実現しており、SaaS モデルが単にユーザー体験だけでなく開発・テストプロセス自体を加速したと論文は述べている。 - 論文執筆時点で本番稼働3年(2012年実装開始、2015年6月 GA)の実運用知見に基づく、産業論文としての具体性(file stealing・楽観的変換・Bloom filter プルーニング等の実装レベルの工夫)がある。 ### 弱点・課題(論文が自認するもの) - 部分再試行(partial retry)を実装しておらず、非常に大規模・長時間実行のクエリは懸念事項・今後の課題として残る。 - AZ 全体障害時には、そのAZ上で実行中の全クエリが失敗し、ユーザーが手動で別 AZ に VW を再プロビジョンする必要がある唯一の部分可用性喪失シナリオを許容している。 - worker node の VW 間共有は行っておらず、利用率向上・低コスト化の余地として今後の課題に位置づけている。 - 早期実装の単純化されたリレーショナル演算子、データ型の後追い対応、リソース管理への注力の遅れ、日付時刻機能の後回し等、回避可能だったミスがあったと Lessons Learned で率直に振り返っている。 - SF1000 の Q9・Q17 で見られた distinct value 推定バグのように、半構造化データのメタデータ収集・クエリ最適化は継続的な改善対象として明記されている。 - 今後の最大の課題として、運用チームの介在なしにユーザーがサインアップ・利用できる「フルセルフサービスモデル」への移行を挙げ、セキュリティ・性能・サポート上の課題が伴うと述べている。