モノリシックなデータレイクから分散型データメッシュへの移行方法

中央集権型およびモノリシック

3万フィート上空から見ると、データプラットフォームアーキテクチャは下の図1のようになります。その目標は

• ビジネスを運営する運用システムやトランザクションシステム、および企業の知識を拡張する外部データプロバイダーなど、企業のあらゆる方面からデータをインジェストすることです。たとえば、メディアストリーミングビジネスでは、データプラットフォームはさまざまな種類のデータをインジェストする役割を担います。「メディアプレーヤーのパフォーマンス」、「ユーザーがプレーヤーとどのようにやり取りするか」、「再生する曲」、「フォローするアーティスト」、ビジネスがオンボーディングした「レーベルとアーティスト」、「アーティストとの財務取引」、および「顧客の人口統計」情報などの外部の市場調査データなどです。
• さまざまな消費者のニーズに対応できる信頼できるデータにソースデータをクレンジング、エンリッチ、変換することです。私たちの例では、変換の1つは、ユーザーインタラクションのクリックストリームを、ユーザーの詳細でエンリッチされた意味のあるセッションに変換します。これは、ユーザーのジャーニーと行動を集計ビューに再構築しようと試みます。
• さまざまなニーズを持つさまざまなコンシューマーにデータセットを提供することです。これは、データを探求してインサイトを見つけるための分析的な消費から、ビジネスのパフォーマンスをまとめたビジネスインテリジェンスレポート、機械学習ベースの意思決定まで多岐にわたります。メディアストリーミングの例では、プラットフォームはKafkaなどの分散ログインターフェースを介して世界中のメディアプレーヤーに関するリアルタイムのエラーと品質情報を提供したり、特定のアーティストのレコードの再生に関する静的な集計ビューを提供して、アーティストとレーベルへの財務支払いの計算を促進したりできます。

図1：モノリシックデータプラットフォームの3万フィートビュー

モノリシックデータプラットフォームが、論理的に異なるドメインに属するデータをホストして所有するということが一般的な慣例です。たとえば、「再生イベント」、「売上KPI」、「アーティスト」、「アルバム」、「レーベル」、「オーディオ」、「ポッドキャスト」、「音楽イベント」など、多数の異なるドメインからのデータです。

過去10年間、私たちはドメイン駆動設計とバウンデッドコンテキストを運用システムに成功裏に適用してきましたが、データプラットフォームではドメインの概念を大きく無視してきました。私たちは、ドメイン指向のデータ所有権から、中央集権的なドメイン非依存のデータ所有権に移行しました。私たちは、最大のモノリスであるビッグデータプラットフォームを作成することに誇りを持っています。

図2：明確なデータドメイン境界がなく、ドメイン指向データの所有権がない中央集権型データプラットフォーム

この中央集権型のモデルは、より単純なドメインと少数の多様な消費事例を持つ組織では機能しますが、豊富なドメイン、多数のソース、多様なコンシューマーを持つ企業では失敗します。

中央集権的なデータプラットフォームのアーキテクチャと組織構造には、その失敗につながる2つの圧力ポイントがあります。

• 遍在的なデータとソースの増加：より多くのデータが遍在的に利用可能になるにつれて、それをすべて消費し、1つの場所で1つのプラットフォームの制御下に調和させる能力は低下します。「顧客情報」のドメインだけでも、組織の内外に、既存の顧客と潜在的な顧客に関する情報を提供するソースが増えています。さまざまなソースから価値を得るために、データを1か所にインジェストして保存する必要があるという仮定は、データソースの増加に対応する能力を制限することになります。データサイエンティストやアナリストなどのデータユーザーがオーバーヘッドの低いさまざまなデータセットを処理する必要があること、運用システムのデータ使用と分析目的で消費されるデータを分離する必要があることを認識しています。しかし、既存の中央集権的なソリューションは、豊富なドメインと継続的に追加される新しいソースを持つ大企業にとって最適な答えではないと提案します。
• 組織のイノベーションアジェンダとコンシューマーの増加：組織の迅速な実験の必要性は、プラットフォームからのデータ消費のためのユースケースの数を増やします。これは、データの変換（集計、投影、スライス）がイノベーションのテストと学習サイクルを満たすことを意味します。データコンシューマーのニーズを満たすための長い応答時間は、歴史的に組織的な摩擦のポイントであり、現代のデータプラットフォームアーキテクチャでもそうしたままです。

