大規模データ管理 ―エンタープライズアーキテクチャのベストプラクティス

著者 : Piethein Strengholt 村上列

• オライリー・ジャパン (2022年12月2日発売)

作品紹介・あらすじ

急増するデータと最新のビジネス、開発に沿ったデータアーキテクチャを解説！
データ管理と統合が急速に進化し続ける中、データウェアハウスのようにすべてのデータを一か所に保存すると拡張性が持てなくなるため、データは分散され、技術的ソリューションに従って利用できるようになる必要があるとし、企業が、複雑で緊密に結合したアーキテクチャから、現代のデータ消費に対応できるより柔軟なデータアーキテクチャに移行するための方法や考え方を解説するという書籍です。

感想・レビュー・書評

[usk108さんの感想 · 2022年12月30日]

ドメイン駆動設計やマイクロサービスといった新しい考え方も紹介して取り入れつつ、大規模にスケールしやすい「データ管理システム」を作る際の考え方について紹介されている。
紹介されている Scaled Architecture では、ドメイン駆動設計(DDD)の考え方をベースに、データ連携を行う際にはドメイン毎に境界をひいて、外部との連携を行うためのインターフェイスを定義することが大事としている。
データと提供する側のドメインのインターフェイスを使うことで、データプロバイダ -> データレイヤー -> データコンシューマー という流れでのデータ連携が素早く開始できるようにするのが、アーキテクチャの目的である。
データレイヤーの作り方は大きく 3 つあり、1) API によるデータアクセス、2)読み取り専用データストアの利用、3) ストリーミングによるデータ連携 である。
2 の読み取りデータストアとしても RDB、NoSQL、あるいはオブジェクトストレージなど状況に応じて選べばよく、特定の技術を指定するものではないので、使用される技術に目新しい概念はないが、データ連携の手法を整理する上での手法を整理されている点は有益だと思う。

アーキテクチャのポイントは、中央集権にしすぎず、データ利用したい人が各々セルフサービスでデータを見つけて、活用を始められるようにするってところだと思う。
中央、共通プラットフォームで機能を提供するものとして、メタデータ登録・管理（どこにどんなアプリ・データがあるのか）やアクセス可否を判定する機能やそのポリシーの管理といった共通的に求められる部分があるが、そこにデータを投入するのはデータプロバイダ/コンシューマーになる。
またデータ連携の際にはデータ共有合意というデータプロバイダ・コンシューマ双方による取り決めを行い、その契約内容をドキュメント化し、その中で定められた用途やアクセス範囲・アクセス者に絞ってデータ連携が行われる。
データガバナンス部門といった専門のチームを作って、ドメインをまたいだデータ連携を促進したり環境を整備する活動が求められる。

以下、所感。

実際にこの考え方を採用できる企業は少ないんじゃないかと感じた。
まずデータプロバイダ側は大変そう。
使われるかわからないデータ活用のために情報整備したりインターフェイス作ったりしないといけないし、そのためのモチベーション本当に生まれるのかな？と思った。
コストメリットあると判断できるのって相当既に大規模にデータ活用してて、社内がカオスになってて、それによるコストが高くなってしまってる状態なんじゃないかと感じた。
既に色んな別部署にデータを提供していて、それによる苦労が多いって状況なら、それを解決するための方針としてはアリかもしれない。
逆に言うと、まだデータ連携事例もなく、これから作り始める段階であれば、最初からこのアーキテクチャ目指すのは厳しいんじゃないかと。
とはいえ、考え方の一部を取り入れるのは良さそう。（そこまで具体的な実装の話は少ないけど）
データプロバイダ側にも新たな業務が生まれるだけでなく、共通部分を管理したりするデータガバナンス部門が求められる点も、実際の企業でのハードルは高いように感じた。

現実的な応用としては、ドメインをまたぐような何らかのデータ連携をやる時に、今後その活動を企業内（外）で横展開しやすいようにするためにどんな仕組みがあると嬉しいのか、の着想を得るための本として使うと良いかも知れない。
「メタデータの収集もいきなり全部やろうとすると破綻するからまずは不可欠なところから始めると良いよ」という説明もあるように、最初から Scaled Architecture を全部作ろうとするんじゃなく、小さく始める取り組みをどう進めると筋が良さそうかを判断する材料として使えると良さそう。

あと本自体の感想としては、書籍全体として実装例や具体例は少ないため、シンプルに何を言ってるかよくわからない部分と、「なんとなく分かった気がするけど実際どうやるの？」という気持ちになった部分もある。
「ここまで話した機能を実現するには OSS だと〜、〜が有名。AWSだと〜、Azureだと〜、GCPだと〜。」といった説明はあるので具体的な実装方法はそこから調べられる部分もあるが、あくまでも考え方を紹介している本だと割り切った方が良さそう。

[hmk404さんの感想 · 2022年12月10日]

結構微妙。
著者の考えるプラクティスの紹介がつらつらと並んでいて、でもなんだか内容が薄いというか表面的なようにしか自分には読み取れなかった。自分の持っている経験との相性の問題か。

著者の書籍を通して言いたいことが最後まであまりよく伝わってこずに終わったので人にはおすすめできない。
タイトルと目次的に期待感が高かったので惜しい気持ち。

[japapizzaさんの感想 · 2024年5月18日]

