Definition：Data Infrastructure Decoupling
データ基盤におけるデカップリングとは、データの保存・管理、データを処理するコンピュート資源、データへアクセス・利用する機能を、単一のシステムや装置に固定せず、それぞれを独立した構成要素として分離することで、データの物理的配置と処理・利用方法の独立性を高めるデータ基盤のアーキテクチャ上の考え方である。
従来型のデータベースでは、ストレージ、メモリ、CPU、データベースエンジン、キャッシュなどが一体となったシステムとして構成されることが多かった。この構成では、データを保持する場所とデータを処理する場所が基本的に同じシステムの内部に存在する。そのため、データ容量を増やすことと計算能力を増やすことが必ずしも独立して行えず、一方の需要に対応するために他方の資源まで増強しなければならないという制約が生じる。
デカップリングは、このような構成要素間の強い結合を弱めるものである。特にクラウドコンピューティングの発展によって、オブジェクトストレージ、分散コンピュート、ネットワーク、キャッシュ、メタデータ管理などを独立した資源として組み合わせることが可能になり、データ基盤の構造そのものが大きく変化した。
リレーショナルデータベース（RDB）の典型的な構成では、データを格納するストレージと、それを検索・更新するデータベースエンジンが密接に結合している。SQLを受け取ると、データベースエンジンがバッファキャッシュを利用しながらストレージ上のデータを読み出し、CPUによって検索、結合、集約、更新などを実行する。この意味で、伝統的なRDBは「データを持つ場所」と「データを処理する場所」が一体化したシステムであった。
この構成は、オンライン・トランザクション処理（OLTP）には非常に適している。データの更新と参照を低遅延で処理し、トランザクションの一貫性を維持するには、データと処理機構が緊密に連携していることに大きな意味がある。しかし、分析処理の規模が拡大すると、同じデータベース上でOLTPと大規模分析を同時に実行することが負荷上の問題を引き起こすようになる。
そこで発展したのがデータウェアハウス（DWH）である。DWHでは、業務システムを担うRDBからデータを抽出し、分析処理に適した別のデータストアへデータを移すという構成が一般的となった。ETLによって業務データをDWHへコピーすることで、OLTPと分析処理を物理的に分離できるようになったのである。
ここで重要なのは、RDBとDWHの分離が、単なるデータベース製品の違いではなく、「一つのデータベースですべての処理を行う」という考え方からの転換であった点である。業務処理と分析処理を別々のシステムに配置することによって、それぞれのワークロードに適したコンピュート資源とデータ構造を選択できるようになった。
しかし、この方式にはデータを物理的にコピーしなければならないという問題がある。RDBに存在するデータをDWHへ移すためにはETLやELTが必要であり、データの移動、変換、保存、同期を管理しなければならない。つまり、処理を分離する代わりに、データの物理的な移動という新しい結合関係が発生したのである。
クラウドとオブジェクトストレージの発展は、この構造をさらに変化させた。Data Lakeでは、データをオブジェクトストレージなどの比較的安価で大容量のストレージに保持し、必要なときに別のコンピュートエンジンから読み出して処理するという構成が一般化した。
ここでは、データを保存するストレージとデータを処理するコンピュートが明確に分離されている。必要なときだけコンピュート資源を起動したり、処理量に応じてコンピュート資源だけを増減させたりできるため、データ量と計算量を独立した尺度として扱いやすくなる。この構造はStorage-Compute Separation、あるいはStorage-Compute Decouplingと呼ばれる。
クラウドDWHもこの方向へ発展した。従来のDWHではデータと計算資源が比較的密接に結び付いていたのに対し、クラウドDWHではストレージとコンピュートを論理的に分離し、必要な計算資源を動的に割り当てる設計が可能になった。これによってDWHは、単なる「RDBからデータをコピーして分析する場所」から、独立した分析コンピュート基盤へと変化していったのである。
Data Lakeがストレージとコンピュートを分離した一方で、当初のData LakeはDWHが備えるトランザクション制御やスキーマ管理を欠いており、単なるファイルの集積地に留まりやすいという課題を抱えていた。この課題を解決したのが、Apache Iceberg、Apache Hudi、Delta Lakeなどのオープンテーブルフォーマットである。
これらのフォーマットは、オブジェクトストレージ上に存在するファイル群に対して、ACIDトランザクション、スキーマ進化、タイムトラベル、パーティション管理といったメタデータ層を付与する仕組みである。これにより、安価なオブジェクトストレージの上に、DWHに近いデータ管理機能を実現できるようになった。オープンテーブルフォーマットは、ストレージそのものを変えることなく、その上位に論理的な管理層を追加するという点で、デカップリングの考え方を体現する技術であるといえる。
一方で、RDBとDWHの分離が進むにつれて、今度は両者を再び統合しようとする方向も現れた。これは単純に一つのデータベースへ戻るという意味ではない。OLTPと分析処理を物理的に同じエンジンへ戻すのではなく、それぞれの特性を維持しながら、データ基盤全体として統合する方向である。
その代表的な考え方がLakehouseである。Data Lakeが持つ安価で柔軟なストレージと、DWHが持つSQL、スキーマ管理、トランザクション、データ管理などの機能を組み合わせることで、従来別々に存在していたData LakeとDWHの境界を縮小しようとするものである。前述のオープンテーブルフォーマットは、まさにこのLakehouseを技術的に支える基盤として機能している。
この流れをさらに広く捉えると、RDBとDWHの関係も「分離から再統合へ」と単純に振り子が戻ったのではない。むしろ、データそのものを一つの場所へ集約する必要性を減らしながら、利用者から見た論理的な統一性を高める方向へ進んだのである。すなわち、「物理的には分離されているが、論理的には統合されている」という構造が重要になったのである。
デカップリングは、データ基盤の外部だけでなく、データベース内部にも進展した。その代表がDatabase Disaggregationである。Database Disaggregationとは、一つのデータベースシステムを構成する機能や資源を、Compute、Storage、Cache、Metadataなどの単位に分解し、それぞれを独立して配置・拡張できるようにするアーキテクチャである。
従来のデータベースでは、データベースエンジン、バッファキャッシュ、ローカルストレージなどが一体となっていた。Database Disaggregationでは、例えばコンピュートノードとストレージを分離し、複数のコンピュートノードから共有ストレージへアクセスさせるといった構成が可能になる。さらに、キャッシュやメタデータ管理を独立したサービスとして扱う構成も考えられる。
この考え方を早期から体現した実例がFoundationDBである。FoundationDBは2009年に開発が始まったオープンソースの分散トランザクショナルキーバリューストアであり、後にAppleに買収された。FoundationDBは、トランザクション管理を担うコンポーネント、データを永続化する分散ストレージ、そしてクラスタのメタデータや構成を管理するコンポーネントを明確に分離した「アンバンドル・アーキテクチャ」を採用している点に特徴がある。各コンポーネントは独立してスケールさせることができ、この構造によって高い可用性と拡張性を両立させている。FoundationDBの設計思想は、単一のデータベースエンジンにすべての機能を詰め込むのではなく、必要最小限の機能に絞ったコア（トランザクションを保証するキーバリューストア）の上に、SQLやドキュメントモデルなど多様なデータモデルを「レイヤー」として構築するというものであり、これもデカップリングの発想の延長線上にある。
したがって、Database Disaggregationはデカップリングそのものと同義ではない。デカップリングが「構成要素間の依存関係を弱める」という広い概念であるのに対し、Disaggregationは、その分離をシステムアーキテクチャとして明示的に行うものである。Database Disaggregationは、デカップリングの具体的な実現形態の一つと位置付けることができる。
さらに異なる方向からデカップリングを進めるのがData Federationである。Data Federationでは、複数のRDB、DWH、Data Lake、SaaS上のデータベースなどを物理的に一つへ統合するのではなく、それぞれのデータソースを独立したまま維持し、その上に統合的なアクセス層を設ける。
例えば、顧客情報がRDBに、売上履歴がDWHに、ログデータがData Lakeに存在していたとしても、Federationの仕組みを利用すれば、それらを一つの論理的なデータ空間として検索・分析できる場合がある。クエリを各データソースへ適切に振り分け、可能な処理をデータソース側へ押し込むQuery Pushdownなどを利用することで、物理的なデータ統合を行わずに横断的なデータ利用を実現するのである。
ここでDatabase DisaggregationとData Federationの違いが重要になる。Database Disaggregationは「一つのデータベースを内部から分解する」方向の分離であるのに対し、Data Federationは「複数の独立したデータシステムを統合的に利用する」方向の分離である。前者はシステム内部の分離であり、後者はシステム間の分離である。両者は異なるレイヤーの技術であるが、どちらもデータ基盤におけるデカップリングという大きな方向性の中に位置付けることができる。
データ基盤におけるデカップリングの本質は、「データを一つの場所に集め、その場所で処理する」という従来型の構造から、「データの物理的配置と処理・利用の場所を独立させる」という構造への転換にある。
RDBの時代には、データとコンピュートは密接に結合していた。DWHでは、OLTPと分析処理を分離するためにデータを別のシステムへコピーした。Data Lakeではストレージとコンピュートを分離し、オープンテーブルフォーマットとLakehouseでは異なるデータ基盤を論理的に統合しようとした。そしてDatabase Disaggregationではデータベース内部の構成要素そのものを分離し、Data Federationでは複数の独立したデータソースを物理的に統合せずに横断利用する方向へ進んだのである。
この変化を一貫した流れとして見ると、「物理的な結合を弱めながら、論理的な統合性を高める」という方向性が見えてくる。つまり、データを一つのシステムへ集約することで統合するのではなく、データ、ストレージ、コンピュート、データベースエンジン、アクセス層をそれぞれ独立させた上で、それらをソフトウェアによって論理的に統合するのである。
以上から、デカップリングとディスアグリゲーションは同義ではない。デカップリングは、データ基盤を構成する要素間の依存関係を弱めるという、より広いアーキテクチャ上の考え方である。これに対してディスアグリゲーションは、結合していた構成要素を明示的に分解し、それぞれを独立した資源として扱う設計手法である。
したがって、Storage-Compute Separation、Database Disaggregation、Data Federationは、それぞれ異なる対象に対する分離である。Storage-Compute Separationはストレージとコンピュートの分離、Database DisaggregationはDBMS内部の構成要素の分離、Data Federationは複数の独立したデータソース間の分離を維持した論理的統合である。
これらを包含する考え方として「データ基盤におけるデカップリング」を捉えると、RDB、DWH、Data Lake、Lakehouse、Database Disaggregation、Data Federationが互いに無関係な技術として並んでいるのではなく、データ基盤における「物理的な独立性」と「論理的な統合性」を高めてきた一連のアーキテクチャ上の変化として理解できる。
この変化を最も端的に表現すれば、データ基盤は「データを一か所へ集める」ことを中心とした設計から、「分散したデータを必要に応じてつなぐ」ことを中心とした設計へ移行しつつあるのである。
DWHはデータを集約することで分析を可能にした。一方、現代のデータ基盤では、すべてのデータを一つの場所へコピーする必要性そのものを低減し、データがRDB、DWH、Data Lake、クラウドストレージ、SaaSなどに分散して存在することを前提として、それらを必要に応じて利用する方向へ進んでいる。
Mathematics is the language with which God has written the universe.