データメッシュ概要とAWSでの構築パターン

今回はjr.championsアドベントカレンダー企画に参加させていただくにあたり、データメッシュについてと、AWSでの構築パターンについて紹介できればと思います。

<h1>データメッシュについて</h1>

### データメッシュとは
そもそも、データメッシュとはオライリー社から出版されている[クラウドデータレイク](https://www.oreilly.co.jp/books/9784814400676/)によると、
>分権的な形でデータインフラストラクチャとオペレーションを実行できるようにして、社内全体でデータをよりアクセスしやすく、インサイトを得やすくすることを目的としたアーキテクチャ

と記述があります。まだちょっと抽象度が高いかなと思うので、本書をもとに、内容をさらに内容を深ぼってみると、
- **分権的な形で**
    - 組織の面
        - データの全てを行う中央のデータプラットフォーム部門を置く形から、全ての部門にデータのニーズを担当する担当者（スペシャリスト）をおいて、分権化する
    - アーキテクチャの面
        - 中央にデータなデータウェアハウスやデータレイクを置く形から、分散化されたデータレイクとデータウェアハウスのメッシュを作る形にシフトする
    - 運用の面
        - データガバナンスが連邦型へシフトし、各ビジネスドメインが自立的にデータの管理や活用を行う
- **アクセスしやすく、インサイトを得やすくする**
    - 社内のデータチームやビジネスユニットを顧客とみなし、データをプロダクトとして管理する
<br>
つまり、データやそれに関するオペレーションをビジネスドメイン単位で分散化し、社内のデータ消費者に対するデータのプロダクトとしての価値を上げると言うことがデータメッシュの根幹にあるのではと個人的には解釈しました。

### データメッシュの４原則
織がデータメッシュを採用するためには、以下４つの原則を遵守する必要があるとされています。調べてみるとなかなか難しい内容が多いなと思ったので、私なりに噛み砕いて解釈した内容を記載します。

- <b>分散ドメイン駆動型アーキテクチャ</b>
    - データ管理の責任が、ビジネス部門やドメインに委ねられる。
- <b>製品としてのデータ</b>
    - データアセットを製品、組織の他のビジネスチームやデータチームを顧客とみなし、優れたユーザーエクスペリエンスを提供する。
- <b>セルフサービスのデータインフラストラクチャ</b>
    - ビジネスチームがデータを管理する一方で、データエンジニアリングチームは共通のデータプラットフォームの管理をする。データインフラストラクチャの青写真を定義、管理する。
- <b>フェデレーションガバナンス</b>
    - ドメイン全体に適応させるグローバルな基準やポリシーを決定しながら、ドメイン内での基準やポリシーを実装させ、責任共有としてのセキュリティを実装する。

前述したデータメッシュの要素と技術・組織の側面で合致している内容だなと、個人的には感じます。

### データメッシュが現れた背景
そんなデータメッシュですが、データメッシュは主流なデータ基盤の方式である中央集権的なデータレイクの問題を解決するための対応策として考案されたものです。

- データ利用のボトルネック
    - 中央に１つのデータチームが複数部署のデータ依頼に応じる形式では、データを使うシナリオが増加すると、活用実現までの時間が足りなかったり、データの業務文脈の理解が足りず、適切な支援に繋がらない可能性がある。
- 密結合なアーキテクチャによる拡張性の低下
    - データパイプラインが肥大化し、密結合になり拡張性や変更の容易性が低くなる可能性がある。

これらを解決することで、拡張性のある分権型アーキテクチャを実現でき、データ利活用の促進につながると考えられ、これこそがデータメッシュの持つメリットでもあると言えます。

<h1>AWSでの構築パターン</h1>
ここでAWSでデータメッシュを実現しようとした際、どのようなパターンになるのか、検討してみます。
<br>

### DataZoneベース
 AWS構築する場合には、DataZoneが最初に候補に上がるかなと思います。マネージドサービスで、少し設定をするだけで綺麗なUIが整ったデータポータルが作成され、データ活用のための環境のデプロイやデータのアクセスコントロール、カタログ機能まですぐに使用することができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958834/0b7d8594-54c6-a9cb-f9b2-6a30b4e4f5dc.png)
参考：[AWS offerings for data mesh](https://catalog.us-east-1.prod.workshops.aws/workshops/c7b9d931-6d86-4994-99e5-77ada5aaffbc/ja-JP)

![スクリーンショット 2024-12-29 2.18.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958834/354eed73-5e66-85a7-3d28-1cea97c03726.png)
<em>すぐにこのような画面ができ、画面にあるようなデータのアセットや環境（リソース）がすぐに画面から作成できる。</em>

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958834/4fdbd7e1-8ca6-937d-3830-d3c04d9cbac8.png)
<em>主にメタデータ作成の部分で生成AIが使えるようになった。使いこなせたら便利そう</em>


### Data.all
Data.allというオープンソースのフレームワークを使用すれば、DataZoneよりもより高い自由度でかつ、データメッシュが求める分散管理、データの発見、アクセス制御といったData.allの機能を提供し、フルスクラッチよりも効率的に実装できそうです。DataZoneでは要件を満たせない、やりたいことができない場合にはこれが選択肢に上がって来るかなと思います。

参考：[data.all](https://data-dot-all.github.io/dataall/architecture/#end)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958834/c6c530c4-455d-d5bc-83cd-3bae66a57fad.png)
<em>サンプルをみると、サーバーレスっぽくて良さそう</em>

### LakeFormation
一からデータメッシュを構築したいという場合には、Lake Formationでアクセス管理等しつつ、そのほかの機能については自由に実装していくという形になりそうです。
<br><br>

<hr>

以上、データメッシュについてと、AWSでの構築パターンについてでした。DataZoneについてはいつか実際に使ってみての所感や実装方法など、記事に残せればと思っています。