データ基盤の構え方は、データ配置の観点から大きく分けて2種類あります。一つは、1か所にデータを集め、中央集権的に管理することを主とする中央集約型。もう一つは、データを業務システムに分散させたまま管理を任せ、ルールとポリシーだけで統制して公開を促す分散型です。大きな分かれ目なので最初に考えておく必要があります。
UCAの時代に優先すべきは、スケーラビリティとアジリティ
データ基盤の目指す姿として掲げたゴール（理想像、最適解）は、今時点のものです。ゴールの正しさもわからなければ、道半ばでゴール自体が変化することもあります。
ゴールの変化を与える要因には、以下のようなものがあります。
- 市場や競合の変化
- 事業改革
- 予算の変動
- 新しいテクノロジーの登場
特に5年後10年後を見据えるというのなら、ゴールが変わることを前提にしても良いくらいです。
VUCAの時代、企業で考えるべきなのは、変化に対するリスクであり、ITで言えばスケーラビリティとアジリティの確保です。特に規模の大きい企業ほど、基盤システムを考えるうえで重要になります。
中央集中型と分散型の比較表
| 中央集中型 | 分散型 | 補足説明 | |
| 保守性 | 〇 | 分散している場合、バージョン不具合、サイロ化リスクあり | |
| セキュリティ | △ | 集中するとセキュリティ管理しやすい 分散すると被害がドメイン内に収まる | |
| 運用性 | 〇 | 停止計画、運用計画などが各拠点の都合で行える | |
| 回復性 | 〇 | 分散型のほうが復旧しやすい | |
| 可観測性 | 〇 | 1か所で管理をしているほうがロジックが透明である | |
| 監査可能性 | 〇 | 集中しているほうが監査しやすい | |
| 迅速性 | 〇 | 中央で集中すると、アジリティが損なわれる | |
| 変更弾性 | 〇 | 特定システムの変更は、分散型が影響が少ない | |
| 拡張性 | 〇 | 新規システムの参加、既存システムの離脱は分散型が有利 | |
| ガバナンス | 〇 | 中央集中型は統制を効かせやすい |
従来の中央集約型は扱いに要注意
中央集約型のデータ構造は、中央集権型の管理ともいえます。
中央集権型の最大のメリットは、統制を効かせやすいことです。ただしこれらは、「中央管理のスキルの高さ」「環境変化が少ない」「スピード感不要」という３つの要素に支えられていることも認識すべきです。
専門知識を強く反映させる必要がある
データ基盤にかかわらず、スピードよりも一貫性とコンプライアンスが重要なもの、例えば、規制遵守、セキュリティ管理、財務報告、人事関連、法的手続きにかかわるものは、多くの場合、中央集権型にメリットが出ます。これらは専門的な深い知識を持ったメンバーにより、適切なガバナンスを効かせられることが重要です。
しかしながら、中央の管理組織が、専門スキルの無い状態、すなわち薄い知識の元に何となくルールを決めてしまう場合や、単純に作業を請け負うようなスキルしかない場合、恐ろしいデメリットにしかなりません。多くの場合、中央の管理組織は IT 専門部門だけに任せることが多く、このデメリットが強調されます。フェデレーテッドガバナンス (=グローバル横断で守るべき最小限のルール・標準は中央で定義し、実装と運用はドメインに委譲する) の考え方を持ち込む必要があります。
Note:
「One Source」の正しい理解
「One Source」を掲げるコンサルタントは多いですが、「One Source」イコール「One Storage」ではありません。データリネージの先が同一であり、データの権威 (Authority) が一つであればれば One Source です。正確には、One Source of Truth です。
新しいテクノロジの登場に対応し続ける必要がある
中央の構造をいっぺんに変えなければならなくなったときには目も当てられません。例えば、リレーショナル DB のみ考えてたところ、グラフデータベースや非構造データが主流となり対応できなくなった、AIの登場で生成データが爆発的に増え、データ収集が物量的に不可になった、等の事態が発生します。
近年データベース構造の変化を見ても、もはや RDB 型以外に急速に変わっていることが分かると思います。
2007 年 Key-Value 型データベース (Dynamo)
2007 年 グラフ指向データベース (Neo4j)
2009 年 ドキュメント志向データベース (MongoDB)
2010 年 データレイク概念
2013 年 時系列データベース (InfluxDB)
2016 年 ストリーミング基盤データベース (Apache Pulsar)
2019 年 レイクハウス (Deltalake, IceBerg)
2023 年 ベクトルデータベース(pgvector, Milvus, Pineconeなど)
次に何が来るのかわからないので、変化に対応する柔軟な姿勢か、逆にこれ以外は管理しない方針 (今後の新しいテクノロジは中央が関与しない) で進める必要があります。
末端の変化に合わせて逐一付き合う必要がある
中央集権は変更承認、ルール再編などに時間を要します。その結果、ユーザーは中央の管理組織を見限って、独自で様々なことを始めるようになります。
過度に統制をとってはならない
統制をとる必要がなく、むしろ状況による自由度が必要なものまで管理し始めると管理が破綻します。物の一面だけ見た統一ルール作りにはじまり、見落としていた発見とともに無数の条件分岐を追加したルールは目も当てられません。規則によっては各部門に移譲すべきこともあります。統制は専門知識が低い状態で触れると痛い目を見ることになります。
誰にでも使えて、誰にも使えないシステムが出来上がる可能性がある
全方向受容化という、予期しないコストを生むことがあります。たとえば「グローバルで共有するから英語を併記せよ、日本の本社で使えるよう日本語訳せよ」このような要求がいかに多くのコストを生むか想像できるはずです。
分散モデルを推奨
大規模な企業で、データ基盤に必要なのは、1か所集約モデルではなく参照モデルを中心とした構造です。物理的に分散し、概念的に一つにするイメージです。
基本的にはドメインベースの参照アーキテクチャを考える
組織全体のデータを1か所に集約せず発行元が管理する場所を直接参照させます。一方、ガバナンスのルール策定・標準管理は中央に残します。例えば各ドメインに対して、各々のデータを管理させながら以下を求めるようにします。
- データ仕様
- アクセス方法
- 公開データの精査
- 中央ルールの適用
- 結合方法、利用方法、利用例の公開
- データサンプル
各事業部署、機能部署で独立したシステムを持つ
各事業部署、機能部署で独立したシステムと独立した分析システムを持ち、それらがサイロではなく、エンタープライズ全体に公開され、容易に参照され、利用される形をイメージします。
実際には・・・
ドメインベースとはいったものの、実際にやるとしたら、個社、拠点、地域を一つの塊とすることが多いと思われます。統制がとりやすく管理の独立性のある境界線に合わせることになるでしょう。ただし、独立性の境界線でデータを持つことは、サイロ化の危険性も同時に保有することも意識してください。
※ （注意）さらっと「大規模なら分散型」と言っていますが、厳密にはいろいろ考慮する必要があります。
コメント