こんにちは。Azure ビジネス部の安部です。
この記事は「NEXTSCAPE Advent Calendar 2023」の10日目です。
本記事で伝えたいこと
- Microsoft Fabric が GA したことで Azure Synapse Analytics はどうしたらいいか戸惑ってる人向けの記事
- Azure Synapse Analytics は引き続きサポートされる。なので急いで Microsoft Fabric に移行する必要はない
- Microsoft Fabric と Azure Synapse Analytics の使い分けは良く分かってないが、組織図とデータランディングゾーンで考えるといいかも
- Microsoft Fabric を導入する際は組織レベルのデータ戦略とセットで考えたい
はじめに
先月の Microsoft Ignite においては MS製品を広範囲にわたって Copilot を中心に据えてリブランドするなど、Copilot/AI 一色でした。
その中でデータ統合基盤としてプレビューだった Microsoft Fabric がめでたく GA し、Copilot/AI をビジネスに活用していく際にデータを貯める場所として Microsoft Fabric および One Lake は Copilot の次に強くアピールされていた製品だったと思います。
Microsoft Fabric のコンセプトだけ見てると、データ統合関連の多くの機能が内蔵され、Copilot も搭載され、いよいよこれはマイクロソフト社が提供するデータ統合基盤製品の決定版なのでは思わされます。
その一方で、Azure Synapse Analytics は今後どうなるのか、出番はあるのか、という疑問や戸惑いも感じました。
マイクロソフト社の発信内容としても今後 Microsoft Fabric の開発にリソースが注がれていくことは確かだと思います。
私自身、まだ Microsoft Fabric への理解が浅くキャッチアップを始めている段階です。
その中で Azure Synapse Analytics はどうしたらいいのか疑問を抱くものの、（検索がへたくそなのか）腹落ちするズバリな答えを見つけることが出来なかったので、今時点の自分の見解を整理してみました。
Azure Synapse Analytics からすぐに Microsoft Fabric に移行しなくても大丈夫
Microsoft Fabric のよくある質問 では既存のデータ関連製品のサポートはしていくと明記されています。
移行ツールも段階的に提供されるとのことなので、急いで移行する必要は無さそうです。
既存の Microsoft 製品 (Azure Synapse Analytics、Azure Data Factory、Azure Data Explorer など) は今後も、データ分析のための堅牢なエンタープライズグレードの PaaS ソリューションとして提供されます。Microsoft Fabric はこれらのオファリングが 1 つのシンプルな SaaS ソリューションの形で進化したものであり、既存の PaaS オファリングへの接続も可能です。サービスを切り替える準備ができている移行チームのための移行パスは間もなく公開される予定です。
じゃあ移行ツールが揃ったらすぐに移行すべきなのかというと、その辺りについてははっきりとは分かりませんでした。どこかに説明されているドキュメントがあったのならすみません、見落としです。
ただ今時点の自分理解としては、技術的に可能であっても何も考えなしに Microsoft Fabric に移行するものではなく、Microsoft Fabric に移行するにあたり組織レベルのデータ戦略とフィットするかの見極めが必要になるのではと思っています。
組織とデータ基盤の役割を整理した上で Microsoft Fabric がフィットするかを考えてみたい
データ基盤の用途としてはデータを集める、貯める、加工する、分析する、可視化するなどがあり、最後に業務に役立てるところまでがデータ基盤の役割だと考えています。
このデータ基盤をどのように業務に役立てるかは、業務の課題や目標に向けた戦略が初めにあって、その戦略に沿ってデータ基盤の用途が定義され、構築されるという成り立ちが多いのではと感覚的に思っています。
その場合、業務の戦略を考える立場の人がそのデータ基盤のプロダクトオーナーであり、このプロダクトオーナーが組織の規模や組織内の立場次第でそのデータ基盤のスコープが変わるものだと自分は捉えています。
Microsoft Fabric には One Lake 機能を通じて組織内のデータをすべて一か所に集めてデータを見つけやすくし活用しやすくする的なコンセプトがあります。
ただ、このコンセプトイメージを素直に受け取り、実際に叶えようとしたら組織全体のデータ戦略を指揮できる立場や組織に居て、トップダウンで遂行できる権限が必要になってくる話だと思います。
小規模な企業ならまだしも、多数の事業部や全国に支社を抱えるような大規模な組織になれば簡単な話ではないです。
現実的な話、大規模の企業内で全社にまたがる施策やシステム導入を推し進める場合、強力な CoE を持つ組織でなければ、小さな範囲で検証や実績を積み上げてからという進め方が多いと思っていて、データ基盤の導入もまずは事業部レベルや特定領域でデータ基盤を構築して運用を始める、といったケースは往々にしてあると思います。
加えて、具体的な業務の課題に直面していてデータ基盤を最初に必要とするのは事業部であり、流れとしてその事業部の人がその事業部スコープのデータ基盤の役割を定義、構築し運用していくことなります。
そうしてそれぞれの事業部でデータ基盤相当の何かが構築されていき、結果的には組織全体のデータ基盤を持つ前にいくつかのデータ基盤が点在している状況になる、というのは自然な流れかなと自分は思います。
前項で、Azure Synapse Analytics から Microsoft Fabric に移行するにあたり組織レベルのデータ戦略とフィットするかの見極めが必要と言った理由には、Microsoft Fabric のコンセプトから見える理想と現実のギャップがある場合には、Microsoft Fabric 運用がすんなりとフィットしないケースがあるのはと疑問を抱いている。
データランディングゾーンと組織図
どのようなケースだと Microsoft Fabric はフィットしないのかの答えは Microsoft Fabric 初学者の私自身が理解を深めていく過程でいずれ見えてくる（Microsoft Fabric を理解している方から見たら）些細な疑問だと思っていますが、その疑問解消に繋がる気配を感じている気になっている資料として MS Learn のデータランディングゾーンを紹介したいです。
ざっくりいうと、データ基盤の各レイヤと対応するユーザの関係が整理された図です。
過去に、この図を知る前はデータ基盤の全体像のことをぼんやりと分かっていたつもりですが、この図の存在を知ってからはデータ基盤の全体像が鮮明になり理解の助けになった経緯があります。
そのデータランディングゾーンの関連ドキュメントにスケーリングに関するアーキテクチャが紹介されています。
この図はいくつかのデータランディングゾーンと１つのデータ管理ランディングゾーンで構成されています。
データ管理ランディングゾーンはそれぞれのデータランディングゾーンを管理したり可視化するといった役割になっています。
データランディングゾーンの詳細は MS Learn をご参照ください。
これを見たときに、私は組織図にフィットしそうだなと思いました。
スケーリングの方法 より引用
組織図にデータランディングゾーンを当てはめてみると One Lake の概念図とフィットしそう
簡単なイメージですが、組織図に上記のデータランディングゾーンを当てはめてみました。
事業部はそれぞれ自分たちのデータ基盤を抱えていて、それらを束ねる中央データ基盤を上位層に据えたイメージです。
中央データ基盤は各事業部のデータ基盤を集約し、組織全体にデータを提供する役割をイメージしています。
データ基盤内のデータ形式やモデリングをどのように解釈し、どのような形で提供していくかは考える必要がありますが、ひとまず組織内のデータ一つに束ねて利用できる場所としてデータ管理ランディングゾーンと見なすことが出来そうな気がしました。
事業部は組織全体のことは考えず、自分たちの業務に集中できるように自分たちのデータ基盤を持つのことは合理的だと思います。
事業部の数に応じてデータ基盤は複数存在することになりますが、データランディングゾーンと見なせば特に問題ないと感じました。
下図は Microsoft Fabric の One Lake にデータを集約してくる概念図です。
上記の図を当てはめてみると、下層の Azure Data Lake Storage や Amazon, Dataverse が各事業部のデータ基盤に該当し、中央層の One Lake が中央データ基盤といった感じで当てはめるとフィットしそうな気がします。
ショートカットを使用すると、データを移動せずにドメインにまたがってデータを接続 より引用
Azure Synapse Analytics の方がフィットするケース、Microsoft Fabric が実はフィットしないケースはあるか
結局この疑問についてここまで個人的な解釈を整理してきたわけですが、あくまで個人的な見解としては 中央データ基盤としては Microsoft Fabric がフィットするが、それ以外は Azure Synapse Analytics でも大丈夫そうな気がしました。
少なくとも、現に Azure Synapse Analytics で構築運用中であれば少し様子見てから判断でいいと思います。
重要なのは、組織全体のデータ戦略があって、そこの中央データ基盤相当に Microsoft Fabric を据えて、それをどのように活用していくかの方針と利用可能な状態まで整備済みかどうかだと考えています。
それ無しに事業部レベルで Microsoft Fabric に（どれ程度の苦労が必要なのか予想できないですが）頑張って移行したとしても、Fabric の製品コンセプトを体現できず中途半端にな結果になりそうな気がしています。
私が思いつく Azure Synapse Analytics を運用していく方が都合がいいケースの１つとして、Azure サブスクリプションで明示的に領域が線引きされていることです。
Microsoft Fabric は M365 空間に内蔵された SaaS みたいな位置づけななのと、組織間でデータを共有する場所柄なゆえ、組織間同士線引きが Azure に比べ曖昧に感じました。
そういう意味では慣れ親しんでいる Azure サブスクリプションで組織同士がキチンと線引きされた場所で、運用していく方がやりやすいケースはありそうかなと想像しています。
終わりに
結局のところ、じゃあ急いで Fabric に移行せず様子見が良さそうと言って Azure Synapse Analytics から Microsoft Fabric への移行に関してトーンダウンするような言い方になっています。
かと言って Microsoft Fabric への移行を消極的になるのも良くないとは思いますので最後に念のため強調させていただきますが、基本的に Microsoft Fabric が今後のデータ基盤の中心になっていくのおり、積極的に使っていくべき製品です。
もうすでに AI 時代真っただ中な状況なので早く Microsoft Fabric を活用していけるように社内のデータ活用戦略を考え始めたり、小さいところから試験的に導入していくべきだと思います。
今回は Microsoft Fabric の詳しい機能については触れなかったですが Synapse Analytics に比べて機能統合が最適化され進化しているはずなので、これから Microsoft Fabric を触る時間を増やして引き続きキャッチアップしていきたいと思います。