Snowflakeのアーキテクチャはどうなっているか 圧倒的なスケーラビリティを実現するクラウドネイティブ設計思想：Snowflakeで何ができる？ 基礎情報解説（3）

過去2回の記事でSnowflakeとは何か、何ができるかを見てきました。今回はSnowflakeの特長を裏付ける実装とクラウドネイティブな設計思想を見ていきます。

[渋谷亮太，株式会社NTTデータ]

　Snowflake連載の第3回は、Snowflakeの内部的な設計についてDeep Diveして解説していきます。

　前回までの記事でSnowflakeが他のDWHサービスとは異なる特徴を持っていると説明しましたが、それを可能としているのはSnowflakeのクラウドネイティブな設計思想です。Snowflakeを理解するカギである内部アーキテクチャについて紹介します。少し技術的な話も出てきますが、クラウドとデータの歩みについての歴史の一部として理解すると、Snowflakeをより深く理解できるようになるでしょう。

　本稿では主に以下の点を解説していきます。

• Snowflakeのアーキテクチャ概要
• 従来のDHWの課題とSnowflakeの実装の特長
• オブジェクトストレージの強みを生かした「マイクロパーティション」の実装
• DWHを超えたData Cloudの魅力

筆者紹介：渋谷亮太（NTTデータ Data&Intelligence事業部データマネジメント統括部ソリューション担当 課長代理）

2011年にNTTデータに入社。データベースやApache Hadoopなどのインフラレイヤーの構築・運用から、データマネジメントやデータモデリングのコンサルティングまで、入社以来一貫して「データ」のスペシャリストとして多くのプロジェクトに従事。2019年、技術者としてSnowflakeのアーキテクチャにほれ込み、それ以来Snowflake事業の推進担当として主に技術面の検証や導入プロジェクト支援を実施。また社内外のコミュニティーでSnowflakeの魅力を発信している（YouTube：SnowVillage LIVE 002講演動画、twitter：@ryotas_data）。

クラウドネイティブなアーキテクチャとは何か

　これまでの連載ではSnowflakeを説明するに当たり、「クラウドネイティブ」という言葉を何度も使ってきました。本稿は、まずこの言葉をもう一歩深く考えるところから始めてみましょう。

　クラウド黎明期の2008年、Amazon Web Services（以下、AWS）は「クラウドアーキテクチャアプリケーションの設計TIPS」として、以下の5項目を挙げました（注1）。

• スケーラブルな設計
• 疎結合化
• 並列化
• 故障に備えた設計（Design for Failure）
• コストの最適化

　クラウドネイティブアーキテクチャを語る上でよく参照されるCloud Native Computing Foundation（CNCF）が2015年に発表したクラウドネイティブの定義も「パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらすもの」とされており、ほぼ同じ方向性を示しています（注2）。クラウドにとって今なお最重要と言えるベストプラクティスが今から13年も前の2008年の時点で整理されていたことに驚くばかりです。

（注1）https://aws.amazon.com/jp/articles/building-greptheweb-in-the-cloud-part-1-cloud-architectures/
（注2）https://github.com/cncf/foundation/blob/master/charter.md

　その後、AWSのこの考え方はWebシステムなどの領域で一気に取り入れられていきました。一つのサーバを堅牢にするのではなく、シンプル化したインスタンスを並列に動作させ、自動でスケールアウト／スケールインし、一部に故障があってもすぐに他のインスタンスで代替が可能となるような仕組みが整備され、クラウドの強みが非常によく発揮されたのです。

図1　クラウドネイティブなアーキテクチャによるWebサービスの例（アマゾン ウェブサービス ジャパンが公開する任天堂とDeNAの事例＜https://aws.amazon.com/jp/solutions/case-studies/nintendo-dena/＞より）

　一方、DWHを含むデータベースの領域は、このような考え方になかなか適合できませんでした。データベースにとっては、「データ」とその「一貫性」が非常に重要だからです。サーバ内にデータを持つため、Web/APサーバのように疎結合にして自由にスケールすることもできず、故障への対応は地道なバックアップに頼らざるを得ません。また一貫性を管理するインスタンスは並列化も困難です。

　この考え方は「CAP定理」として知られ「データベースをスケールさせるにはデータの一貫性を諦めなければならない」と考えられてきました。そこで、一貫性制御機能を持たない代わりにスケール可能なHadoopなどのデータレイクやNoSQLが重視されるようになっていきました。

　ところが2012年に開発が開始されたSnowflakeは、クラウドの特徴を生かしたアーキテクチャをDWHで実現することを諦めていませんでした。

DWHにおける一貫性と分散の問題にSnowflakeはどう対応するか