• セールスで使用されるSalesforce
  • 経理で使用されるfreee会計
  • マーケティングで使用されるMAツールのMarketo

など、各部署・部門で使われるツールの分散が進んでいます。ツールが分散すると、各ツールで扱うデータの分散にもつながります。

データの分散を解消するため、データウェアハウス(DWH)などのツールを導入し、データの統合、集中管理を進めている企業も多いのではないでしょうか。

近年主流になったクラウド型のデータウェアハウスサービスは、ごく小さなデータからビッグデータの処理まで、難なくこなせるスケーラビリティの高さが特徴の一つです。

一方で、それを運用するデータエンジニアチーム側は、扱うデータの量に応じて負担が増し、データエンジニアチームのスケーラビリティが課題になります。

本記事で紹介するデータメッシュは、データエンジニアチームの負担を軽減しつつ、大規模なデータ処理をするために考えられたデータアーキテクチャの一つです。

データメッシュは、「データの統合と集中管理」という従来のトレンドとは真逆のアーキテクチャです。しかし、増え続けるデータ量に悩まされてるデータエンジニアの方にとっては、有効な考えになるかもしれません。

データメッシュのアーキテクチャを取り入れることで、データベース全体のマネジメントにフォーカスでき、少数のデータエンジニアチームでも無理なく運用できるようになります。

データメッシュとは

“データメッシュなアーキテクチャ”とは、統合したデータをふたたび各ドメイン(セールスやマーケティング、製品別・事業別などデータを扱う各主体)の管理に戻し、データエンジニアチームがドメイン間のデータの連携を統御することです。

この”非中央集権型”のデータ設計にすることで、従来の”中央集権型”のアーキテクチャよりデータを管理しやすくする効果があります。

中央集権型データベース非中央集権型データベース
マスターのデータベース単一のデータレイクに格納各ドメインのデータベースを利用
データの責任者データエンジニア各ドメインの責任者
データの整備データエンジニアが各ドメインのニーズに応じて行うデータエンジニアによるルールの下、各ドメインで行う

データメッシュは、

各ドメイン → 中央データベース → データのユーザー

上記の一方向の流れ(データパイプライン)に対して、データが各ドメイン間で網目(メッシュ)のようにやり取りされるのが特徴です。

データエンジニアの負担軽減と効率的なデータ活用を目的として活用され、後述する4つの原則を理解したうえで導入することが重要です。

データメッシュの必要性とは|中央集権型アーキテクチャの課題

データウェアハウスへの統合・集中管理から成る中央集約型のデータアーキテクチャには、以下の2つの問題がありました。

  • データを取得する各ドメインがデータに対しての責任を持たないため、データを活用しやすい形に整える作業がデータエンジニアの負担になった
  • データを統合したデータウェアハウスがブラックボックス化し、内部の構造や処理の責任がデータエンジニアの負担になった

増え続けるデータに対するスケーラビリティが欠けていたのです。

データエンジニアチームの負担がデータ活用のボトルネックとなり、チームの規模に依存しないデータアーキテクチャが求められるようになりました。

データメッシュはこのスケーラビリティの課題を解消しつつ、副次的な効果として、データの加工・整形の精度を向上させます。

加工・整形作業をデータエンジニアから移動させ、そのデータを一番よく理解する各ドメインに担わせることで、より実用的なデータの整備が期待できます。

データメッシュとデータレイク、データファブリックとの違い

データメッシュと同じくデータアーキテクチャに関連する言葉に、「データレイク」「データファブリック」があります。

  • データをどこに配置するのか
  • 誰が管理するのか

などの特徴に違いがあります。

それぞれ一長一短のアーキテクチャなので、自社に合ったアーキテクチャを選択することが必要です。

データメッシュとデータレイクの違い

データレイクは、従来型のデータ統合・集中管理のためのデータアーキテクチャです。社内のデータをひとつのデータウェアハウスサービスに統合し、データエンジニアチームが管理します。

社内に散逸するデータが一箇所に統合され、データを活用する土台を作れます。

「元データ→データレイク→データ活用」というデータの流れがシンプルでわかりやすいのが特徴です。クラウド型のデータウェアハウスサービスであれば、安価な導入コストで取り入れられます。

ただし、データレイクはデータエンジニアの負担が大きくなりやすい点がデメリットです。

そこでデータメッシュは、データレイクの課題を解決するためのアーキテクチャとして考えられました。データレイクは前述の”中央集権型”のデータアーキテクチャのなかでも代表的なものであり、データメッシュとは対になるアーキテクチャです。

データメッシュとデータファブリックの違い

データファブリックはデータパイプラインを構築せず、データを活用するためのアーキテクチャです。

