はじめに
3/17、18に開催されたDevelopers Summit 2022にて幸運にもData Meshについてお話しする機会を頂きました。普段は特定のお客様に対してお話しする機会の多い私ですが、多くの方にお話しできる大変貴重な機会となりました。一方、時間的制約もあり、またスポンサーセッションではなく公募でもあったため、より踏み込んだお話はまた別の機会とさせて頂きました。本エントリーは、その続きという訳ではありませんが、Data Meshの今後について個人的な見解についてもう少し書きたいと思います。
登壇資料はこちらに公開しています：
Microservices, Data, and Data Mesh (Deverlopers Summit 2022)
マイクロサービス デジャヴ
「マイクロサービスなんて。そんなスケーラビリティはいらない。」
「別にSOAとそんな変わりないじゃん。」
「ハードルが高すぎる。うちには無理。」
10年程前、マイクロサービスという単語が世に出始めた頃には良くこんな声が聞かれました。10年ほど経って、とは言っても世の中の大多数のアプリがマイクロサービスに変わった訳でも、新しく生まれたアプリが全てマイクロサービスとして構成されている訳ではありません。しかしながら、当時のマイクロサービスに対する懐疑的な見解は今日ほとんど聞かれません。
まず我々を取り巻く技術が大きく変わっています。
インフラは仮想化され、宣言的な手法で構成出来るという世界。インフラはコードと同様にバージョン管理され、再現性のある構築が出来る世界。アプリUIの振る舞いがロジックと完全に分離され、ブラウザ上で全てが動く世界。インフラからアプリまで、スタック全てを不可変なパッケージとして配布/利用出来る世界。そしてアプリ、ミドルウェア (この表現が今日も適切かは別として) 、インフラが等しくAPIで扱える世界。これら技術やプラクティスは10年前にはオープンな領域では存在せず、ごく一部の会社が内製によって利用するに限られていました。今はマイクロサービスを採択するか否かに関わらず、多くの企業としてこれら技術を選択する事は困難では無くなりました。
Early Adopters
これら新しい技術の成熟は、ニーズと共に起こった新たな技術と競争の産物です。
創世記にはそれまでの思想と大きく異なる尖ったアプローチが主流でした。Spring Cloud Netlixは、アプリのレイヤーで分散システムの複雑さを軽減させるという「アプリが解れば分散システム化できる」なアプローチ。Herokuに代表されるSaaSは、コードの管理手法を (アプリから見る) インフラの管理と融合させインフラの複雑さを隠蔽化するアプローチ。マイクロサービスという (当時は) 特殊なニーズに応える為なのか、それとも他の理由か、様々な要因によってこれら技術が生まれました。
結果として「これまでの全否定」に近いこのアプローチが、多くの注目と議論、成功と失敗を集めて評価される事となりました。残念ながらこれら技術の多くは本日では主流なアプローチとして捉えられる機会は減っていますが、今ある技術の多くがそのルーツをこれらアプローチに起因しており、またより「汎化」されることにより活用領域が広ったものであるよう見受けられます。Cloud Nativeなエコシステムが近年爆発的に広がっているのは、過去10年に渡って新しい価値観が実際に評価された結果であって、特段筋の良いアプローチが突如登場した訳ではありません。
マイクロサービスに関する回想は、現在のData Meshに対して考察する上で重要だと思っています。マイクロサービスという言語が登場してから、その思想の体現方法を模索した人達と、否定し受け入れなかった人たちには、本日とても大きな開きが生まれているのでは無いでしょうか？Data Meshも概念であり、特定のユースケースや、特定の技術活用を前提としたものではありません。マイクロサービスの時と同じ轍を踏む、つまり概念を技術的/実務的な理由で否定するという反応は得策ではないと考えています。
Data Meshと将来性
ではData Meshにマイクロサービス同様の将来性があるのか？というのは至極妥当な懸念です。結論から言うと、答えは誰にも分からないもので、実際に「評価」されない限り答えは見つからないものです。
一方、Data Meshの背景であるニーズと取り巻く環境はリアルなものです。仮にData Meshがその解法として適切でなかったとして、業界における力学はそのニーズを別の形で埋めようと働きかけます。ただ現時点ではData Meshがそのニーズに応えうる最も妥当なアプローチであるなら、Data Meshと真剣に向き合うことは正しい方向に向かった前進であると言えるのではないでしょうか？いずれにせよ、進まない限り景色は変わらないのだから。
データ分析へのニーズの変化
かつてデータ活用はBIツールやDWHの導入を意味し、週報や日報という周期で一部の人が「判断に利用する」為になされるのが常でした。今はデータの鮮度に対する期待値が大幅に高まり、判断の対象となる時期感は限りなく「今」に近いています。またデータは人が判断する為のツールとしてだけではなく、イベントとしてより高い粒度に対し、アクションが取る必要があるニーズも増えました。これまでのOLAP/OLTPといった明確な責任分岐の境界を超えて、データ活用の領域はより今に近い、オペレーションの中にもその用途は広がっています。
Hadoopのエコシステムは大量化/多様化するデータの保全と活用の双方をスコープに置く技術群ですが、保全と比較して活用の領域での効果は限定的でした。これが未成熟な技術が原因なのであれば、同じエコシステムに登場する新たな技術の採択で改善するかも知れません。しかし原因は技術にはなく、データを集めて活用するという固着した思想自体にあるならば、我々はデータに対する見方と扱い方について根底から考え直さなければなりません。Data Meshは後者であり、これまでのプラクティスに対して破壊的な提案をするアプローチです。
環境の変化とドメイン駆動
私個人はエヴァンスのドメイン駆動設計をなかなか手に取らず、ずっとAmazonのwishlistに入れていたエンジニアでした。数年後に重い腰を上げて読み始めましたが、どうも分からないというか、集中して読むことが出来ず半ばで一度放棄しています。10年近く経ったのち、マイクロサービスの文脈でこの本について言及された時、正直ピンと来なかったというか、この本の存在自体を忘れていました。お恥ずかしながら、エヴァンスの思想を理解し、20年近くドメイン駆動の分野での探究を続けてきた訳ではありません。
マイクロサービスの議論を深めると、機能で切り出したり再利用のキーワードで分類されるサービス設計には強い違和感を覚える様になりました。マイクロサービスの様な無理ゲーにチャレンジするのに、得れる成果はそんなものなのか？そんな機能だけ個別にスケールしたりデプロイしてそんな嬉しいのか？一時期はマイクロサービスに対してかなり懐疑的に捉えてもいました。誰も幸せなれるイメージが持てず、そんなアプローチが継続的に成果を出すとは思えませんでした。ドメインを軸ととした思想とマイクロサービスは、私にとっては両者を同時に捉えて初めて意味を成す様になったと思います。
ドメインが独立性を保ち、ドメイン同士が協調して稼働する分散システムという無理ゲーが可能なのであれば、今度はデータもその流れに倣ってドメインがオーナーシップを持つというのは自然な流れであるよう思います。
おわりに
Developers Summitでも少し触れましたが、Data Meshという思想はまだ創世記にあり、今日の時点で何か正解というような解法が存在する訳ではありません。少なくともマイクロサービスの時と同様、現時点では効果的にData Meshを導入/運用する上で必要な技術はまだ出揃っていないと思います。それでもData Meshの方向に向いて前に進んで欲しい、と思っています。思想は評価されることによって初めて具現化し価値を持ちます。評価されない思想はただの夢に留まり、そのまま朽ちていってしまいます。
Data Meshを評価に値しないと理由付ける事は容易です。しかし先述した通り、思想や概念を技術的/実務的な理由で否定する事は避けて欲しいと思います。思想の創世記で流した汗は、その思想が花開く時に必ず糧に、しかも大きな競争優位になると思います。