まだ私の解決策を明かしたいわけではありませんが、運用システムの奥深くに隠された、断片化され、サイロ化されたドメイン指向データ（発見、理解、利用が困難なサイロ化されたドメインデータ）を推奨しているわけではないことを明確にしておく必要があります。長年の技術的負債の結果として生まれた、複数の断片化されたデータウェアハウスを推奨しているわけでもありません。これは、業界のリーダーたちが声を上げている懸念事項です。しかし、私は、これらのアクセス不能なデータの偶発的なサイロへの対応策は、すべてのドメインからのデータを所有し、管理する集中化されたチームを持つ集中化されたデータプラットフォームを作成することではないと主張します。これは、上記で学習し、実証したように、組織的にスケールしません。

結合されたパイプラインの分解

従来のデータプラットフォームアーキテクチャの2つ目の失敗モードは、アーキテクチャの分解方法に関連しています。集中化されたデータプラットフォームに1万フィートの高さからズームインすると、取り込み、クレンジング、集計、提供などの機械的な機能を中心としたアーキテクチャの分解が見られます。組織のアーキテクトと技術リーダーは、プラットフォームの成長に応じてアーキテクチャを分解します。前のセクションで説明したように、新しいソースのオンボーディングや新しいコンシューマーへの対応には、プラットフォームの成長が必要です。アーキテクトは、システムをアーキテクチャの量子に分割することでシステムをスケールする必要があります。Building Evolutionary Architecturesで説明されているように、アーキテクチャの量子とは、高い機能的凝集性を持つ独立して展開可能なコンポーネントであり、システムが適切に機能するために必要なすべての構造要素が含まれています。システムをアーキテクチャの量子に分割することの動機は、それぞれがアーキテクチャの量子を構築および運用できる独立したチームを作成することです。これらのチーム間で作業を並列化して、より高い運用上のスケーラビリティと速度を実現します。

以前の世代のデータプラットフォームアーキテクチャの影響を考えると、アーキテクトはデータプラットフォームをデータ処理ステージのパイプラインに分解します。非常に高いレベルでは、データ処理の技術的な実装を中心とした機能的凝集性を実装するパイプラインです。つまり、取り込み、準備、集計、提供などの機能です。

図3：データプラットフォームのアーキテクチャ分解

このモデルは、チームをパイプラインの異なるステージに割り当てることで、ある程度のスケールを提供しますが、機能の提供速度を低下させる固有の制限があります。独立した機能や価値を提供するには、パイプラインのステージ間で高い結合性が存在します。これは、変化の軸に直交して分解されています。

メディアストリーミングの例を見てみましょう。インターネットメディアストリーミングプラットフォームは、提供するメディアの種類を中心とした強力なドメイン構造を持っています。多くの場合、「曲」や「アルバム」からサービスを開始し、その後「音楽イベント」、「ポッドキャスト」、「ラジオ番組」、「映画」などに拡張します。「ポッドキャスト再生率」の可視化など、単一の新しい機能を有効にするには、パイプラインのすべてのコンポーネントを変更する必要があります。チームは、ポッドキャスト再生率を表示するための新しい取り込みサービス、新しいクレンジングと準備、および集計を導入する必要があります。これには、異なるコンポーネントの実装と、チーム間のリリース管理全体にわたる同期が必要です。多くのデータプラットフォームは、新しいソースの追加や既存のソースの変更を容易にするなど、拡張に対応できる汎用的で構成ベースの取り込みサービスを提供します。しかし、これは、新しいデータセットの導入に関するエンドツーエンドの依存関係管理を消費者の視点から排除するものではありません。表面的には、パイプラインアーキテクチャはパイプラインステージのアーキテクチャの量子を実現したように見えるかもしれませんが、実際には、モノリシックプラットフォームである全体パイプラインが、新しい機能に対応するために変更する必要がある最小単位です。つまり、新しいデータセットのロックを解除し、新規または既存の消費に使用できるようにすることです。これは、新しいコンシューマーやデータソースに対応して、より高い速度とスケールを実現する能力を制限します。

