Snowflake上で構築したデータメッシュで、データチームに力をもたらす
注：本記事は(2021年8月30日)に公開された(Empower Data Teams with a Data Mesh Built on Snowflake)を翻訳して公開したものです。
この数年の間に、データとデータチームを拡大してより多くの価値をより迅速に実現することを目指す組織を悩ませていた多くの課題の解決に貢献する新しいフレームワークが登場しました。データへの障壁を解消して大規模に価値を実現することは非常に高い目標であり、Snowflakeもこうした問題を解決するお客様のお役に立ちたいと考えています。他のアーキテクチャパターンと同様、データメッシュで成功するには、単に技術の問題を解決するだけではなく、成功に向けて適切なテクノロジーをセットアップして、組織全体で変化を促進することが重要になります。
ここからは、データメッシュの基本原理を分類し、当社独自のプラットフォームに支えられたSnowflakeデータクラウドがいかにデータメッシュへの道のりに適した基礎の構築を実現するかを確認していきましょう。
データメッシュの4つの原理
データメッシュとは、Thoughtworks社のエマージングテクノロジー部門ディレクターであるZhamak Dehghani氏が、自身の影響力あるブログ記事「How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh（モノリシックなデータレイクから分散型のデータメッシュへの移行方法）」1 および「Data Mesh Principles and Logical Architecture（データメッシュの原理と論理アーキテクチャ）」2の中で生み出した言葉です。データメッシュの概念は、組織がガバナンスと構造化の度合いが低いモノリシックなデータレイクにデータを格納する際に組織が強いられるトレードオフへの対応手段として生まれました。データソースとデータ利用者の数が増えるにつれ、それらすべてをつなげるために必要なデータパイプラインの数も増えました。結果、この難しいテクノロジーのための開発スキルを持つ専門チームの作業負担がますます増え、仕事でデータを必要とするドメインエキスパートから切り離されていました。下流のデータ利用者は、複雑なデータパイプラインと緩くつぎはぎされたテクノロジーのせいで必要なデータをすぐに入手できず、エンジニアリングチームは需要に応えようと疲労困憊していました。
図1は、Zhamak Dehghani氏の「Data Mesh Principles and Logical Architecture（データメッシュの原理と論理アーキテクチャ）」から引用したものですが3、データメッシュアーキテクチャを定義する4つの基本原理を示しています。
- ドメインドリブンのオーナーシップ
- プロダクトとしてのデータ
- セルフサービスインフラストラクチャー
- フェデレーテッドガバナンス
図1：データメッシュアーキテクチャの4つの基本原理
原理1：ドメインドリブンのオーナーシップとアーキテクチャ
データメッシュの1つ目の原理は、データの力とオーナーシップをドメインチームの手に委ねることです。ドメインチームがエンドツーエンドにデータを所有します。つまりソースや取得したデータが使用に適しているかを確認するところから、必要な処理パイプラインを構築、維持すること、さらにはデータをプロダクトとして利用できるよう、品質保証やガバナンス管理を施しながら、他のドメインチームに供給することまでがこれに該当します。ドメインチームは、部門、事業部門、その他類似のグループごとに定義できますが、特にデータが新しいデータプロダクトに関連している場合、流動的に新しいドメインチームを追加できるようにしておく必要があります。
原理2：プロダクトとしてのデータ
1つ目の原理からも分かるとおり、ドメインチームは単にデータに対して責任を負うだけではなく、結果として得られるデータプロダクトにも責任を負います。さらに、データプロダクトは、他のあらゆるプロダクトと同様に扱われる必要があります。データプロダクトは、利用者や他のドメインチームによるディスカバリー（発見）や使用が容易である必要があります。さらに、ドメインの責任者はこれらのプロダクトの品質と正確性を確保するため、メンテナンスと更新（または非推奨化）に対して責任を負います。現実に当てはめて考えると、たとえばサプライチェーンチームが在庫データプロダクトを作成し、それをマーケティングチームが新しい割引キャンペーン構築に利用する、または地域チームが新たな発注に利用する、といった事例が挙げられます。
原理3：プラットフォームとしてのセルフサービスインフラストラクチャー
3つ目の原理は、すべてをセルフサービスとし、ドメインチームの負担を減らすことです。データメッシュ設計において、複雑なテクノロジーやニッチなスキルは持続可能性がありません。インフラストラクチャーのメンテナンスやリソースの限界に悩まされることなく、あらゆるドメインチームがデータプロダクトの構築やサービスのためにいつでも利用できる共通のプラットフォームや一連のツールである必要があります。
原理4：フェデレーテッドガバナンス
データメッシュの成功のための最後の要素はガバナンスです。データメッシュアーキテクチャは、アクセス管理やデータ保護を犠牲にしては成り立ちません。グローバルなガバナンスポリシーや管理を徹底することと、データプロダクトの開発や共有にあたって各ドメインチームがそれらのポリシーを定義、実装できるようにすることとの間でバランスを取る必要があります。こうしたフェデレーテッドガバナンスは、データのプライバシーやコンプライアンスを確保するためだけでなく、大規模なデータディスカバリーを支援するためにも重要です。
Snowflakeを利用したデータメッシュの成功
Snowflakeデータクラウドは組織とデータチームを、サイロや複雑さなしで、必要な時に、最も関連性あるデータにつなぐよう設計されています。その仕組みに関しては、データクラウドは、大規模でのパフォーマンス、使いやすさ、管理されたデータシェアリングとコラボレーションを念頭に独自に開発されたSnowflakeのプラットフォームに支えられており、データメッシュ展開の成功に必要となる一元化された標準と分散化されたオーナーシップの両方をサポートする上で最適です。
プラットフォームとしてのセルフサービスインフラストラクチャーの提供
セルフサービスインフラストラクチャーの構築は、適切な技術が役立つ最も明白なデータメッシュ原理です。適切なデータのアクセスから、その処理、準備、分析、そしてモデルの作成まで、データプロダクトライフサイクルのあらゆる段階をサポートするため、ドメインチームがオンデマンドでリソースやツールにアクセスできることが重要です。Snowflakeのプラットフォームは、ドメインチームにワンストップショップを提供しながら、広範なスキルをサポートします。
Snowflakeの伸縮性あるパフォーマンスエンジンにより、ドメインチームは大規模なパイプライン、アドホック検索、BIレポート、特徴量エンジニアリング、インタラクティブなアプリケーションなど、すべてを単一のエンジンで実現できます。これにより、組織は速度や便利さを犠牲にすることなく、アーキテクチャをシンプル化できます。チームが作業にSQLを使用していようと、コード（Java、Scala、Pythonなど）を使用していようと、またはそれらの混合であろうと、パフォーマンスエンジンはすべてを同じようにサポートできます。伸縮自在な拡張性と分離されたマルチクラスタコンピュートにより、各ドメインチームは、パフォーマンスや他のチームとの同時実行を気にすることなく、専用リソースにアクセスできます。
ドメインドリブンのオーナーシップとプロダクトとしてのデータの提供
この拡張性ある専用リソースという最後のコンセプトにより、Snowflakeのカスタマーは分散型でドメインドリブンの設計を論理的に実装し、標準の一元的プラットフォームですべてを管理することができます。この一元的なSnowflakeプラットフォームは、多種多様なデータタイプやファイルフォーマットを組み込むことができ、さらには外部データへのアクセスにも対応しているため、データ環境を包括的にカバーできます。また、オートメーションを組み込んだ完全マネージド型のサービスであるため、ドメインチームは簡単にセルフサービスでき、ITチームはプロビジョニング、メンテナンス、アップグレード、またはダウンタイムの心配をせずに済みます。さらに、ドメインチームは個別のユニットとして稼働しながら任意の数のユーザー数に規模を調整できるとともに、インフラストラクチャーの専門知識や調整の必要なしに、事実上どのような量のデータもオンデマンドで扱うことができます。
しかし、この設計をもってしても、データメッシュは依然として専門分野ごとのサイロを大量に生み出すリスクを持ちます。サイロはどの組織にとっても致命的です。この問題を回避しながらデータメッシュの成功を確実なものにする上で、Snowflakeは特に適しており、ドメインチームは他のチームとの間でETLやコピーを介さずに、データプロダクトをシームレスに接続、シェアすることができます。
Snowgridという独自のテクノロジーを活用することで、Snowflakeは組織内だけでなく、パートナーやサードパーティとのデータシェアリングやコラボレーションの在り方を変えました。Snowgridを通じて、ドメインチームがデータの単一のコピーを安全にシェアすると、他のドメインチームはそれを発見し、即座にアクセスできます。ETLは一切不要です。すべてのデータはライブで、更新があると自動的に他のチームに伝播されます。チームはSnowflakeデータマーケットプレイスで提供されているサードパーティデータの広範なエコシステムを活用することで、時間のかかるデータの調達やFTPサイクルなしに、自身のデータプロダクトをエンリッチ化できます。さらにチームは単にプロダクトとしてデータを利用するだけでなく、事前構築済みのモデルや関数をプロダクトとして公開、シェアし、他のドメインチームに知識を提供することで、付加価値をもたらすことができます。
特に強力なのは、Snowgridの範囲はグローバルに及ぶことから、ドメインチームがリージョンやクラウドによって分かれていても、シームレスに接続できるという点です。つまり組織は、単一のクラウドベンダー上で標準化する必要なしに、またリージョン的なサイロがあってもデータメッシュを運用することができます。各ドメインチームは、好みのクラウド上、またはリージョンでローカルに運用できますが、すべては各ドメインに向けて難読化されます。データプロダクトは、ドメインチーム内でも地球の反対側にいるチームでも、まるで同じオフィス内にいる1つのチームのように共有できます。さらに組織は、クラウドまたはリージョン間でデータをレプリケーションして滞りのないオペレーションを実現し、新たなレベルのビジネス継続性と規制遵守を維持できます。
フェデレーテッドガバナンスの実現
Snowgrid内では、すべてのネイティブクロスクラウドガバナンス制御機能がフェデレーテッドガバナンスを可能にする基礎ブロックの役割を果たします。組織は、ドメインオーナーに独自の詳細なポリシーの定義と適用を許可することと、一元的なマネージド型のガバナンスプロセスを運用することとの間で適切なバランスを取ることができます。ポリシーはデータおよびロールレベルで定義できるほか、そのデータをフォローすることで、データがクラウド、リージョン、またはワークロード間でシェアされていても、一貫したポリシーの運用が徹底されます。複数のドメインチームが同じデータをディスカバリーおよびクエリしながら、結果ビューはロールやデータの機密性に応じて変えることができるなど、チームにデータの価値を提供しつつ、大規模でのガバナンスを大幅にシンプル化できます。さらに組織はこれらのガバナンス管理機能を、Alationなどの既存のガバナンスおよびカタログ標準と統合して、品質、発見しやすさ、およびデータ保護をドメインチーム全体でさらに強化できます。
Snowflakeでは、初めに直面する技術的障壁を解消しながら、データに対するモノリシックなアプローチから離れ、必要な時に必要なデータとチームをつなげる、より流動的かつ動的なモデルに移行するようカスタマーを支援してきました。あるカスタマーは、「Snowflakeがあることで、DPG Mediaはプラットフォームを動作させ続けることよりも、プラットフォームを利用して自らの専門を実現することに集中できます。」と、述べていました。（DPG MediaがSnowflakeでデータメッシュをどのように導入したか、詳しくは同社の記事：Data Mesh — A Self-service Infrastructure at DPG Media with Snowflake（データメッシュ — Snowflakeを利用したDPG Mediaのセルフサービス型インフラストラクチャー）4およびData mesh at DPG Media（DPG Mediaのデータメッシュ）を参照してください5）。データメッシュの導入へ向けて進む際はぜひ当社にご連絡ください。じっくりお話を聞かせていただきます。
著者
