Notes on Snowflake’s new paper: Building an Elastic Query Engine on Disaggregated Storage

wangda-tan.medium.com

概要
  • ストレージ-メモリ-CPUの分離は最近のコンピュータアーキテクチャのメインテーマだ
  • この3つを分離すれば、過大なプロビジョニングをすることなく、それぞれのスケールを達成できる

＜中略＞

  • 1.イントロダクション: 既存のソリューションの問題
    • Shared Nothingアーキテクチャでは、過剰なリソースが確保されてしまう
    • ノードを追加したときに高コストなreshufflingが必要になる
  • 2.デザイン
    • Computeノードの、SSDとメモリを合わせてEphemeral Storageと呼び、中間データの置き場所とする
  • 4.ストレージアーキテクチャ
    • 中間データはローカルSSDとメモリに収容するが...
    • Shared NothingでありがちなOut of Diskエラーを避けるため、溢れたデータはS3に書き出す
    • 今後の方向性: パフォーマンスを死守すべきクエリならば、中間データをS3に漏らさないようにしたい
    • (かつ、Out of Diskエラーも起こしたくないが)中間データのサイズがローカルSSDに収容し切れるかは事前予測できないので、あり得る方向はEphemeral StorageとCPUの分離だろう
  • 6. リソースの柔軟性
    • Snowflakeは(reshufflingを避けるために)Lazy consistent hashingでデータを分散している
    • (何がEagerでなくてLazyかというと、あるデータをhashingアルゴリズムが指定するノードのEphemeral Storageに取りに行って、なかったらS3から取ってきてキャッシュすることで、ノードを増やしてもreshufflingの必要がないから)
  • マルチテナンシー
    • EC2が時間単位の課金から秒単位の課金になったことで、スタンバイノードのプールは、高くつくようになった(なぜかはよくわからない)
    • そのため、顧客間でノードを共用するモデルに移行したほうがよい感じになった
    • ある顧客のVirtual Warehouseの使用率が低い時、ノードを共有する別のVWが余ったCPU/メモリを使えるようにするのは理にかなっている
    • SNOW社はさらに、複数テナントを同一VWに入れられるようにしたいと考えているが、その実現にはこんなチャレンジがある:
      • テナント間の独立性を維持したEphemeral Storageのデザインをどうするか
      • 誰かがノードを追加したとき、Lazy consistent hashingにより、関係ないテナントまでキャッシュを失ってパフォーマンス低下してしまう
語彙
  • leverage: (利益を得るために)利用する
  • future direction: 今後の方向性
  • make sense: 意味がある。理にかなう