この記事は以下の2つのアドベントカレンダーの5日目のポストです。クロスコミュニティ！
Snowflake Advent Calendar 2024
HTAPデータベース Advent Calendar 2024
Snowflake Hybrid Tables
2024年10月についにGAされたSnowflake Hybrid Tablesは、主キーや行ロック、インデックス等を具備した行指向の実装によるOLTP（Online Transaction Processing）的なワークロードと従来のOLAP（Online Analytical Processing）ワークロード双方に同時に対応できるその名の通りハイブリッドなアーキテクチャとなっています。こうしたOLTPとOLAPのハイブリッドアーキテクチャやハイブリッドワークロードはHTAP（Hybrid Transactional/Analytical Processing）と一般的に呼ばれます。SnowflakeではこういったワークロードをUnistoreと呼び、それを実現する機能がHybrid Tablesです。
Hybrid Tablesのコンセプト自体はシンプルで、従来のマイクロパーティション型ストレージのほかに、行指向のストレージを同じテーブルに対して持ち、二つのストレージ間でデータを同期することで、どちらのワークロードにも対応するというものになっています。
Snowflake公式ドキュメントより
実はこのような行列ストレージ同期のコンセプト自体は昔からよく提唱されているもので、元エンプラDB屋の私はまずOracle DB in-memoryやDB2 BLUを思い出しました。最近でもMySQL HeatwaveやAlloyDB、NewSQLで知られるTiDBのHTAPも同じようなコンセプトです。
そういった既存のHTAPデータベースのなかで、Snowflakeが独自のポジションを取っているのは、Snowflakeがクラウドネイティブな分析用DBとして出発し、そこからOLTP側に拡張しているという点です。多くのHTAPデータベースはOLTP側の出自を持っているため、そのなかで分析側出身として大規模データに対する高い性能、拡張性、可用性を備えていることはSnowflakeの大きな利点です。
それでは、長年分析DBを作ってきたSnowflakeは、OLTP向けのワークロードをどのように実装しているのでしょうか。実はそのアーキテクチャにおいては、Snowflakeが内部でずっと使ってきた分散KVS「FoundationDB」がキーとなっています。
HTAP/NewSQL界隈にとっても注目なHybrid Tablesの内部アーキテクチャについて、今年のSnowflake Summitでの開発エンジニアによるセッションがYoutubeに上がっていてとても面白かったので、まずはその内容のメインとなっているFoundationDBがどういったものなのか解説し、そのうえで動画の内容についても解説してみたいと思います。
FoundationDBとは？
FoundationDB（FDB）は、2009年に開発が始まり、2012年に公開されたOSSのデータベースで、いわゆるキーバリューストア（KVS）の一種です。その開発当初から、FoundationDBが目指した最大の特徴は、何と言っても分散DBでありながら複数キーの厳密なACIDトランザクションに準拠するという点でした。
当時の分散DBと言えばNoSQLが全盛で、トランザクションが不完全であるからこそ高速化が可能で、CAP定理に基づき分散DBは完全なトランザクションを守ることができないと一般に信じられていた時代です。そんななかでFoundationDBはPaxosというコンセンサスベースのアルゴリズムを用いたクラスタ管理により、トランザクションを維持したままスケーラビリティを担保することを可能にしました。（実際には、CAP定理は定理としてある瞬間の状態としては正しいのですが、システムアーキテクチャとして分離を管理・回復することができないという意味を持つものではありません。最近のNewSQLではPaxosの後継ともいえるRaftというアルゴリズムが主流です。）
FoundationDBが公開された2012年は、奇しくもGoogleがNewSQLの先駆けとなるSpanner論文を発表した年で、ある意味分散DBの新たな時代が始まった年だったと言えるかもしれません。もちろん今では分散DBでトランザクションを実装することは難しいけれど不可能ではないということは良く知られており、多数の製品が実現しています。ちょうど先日AWSからAurora DSQLが発表されましたね。
そんななかかでFoundationDBが他のNewSQLと少し違うのは、"Foundation"の名の通り、基盤としての分散ストレージに焦点を当てたデータベースであるということです。FoundationDBは、純粋なシーケンシャルKVSとシンプルなAPIを除けば、スキーマ管理もクエリ言語もインデックスも、DBMSの「上半分」に相当する機能を持ちません。ユーザはほとんどむき出しのストレージエンジンとしてのFoundationDB上に自らデータモデルレイヤを構築して利用することになります。Appleが作ったデータモデルレイヤであるRecord LayerはOSSとして公開されていますが、デプロイも決して簡単ではなく、あまり一般企業向けのDBとは言えません。
普通の人が直接触ることは少ないであろうFoundationDBですが、AppleのCloudKit（iOSやmacOSのアプリがデータを管理するクラウドストレージ機能）やSnowflakeのメタデータ管理に使われています。つまりFoundationDBを直接使うことはない私達も、iPhoneでアプリを使ったりSnowflakeを利用したりしているということは、その恩恵にあずかっているということです。
FoundationDBによるSnowflakeメタデータ管理
Snowflakeは、その開発段階の2014年から現在まで、メタデータ管理にFoundationDBを活用していることを公言しています。
Snowflakeのメタデータ管理は、クラウドサービスと呼ばれるユーザクエリを受け付ける層に展開されており、テーブル等の定義情報、ユーザー、セッション、アクセス制御といった情報、そしてユーザクエリのトランザクションそのものを管理しています。
こういったデータは、ユーザが利用しているウェアハウスデータに比べて小さいですが、低レイテンシかつ高スループットなデータ管理が必要です。またSnowflakeのトランザクションとスケーラビリティを実現するためには、このメタデータ管理自体もトランザクションとスケーラビリティをもっていなければなければなりません。そのためにFoundationDBを利用しているのです。
上記Snowflake公式ブログより
Snowflakeは現在、世界で1日平均63億クエリを処理していると言います。そのそれぞれのクエリにおいて、内部のメタデータ管理DBへのアクセスが1回のユーザクエリにつき複数回発生しています。つまり、Snowflake自体はOLAP用途のサービスですが、その内部ではメタデータ管理という高スループット低レイテンシなOLTPワークロードをグローバル規模で処理してきたということです。それを実現してきたのがFoundationDBでした。
そしてさらに、Snowflakeはその利用用途をメタデータ管理から一歩広げ、ユーザデータの格納にも利用して、ユーザにも高スループット低レイテンシなOLTPワークロードを提供することを決めました。それがHybrid Tablesです。
FoundationDBを活用したHybrid Tablesの実装
ここからは、冒頭のYouTube動画をもとに、FoundationDBを用いて技術的にどのようにHybrid Tablesが実現されているか解説していきます。
新しいストレージレイヤに寄与するFoundationDBのネイティブ特性
Hybrid Tablesのストレージレイヤの説明として、以下のFoundationDBのネイティブ特性を生かして構築されていると説明されています。
YouTube動画より引用
- 信頼性：10年以上使われてきた信頼性と、ネイティブのシミュレーションテスト機能
- 可用性：クラウドプロバイダの3AZにデータ複製できてAZ障害に対応できる可用性の高さ
- パフォーマンス：ネイティブで高い性能からさらに高速化可能
- リカバリ速度：ノードがダウンした際のシステム全体のダウンタイムが短い
- オンラインアップデート：クラスタ内のノードを順次変更していって無停止でアップデートできる
- トランザクション：FDBのトランザクションは制約も多いが、複数レコードのアトミックな更新が可能なので、その上にトランザクションマネージャーを構築してユーザ向けのトランザクションを提供
Snowflakeは常に開発が進んでいて毎週バージョンアップします。内部では膨大なCI/CDが走っているでしょうから、テスト機能やオンラインアップデートと言った点は、FoundationDBを用いて大規模にサービス提供者する側としては重要な要素ですね。
また、FoundationDB自体のトランザクション（マイクロトランザクションと呼んでいます）はトランザクション時間等にかなり大きな制約があるのですが、それを用いてユーザ向けトランザクション管理機能を作り込めばエンドユーザにはその制約を意識させずに済むという発想も面白いです。これは従来のメタデータ管理FDBでも行われてきたことですが、Hybrid Tables特有の行ロックなどはストレージレイヤのFDBと協調してトランザクション管理をしているのでしょう。
HTAPを実現するためのFoundationDBへの作り込み
さらにOSS版のFoundationDBを変更して実装した仕組みも以下のように説明されています。
YouTube動画より引用
- テナント：ユーザごとにリソースを割り当ててそれが他に影響しないようにクオータを設定可能にし、かつ他のユーザのデータが誤って混入することを絶対に防ぐマルチテナント機能の実装
- 継続的バックアップ：最新のデータをFDBが持ち、履歴データを継続的にBlobストレージにバックアップすることで、クローンやタイムトラベルにも対応
- アダプティブクエリ：ルックアップクエリはFDBへ、分析クエリはBlobへと振り分けられ、分析クエリは従来のSnowflakeのクエリエンジンと同じロジックで動作
- バルクロード：バックアップと同じ仕組みを逆向きに動かすことで、一般的にOLTPデータベースが苦手とするバルクロードをネイティブで高速化
- クラスタの弾力性：ワークロードの予測が難しいため、FDBのコントロールプレインを大幅に改良してダウンタイムなしで柔軟にクラスタの拡縮を可能に
- クオリティオブサービス：性能の外れ値を無視せず、最悪のケースと最善のケースの差をなくすためのチューニング
どれもサラッと言ってますがすごい機能ばかりで、相変わらずSnowflake開発チームは素晴らしいエンジニアリング力だなと改めて感じました。マルチテナントやクラスタの弾力性の実装のためにはFoundationDBの根幹に近い部分に手を入れているはずです。
バックアップ機構によるHTAPの実装と、その逆転によるバルクロードの実装というのも、単にデータをレプリケーションして2つのストレージに持つという以上の工夫を感じて面白いポイントです。バルクロードの速さはHybrid Tablesの特徴の一つとして地味ですが優位性のある部分です。
クラウドサービスレイヤとコンピューティングレイヤの改善
Hybrid TablesのOLTPクエリは従来のテーブルとは別ストレージを利用するわけですが、そのクエリはSnowflakeの3層構造のうちのクラウドサービスレイヤとコンピューティングレイヤ（バーチャルウェアハウス）をそのまま利用します。従来分析ワークロードのみを処理してきたこの残りの2層に、OLTP的なスループットとレイテンシを要求してそのまま負荷をかけてもパフォーマンスは出ません。これらの層の改善はFoundationDBとは少し離れますが、非常に重要な観点です。
- ログ出力最適化：高スループットな環境で調査用ログ出力がボトルネックにならないように、ログの書き込みを非同期化したり、ログラインそのものを精査して内容を簡素化したりして最適化
- メタデータ管理：メタデータ管理FDBへのアクセスのレイテンシ向上のためキャッシュを導入
- プロセス再利用：ウェアハウスにおけるクエリ処理は従来1つ以上のプロセスを占有して実行されてきたが、プロセス管理にCPUリソースを必要以上に割かないよう、複数クエリ処理がプロセスを再利用できるように修正
このような様々な改善は、Snowflakeの既存のアーキテクチャを変更し、コードベースに大きな修正を行って実現してきました。スピーカーの方も言っていますが、特に最後のプロセス再利用はものすごい重大な変更です。Snowflakeが10年安定的に動いてきた、その根幹中の根幹となるクエリエンジンのプロセスモデルが変更されたのです。
Hybrid TablesがPuPrからGAになってもSnowflakeユーザは何も気づかずに従来通りSnowflakeを使い続けています。1日63億クエリが実行されるプラットフォームにおいてこれらの改善のリリースはまさにミッションクリティカルで絶対に失敗できない戦いだったはずです。これをやりとげ、また今後も改善を続けていくであろう開発者チームには頭が下がる思いです。
終わりに
個人的な話ですが、私が最初にSnowflakeに引き込まれたのは、2019年に初めてSnowflakeを触ったあと、例の論文を読んだり他の資料や動画を見たりしてトランザクション管理のアーキテクチャの一端を知ったときでした。DBAとして分散トランザクションに散々苦しめられた経験のあった私にとって、FoundationDBによるメタデータ管理とマイクロパーティションが可能にするトランザクションとスケーラビリティの両立は非常に刺激的でした。一番最初のSnowVillageのミートアップ（確か10名ちょっとくらいの参加者で、菱沼さんが村長になった会でした）でそのことを熱く語ったことを覚えています。
とは言えそれは分析ワークロードというトランザクション管理にとっては比較的取り組みやすい分野。実際のユースケースでも、どちらかというとトランザクションよりも分散処理そのものの方が重要なことが多く、私もこうしたブログ等でマイクロパーティションの話は多くしても、FoundationDBの話をする機会は限られていました。
しかしあれから5年、ついにSnowflakeがOLTPの世界にも一歩踏み出し、私もようやく意気揚々とFoundationDBの話をブログにできました。まだまだ書き足りていない部分も多くありますのでまた書きます！
昨今はNewSQLもHTAPもかなり一般的になってきましたが、分析領域からハイブリッドへ、UnistoreというHTAPユースケースは世の中にどう受け入れられるのでしょうか。この記事はあくまでも技術に寄ったもので、使い方には一切触れていませんが、すでに大量の分析データを抱えたSnowflakeがHTAP能力を持った今、どのような使われ方をしていくのか楽しみでなりません。
AIデータクラウドa.k.aクラウドネイティブHTAPデータベースのSnowflakeに、今後も注目していきましょう！
参考文献
FoundationDB Official
FoundationDB: A Distributed Unbundled Transactional Key Value Store
FoundationDB Record Layer:A Multi-Tenant Structured Datastore
Under The Hood: Snowflake Hybrid Tables
How FoundationDB Powers Snowflake Metadata Forward
FoundationDB: A distributed, model neutral, ACID-compliant, cloud native database for developers
Snowlfake データクラウドのユーザ会 SnowVillage のメンバーで運営しています。 Publication参加方法はこちらをご参照ください。 zenn.dev/dataheroes/articles/db5da0959b4bdd
Discussion