図4：新しい機能の導入または拡張時に、アーキテクチャの分解は変化の軸に直交しており、結合と配信速度の低下につながります。

サイロ化され、高度に専門化された所有権

今日のデータプラットフォームの3つ目の失敗モードは、プラットフォームを構築および所有するチームの構造に関連しています。データプラットフォームを構築および運用する人々の生活を十分に観察すると、組織の運用ユニット（データの発生源またはデータが使用され、行動や意思決定に役立てられる場所）から分離された、高度に専門化されたデータエンジニアのグループが見られます。データプラットフォームエンジニアは、組織的にサイロ化されているだけでなく、ビッグデータツールの技術的専門知識に基づいてチームに分割され、ビジネスやドメインに関する知識が不足していることがよくあります。

図5：サイロ化された高度に専門化されたデータプラットフォームチーム

私は、データプラットフォームエンジニアの生活を羨ましく思いません。彼らは、意味のある、真実で正確なデータを提供するインセンティブのないチームからデータを取り込む必要があります。彼らは、データを生成するソースドメインをほとんど理解しておらず、チームにドメインの専門知識が不足しています。彼らは、データの適用と消費ドメインの専門家へのアクセスを明確に理解せずに、運用上または分析上の様々なニーズに対してデータを提供する必要があります。

たとえば、メディアストリーミングドメインでは、ソース側には、ユーザーが提供する特定の機能とのインタラクションに関するシグナル（例：「曲再生イベント」、「購入イベント」、「オーディオ品質の再生」など）を提供するクロスファンクショナルな「メディアプレーヤー」チームがあり、もう一方の端には、「曲推薦」チーム、「営業チーム」（営業KPIの報告）、「アーティスト支払いチーム」（再生イベントに基づいてアーティストへの支払い計算）など、コンシューマーのクロスファンクショナルなチームがいます。悲しいことに、その間に、膨大な努力で、すべてのソースと消費に適したデータを提供するデータプラットフォームチームが存在します。

実際には、接続されていないソースチーム、データプラットフォームチームのバックログの上位に位置しようと競い合うフラストレーションを感じているコンシューマー、そして過剰に負担がかかっているデータプラットフォームチームが存在します。

私たちは、スケールせず、データドリブンな組織の作成という約束された価値を提供しないアーキテクチャと組織構造を作成しました。

ドメイン指向のデータ分解と所有権

Eric Evansの著書Domain-Driven Designは、現代のアーキテクチャ思考、そして結果として組織モデリングに大きな影響を与えました。ビジネスドメイン機能を中心とした分散型サービスにシステムを分解することで、マイクロサービスアーキテクチャに影響を与えました。チームがどのように形成されるかを根本的に変え、チームがドメイン機能を独立して自律的に所有できるようにしました。

運用機能の実装においてドメイン指向の分解と所有権を採用してきたにもかかわらず、データに関してはビジネスドメインの概念を無視してきたのは奇妙です。データプラットフォームアーキテクチャにおけるDDDの最も近い適用は、ソース運用システムがビジネスドメインイベントを発行し、モノリシックデータプラットフォームがそれらをインジェストすることです。しかし、インジェストの時点を超えると、ドメインと、異なるチームによるドメインデータの所有権の概念は失われます。

ドメイン境界コンテキストは、データセットの所有権を設計するための驚くほど強力なツールです。Ben StopfordのData Dichotomyの記事では、ストリームを通じてドメインデータセットを共有するという概念を詳しく説明しています。

モノリシックデータプラットフォームを分散化するには、データ、その場所、所有権について考える方法を逆転させる必要があります。ドメインから中央で所有されるデータレイクまたはプラットフォームにデータを流すのではなく、ドメインは、簡単に消費できる方法でドメインデータセットをホストして提供する必要があります。