1章　データ管理の崩壊
◾️まとめ
　データウェアハウスは今後も存続します。なぜなら、さまざまなソースからのデータを、特定のコンテキストに調和させる場面は常に存在するからです。データを段階的に処理して分離するパターンも、スキーマのクレンジング、修正、変換という作業もなくならないでしょう。Bill Inmon 氏(https://oreil.ly/wlB9w)、Ralph Kimball氏(https://oreil.ly/ToDNb)が作ったアーキテクチャスタイルや、データボルトモデリング(https://oreil.ly/Fj8JL)は、ユースケースの要件によっては、うまく適用できる場合もあるでしょう。データレイクについても同様です。膨大な量のデータを分散処理して分析する必要性はすぐにはなくならないでしょう。
　しかし、私たちは大規模なデータをどのように管理し、分散させるかを考えなければなりません。エンタープライズデータウェアハウスのような大きなサイロは、拡張性がないために消滅するでしょう。統合レイヤーが密結合してしまい、コンテキストが失われ、データ消費量が増加することにより、企業は代わりとなる方法を探さなければならなくなるでしょう。データを生のまま取り込むデータレイクアーキテクチャは、もう一方の極端な例です。生データは、いつでも変化する可能性があり、実験やユースケースを本番環境に導入できません。また、生データを活用するには、多くの作業を繰り返し行わなければなりません。

　このように複雑にサイロ化したデータの問題を解決するのが、Scaled Architectureです。これはドメインベースの参照アーキテクチャです。


2章　Scaled Architectureの紹介：大規模なデータ管理
◾️Scaled Architecture の原則
原則1:変更はゴールデンソースでしか行われない。
　ゴールデンデータセットとその要素の変更は、所有者の承認を得て、ドメイン内のゴールデンソースでのみ行うことができます。
原則2:ゴールデンデータセットだけを提供する。
　ゴールデンソースシステムからは、生成されたデータ(ゴールデンデータセット)のみを配信することができます。
原則3:ゴールデンデータセットはアプリケーションのサブセットである。
　ゴールデンデータセットは、あるアプリケーション内で生まれるため、複数のアプリケーションにまたがることはできません。
原則4:ゴールデンデータセットと要素は、検索性を高めるために中央に登録される。
　透明性と信頼性を提供するためには、ゴールデンソースと所有権メタデータ(データに関するデータ)を、ツールやプラットフォームを通じて中央で利用できるようにすることが重要です。そのためには、すべてのドメインが一意のゴールデンデータセットと要素を中央で管理されるように登録し、自らが生成し公開するデータと関係付ける必要があります。
原則5:新しいデータは新しい所有権を生む。
　データが変更され、新しい事実が作成されると、新しい所有権が発生します。フィルタリング、統合、結合、大文字と小文字の変換、フィールド名の変更、集約などの単純な「構文変換」では、事実が変わらないため、新しい所有権は生まれません。
原則6:受け取ったゴールデンデータセットを転送することは許されない。
　データコンシューマが入手したゴールデンデータセットは、データ所有者やデータセキュリティチームの承認なしに、ほかのドメインに流通させることはできません。
原則7:必要のないDDSは作成しない。
　ゴールデンデータセットを、管理されていない状態でコピーすることは、管理コストが高くなり、コントロールが難しくなるため、避けるべきです。データ統合は複雑です。ユーザーは、抽出したデータやデータのコピーが必要でないならば、保持しつづけてはなりません。アプリケーションからデータを抽出し、データコンシューマ側に保存することは、新たに作成されたデータを保存する必要がある場合のみにしてください。
原則8:データ流通と消費は、契約や合意によって守られる。
　データの提供と消費に関する説明責任とデータガバナンスについては、データ配信契約とデータ共有合意によって守られます。
原則9:データはドメイン全体で管理・流通される。
　データ品質、データパイプライン、データが読み出せることは、ドメインの関心事です。そのデータについて熟知しているはずの人々が、データの管理に責任を持ちます。データ所有権モデルは、中央管理ではなく分散管理とします。
原則10:コンテキスト境界はインスタンス化されたビジネスケイパビリティに関係付けられる。
　コンテキスト境界は、ケイパビリティインスタンスまたはその一部を実装します。つまり、コンテキスト境界は、その実装を表すものです。そのため、コンテキスト境界は同じ解決空間に焦点を合わせます。
原則11:コンテキスト境界は、1つまたは複数のアプリケーションに関連付けることができる。
　コンテキスト境界は、1つのアプリケーションで構成されても、複数のアプリケーションで構成されてもかまいません。複数のアプリケーションで構成する場合、すべてのアプリケーションは、あるバリューストリームにおいて同一の(ビジネス)ケイパビリティインスタンスに対して、価値を提供することになります。
原則12:ユビキタス言語は、コンテキスト境界の中で共有される。
　自身のコンテキスト境界内で、データを流通するアプリケーションペアプリケーションコンポーネントは、同一のユビキタス言語を使います。同じ用語や定義が別の意味で使われることはありません。それぞれのコンテキスト境界は、概念データモデルと1対1の関係になります。
原則13:コンテキスト境界は、インフラストラクチャー、ネットワーク、組織から独立する。
　アプリケーション機能、プロセス、データをまえて、どのようにまとめるかを考えてください。データ管理の観点で言えば、コンテキスト境界をどう作るかについては、インフラストラクチャーや、ネットワーク、組織は関係ありません。
原則14:1つのコンテキスト境界は、1つのチームに属する。
　理想的には、それぞれのコンテキスト境界は、1つのアジャイルチームまたはDevOpsチームに属します。1つのチームにしか属していないのであれば、結合点をどうするかは管理しやすくなり、チームメンバー全員が簡単に理解できるからです。
原則15:境界線は厳密にする。
　コンテキスト境界の境界線は厳密にしてください。コンテキスト境界はそれぞれ区別してください。一括りで考えるべきビジネス上の関心や、プロセス、データは、一括りにして、コンテキスト境界内で維持・管理するようにしてください。
原則16:境界を越えるときは分離する。
　コンテキスト境界内では、密結合できます。しかし、境界線を越えるときには、インタフェースを分離してください。
原則17:境界内であれば、どんな形式でも問題ない。
　明示的な境界線を守っているのであれば、あるコンテキスト境界でのデータ形式はどのようなものでもかまいません。
原則18:仮想化と調和は、コンテキスト境界の中でのみ許される。
　データの仮想化やデータの調和は、レイヤーを追加・作成することと同じように許されます。ただし、それはコンテキスト境界の境界内に限られます。
原則19:データは、付加システムや中間システムを介して配信されるべきではない。
　ゴールデンソースシステムを難読化する付加システムを使うと、複雑さが増大し、データとその品質が変化し、データのリネージをたどってデータの出所を調べることが難しくなります。データの受け渡しに付加システムや中間システムを使用することは推奨されません。
原則20:データレイヤーはドメインロジックを含むべきではない。
　ドメインロジックや複雑な統合は、コンテキスト境界内にとどめるべきです。統合コンポーネントに含めてはなりません。こうすることで、隠蔽されたドメインロジックによって、ほかのドメインとの対話を邪魔されるという不安を抱えることなく、ドメインは価値を提供することに集中できます。
原則21:アプリケーションの技術的な情報を隠す。
　この原則は、依存性逆転の原則(p.23「2.2.1オブジェクト指向プログラミングの原則」参照)とよく似ています。データをほかのデータコンシューマに提供する際に、データ内部の構造を抽象化することが求められるため、データの提供方法に影響します。アプリケーションの観点から見ると、データプロバイダー側は、アプリケーションロジックをすべて除外しなければなりません。アプリケーションロジックは、アプリケーションに関する特定の知識を必要とするからです。データコンシューマは、物理データモデルの専門家になる必要はなく、データを使用するためにアプリケーションの機能を再構築する必要もありません。この原則は、データ移行情報や、ログ情報、データベーススキーマなど、アプリケーションでよく見られる技術的なデータにも適用されます。このような技術的なデータはある特定のものであり、おそらくドメイン内部にしか関係がないでしょう。データプロバイダーは、データを公開する前に、無関係なデータを除外する必要があります。
原則22:集中的なデータ消費に最適化する。
　多くのアプリケーションは、大量のデータを消費するようには最適化されていません。ドメインが簡単にデータを消費できるようにするということは、親と子の構造が延々と続く高度に正規化されたデータを、ほかのドメインに提供することではありません。データは正規化しすぎず、直感的にグループ化されるべきです。ユーザーフレンドリーなフィールド名をつければ、データコンシューマ側で検索しやすくなります。命名規則やデータフォーマットに一貫性がなかったり異なったりしている点は、前もって解決されることが求められます。この手法では、データは汎用的に消費できるように最適化されなければならず、データ利用者の潜在的なニーズを満たすために、可能な限り再利用できるようにすることが目的となります。このことは、1章で述べた、書き込みに対して読み出しの比率が高まっていることとも関連しています。
原則23:ユビキタス言語は、通信のための言語である。
　データプロバイダーとして機能するコンテキスト境界は、それぞれ独自のユビキタス言語を使ってデータを公開する必要があります。つまり、データプロバイダーは、ほかのドメインのビジネスロジックを自分のドメインに組み込むべきではありません。
原則24:インタフェースには一定の成熟度と安定性が求められる。
　この原則は、変化のペースを抽象化するためのものです。例えば、ドメインの扱う範囲が頻繁に変更される場合、その変化を抽象化して安定的なものにすることが求められます。また、スキーマも、ある程度安定した互換性を提供しなければなりません。
原則25:データはすべてのパターンで一貫しているべきである。
　さまざまなパターンでデータを公開する際に、その公開方法については一貫性を持つべきというものです。例えば、顧客住所というフィールドは、同じデータがさまざまな方法で公開される場合でも、すべてのパターンで一貫性がなければなりません。

◾️まとめ
　これまでに学んだことをすべて組み合わせてみましょう。中央集権的なモノリスを取り除くことで、連合型モデルで、ドメインやチームが独立してデータを変更・交換できるようになります。各ドメインは、全体のアーキテクチャのある部分に対して責任を持ちます。データ統合と調和は下メインによって実行されます。一方で、データレイヤーは標準化されたアーキテクチャや、構成要素、迅速なデータ交換と統合のためのインフラストラクチャーを提供します。このレイヤーは、セキュリティや中央管理が行われ、データを容易に消費可能にするための明確な原則に従います。データランドスケープは断片化されていますが、それでもデータへのアクセスは容易なままです。また、多様な統合パターンを提供して、ドメインがある特定のビジネス問題に対処できるようにすることで、幅広い種類のアプリケーションが実現可能になります。
　ビジネスケイパビリティとバリューストリームのレベルでアプリケーションを論理的にグループ化することで、同じ関心事を共有するアプリケーションは一緒に管理されます。また、関心が異なるビジネス用のアプリケーションとは、直接的な依存関係が存在しないようにできます。このアプローチにより、チームは単一のビジネスケイパビリティの価値を提供することに完全に集中できるため、組織の目的が明確になり、アジリティがもたらされます。各ドメインは、コンテキスト境界によって論理的にグループ化され、アーキテクチャ全体のある特定の部分を管理します。この管理対象には、権威ある一意のデータセットも含まれます。
　アプリケーションをデータレイヤーに接続し、1度コンテキスト変換を実施することで、すべてのデータが同じ1つの論理レイヤーを流れるようになります。これにより、透明性とデータ消費のスピードが最大化されます。すべてのデータは、論理的に同じ場所からルーティングされ、流通され、利用できるようになります。高品質で、ユーザーフレンドリーで、消費可能なデータを流通する責任を負うという原則により、データは確実に分離され、データの再利用が促進されます。データレイヤーとメタデータを結び付けることで、すべてのデータ管理領域で深い知見を得ることができます。データレイヤーがその知見を提供します。また、アプリケーションがどのように接続し、データ交換するのかをコントロールすることができます。
　データ統合が容易になり、管理しやすくなるようなレベルに到達するのは簡単ではありません。そのためには、中央機能への投資と選択が必要です。単一の統合ソリューションやプラットフォームで、すべてのユースケースに対応することはできません。これらの機能を構築するためには、標準化や、ベストプラクティス、開発チームやプロジェクトチームをサポートするための専門知識が必要です。このような中央機能を構築するためには、個々のチームが統合パターンやツールに関する決定権を放棄する必要があります。これには抵抗があるでしょう。社内政治的な選択が必要になるかもしれません。さらに、このようなデータランドスケープの近代化には、現実的なアプローチが必要です。なぜなら、密結合されたランドスケープからの移行は非常に難しいからです。単純なデータフローから小さく始めて、徐々に規模を拡大していくことで、ドメインやユーザーはメリットを認識し、組織の競争力を高める新しいアーキテクチャに貢献したいと考えるようになります。そして次第に、統合アーキテクチャを拡張し、ソースを増やし、統合パターンを追加し、機能を強化することで、データ品質を向上させます。このようにすることで、企業全体のインサイトを提供できるようになるはずです。
　新しい統合アーキテクチャには、企業全体を見る視点が必要です。これがなければ、アーキテクチャはその潜在能力を十分に発揮できません。データサービスを自分たちで導入し、データサイロをほかのデータサービスで置き換えるだけのチームは、「データスプロール」+21のリスクを抱えることになります。再利用性や、一貫性、データ品質は、新しいアーキテクチャにおいて重要な観点です。スケールアップのためには、絶え間ないコミュニケーション、貢献、そして強力なガバナンスが必要です。


3章　膨大な量のデータの管理：読み出し専用データストアアーキテクチャ
　データ管理におけるデータ品質とは、品質問題を継続的に修正し、二度と品質問題が発生しないようにするフィードバック制御を行うことです。つまり、データ品質が継続的に監視され、品質レベルが落ちた場合には直ちに対処されるということです。データ品質の問題は、ソースシステムで解決しなければなりません。RDSではありません。ソースシステムで解決すれば、データ品質の問題がほかの場所で発生しなくなるからです。
　筆者の経験を踏まえて助言しておくと、データ品質の悪さがもたらす影響を過小評価してはいけません。データ品質が確保されていなければ、すべてのデータコンシューマで、データのクレンジングと修正という繰り返し作業を行うことになってしまいます。

◾️まとめ
　RDSは、膨大な量のデータを、データコンシューマが利用できるようにするためのものです。RDSは、単なるデータレイクやデータウェアハウスではありません。RDSは既存のアプリケーションを拡張し、そのコンテキストを継承します。RDSは十分に管理されており、強力に分離されています。依存関係があまり共有されていないということは、チーム間の調整が少なくてすみます。これは重要です。
　また、RDSは、大量のデータを提供することで、トランザクションシステムと運用システムを分離するためにも使われます。RDSは、データのライフサイクル管理において重要な役割を果たします。ドメインからのコンテキストが保持されるため、運用分析の理想的な場所となります。多くの場合、データ提供側のドメインが、その効果を実感し、自らもRDSを利用するようになります。本章では、RDSの共通インフラストラクチャーと機能についても見てきました。理論的には、RDSはドメイン自身が展開し、ホストすることができますが、プラットフォームを共有することで、全体としてコスト対効果が良くなり、ポリシー管理も容易になります。筆者がお勧めするのは、中央で始めて、広げていく方法です。
　また、組織のニーズに基づいてアーキテクチャとそのパターンを共同で設計・実装することもお勧めします。汎用的なブループリントをドメインチームに提供します。アーキテクチャを1つのチームで構築するのではなく、ほかのチームが貢献したり、一時的にプラットフォームチームに参加したりできるようにしてください。例えば、RDS間の同期が必要な場合や、関係スキーマをキーバリュースキーマに変換する必要がある場合には、再利用可能なパターンやコンポーネントとして継続的に提供してください。同じことが、データの導入時と消費にも当てはまります。最新のデータプラットフォームを構築する際には、多くのセルフサービス型アプリケーションコンポーネントが必要になります。多くの場合、これらのコンポーネントには、中央管理されたETLフレームワークや、変更データキャプチャプラットフォーム、およびリアルタイムインジェストツールなどが含まれます。
　次の章では、APIアーキテクチャについて見ていきます。APIアーキテクチャは、サービスの通信で使われます。また、リアルタイムで低遅延なユースケースにおいて、少量のデータを流通させるためにも使用されます。


4章　サービスとAPI管理：APIアーキテクチャ
　マイクロサービスの真髄を説明するために、アプリケーションとは何かから簡単に説明しましょう。アプリケーションとは、一連の機能やタスクが協調して実行するように設計されたコンピュータプログラムのことです。アプリケーションは通常、プレゼンテーションと、ビジネス、データの3つの異なる層で構築されています。
　組織がアプリケーションを開発する方法や、基盤となる技術インフラストラクチャーを活用する方法は、ここ数年で変化しています。最新の方法では、アプリケーションを複数のパーツに分割します。これにより、個々のアプリケーションのパーツに専念することができます。結果として、より高いアジリティと、個々のパーツをより柔軟に拡張することができるようになります。この方法を、図4-9に示します。

　アプリケーションをマイクロサービスアーキテクチャに分割することには、マイクロサービスと呼ばれるアプリケーションのコンポーネントを個別に独立して開発し、テスト、配備できるというメリットがあります。このアーキテクチャでは、各コンポーネントがそれぞれ専用のプロセスで実行されるため、スケーラビリティが格段に向上します。アプリケーション全体の規模を調整するのではなく、個々のアプリケーションコンポーネント単位で規模を調整できるようになります。そのほかにも、以下のような特筆すべき特徴があります。
・各マイクロサービスには、独自のランタイムや、ライブラリ、ツール、機能を持たせることができます。これらは同じである必要はありません。Python、Java、JavaScript、PHPなど、好きなものを組み合わせることができます。
・軽量な実行環境であるコンテナを利用するコンテナ化は、配備の方法として人気があります。
・各マイクロサービスでは、通常、専用のデータベースにデータを保存します。使用するデータベースも、マイクロサービスごとに異なることがあります。
・サービスは、論理的に構成され、コンテキスト境界を中心に管理されます。
・ほかのマイクロサービスとの通信は、一般に、JSONとREST、gRPC、Thriftなどの軽量な機構で行われます。

◾️まとめ
　急速に変化する企業の状況において、本章で学んだAPIアーキテクチャは、API戦略を刷新することでしょう。サービス指向アーキテクチャの基本となる部分は残ったままで、より責任が明確になり、最新のパターンと原則が使われ、そしてより柔軟なアーキテクチャになります。
　APIアーキテクチャは、RESTアーキテクチャであるため、すべてのデータを分散して利用することもできます。複数のAPIゲートウェイとサービスメッシュを同時に配備しながら、メタデー夕を利用して完全にコントロールすることができます。各チームやドメインが、独自のAPIゲートウェイを使用してサービスを提供することも可能です。メタデータリポジトリを活用して、どのサービスが利用可能で、どのように消費されるかという情報を保持することにより、常にコントロールを維持することができます。
　また、APIアーキテクチャのモジュール性とリクエスト/レスポンスモデルにより、ある特定のユースケースに対して、高度にモジュール化されたマイクロソリューションも提供できます。このアーキテクチャは非常にスケーラブルになります。ここで注意すべき点は、RDSアーキテクチャと同じように、2章で説明した原則に従わなければならない、ということです。APIは、リアルタイムでデータを生成し、送受信するために使われる製品と見なすべきです。それらは、読み出しやすく簡単に消費できるように責任を持って管理され、最適化されなければなりません。APIは、そのドメインのユビキタス言語を使用すべきであり、ほかのドメインのビジネスロジックを取り込むべきではありません。
　次章では、非同期メッセージングとイベント駆動型通信を中心としたストリーミングアーキテクチャについて見ていきます。


5章　イベントとレスポンスの管理：ストリーミングアーキテクチャ
◾️まとめ
　企業はすでにイベントの力を認識しています。イベントによって、アプリケーションを接続し、データを連携させ、プロセスをデジタル化し、社内外の通信を、より良いものにできるのです。イベントがあれば、システムが互いにどのように反応するかを理解することができます。この知識によって、日々のビジネスオペレーションを改善することができるのです。
　これまで見てきたように、ストリーミング処理は複雑です。継続的にデータを取得し、ストリームをプラットフォームにインジェストするには、アーキテクチャに多くのコンポーネントを追加する必要があります。このような複雑で多様な状況を考慮すると、例えば、正確に1回処理を保証するために、さまざまな多くのツールセット、フレームワーク、サービスを追加して使用することになります。ここで重要なのは、イベントプロデューサーがデータのインジェストに責任を持つことです。イベントプロデューサーの役割は、自身のコンテキストを使って、安定した再利用可能なデータを提供することです。
　ストリーミングアーキテクチャのコアとなる部分は、プラットフォームです。このプラットフォームで、データをリッチ化、変換、統合、分析することができます。選択したプラットフォームによっては、ストリームと相互作用するために、豊富なウィンドウ機能やAPIを使用することになるかもしれません。企業レベルでは、アプリケーション間でプライベートな通信チャネルとストリームを明確に分離し、ストリームが密結合された分散型モノリスになるのを避ける必要があります。ここで重要なのは、明確なガバナンスを導入することです。コンテキストが変われば、所有権も変わります。また、エンタープライズキーに注目することも重要です。エンタープライズキーは、複数のストリームからストリームを結合する際に、コンシューマに一貫性をもたらすからです。このテーマについては、9章でより詳しく説明します。
　消費側では、選択すべきユースケースやパターンの数が圧倒的に多いため、さらに複雑になります。アプリケーションやドメインのニーズによっては、ストリーミング処理フレームワークや分析機能を追加したり、ストリームを内部に分散させるパイプラインを追加したりすることになるかもしれません。さらに、ドメインはAPIを使用してストリーミングメッセージをやり取りし、リッチ化することもできます。
　プロバイダーとコンシューマの間でメッセージやイベントをやり取りするためのストリーミングやイベント処理機能は、ストリーミングアーキテクチャに配置するべきです。これらの機能は、さまざまな環境間でメッセージを配信したり、RDSを最新の状態に維持したりするために重要な役割を果たします。複数のイベントブローカーを接続する場合、完全に分散し、分離した状態で、複数のプラットフォームやクラウド環境上の多くのアプリケーションを接続することができます。このようなアーキテクチャは、イベントメッシュとも呼ばれています。
　次の章では、さまざまなアーキテクチャがどのように連携するのかについて紹介します。


6章　すべてをまとめる
6.3.1 消費最適化の原則
　データ消費に真剣に取り組むには、データを組織における重要な資産として捉える必要があります。この理念のもと、データ品質、表現力、粒度、情報のリッチさについては、それぞれのデータ所有者(プロダクト所有者)が責任を負わなければなりません。前節で紹介した、バージョン管理などのインタフェースのライフサイクル管理も含まれます。Informaticaの元CEOであるAnil Chakravrthy氏は、「データを資産とみなす、この哲学が、データの管理・提供のあり方を根本的に変える」と論じています(https://oreilly/ZKigS).繰り返し作業をなくすために、「データ提供は適切に一度、消費は何度も」という新しい標語を提案します。この理念は、SOA界限で提唱されているサービスの再利用性原則(https://oreil.ly/BxpGx)と似ています。データは再利用可能な資産として提供され、同時にできるだけ多くの顧客に対応できるようにしなければなりません。ある特定のデータコンシューマのために設計してはなりません。
　可読性と再利用性の目標は、データレイヤーを通過するデータセットの内部設計に影響を与えます。例えば、延々と続く複雑な親子関係や、高度に正規化されたデータ構造、技術的なデータモデルなどは、データコンシューマにとっては、データが理解・利用しにくいものになってしまいます。したがって、データはできるだけ多くの消費者に提供できるように、適切な粒度で提供されなければなりません。また、論理的に一緒にすべきデータは、グループ化する必要があります。
　即座に簡単に利用できるように、分離され、再利用可能で、消費に最適化されたデータを流通するという方法は、多くのデータレイク参照アーキテクチャと矛盾しています。例えば、RDSについて言えば、すべてのソースシステムの膨大な数の生データのコピーを、もともとの形式で保持するような大規模ストレージリポジトリと見なすべきではないと、筆者は主張しています。複雑なデー夕を生のまま(1対1に)投入することは、近視眼的には利点があるかもしれませんが、長期的に見ルトうまくいきません。データコンシューマが、複雑なアプリケーションロジックを構築したり、大規模な結合を実行したり、データを解釈するのに苦労したりするようなことは避けたいはずです。このため、次に示すような、インタフェース設計に関するガイドラインに従うよう、チームに強く求めます。
•RDS、API、ストリームのいずれに対しても、汎用的なブループリントとしてデータエンドポイントを設計してください。できれば、これらはすべて同じメタデータまたはコードから生成されることが望ましいです。
・消費最適化されたデータを提供してください。つまり、過度に正規化された物理モデルや通度に技術的な物理モデルを、より再利用しやすく論理的にグループ化されたデータセットに変換する必要があります。このような処理をドメイン集約(https://oreil.ly/d0STt)と呼びます。複雑なアプリケーション内部ロジックは抽象化する必要があります。
・ドメイン駆動設計のユビキタス言語は、通信のための言語です。つまり、防彙や、言語、デー夕構造、命名規則はドメインから継承されます。データとコンテキストは、運用システムやトランザクションシステムが生成するものに近いものにしてください。
・データプロバイダーは自分のデータモデルをほかのドメインのニーズに合わせてはなりません(ビジネスロジックを組み込むのは、データを解釈するために非常に特殊なドメインの知識が必要な場合だけです)。
・できるだけ多くのドメインが再利用できるような包括的なデータセットを提供してください。あるデータコンシューマだけのために非常に特殊なデータ形式を使ってはなりません。
・データ利用者が本当に関心のあるデータのみを提供してください(システム内でのみ使用されるデータは提供しないでください)。
・データ要素は不可分でなければなりません。つまり、その属性はこれ以上意味のあるサブコンポーネントに分割できないようなものにしてください。不可分なデータ要素は最も低レベルの要素であり、正確な意味(セマンティクス)を持ちます。正しい値を得るのに、データの分割や連結、複雑なロジックの実行などをドメインに強制すべきではありません。
・一貫性のあるドメイン識別子を使用してください。相互参照と外部キーの関係は、データセット全体を通して不可欠であり、一貫性がなければなりません。データコンシューマがデータセットを結合する際に、キーを操作する必要がないようにしてください。
・データは、データセット全体で一貫した形式でなければなりません。これは、データ要素の表現形式や構文(小数部の精度、表記法、文法など)が同じであることを意味します。消費側のドメインが正しい値を得るためにアプリケーションロジックを適用する必要がないようにしてください。
・ローカルでマスターでない参照データは、変化しやすいので、消費しやすい安定した粒度の粗いデータに抽象化する必要があります。
・データが参照データ管理やマスターデータ管理の対象である場合、エンタープライズ識別子を提供してください。この原則については、9章でさらに説明します。


◾️まとめ
　Scaled Architectureは、3つの統合アーキテクチャをパッケージ化しているため、ほかの多くのアーキテクチャとは異なります。テクノロジーにとらわれず、包括的で、将来を見据えたものであり、どのようなタイプのアプリケーションも排除しません。Kubernetes、Hadoop、Kafkaを使ったマイクロサービスだけを推奨しているわけではありません。データを安定して交換・流通させるために、さまざまな技術に対応しやすくする汎用的な仕組みなのです。
　結合の悩みから開放されたので、メタデータがすべてをまとめる接着剤になります。メタデータは、すべてのデータフローに関する情報をもたらしてくれます。本章で説明した分離の原則により、アーキテクチャはアジリティを維持します。すべてのドメインは、独自のスピードで、独立してデータを進化させ、データを消費し、提供することができます。ドメインが持つ唯一の依存関係は、データレイヤーだけです。この仕組みがうまく機能するためには、すべてのドメインが、消費最適化された再利用可能な方法でデータを提供する必要があります。このような形式で提供すれば、データを1回取得するだけで、さまざまな用途に何度も利用することができます。ネットワークを越える際の原則を明確にしておけば、同じデータを何度も流通させることを避けられます。
　ドメイン駆動設計モデルにも欠点があります。それは、コンシューマチームがドメインのさまざまなコンテキストを理解しなければならないことです。統合にはより多くの作業が必要です。しかし、アジリティの向上とユーザーフレンドリーな消費型データの原則によって、それだけの価値があるものになります。9章でマスターデータ管理について触れるとき、データのマスター化、キュレーション、再発行によって、アーキテクチャに企業レベルの一貫性が取り戻せることを学びます。
　次の章では、データを価値に変えるために、データガバナンス、データセキュリティ、メタデー夕管理、マスターデータ管理、DDSなど、より多くのデータ管理領域と規律を使って、アーキテクチャを拡張していきます。


7章　持続可能なデータガバナンスとデータセキュリティ
◾️データガバナンスの役割
データ所有者
　データ所有者は、データ受託者やプロセス所有者と呼ばれることもあります。データ所有者は、データと、そのデータに対応するメタデータを適切に管理する責任を負う組織内の従業貝個人のことです。データ品質、データ定義、データ分類、データの使用目的、ラベルなどが含まれます。分散型エコシステムにおける説明責任は、エンタープライズデータだけに限定されるものではありません。データ所有者は、外部データやオープンデータについても説明責任を負う場合があります。
データ利用者
　データ利用者とは、特定の目的のためにデータを使用することを意図し、要件を設定する責任を負う組織内の従業員個人を指します。
データ作成者
　データ作成者は、データ所有者との合意に基づいてデータを作成する内部パーティーまたは外部パーティーのことです。
データコンシューマ
　データコンシューマとは、データ所有者および(または)データ利用者が意図したとおりに
データを利用する内部パーティーまたは外部パーティーのことです。
アプリケーション所有者
　アプリケーション所有者は、データ管理者と呼ばれることもあります。アプリケーション所有者は、アプリケーションのコアとそのインターフェースを管理します。アプリケーション所有者は、ビジネスの提供、機能、サービス、アプリケーション情報とアクセス制御の管理に責任を負います。アプリケーション所有者は、内部パーティーでも外部パーティでもかまいません。

◾️まとめ
　データガバナンスとデータセキュリティは、大きく関連しています。データガバナンスは、最新のデータ活用を実現する上で、重要なポイントになります。厳しい法規制に準拠するためには、所有権を定義し、リネージ、分類、目的、説明などに関する標準を設定することが重要です。これらの作業では、組織内のすべてのアプリケーションと一意な(ゴールデン)ソースを、はっきりとさせることも重要です。データガバナンスを大規模化するには、関連する役割とその責任の所在を明らかにし、それらを適切に割り当てる必要があります。まずは小さく始めて、短期間で成果を上げるよう努めましょう。
　データセキュリティについては、データリクエスト処理をサポートする、エンドツーエンドのフレームワークを構築することが重要です。このフレームワークは、データレイヤー内でセキュリティモデルを強化するためのスタート地点となります。ここが、アーキテクチャ全体の中で、もっとも賢い部分になります。徐々に進めていくうちに、もっと多くのメタデータ、分類、ラベル、属性などを追加して、拡張していきましょう。さらに規模を拡大するために、機械学習でインテリジェント化することもできます。
　次の章では、データを価値に変えることに着目します。ドメインデータストア、データバイプライン、セルフサービスモデル、ビジネスインテリジェンス、アドバンストアナリティクスについて詳しく学びます。


８章　データを価値に変える
◾️まとめ
　本章を通して構築してきたアーキテクチャは、本番環境、ビジネスインテリジェンス、機械学習などのアドバンストアナリティクスを大規模に管理するのに役立ちます。データ管理と自動化に真摯に取り組むことで、大規模なデータの民主化が実現することがおわかりいただけたと思います。また、セルフサービスと管理されたデータ処理、およびそれらをサポートする原則についても紹介しました。また、価値実現までの時間を短縮するためには、バージョン管理、分析監視、配備などの手作業をなくすことが重要であることも理解いただけたと思います。このためには、従来のデータモデリングとは、まったく異なる文化が必要です。データエンジニアは、ここで挙げたスキルを習得するために、十分なトレーニングを受けたり、経験豊富なソフトウェアアーキテクトになったりする必要があります。また、セルフサービスを広く普及させることも必要です。
　最後に、サイロを壊し、DDS間の依存関係を最小にすることを学びました。分離と隔離を行うことで、チームは作業に集中することができます。また、ドメイン内の汎用データをサブドメイン間で共有する原則についても紹介しました。このパターンは、次の章で、マスターデータ管理と参照データ管理について学ぶ上で、基礎となるものです。


9章　エンタープライズデータ資産の活用
◾️まとめ
　マスターデータ管理が重要であることは明らかです。なぜなら、ユーザーは、使用するデータに一貫性と正確性があればこそ、正しい判断を下すことができるからです。MDMは、エンタープライズレベルでの一貫性と品質を保証します。この2つは非常に密接に絡み合っているため、多くのソリューションがターゲットにしています。
　MDMの導入を始めるにあたって、最もシンプルな導入スタイルである「リポジトリ」から始めるのが現実的な方法です。このスタイルでは、運用システムを調整することなく、どのデータを整合させる必要があるかや、どのデータの品質が悪いかを知ることによって、迅速に価値を提供することができます。
　次のステップは、スコープをはっきりとさせることです。すべてのデータを選択しようとするあまり、企業レベルのデータ統一という落とし穴にはまらないでください。顧客、契約、組織單位、製品など、組織にとって付加価値の高い対象から始めましょう。マスター管理するフィールドは、特に重要なものだけを選択するようにします。属性の数は数百ではなく、数十程度にすべきです。意見がまとまったら、プロセスやガバナンスを調整します。スケジュールや見直しなどに関する合意事項は、誰にでもわかるようにしておきしましょう。メタデータについても同様です。マスターデータがカタログ化され、ユーザーはどのソースシステムからのどのデータ要素が対象となるのか、また、これらの要素がどのようにデータパイプラインを流れていくのかを把握できるようにします。
　最後のステップは、最終的な目標である「共存」を実現することです。つまり、改善されたものが元のソースシステムに直接戻ってくるようにすることです。このステップは、アーキテクチャに多くの変更を加える必要があるため、非常に大変な作業となります。ソースシステムは、マスターデータストアからのマスターデータの修正や改善に対応できるようにしなければなりません。このような変更があった場合は、統合アーキテクチャのパターンを使って適切に流通させる必要があります。
　また、キュレーションデータを作成することで、企業全体でのデータ一貫性を向上させることについても議論しました。このためには、効率的なコミュニケーションモデルとデータガバナンスが重要です。データの再利用が進めば、組織はより有効に機能するようになります。このため、多くの企業がコミュニティベースの手法、オープンデータモデル、データマーケットプレイスに注目しています。これらについては、10章で扱います。


10章　メタデータによるデータの民主化
10.2.0.2　データモデル
　フレームワークの最上位に位置するデータモデルには、特に注意が必要です。
　最上位には概念データモデルがあります。このモデルには、オントロジーやタクソノミーなどが含まれる場合があります。これらはビジネスの概念を要約し、ビジネスの観点から見た、データの意味と目的を説明するものです。これらは抽象的なものでも構いませんが、すべての用語に定義や、属性、依存関係を持たせて詳細に説明することをお勧めします。定義は、データプロバイダーとデータコンシューマの双方のコンテキスト境界を理解し、ある特定のコンテキストにおけるデー夕の意味について、組織が深く理解できるようにする必要があります。
　その1つ下のレベルには、アプリケーション論理データモデルがあります。概念モデルから論理的に拡張されたものです。概念に対して、エンティティと属性を追加したものです。適切に作成された場合、この論理データモデルは、ビジネスの原点を説明し、概念がどのようにアプリケーションの論理データベース設計に反映されたかを明らかにします。一般的に、この種のメタデータは、データモデリングツールを使って作成することができます。
　一番下のレベルは、アプリケーション物理データモデルです。これは、どのデータがどのデータベースの中にあるのかを正確に指定するスキーマです。この種のメタデータは一般的に、データモデリングツールや、物理プラットフォーム上のデータベースから自動的に生成されます。


◾️なぜ概念データモデルが欠落しがちなのか
　概念データモデルは、いくつかの理由で欠落しがちです。1つの理由としては、多くのビジネスユーザーやIT専門家が、その存在を知らないことが挙げられます。多くの概念モデルは、ホワイトボード上のスケッチやドキュメントなど、暗黙のうちに作成されますが、デジタルデータとして保存されることがありません。また、概念モデルは、ほかのデータモデルと混同されることもよくあります。概念モデリングに関する専門家や深い知識を持つ人はほとんどいません。また、概念データモデリングは抽象的で難しい、という印象を持っている人もいます。さらに、すべてのアプリケーションに関連するすべての概念データモデルを把握するのに、使い勝手の良いツールがなく、モデルの把握が困難になっています。ほとんどのツールは、狭い範囲のテクノロジーにしか対応していません。Protégé(https://protege.stanford.edu)は、OWLを使った概念データモデルを構築するための有名なオープンソースツールです。しかし、使い方を十分に学習しないと、非常に操作が難しいという欠点があります。
　概念データモデルが欠如しがちな理由は、データモデルを作成することの意義を疑問視する人々がいるためです。アジャイル開発プロセスの中や、時間的な制約の中で、暗黙の了解や概念をまったく把握しない、という決断を下すのを見たことがあります。このような状況では、ビジネスユーザー、開発者、エンジニアは、アプリケーションを期限内に完成させるために安易な手段を取ることになります。


◾️まとめ
　これまで見てきたように、メタデータはすべてを結び付けてくれます。データの完全性と品質の検証、新しい場所へのルーティングや複製、データの変換、データの意味の把握は、すべてメタデータを通じて行われます。メタデータは、セルフサービス型ポータルによってデータを民主化する際にも不可欠です。
　メタデータは、データ品質、データガバナンス、データ統合の各分野と密接に関連し、エンタープライズアーキテクチャと深く関係します。データとメタデータの所有権に関して明確な境界を設定し、メタデータの相互運用性の原則に従って、高品質のメタデータを配信・収集し、効率的に管理できるようにします。エンタープライズアーキテクチャ部門は、アーキテクチャのブループリントを生成し、アーキテクチャをコントロールすることに深く関与する必要があります。
　メタデータ管理は、ビッグデータ、ビジネスインテリジェンス、分析だけに限ったことではありません。メタデータ統合は、アプリケーション統合やその運用・トランザクションとも深い関係があります。サービス指向、マイクロサービス、継続的インテグレーションとデブロイの実現を含むDevOpsも、メタデータ管理の一部です。これらすべての領域において、データガバナンスチームは、どのようなメタデータを中央で利用できるようにすべきかを判断しなければなりません。
　データマーケットプレイスの構築は、メタデータだけではありません。構造、文化、そして人々についてもです。文化については、あまり厳密なガバナンスは必要ありません。ユーザーに信頼を与え、人々を調練し、意識改革に取り組むことが必要です。これらの活動は軽視されるべきではありません。ユーザーは大事な経営資源です。ユーザーはデータランドスケープの一部を所有し、利用しています。ユーザーをうまく利用すれば、データに関する知識やデータの利用効率を高めることができます。

[Go Extremeさんの感想 · 2022年12月27日]

データ管理と統合が急速に進化し続ける中、データウェアハウスのようにすべてのデータを一か所に保存すると拡張性が持てなくなるため、データは分散され、技術的ソリューションに従って利用できるようになる必要があるとし、企業が、複雑で緊密に結合したアーキテクチャから、現代のデータ消費に対応できるより柔軟なデータアーキテクチャに移行するための方法や考え方を解説するという書籍です。
1章　データ管理の崩壊

2章　Scaled Architectureの紹介：大規模なデータ管理

3章　膨大な量のデータの管理：読み出し専用データストアアーキテクチャ

4章　サービスとAPI管理：APIアーキテクチャ

5章　イベントとレスポンスの管理：ストリーミングアーキテクチャ

6章　すべてをまとめる

7章　持続可能なデータガバナンスとデータセキュリティ　

8章　データを価値に変える

9章　エンタープライズデータ資産の活用

10章　メタデータによるデータの民主化

11章　おわりに