データウェアハウスへのデータ統合はしません。社内に散在するどのデータベースにも容易にアクセスできるよう整えることで、仮想的に統一されたデータベースを構築します。

データメッシュと異なるのは、各データの処理にデータエンジニアが関わらない点です。データファブリックは、各サービスから取得したデータを自分で加工して活用する必要があり、データは取得しやすくても活用までのハードルは高い傾向にあります。

一方でデータメッシュは、データエンジニアチームが各ドメインの責任者にデータの形式や構造を分析標準化して提供させるため、ユーザーにとってデータの使いやすさが異なります。

データメッシュの4原則

データメッシュアーキテクチャは根幹に4つの重要な原則があります。

  • ドメイン主導のオーナーシップやアーキテクチャ
  • プロダクトとしてのデータ
  • セルフサービス型データ基盤
  • 横断的なガバナンス

上記の4原則を押さえずにデータメッシュを導入した場合、徐々にデータメッシュが機能しなくなる恐れがあります。

長期的にデータメッシュを維持・運用していくにはいずれも欠かせない概念です。

ドメイン主導のオーナーシップやアーキテクチャ

データ活用には、「そのデータはきちんとルールに則って収集されたものか」の保証が求められます。データの正確性が揺らぐと、データの分析結果が信頼できないものになるからです。

データメッシュのような分散管理型のデータアーキテクチャは、データの責任が分散するためデータの正確さが保証しにくくなります。

そのためデータの信頼性を守り、円滑にデータ活用するには、各ドメインが、データに対するオーナーシップ(責任)をきちんと認識している必要があります。

また収集したデータの加工も各ドメインで担当します。そのデータの構造や規模を詳しく知る現場でのデータ加工なので、無関係のデータエンジニアが加工するより効率的にデータを整えられるほか、データのエラーにも気づきやすくなる効果が期待できます。

プロダクトとしてのデータ

各ドメインが自分のデータに責任を持つために重要なのが、データをひとつの製品(プロダクト)とみなして提供する「プロダクトとしてのデータ」の考え方です。

自分のドメインで管理するデータのなかには、自分たちのデータ活用には関係ないデータも含まれているかもしれません。

とはいえ自分には関係ないデータの管理をおざなりにしてしまうと、ほかのドメインがそのデータを必要とした際に、うまく活用することができなくなってしまいます。

  • データがどこにあるかわからず、すぐにデータを渡せない
  • 適当に集めたデータだから形式がぐちゃぐちゃ

などのトラブルを防止できるかは各ドメインのオーナーシップに懸かっています。

自分のドメインだけでなく、ほかのドメインがデータを必要とした際のことも考慮し、質の高いデータの提供を念頭に置いた運用形態が「プロダクトとしてのデータ」です。

具体的には、

  • データにアクセスしやすい
  • データが正確である
  • データの説明が充実している

などが要件として求められます。

各ドメインでデータの質を担保するには、各ドメイン任せに運用せず、データエンジニアチーム主導で共通の規格・ルールをきちんと定めておくことも重要です。

セルフサービス型データ基盤

「プロダクトとしてのデータ」が浸透しても、各ドメインのデータ整備にデータエンジニアチームが駆り出されていては、データの分散管理によるメリットが損なわれてしまいます。

データエンジニアに依存せず、各ドメインが自律的にデータを取り扱えるような「セルフサービス型データ基盤」を作り上げることが必要です。

具体的には、社内教育に力を入れたり、外部からの講師を招いて各ドメインのデータエンジニアリング力を向上させたり、などの取り組みがあります。

またデータエンジニアリングの知見がない人にも、データの操作ができるようなサービスの導入も有効です。とくにETLツールは、もっともデータエンジニアの負担となるデータパイプラインの構築負担を軽減させることができ、各ツールからデータウェアハウスへのデータ統合をサポートします。

「セルフサービス型データ基盤」は、データメッシュの構築に必要なだけではありません。各ドメインのデータエンジニアリング力が向上すると、データエンジニアに依存せずドメイン内でデータの仮説・検証を繰り返すなどデータ活用を進められるようになります。

横断的なガバナンス

  • ドメイン主導のオーナーシップやアーキテクチャ
  • プロダクトとしてのデータ
  • セルフサービス型データ基盤

これらの原則をコントロールするのは、各ドメインから独立したデータエンジニアチームです。

データメッシュの必要性を説明し、各ドメインの協力を得ながら質の高いデータを提供してもらうには、データエンジニアチームの「横断的なガバナンス」が重要になります。

データのニーズに応じて各ドメインにどのようなデータを提供させるか、どうやって提供させるかを決め、それが満たされるよう各ドメインの責任者と強調してデータベース全体のマネジメントをしましょう。

