Shift Left Architectureを考える
はじめに
AWS Community Builderのぺんぎん（@jitepengin）です。
近年、データ基盤界隈で、「Shift Left Architecture」が注目されています。
これは、従来のようにソースからデータを取り込んだ後に整形・加工を行う、方式とは異なり、アプリケーションやソース側にデータプロダクトに関する責任を寄せていくという考え方です。
この方式により、データ品質の向上・整合性の担保・コストの最適化といった効果が期待できます。
一方で、従来のメダリオンアーキテクチャに代表されるような「Shift Right」と比べると、様々な課題や疑問があります。
そこで今回は、Shift Left Architectureについて考えてみたいと思います。
Shift Right Architecture(従来型のアーキテクチャ)とは
Shift Rightはデータの成形・品質管理・ガバナンスをデータ基盤側（下流）で一元的に担保するアーキテクチャです。
例えばDatabricksが提唱したメダリオンアーキテクチャが有名です。
メダリオンアーキテクチャとはデータを論理的に整理するためのデータアーキテクチャで、データのレイヤー（ブロンズ⇒シルバー⇒ゴールド）を遷移するごとにデータの構造と品質を洗練・向上させることを目的にしています。
データが順次処理されることからマルチホップアーキテクチャとも呼ばれています。
オリンピックのメダルのように銅⇒銀⇒金の順に品質や価値が向上していくようなイメージですね。
ゴールドレイヤーまで来るとビジネス価値により直結したものになります。
メダリオンアーキテクチャについては下記の記事にまとめているので参考にどうぞ！
メダリオンアーキテクチャの3つの層の役割
前述したようにメダリオンアーキテクチャでは3つの層が存在し、それぞれのレイヤーでデータを品質に応じて階層化し保存します。
-
ブロンズ層：様々なデータソースから取り込んだデータそのもの（生のデータ）が保存されるレイヤーとなります。データとしてはノイズが含まれており、データの欠損がある場合があります。
ここで重要なのがデータの完全性を維持するということです。生のデータを加工せずに保存しておくことがなにより重要となります。
ちなみに完全性が維持されたデータになるので監査にも対応できるデータとなります。 - シルバー層：ブロンズ層に保存された生のデータに対してクレンジングやフィルタリングを行い、分析に対応できる形式で保存するレイヤーとなります。このレイヤーに格納するタイミングで後続処理で不要なフィールドの削除、データ欠損の補完や整合性チェックを行う必要があります。
- ゴールド層：BIや機械学習等で使用されるある特定の目的向けに加工されたデータが格納されたレイヤーとなります。つまり最終目的のためにデータの集計や結合、場合によっては追加でクレンジングが行われ、ビジネスに直結するデータとなります。
このようにブロンズ⇒シルバー⇒ゴールドと遷移する中でデータがより洗練され、ビジネス価値に直結したものとなります。
このようにソースデータをデータ基盤側で取り込み、データの成形・品質管理・ガバナンスを担保する仕組みがShift Right Architectureです。
Shift Left Architectureとは
Shift Left Architectureは、データモデリング・品質担保・プロダクト提供の責務を、ソース側（アプリケーションチーム）へ寄せるアプローチです。
そして、データ契約（Data Contract）を前提に、上流で整ったデータを提供し、下流の変換工程を最小限にします。
ポイントは以下の通りです
- ドメイン知識を持つプロダクトチームがデータを定義する
- データパイプラインは軽量化され、変換は最小限となる
- 下流でのデータエンリッチやクレンジングの負荷を削減できる
- 変更に強いデータモデル（契約）を上流から提供する
つまり、「ソース中心」の構造になります。
- アプリケーションチームがデータ契約を定義
- 下流は契約に従って使うだけ
Shift Leftのメリット
Shift Leftのメリットとしては以下のようなものがあります。
ドメイン知識を持つチームがデータ定義するため品質が高い
Shift Left の最も大きな価値はここにあるのかなと思います。
Shift Rightの場合、アプリケーション開発チームは動くシステムを作ることが主務であり、データの利用を前提としたスキーマ設計・ライフサイクル設計は必ずしも最優先ではありません。
そのため下流では、データからドメイン本来の意味を再解釈する作業が大量に発生します。
例えば、欠損や0は「本当に0」なのか「データが来ていないだけ」なのか？、どの状態が最終確定なのか？などです。
Shift Leftではソースシステムを所有するドメインチームとデータチームが同じコンテキストでデータを設計するため、ビジネスルールの意図をスキーマに反映することが可能となります。
つまり、
- 不整合が起きやすい箇所（状態遷移、ID管理など）を最初から正しく設計できる
- 仕様変更に対してデータモデルとアプリ変更を同期しやすい
ということが可能となります。
結果として、Shift Rightで課題となっていたドメイン本来の意味を再解釈する作業が減り、品質のボトルネックが上流で解消することが可能となります。
加工レイヤが薄くなり、リアルタイム処理が簡潔になる
メダリオンアーキテクチャでは、ブロンズ⇒シルバー⇒ゴールドと複数段階での加工・品質担保を行います。
これはデータを加工する場所が多いということにもなり、リアルタイム処理ではレイテンシ増加の原因になります。
Shift Leftではイベントは最初から意味のある構造で提供され、下流での標準化処理（Silver相当）が極小化されます。
つまり、ストリーミング処理の場合は、変換ステップが減り、そのまま下流でデータを活用することが可能となり、低遅延を維持することができます。
二重変換が減り、コスト効率が良い
Shift Rightの場合、以下のように変換が重複することがあります。
- アプリ側で内部用の形式に変換（アプリ都合）
- Bronze→Silver で分析用に変換（分析都合）
- Silver→Gold で業務指標用に変換（BI都合）
というように、目的の違いに応じて 同じ元データを何度も加工することになります。
Shift Leftでは最初にソース側が分析で使える形まで整えたイベントやデータを出すため、データの再整形の手間が省かれます。
つまり、下記のようなメリットが考えられます。
- 処理コストの削減（ETL/ELT回数が減る）
- ストレージコスト削減（不要な中間データが減る）
- パイプライン運用負荷削減
Data Contractベースで品質担保
Data ContractはShift Leftのコアとなる概念です。
例えば下記のようなデータの規約を「契約」として定義し、ソース側として担保します。
- スキーマ
- ルール
- データ品質
- バージョニング
これにより下流は正しいデータが来る前提で処理できます。
また、バリデーションによる担保も容易となり、バージョンアップも契約ベースで管理することが可能となります。
つまり、Shift LeftではData Contractがデータ品質とアーキテクチャの共通言語となり、結果として、チーム間の調整コストが減り、データの品質保証が簡潔になり、変更に強い構造を作ることができます。
Data Contractについてはなかなか体系的に解説された書籍が少なく、アプローチも固まりきっていない印象です。
その中でも下記の書籍が理解しやすいと思います。
わたしもアプローチを色々考えているのでまとまったら記事化したいと思います！
Shift Left Architectureは銀の弾丸となるか
これは、場合によるという結論となります。
前述したようなメリットがある一方で新たな課題が発生します。
ソース側への負荷が大きい
アプリケーションチームは、従来のシステム開発に加え、データモデリング、データ品質保証、スキーマバージョン管理、Data Contractの管理といった新たなタスクと責任が発生します。
新たなスキルが必要となる
データモデリングやData Contractの知識をソフトウェア開発チームが理解する必要があります。
ここでいうデータモデリングはディメンショナルデータモデリングやData Vaultといったモデリング手法となります。
ソフトウェア開発とは異なる知識が必要となるため、ここにどう対応するかが課題となります。
組織やシステム構造に依存する
ここが一番大きい課題だと思います。
そもそもソースシステム側でデータプロダクトを作成するデータチームが編成できるかが課題となります。
特に大規模システムだと外部システムやSaaSなど複数のシステムやサービスを組み合わせることも多く、現実的に難しい部分も多いと思います。
上流の設計ミスが全体に波及する
ソース側ですべてを担保する必要があります。
つまり、上流でのミスが下流のデータを使うすべてのシステムやユーザに影響することになります。
また、メダリオンのような段階的な品質向上も行わないため、品質をいかに担保するかもポイントとなります。
結論
上記のようにShift Leftにはメリットの他、課題も多く存在するため、Shift Rightと組み合わせるのが現実的かなと思います。
例えば、Data ContractだけをShift Leftで採用するなどです。
これにより、Data Contractがデータ品質とアーキテクチャの共通言語となり、結果として、チーム間の調整コストが減り、データの品質保証が簡潔になり、変更に強い構造を作ることができます。
まとめ
今回はShift Left Architectureを考えてみました。
Shift Left Architectureは、データ品質・リアルタイム性・コストの観点で非常に魅力的なアプローチです。
一方で、ソース側への負荷や、新たなスキルセットの要求、組織的な負荷といった課題も存在します。
個人的に、重要なのはテクノロジーよりも組織と責務の設計にあると考えています。
- どこまでを上流に寄せるべきか
- どこからを従来アーキテクチャで担保すべきか
- 組織文化・スキルセット・運用体制はどうか
つまり、Shift LeftやShift Rightにこだわらず、組織やシステム、そして要件に合った現実的なアプローチをとることが重要だと思います。
今回の記事がアーキテクチャ検討の参考になれば幸いです。
Discussion