# 分散ストレージ ## 定義 分散ストレージ（distributed storage）とは、複数のコモディティサーバにまたがってデータを格納・管理するシステムの総称である。単一マシンの容量・帯域・可用性の限界を超え、ペタバイトからエクサバイト規模のデータを水平スケーリングで取り扱う。データモデル（リレーショナル、キー値、多次元マップなど）、整合性保証、分散・レプリケーション戦略、障害耐性、運用モデルの設計がシステムごとに大きく異なる。(Source: [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]], [[@2026__SIGMOD Companion__Twenty Years of Bigtable]]) ## 横断的知見 - **HPC並列ファイルシステムとクラウドオブジェクトストレージの非侵襲ゲートウェイ融合は、Ceph等の単一統一システムに対してI/O帯域とメタデータ性能の両立をもたらす**: 分散ストレージにおける性能（HPC的アプローチ）と弾力性・低コスト（クラウドオブジェクトストレージ的アプローチ）の二項対立に対し、[[Lustre]]と[[MinIO]]をステートレスな専用ゲートウェイ層で結合するハイブリッド構成([[@2026__ACCESS__Convergence of HPC and Cloud Storage Systems for Deep Learning Workflows An Evaluation of LustreFS and S3-Compatible Object Storage]])は、同一ハードウェア上の[[Ceph]]と比較して読み出しスループットで33.3%向上、メタデータ操作レイテンシで40.7%削減を達成した。CephがCRUSHアルゴリズムや複雑なオブジェクトメタデータ階層に起因するオーバーヘッドを抱えるのに対し、Lustreの大規模シーケンシャル帯域とMinIOのフラットなキー値メタデータおよびチャンク分散処理を分離・協調させたことで、既存クラスタに侵襲的な変更を加えることなくストレージの階層的最適化が可能であることを実証している。(Source: [[@2026__ACCESS__Convergence of HPC and Cloud Storage Systems for Deep Learning Workflows An Evaluation of LustreFS and S3-Compatible Object Storage]]) - **長寿命の分散ストレージは中核モデルを保ち、周辺機構で時代要求へ適応する**: 2006 年 Bigtable は多次元疎マップ、タブレット、SSTable/メムテーブル、単一行 ACID を提示した。2026 年の Bigtable 経験論文では、この中核はほぼ維持されつつ、レプリケーション、SQL、CDC、CRDT、マテリアライズドビュー、外部コンパクション、行キャッシュ、オートサイジングが追加された。これは「最初から完全な汎用 DBMS を作る」のではなく、制約の明確な中核を長期運用の中で拡張する設計パターンである。(Source: [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]], [[@2026__SIGMOD Companion__Twenty Years of Bigtable]]) - **分散ストレージのスケーラビリティ課題はデータ分割からメタデータ・位置特定・運用分離へ移る**: 2006 年論文はタブレット分割と三階層位置特定を中心に設計を説明したが、20 年後の論文ではタブレット数爆発、位置キャッシュの冷え、メタデータホットスポット、マスタのロック競合、ファイルガベージコレクションの直列性、リバランサの副作用が主要課題として扱われる。規模拡大後の律速は「データを分けられるか」だけでなく「分けたものをどう安く管理するか」に移る。(Source: [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]], [[@2026__SIGMOD Companion__Twenty Years of Bigtable]]) - **運用モデルは分散ストレージのアーキテクチャ要素である**: Bigtable は当初ユーザーが運用する想定だったが、2006 年半ば以降は Bigtable SRE チームが全社サービスとして運用するモデルへ移った。標準サーバ形状、メタデータ専用パーティション、プローバ、既定バックアップ、オートサイジングは、単なる運用手順でなくシステムの可用性・性能予測可能性を支える構成要素になっている。(Source: [[@2026__SIGMOD Companion__Twenty Years of Bigtable]]) - **Raft を採用した分散ストレージでは、コンセンサスログが異常検知の無償データ源になる**: [[RBAD]]([[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]])は、Apache IoTDB・Alluxio において監視データ（収集でスループット -23.79%）やアプリログ（-55.37%）の代わりに、システムの正常動作に不可欠な Raft ログ（収集コスト -1.3%）を異常診断の入力とすることで、F1-Score 92–94% を達成した。これは分散ストレージの運用において「コンセンサスアルゴリズムの副産物を活用する」という新しい設計軸を開く。DB-Engine ランキング上位の大半（TiDB・Apache IoTDB・OceanBase・Google Spanner 等）が Raft または Paxos 系を採用しているため、この手法の適用範囲は広い。(Source: [[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]]) - **ディスアグリゲートされた分散ストレージでは、ネットワークがストレージエンジンの一部になる**: Bigtable 系の知見はデータモデル、タブレット、メタデータ、サービス運用の長期進化を示す。一方、[[Azure Storage]] の RDMA 展開は、計算クラスタとストレージクラスタを分離したクラウドストレージでは、TCP/IP 処理の CPU 予約やリージョン内 RTT 差がストレージ性能・コストを直接支配することを示す。分散ストレージの設計対象は、データ配置や整合性だけでなく、ストレージ通信のトランスポート、輻輳制御、NIC/スイッチ更新、診断テレメトリまで広がる。(Source: [[@2026__SIGMOD Companion__Twenty Years of Bigtable]], [[@2023__NSDI__Empowering Azure Storage with RDMA]]) - **OLTP 向けの専用ストレージサービスは、汎用分散ストレージとは異なりログ処理の責任を担う**: Bigtable・Azure Storage が汎用ブロック/テーブルストレージとして設計されるのに対し、Aurora の分散ストレージサービスは RDBMS の Redo ログアプライヤを内包し、データページをバックグラウンド生成する。これにより「ログがデータベース」という抽象化が成立し、OLTP エンジンとストレージの間でやり取りするデータ量を大幅に削減できる（ページではなくログレコードのみ）。目的特化型ストレージはより深い最適化が可能だが、汎用性を失う。(Source: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]) - **ユーザー向けオブジェクトストレージは、Bigtable・Aurora が扱う構造化データ向け分散ストレージとは異なり、検証システムへの投資規模そのものが設計の中心になる**: Bigtable(構造化データのタブレット分割・メタデータ管理)や Aurora(OLTP ログのストレージ層への移譲)が主にデータモデルと性能の最適化を論じるのに対し、[[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]]が説明する Dropbox のマルチエクサバイト規模のオブジェクトストレージシステムは「検証システムの開発の方が、基盤となる検証対象のストレージシステムそのものよりも、はるかに多くの時間と労力を要した」と明言する。Disk Scrubber(全ブロックの継続的チェックサム検証)・Index Scanner(毎秒100万回超のメタデータ整合性チェック)・Storage Watcher(ストレージ実装者とは独立したSREによるブラックボックス検証)という3層の検証スタックは、ユーザーデータの永続性という「取り返しのつかない」要件を持つ分散ストレージ特有の設計投資であり、性能・スケーラビリティを主目的とする他の分散ストレージシステム(Bigtable・Aurora・Azure Storage)の設計論には見られない比重の置き方である。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] §17.5.2) - **『ウェブオペレーション』15章(2011年)が伝えるDiggの「Cassandraを選んだ5つの理由」は、本ページがBigtable・Aurora・Azure Storageから積み上げてきた分散ストレージの設計論(性能・スケーラビリティ・検証投資)とは異なる、導入時点の意思決定基準という別の粒度の一次資料を提供する**: 本ページの既存知見は、いずれも分散ストレージシステムの内部設計(タブレット分割・クォーラム・RDMA・検証スタック)を論じるものだが、15章がDiggのクリス・ゴフィネットから引用する採用理由——「書き込みの比率が高い」「複数のデータセンタをサポートする必要がある」「ラックアウェアネスが必要である」「結果整合性は許容できる」「自動負荷分散が必要である」——は、いずれも内部実装ではなく、導入する側の組織が持つ要件のチェックリストである。これはBigtable(構造化データの読み書き最適化)・Aurora(OLTPレイテンシ)のような「システムがどの軸を重視したか」という設計者視点の記述を、「利用者がどの軸で選んだか」という逆方向(需要側)の視点から補完するものであり、分散ストレージの設計上のトレードオフが実際の採用判断でどう具体的なチェックリストに翻訳されるかを示す2010年代前半の実例である。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 15 非リレーショナルデータベース]] §15.2.1 導入事例) - **自社製ストレージへの移行動機は、技術的トレードオフの検討(15章)とコスト削減(14章)という異なる出発点を持ちうる**: 本ページ既出の知見(§55)は、15章がDiggから引用する「Cassandraを選んだ5つの理由」——書き込み比率・マルチデータセンタ対応・ラックアウェアネス・結果整合性・自動負荷分散——という**技術的な要件チェックリスト**を、分散ストレージの需要側からの導入判断として位置づける。これに対し[[キャパシティ計画]]が集約する[[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]]は、高価な商用NASアプライアンスを安価な自社製ストレージエンジンへ置き換える動機を、専ら**コスト**(「もっと経済的なソリューションを工夫できる」)として語り、スケーラビリティや一貫性モデルへの言及はない。両者を合わせると、実務者が独自のストレージシステムを構築する動機は、技術的な適合度(15章)だけでなくインフラ調達コスト(14章)という全く別の軸からも生じうることがわかる。ただし14章の事例は、移行期間中のバグ由来の遅延とトラフィック急増が重なりRPO割れを招いており、コスト動機による自社製ストレージ移行が、技術検証(15章のような要件チェックリストの整備)を欠いたまま進むリスクも同時に示している。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 15 非リレーショナルデータベース]] §15.2.1, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.3) - **オンプレミス分散ストレージ(MogileFS)をクラウドストレージ(S3)の障害フォールバックとして併存させる、という第三の動機が2章に現れる**: 15章の技術適合(§55)・14章のコスト削減という2つの既存知見は、いずれも「自社製ストレージへ全面的に移行する」動機を論じるが、2章([[Picnik]])はこれと異なり、S3への移行後もオープンソースの[[MogileFS]]を完全に廃止せず稼働させ続けた事例を示す。動機は技術適合でもコストでもなく、**クラウド依存に対するレジリエンスのフォールバック**である——S3の書き込みが失敗した場合にMogileFSへ切り替えることで、S3のパーティションメンテナンスに由来するHTTP 500エラーの局所的爆発の被害を限定し、逆にMogileFS側のメンテナンス(MySQLテーブル変更・Perlスクリプトのデバッグ)でMogileFSをオフラインにした際にはS3が全トラフィックを肩代わりした。これは、単一の分散ストレージシステムに全面移行するのではなく、性質の異なる2つのストレージシステム(クラウドオブジェクトストレージとオンプレミス分散ファイルストレージ)を意図的に並行稼働させることで、互いの障害モードを相殺するという設計パターンであり、15章・14章のどちらの動機とも異なる「可用性のための冗長化」という第三の軸を分散ストレージの採用動機に加える。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] §2.1.1) - **WSC教科書は、Bigtable論文とは異なる粒度で「クロスサーバ冗長性 対 単一装置内冗長性」という設計選択を明示的に対比し、複製と誤り訂正符号(EC)を並置する**: 本ページの既存知見はBigtable・Aurora・Azure Storageというシステム個別の設計を扱うが、[[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]]は、WSC内部ストレージサービス全般に共通する設計原則として「RAID のような単一装置内冗長性でなく、サーバ・ストレージ装置全体の故障を許容するクロスサーバ複製(GFS)や誤り訂正符号(Colossus)を使う」という方針を明示する。これはBigtable論文(2006)がGFS/Colossusを「下位ストレージ層」として前提するだけで詳述しない設計判断の根拠を補い、また[[イレイジャーコーディング]]([[@2026__SIGMOD Companion__Twenty Years of Bigtable]]が触れる外部コンパクション等の周辺機構)へつながる複製とECのトレードオフを、WSC全体のアーキテクチャ設計原則として位置づけ直す。(Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]] §6.2, §6.3, [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]]) - **eventual consistencyは、WSC教科書ではネットワーク帯域節約という運用上の合理性として説明され、Bigtable論文が採用した「単一行ACID」という設計選択とは異なる整合性モデルの選択理由を示す**: Bigtable(2006)は単一行トランザクションのみをサポートしACIDの範囲を限定した設計を選んだのに対し、本章はGFSの eventual consistency について「複数レプリカが常に一致している必要はなく、いずれ一致すればよい」という緩和がレプリカ間の整合コストを下げ、ストレージシステムのネットワーク帯域要求を減らすと説明する。両者はいずれもACID全体を要求しないという点で共通するが、Bigtableは「単一行の範囲でACIDを保証する」設計、GFSは「複数レプリカ間の一致を時間的に緩和する」設計であり、整合性モデルの緩和軸が異なることが分かる。(Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]] §6.2, [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]]) ## 未解決の問い - HPC並列ファイルシステム（Lustre）とS3オブジェクトストレージ（MinIO）を仲介するステートレスゲートウェイにおいて、ゲートウェイノード自身のスケールアウトと単一障害点（SPOF）排除に伴う一貫性保証プロトコルはどう設計されるべきか。(Source: [[@2026__ACCESS__Convergence of HPC and Cloud Storage Systems for Deep Learning Workflows An Evaluation of LustreFS and S3-Compatible Object Storage]]) - Bigtable のタブレットベース動的分割と、他の分散ストレージシステム（Dynamo の一貫性ハッシュ法など）のパーティショニング手法はどのような条件下で優劣が分かれるか。 - Bigtable が採用した Chubby への集中依存と、完全非集中のメンバーシップ管理（ゴシッププロトコルなど）は可用性・運用複雑性のトレードオフでどう評価されるか。 - NoSQL 系システムが時間とともに SQL・CDC・マテリアライズドビューを取り込むとき、中核の単純さとユーザー操作性の境界はどこに置くべきか。 - 単一行トランザクションのみの制約は、セカンダリインデックスやクロステーブル整合性が必要なアプリケーションでどう回避されたか。 - Bigtable のような全社サービス運用モデルは、オープンソース分散ストレージやマルチテナントクラウド DB でどこまで再現可能か。 - 分散ストレージが RDMA に依存するとき、通常時に節約した CPU コアと、TCP フェイルオーバー時に必要になる予備 CPU コアの容量計画をどう両立するか。([[@2023__NSDI__Empowering Azure Storage with RDMA]]) ## 関連 - ソース: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]](§6.2, §6.3、クロスサーバ複製 対 誤り訂正符号、eventual consistencyの帯域節約という運用理由) / [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]] / [[@2026__SIGMOD Companion__Twenty Years of Bigtable]] / [[@2023__NSDI__Empowering Azure Storage with RDMA]] / [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 15 非リレーショナルデータベース]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] - エンティティ: [[Bigtable]] / [[Google File System]] / [[Chubby]] / [[Google]] / [[Jeffrey Dean]] / [[Sanjay Ghemawat]] / [[Azure Storage]] / [[James Cowling]] / [[Dropbox]] / [[Apache Cassandra]] / [[Apache HBase]] / [[Riak]] / [[Anoop Nagwani]] / [[MogileFS]] / [[Picnik]] - 概念: [[データ耐久性]] / [[イレイジャーコーディング]] / [[キャパシティ計画]] - 関連 MOC: [[Systems for ML - MOC]] ## 出典 - [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]] §6.2, §6.3 - [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]] - [[@2026__SIGMOD Companion__Twenty Years of Bigtable]] - [[@2023__NSDI__Empowering Azure Storage with RDMA]] - [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]（OLTP 向け専用ストレージとログ処理移譲） - [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] §17.5.2(検証システムへの投資規模) - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 15 非リレーショナルデータベース]] §15.2.1(Diggの導入事例。需要側=採用判断基準という視点) - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.3(NASからの自社製ストレージエンジン移行。コスト動機という別の需要側視点) - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 2 Picnik におけるクラウドコンピューティングの利用とその教訓]] §2.1.1(MogileFSをS3の障害フォールバックとして併存させる冗長化動機)