ここで陥りがちなミスに、

  • 各ドメインの理解が得られずきちんとデータ管理をしてもらえない
  • トップダウンのルールの押しつけになってしまって各ドメインがついてこれない

などがあります。

データエンジニアチームは各ドメインの責任者と密にコミュニケーションをとり、必要に応じてサポートしながら、すべてのドメインが自立してデータを運用できるようサポートしましょう。

また並行して、各ドメインのデータを効率よく安定的に連携させるための基盤づくりも重要です。各ドメインの努力を無駄にしないためにも、使用するツールやデータベースの配置などデータメッシュの完成図をきちんと決めておきましょう。

データメッシュを活用する魅力

データメッシュを取り入れるメリットで、もっとも大きなものはスケーラビリティからの解放です。

従来の中央集権型のアーキテクチャと比べて、データメッシュはデータの管理が分散されているため、データ量の増加に強いアーキテクチャになります。

多くのデータを利用すれば、従来のデータ分析より、精度の高い統計的な予測分析が可能です。

次に大きなメリットがデータエンジニアの負担軽減です。

データエンジニアの知見が必要になる場面は引き続きあります。しかし日常的な業務の負担は軽くなるため、データエンジニアにしかできない大規模なデータ分析にフォーカスできるようになります。

「セルフサービス型データ基盤」が成熟していれば、基本的なデータ分析はデータエンジニアの力を借りずに運用できます。各ドメインでスピーディーに仮説検証し、分析業務の加速が期待できます。

非データエンジニア人材でもPDCAサイクルのC:CheckA:Actionを回せるようになり、誰でも効率よく打ち手を改善できるようになります。

データメッシュは企業のデータマネジメントを発展させていくために必要な考え方

ここまで読んだ方のなかには、「初めからデータメッシュのアーキテクチャを採用するべきなのか?」と疑問に思う人もいるかもしれません。

データメッシュは、

  • データエンジニアの負担を軽減できる
  • 各ドメインが自立して判断できるようになる

などのメリットがある一方で、導入には全社的な取り組みを必要とします。

便利なツールではあるものの、ある程度の導入コストが必要となるため、慎重な判断が求められます。

無理に初めからデータメッシュを目指すべきではないかもしれません。

初めは従来どおり中央集権的なアーキテクチャでデータ活用を進め、スケーラビリティに限界を感じた時点でデータメッシュの導入を検討してみるのも一つの選択肢です。

データメッシュを導入した後も、データエンジニアが直接管理したい重要なデータは分散管理せず、引き続きデータエンジニアの管理に任せてもいいかもしれません。

データメッシュそのものを導入しなくとも、取り入れられそうな部分から自社のデータマネジメントに活用していくことは有効です。

とくにデータマネジメントにソフトウェア開発の手法を取り入れる近年のトレンドはデータメッシュの原則のひとつ、「プロダクトとしてのデータ」に基づくものです。

重要なのは、各アーキテクチャの要素を正しく理解し、メリットとなる部分を柔軟に取り入れていくことだといえます。自社のビジョンや今後の事業計画、課題に合わせて、データメッシュを目指すべきか判断してみてください。

まとめ

近年注目されつつある分散管理型のデータアーキテクチャ「データメッシュ」の基本となる4原則や魅力を解説しました。

データベースの分散管理は、エンジニアの負担軽減だけでなく非データエンジニア人材のデータ活用にも効果的なデータアーキテクチャです。

データエンジニアによる場当たり的な対処では難しい、高いスケーラビリティを備えたデータ活用基盤を構築できます。

自社のデータアーキテクチャに課題を感じている方は、ぜひデータメッシュを取り入れてデータ活用を加速させましょう。

弊社は非データエンジニアのデータ活用をサポートするETLサービスのtrocco®を提供しています。

基本的な転送は画面上の設定のみで完結し、国内外を問わず主要なサービスからのデータ転送をほぼノーコードで実現可能です。データメッシュにおける「セルフサービスデータ基盤」の推進を強力にサポートするサービスです。

trocco®では、クレジットカード不要のフリープランをご案内しています。ご興味がある方はぜひこの機会に一度お試しください。

hirokazu.kobayashi

慶應義塾大学卒業後、2014年より株式会社リブセンスへ入社。データエンジニアとして同社分析基盤立ち上げをリードする。2017年より現職primeNumberに入社。自社プロダクト「systemN」におけるSpark/Redshift活用等のデータエンジニアリング業務を行うかたわら、データ統合業務における工数削減が課題だと感じ、データ統合を自動化するサービス「trocco®」を立ち上げる。