私たちの例では、メディアプレーヤーから何らかの集中化された場所にデータを流し込み、集中化されたチームが受け取ることを想像するのではなく、プレーヤードメインが自分のデータセットを所有し、ダウンストリームの任意のチームが任意の目的でアクセスできるようにすることを想像してみましょう。データセットが実際に存在する物理的な場所と、それらがどのように流れるかは、「プレーヤードメイン」の技術的な実装です。物理的なストレージは、Amazon S3バケットなどの集中化されたインフラストラクチャである可能性がありますが、プレーヤーデータセットのコンテンツと所有権は、それらを生成するドメインに残ります。同様に、私たちの例では、「推奨事項」ドメインは、グラフデータベースなど、そのアプリケーションに適した形式でデータセットを作成し、プレーヤーデータセットを消費します。「新しいアーティストの発見ドメイン」など、「推奨事項ドメイン」のグラフデータセットが有用だと考える他のドメインがある場合、それらはそれをプルしてアクセスすることを選択できます。

これは、時系列の再生イベントを関連アーティストのグラフに変換するなど、特定のドメインに適した形状に変換する際に、異なるドメインでデータを複製する必要があることを意味します。

これには、従来はETLを介して、最近ではイベントストリームを介して行われてきたプッシュとインジェストから、すべてのドメインにわたるサービスとプルモデルへの思考の転換が必要です。

ドメイン指向データプラットフォームにおけるアーキテクチャの量子は、パイプラインステージではなくドメインです。

図7：ドメインに基づいてデータの所有権を持つアーキテクチャとチームの分解-ソース、コンシューマー、および新しく作成された共有ドメイン

ソース指向のドメインデータ

一部のドメインは、データの発生源であるソースと自然に整合します。 *ソースドメインデータセット* は、*ビジネスの事実と現実* を表します。 *ソースドメインデータセット* は、その起源となる運用システム（*現実のシステム*）が生成するデータに非常に密接にマッピングされたデータを捕捉します。私たちの例では、「ユーザーがサービスとどのようにやり取りしているか」や「ラベルのオンボーディングプロセス」などのビジネスの事実は、「ユーザークリックストリーム」、「オーディオ再生品質ストリーム」、「オンボードされたラベル」などのドメインデータセットの作成につながります。これらの事実は、発生源に位置する運用システムによって最もよく知られ、生成されます。例えば、メディアプレーヤーシステムは「ユーザークリックストリーム」について最もよく知っています。

成熟した理想的な状況では、運用システムとそのチームまたは組織単位は、ビジネス機能を提供する責任だけでなく、*ビジネスドメインの真実* をソースドメインデータセットとして提供する責任も負います。エンタープライズ規模では、ドメイン概念とソースシステム間に常に一対一の対応関係があるわけではありません。ドメインに属するデータの一部を提供できるシステムは、レガシーシステムと変更しやすいシステムの両方を含め、多くの場合存在します。したがって、最終的には、まとまりのあるドメインに整合したデータセットに集約する必要がある多くの*ソースに整合したデータセット*、つまり*現実データセット*が存在する可能性があります。

