データ基盤

保存と計算の分離で、クラウドの分析は何を得て何を払ったか

2026/10/6 シリーズ「データ基盤はなぜ作り直されてきたか」 第5回 / 全6回

🤖 AIが執筆しています

データを計算する機械に置くと、保存と計算を別々に増やせない

Snowflake の開発者は 2016 年の論文で、各機械が自分のディスクにデータを持つシェアードナッシングの形を、計算と保存を強く結び付ける形と呼び、クラウドで問題になる点を三つ挙げた¹。読み込みの多い仕事と計算の多い仕事では向く機械の構成が違い、一つの構成では平均の使用率が低くなる。機械が壊れたり台数を変えたりするたびに大量のデータを配り直す必要があり、その作業を問い合わせと同じ機械が担うので性能が落ちる。全部の機械が結び付いているので、止めずに一台ずつ更新するのが難しい。論文は、自社の機械の上ならこれらは我慢できたが、クラウドでは台数の変化は例外ではなく日常になると書く。

Google も、自社の分析の仕組み Dremel で同じ問題にぶつかった。2020 年の振り返りの論文によれば、Dremel は当初、データを各機械のディスクに分けて置いていた。2009 年の初めからは、表の一部を三つの機械の手元のディスクに複製して置くようになった²。手元のディスクに複製して置くこの形では、データを移さずに台数を変えられず、保存の量を増やすには計算の機械も一緒に増やす必要があり、データは Dremel の外からは読めない状態に閉じ込められてもいた。論文は、どれも解ける問題だったが、解いた先の形が社内の分散ファイルシステムに似てきたと書く。

Amazon Redshift の初期の設計も、計算する機械が自分のディスクのデータを処理する形だった。2015 年の論文によれば、台数を変えるときは新しいクラスタを用意し、元のクラスタを読み取り専用にして、全部のデータを機械どうしで写していた³。同じ論文は、S3 に取ったバックアップから必要な部分を読みながら戻せる機能を説明し、無視できない割合の利用者が毎週金曜日にクラスタを消し、月曜日に戻していたと書いている。止めれば払わずに済む使い方は、この時点で一部はできていた。

利用企業の側の記録もある。OLX Group は 2023 年に AWS のブログで、Redshift の旧型のクラスタでほぼ毎日ディスクの空きが無くなる警告を受けていたと書いた⁴。対処はいつも機械の台数を増やすことで、18 台まで増やしたが、計算の能力は余っていたのにディスクのために計算の機械を足していたという。この記事は AWS の担当者との共著で、利用企業自身の報告である。

共有の保存先に置けば、計算を必要なときだけ動かせる

Snowflake は、データを Amazon S3 に置き、問い合わせを処理する機械の集まり（仮想ウェアハウス）を別に動かす形を採った¹。仮想ウェアハウスは計算だけを担い、いつでも作り、消し、大きさを変えられる。論文は、問い合わせが無いときは全部止めることを勧めている。論文は、4 台で 15 時間かかる読み込みが 32 台なら 2 時間で済むかもしれず、払う機械の時間はほぼ同じだという例を挙げているが、これは測定ではなく説明のための仮定である。論文は運用の教訓として、利用者が調整するのは、どれだけの性能を求め、それにいくら払うかの一点になったと書く。

Redshift も後に同じ方向へ移った。2022 年の論文によれば、新しい型の Redshift はデータを S3 に置き、計算の機械の SSD を手元のキャッシュとして使う⁵。台数の変更は、データを動かさずに管理用の情報を書き換えるだけの作業になり、台数の変更と別の型への復元を合わせて、月に 15,000 回を超えて使われているという。Google は社内の分散ファイルシステム、Snowflake と Redshift は S3 と、保存先は違うが、三社とも保存を計算の機械の外に置く形にたどり着いている。三社の論文はどれも自社の仕組みについての報告である。

Snowflake の研究者と大学の研究者は 2020 年に、2018 年 2 月の 14 日間に Snowflake で動いた約 7,000 万件の問い合わせを分析した⁶。この期間に大きさを一度も変えなかった仮想ウェアハウスは 82% で、大きさを変える機能を使ったのは約 2 割だった。論文はこれを、多くの顧客がすでに使っていると表現している。使ったものの中には、台数を 100 倍ほど変えたものもあった。

その後、ネットワークの速さがこの形の不利を小さくした。ミュンヘン工科大学の Durner らは 2023 年の論文で、AWS が 2018 年に 100 Gbit/s のネットワークを持つ機械を出し、一台あたりのネットワーク帯域が 4 倍になったことを、オブジェクトストレージで分析する障害が小さくなった理由に挙げた⁷。

遠い保存先は遅く、各社は手元のキャッシュで補った

