この記事は会員限定です。会員登録すると全てご覧いただけます。
Snowflake連載の第3回は、Snowflakeの内部的な設計についてDeep Diveして解説していきます。
前回までの記事でSnowflakeが他のDWHサービスとは異なる特徴を持っていると説明しましたが、それを可能としているのはSnowflakeのクラウドネイティブな設計思想です。Snowflakeを理解するカギである内部アーキテクチャについて紹介します。少し技術的な話も出てきますが、クラウドとデータの歩みについての歴史の一部として理解すると、Snowflakeをより深く理解できるようになるでしょう。
本稿では主に以下の点を解説していきます。
2011年にNTTデータに入社。データベースやApache Hadoopなどのインフラレイヤーの構築・運用から、データマネジメントやデータモデリングのコンサルティングまで、入社以来一貫して「データ」のスペシャリストとして多くのプロジェクトに従事。2019年、技術者としてSnowflakeのアーキテクチャにほれ込み、それ以来Snowflake事業の推進担当として主に技術面の検証や導入プロジェクト支援を実施。また社内外のコミュニティーでSnowflakeの魅力を発信している(YouTube:SnowVillage LIVE 002講演動画、twitter:@ryotas_data)。
これまでの連載ではSnowflakeを説明するに当たり、「クラウドネイティブ」という言葉を何度も使ってきました。本稿は、まずこの言葉をもう一歩深く考えるところから始めてみましょう。
クラウド黎明期の2008年、Amazon Web Services(以下、AWS)は「クラウドアーキテクチャアプリケーションの設計TIPS」として、以下の5項目を挙げました(注1)。
クラウドネイティブアーキテクチャを語る上でよく参照される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システムなどの領域で一気に取り入れられていきました。一つのサーバを堅牢にするのではなく、シンプル化したインスタンスを並列に動作させ、自動でスケールアウト/スケールインし、一部に故障があってもすぐに他のインスタンスで代替が可能となるような仕組みが整備され、クラウドの強みが非常によく発揮されたのです。
一方、DWHを含むデータベースの領域は、このような考え方になかなか適合できませんでした。データベースにとっては、「データ」とその「一貫性」が非常に重要だからです。サーバ内にデータを持つため、Web/APサーバのように疎結合にして自由にスケールすることもできず、故障への対応は地道なバックアップに頼らざるを得ません。また一貫性を管理するインスタンスは並列化も困難です。
この考え方は「CAP定理」として知られ「データベースをスケールさせるにはデータの一貫性を諦めなければならない」と考えられてきました。そこで、一貫性制御機能を持たない代わりにスケール可能なHadoopなどのデータレイクやNoSQLが重視されるようになっていきました。
ところが2012年に開発が開始されたSnowflakeは、クラウドの特徴を生かしたアーキテクチャをDWHで実現することを諦めていませんでした。
Copyright © ITmedia, Inc. All Rights Reserved.