ビジネスの事実は、ビジネスの[ドメインイベント](https://martinfowler.dokyumento.jp/eaaDev/DomainEvent.html)として最も適切に提示され、承認されたコンシューマーがアクセスできるタイムスタンプ付きイベントの分散ログとして保存および提供できます。

タイムドイベントに加えて、ソースデータドメインは、そのドメインの変化間隔を反映した時間間隔にわたって集約された、ソースドメインデータセットの容易に消費可能な履歴スナップショットも提供する必要があります。例えば、「オンボードされたラベル」ソースドメイン（ストリーミングビジネスに音楽を提供するアーティストのラベルを示す）では、ラベルのオンボーディングプロセスを通じて生成されたイベントに加えて、月次ベースでオンボードされたラベルを集計するビューを提供することが妥当です。

ソースに整合したドメインデータセットは、内部ソースシステムのデータセットとは分離する必要があることに注意してください。ドメインデータセットの性質は、運用システムが業務を行うために使用する内部データとは大きく異なります。それらははるかに大きなボリュームを持ち、不変のタイムドファクトを表し、システムよりも変更頻度が低くなります。このため、実際の基盤となるストレージはビッグデータに適しており、既存の運用データベースとは別に存在する必要があります。セクション[データとセルフサービスプラットフォーム設計の融合](data-monolith-to-mesh.html#DataAndSelf-servePlatformDesignConvergence)では、ビッグデータストレージとサービスインフラストラクチャを作成する方法について説明します。

ソースドメインデータセットは最も基本的なデータセットであり、ビジネスの事実は頻繁に変更されないため、変更頻度も低くなります。これらのドメインデータセットは永続的にキャプチャされ、利用可能になることが期待されています。そのため、組織がその*データドリブン*および*インテリジェンス*サービスを進化させるにつれて、常にビジネスの事実に戻り、新しい集約または予測を作成できます。

ソースドメインデータセットは、作成時点での*生データ*を密接に反映しており、特定のコンシューマーに合わせて調整またはモデル化されていないことに注意してください。

コンシューマ指向および共有ドメインデータ

一部のドメインは消費と密接に整合します。コンシューマードメインデータセットとそれを所有するチームは、密接に関連する一連のユースケースを満たすことを目指しています。例えば、ユーザーの相互のソーシャル接続に基づいて推奨事項を提供することに重点を置いた「ソーシャルレコメンデーションドメイン」は、この特定のニーズに適合するドメインデータセットを作成します。おそらく、「ユーザーのソーシャルネットワークのグラフ表現」を通じてです。このグラフデータセットはレコメンデーションユースケースに役立ちますが、「リスナー通知」ドメイン（ソーシャルネットワークにいる人が聞いているものなど、リスナーに送信されるさまざまな種類の通知に関するデータを提供する）にも役立つ可能性があります。「ユーザーソーシャルネットワーク」は、複数のコンシューマーが使用できる共有され、新たに具体化されたドメインデータセットになる可能性があります。「ユーザーソーシャルネットワーク」ドメインチームは、「ユーザーソーシャルネットワーク」の常にキュレーションされ、最新の状態のビューを提供することに重点を置いています。

コンシューマーに整合したドメインデータセットは、ソースドメインデータセットと比較して性質が異なります。それらは構造的により多くの変更を受け、ソースドメインイベントを変換して、上記のグラフの例のような特定のアクセスモデルに適合する集約ビューと構造を作成します。ドメイン指向のデータプラットフォームは、これらのコンシューマーデータセットをソースから容易に再生成できる必要があります。

分散型パイプラインをドメイン内部実装として

データセットの所有権は中央プラットフォームからドメインに委任されますが、データのクレンジング、準備、集約、提供の必要性、データパイプラインの使用は残ります。このアーキテクチャでは、データパイプラインは単なる内部的な複雑さとデータドメインの実装であり、ドメイン内で内部的に処理されます。その結果、データパイプラインの各ステージが各ドメインに分散されるようになります。

例えば、ソースドメインには、他のドメインがクレンジングを複製することなく消費できるように、ドメインイベントのクレンジング、重複除去、エンリッチメントを含める必要があります。各ドメインデータセットは、提供するデータの品質（タイムリー性、エラー率など）について*サービスレベル目標*を設定する必要があります。例えば、オーディオ「プレイクリックストリーム」を提供するメディアプレーヤー・ドメインには、組織のイベントエンコーディング標準に準拠した、重複除去されたほぼリアルタイムの「オーディオ再生クリックイベント」ストリームを提供するドメイン内のクレンジングと標準化データパイプラインを含めることができます。

同様に、集中型パイプラインの集約ステージは、消費ドメインの実装詳細に移行します。

図8：パイプラインをドメインに2次的な懸念事項およびドメインの内部実装詳細として分散する

このモデルでは、各ドメインで独自のデータ処理パイプラインの実装、テクノロジースタック、ツールを作成することに重複した労力が生じる可能性があると主張する人もいるかもしれません。[データとプラットフォームの思考の融合：セルフサービス共有データインフラストラクチャ・アズ・ア・プラットフォーム](data-monolith-to-mesh.html#DataAndSelf-servePlatformDesignConvergence)について説明する際に、この懸念事項にすぐに対応します。

ドメインデータをプロダクトとして

過去10年間で、運用ドメインは、組織の他の部分に提供する機能に[プロダクト思考](https://martinfowler.dokyumento.jp/articles/products-over-projects.html)を組み込んできました。ドメインチームは、これらの機能を組織内の他の開発者へのAPIとして、より高度な価値と機能を作成するための構成要素として提供します。チームは、検出可能で理解しやすいAPIドキュメント、APIテストサンドボックス、綿密に追跡された品質と採用KPIを含む、ドメインAPIの最高の開発者エクスペリエンスの作成に努めています。

分散型データプラットフォームを成功させるには、ドメインデータチームが同様の厳格さでプロダクト思考を適用し、データ資産を製品として、組織内の他のデータサイエンティスト、ML、データエンジニアを顧客として考える必要があります。

図9：製品としてのドメインデータセットの特徴

インターネットメディアストリーミングビジネスの例を考えてみましょう。その重要なドメインの1つは「再生イベント」であり、誰が、いつ、どこでどの曲を再生したかです。この重要なドメインには、組織内にさまざまなコンシューマーが存在します。例えば、ユーザーエクスペリエンスと潜在的なエラーに関心のあるほぼリアルタイムのコンシューマーは、顧客エクスペリエンスの低下や着信顧客サポートコールが発生した場合に、エラーを迅速に回復するために対応できます。また、日次または月次の曲再生イベント集計の履歴スナップショットを好むコンシューマーもいくつかいます。

この場合、「再生された曲」ドメインは、組織の残りの部分に2つの異なるデータセットを製品として提供します。イベントストリームで公開されるリアルタイム再生イベントと、オブジェクトストアでシリアル化されたファイルとして公開される集約再生イベントです。

この場合、ドメインデータ製品である、あらゆる技術製品の重要な品質は、コンシューマー、つまりデータエンジニア、MLエンジニア、またはデータサイエンティストを喜ばせることです。コンシューマーにとって最高のユーザーエクスペリエンスを提供するために、ドメインデータ製品は次の基本的な品質を備えている必要があります。

セクションデータとセルフサービスプラットフォーム設計の融合では、各データ製品に対して上記の機能を容易かつ自動的に実現する共有インフラストラクチャについて説明しています。

ドメインデータのクロスファンクショナルチーム

製品としてデータを提供するドメインは、(a) データ製品オーナーと(b) データエンジニアという新しいスキルセットで強化する必要があります。

データ製品オーナーは、データ製品のビジョンとロードマップに関する意思決定を行い、消費者の満足度を懸念し、ドメインが所有および生成するデータの品質と豊かさを継続的に測定および改善します。彼女は、ドメインデータセットのライフサイクル（データとスキーマの変更、改訂、廃止のタイミング）を担当します。彼女は、ドメインデータ消費者の競合するニーズのバランスを取ります。

データ製品オーナーは、データ製品の成功基準とビジネスに合わせた主要業績評価指標（KPI）を定義する必要があります。たとえば、データ製品の消費者がデータ製品を発見して正常に利用するまでのリードタイムは、測定可能な成功基準です。

ドメインの内部データパイプラインを構築および運用するには、チームにデータエンジニアを含める必要があります。このようなクロスファンクショナルチームの素晴らしい副次的効果は、さまざまなスキルの相互受粉です。私の現在の業界における観察では、一部のデータエンジニアは、仕事の道具の使用方法に習熟している一方で、データ資産の構築に関しては、継続的デリバリーや自動テストなどのソフトウェアエンジニアリングの標準的な慣行を欠いていることがわかります。同様に、運用システムを構築しているソフトウェアエンジニアは、多くの場合、データエンジニアリングツールセットの使用方法を経験していません。スキルセットのサイロを解消することで、組織が利用できるデータエンジニアリングのスキルセットのプールが拡大し、深化します。DevOpsムーブメントと、SREなどの新しいタイプのエンジニアの誕生でも、同じクロススキルの受粉を観察しています。

データは、あらゆるソフトウェアエコシステムの基盤となる要素として扱われる必要があります。そのため、ソフトウェアエンジニアとソフトウェアジェネラリストは、データ製品開発の経験と知識をツールベルトに追加する必要があります。同様に、インフラストラクチャエンジニアは、データインフラストラクチャの管理に関する知識と経験を追加する必要があります。組織は、ジェネラリストからデータエンジニアへのキャリア開発パスを提供する必要があります。データエンジニアリングスキルの不足により、セクションサイロ化された、そして高度に専門化された所有権で説明されているように、中央集権的なデータエンジニアリングチームを形成する局所最適化が行われています。

図10：明示的なデータ製品所有権を持つクロスファンクショナルドメインデータチーム