オブジェクトストレージは、手元のディスクより遅い。Snowflake の論文は、S3 は手元の保存先よりアクセスの遅れ（レイテンシ）がずっと大きく、ファイルは丸ごと書き換えるしかなく末尾への追記もできないと書いた¹。Snowflake は、一度書いたファイルを書き換えない設計と、手元のディスクへのキャッシュでこれに対応した。Durner らの測定では、S3 への一回の要求には中央値で約 30 ミリ秒の基本の遅れがあり、100 Gbit/s の帯域を使い切るには 200 から 250 の要求を同時に出す必要があった⁷。Durner らによれば、帯域では手元の SSD との差はほぼ埋まり、残る不利は一回ごとの要求の遅れと、ネットワーク越しに読むための CPU の負荷である。同じ論文は、要求を多数同時に出す仕組みを著者らのデータベースに組み込むと、キャッシュを使わずに、手元の SSD にキャッシュする製品と同程度の速さが出たとも報告している。

Google の経験は、移行の最初の段階が遅かったことを示している。共有の分散ファイルシステムの上で Dremel を動かした最初の実験では、性能が 1 桁落ちた²。数十万のファイルを開くだけで数秒かかったという。保存の形式、管理用の情報の持ち方、処理を割り当てる場所、先読みを調整し続けた結果、最終的には典型的な仕事で手元のディスクを使う形より速くなったと論文は書くが、その差の数字は示していない。同じ論文は、分離を含む設計の原則は対話的な速さとは本来相性が悪いという通念を認めたうえで、それを補う工夫に一つの節を割いている。

キャッシュは小さくても効いた。先の Snowflake の分析では、手元のキャッシュの大きさは顧客のデータの平均約 0.1% だったが、平均のヒット率は読むだけの問い合わせで約 80%、書き込みも含む問い合わせで約 60% だった⁶。ただし同じ論文は、ヒット率が 75% を超える読むだけの問い合わせが件数で 80% あっても、それらが読んだデータの量は全体の 60% 余りにとどまると注記している。

独立した研究者の比較もある。Tan らは 2019 年に、1 TB の TPC-H（分析の性能を比べる業界標準の測定）で複数の分析用データベースを AWS の上で比べた⁸。S3 のようなオブジェクトストレージは、データベースの保存に使われてきたブロックストレージより 1 桁安く、混ざった仕事では大きな性能の不利もなかった。一方で、データを手元の SSD に置く旧型の Redshift は、一人で問い合わせる条件では他より桁違いに速かった。ただし著者らは、その主な理由を手元の SSD ではなく、一つの問い合わせを多くの CPU に分ける処理と機械語への変換に求め、同時の利用者が増えると Redshift が不利になることも測っている。旧型の Redshift は、動かし始めてデータを手元に読み込むまでに約 12 分かかり、他の仕組みの 5 分から 7 分より長かった。

使った分を払う従量課金では、止めれば速さを失い、料金の管理は利用者に移る

計算を止めれば料金はかからないが、手元のキャッシュも消える。Snowflake の文書は、仮想ウェアハウスを止めるとキャッシュが消え、再開後の最初の問い合わせが遅くなることがあると書き、止めて料金を節約するかキャッシュを保つかの兼ね合いを考えるよう勧めている⁹。Tan らも、S3 から計算の機械の保存先へキャッシュする方式は、冷えた状態から始める場合には不利になると報告している⁸。

使った分を払う形では、料金の上限も利用者が決める。Google が Dremel をもとに外部に提供している BigQuery の文書は、使った分だけ払う料金体系では、プロジェクトか利用者ごとの一日の上限で費用を抑えられ、上限に達すると問い合わせは止まると書く¹⁰。同じ頁は問い合わせごとに課金される量の上限も勧めており、見積もった読む量が上限を超える問い合わせは、課金されずに失敗する。枠を予約する料金体系を選べば、使える枠の数で上限を決める。並べ替え（クラスタ化）をしていない表では、問い合わせに LIMIT を付けて返す行を減らしても読む量は減らず、参照した列を全行読んだ分が請求される。

OLX Group の記録は、得たものと払ったものを一社で示している⁴。OLX Group は、データを S3 に置く新しい型の Redshift の 7 台へ移った。移行の翌朝、クラスタは遅かった。記事は、用意していた三つの対策を数日のうちにすべて打ったと書く。一台を足しても効果は小さく、混雑したときに自動で計算を足す機能を一日最大 4 時間まで使うことにした。そのうち 3 時間分は有料で、料金は機械を一台足すのとほぼ同じだったという。さらに、移行前に手で細かく調整していた負荷の割り振り（WLM）の設定が新しいクラスタでは効率が悪かったので、割り振りを自動に切り替えた。追加の計算と自動の割り振りを当ててから、一週間安定したという。一年後、ディスクの空きの問題は無くなり、性能も旧型より全般に良くなったが、新しい型の機械と追加の計算のためにクラスタの費用は増えたと書いている。同じ記事は、月に使う利用者が 250 人から 300 人に増えたことと、当面は台数を変えずに済む見込みも併せて書き、題では費用の効率が上がったとしている。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。