分散型と集約型のハイブリットであるメッシュ型アーキテクチャ
大規模な組織では、分散型を中心としながらも、一部のデータは集約されていたほうが活用の面でも管理の面でも有効に働くことがあります。そのため、実際のアーキテクチャはほぼ確実に分散型と集約型のハイブリッド型になるはずです。
たとえばこの通りです。
- マスタ データや履歴分析用データ：集中型
- リアルタイム参照や業務連携：分散型
- 重要度の高いデータから段階的に集中化
- 同一データ (拠点在庫など) : 集約
私が今回取り上げた前提となる組織は、大規模でコングロマリットな組織を前提にしています。
システムもポリシーも顧客も多様性があるため、全体では分散型になります。
一方、下記の要因で、局所的な集中型データ基盤が出来上がります。
- マスタなど集中管理するものがあるため、このためのベースレジストリという局所的な集約型データ基盤がある
- 海外現法や独立した事業では、その域内でデータがやり取りされ、域外との転送や結合のほうが少ないため、局所的に集中型データ基盤ができる
- 本社 (グループ内のホールディングス等の投資会社) のあるところでは、グループ会社すべてのデータを集め、経営判断に使う基盤を作る場合、局所的な集約型データベースが作られる。
以上の理由により、これらの局所型データ基盤を分散させるイメージになります。
メッシュ型アーキテクチャへのアプローチ
メッシュは集約されたデータの島が分散するイメージです。しかし、その「島」の単位を最初から設計するのは非常に難しく、自発的な要素で自然に形作っていくものです。
局所集約が分散し、メッシュ アーキテクチャになるには、おそらく3通りのアプローチが考えられえます。
① まずは完全分散のデータ共有基盤を作り、それらが意味のある単位で集約していく
② まずは完全統一のデータ共有基盤を作り、それらが崩壊するようにして分裂していく
③ 既に存在している小規模データ基盤をそのままオープンにつなげる
いきなり最終ステップのメッシュ型になることはないでしょう。(IT ベンダーはなぜか最終形だけ提示しドヤ顔します)
巨大な組織の場合、すべての業務を熟知している人はまれです。そして、その人がデータ基盤構築のプロジェクトに参加しているとは限りません。参加していても、IT アーキテクトに対して主導をとれるとは限りません。また、クラスタを作る単位を正確に知ることは困難です。
極端な設計から、実現時の障害を経て、自然に安定した構造に移っていくように、最終的なメッシュ アーキテクチャに落ち着くことがごくごく自然な成り行きと言えます。
完全分散コース
まずはどこにどのようなデータがあるのかを公開し、データを入手可能にします。
しかし、それだけでは、データの品質処理、集約処理、意味統一処理など、データ準備のフェーズを解決できません。それらを解決するために、用途が近いデータ同士で1か所に集められ、徐々に集約してきます。
この組成の仕方は、非常に効率的にデータ基盤を作ることができます。本記事では次のページ以降、これを基にして説明します。
完全集約コース
まず、データを1か所に集めます。しかし、しばらく進めると無理が出てくることに気が付き、「必要なデータのみ」という限定的なデータ収集になるかもしれません。しかしそれでも調査や分析の観点では不足です。結局、ひとつの課題を解決するために必要なデータを集めるために、複数のロケーションからのデータ収集が発生します。
また、一元収集を考える人々は、共通マスタや共通集約トランザクションテーブルのような「共通データ」という思想に取りつかれがちです。しかしながら、業務に多様性があれば、それらを支えるデータセットも多様になります。データ基盤は思ったようなサービスを提供することはできません。
その結果、各利用者は、足りないデータを補うために、また、業務ドメインに特化した独自の共通データをこしらえるために、それぞれで集約ストレージが生まれて主役が移っていきます。
合体コース
すでに部門独自で局所的なデータ基盤が存在している場合、単にそれを統合する形になります。各データ基盤がある程度大きくなっていれば、集約にすることもなくなるので、特に迷いなくできると思います。
ただし、可能な限りインフラ (テクノロジ) アーキテクチャはガバナンスを聞かせて統一する必要があり、また、すでに出来上がったルールをある程度変えないといけないので、その点に苦労しながら進めることになると覆います。最も大きい局所データ基盤が主導する形で全体のメッシュ化が推進されます。
コメント