[レポート]AWSでデータメッシュアーキテクチャを構築する#ANT336 #reinvent

[レポート]AWSでデータメッシュアーキテクチャを構築する#ANT336 #reinvent

Clock Icon2023.01.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

データアナリティクス事業本部の鈴木です。

AWS re:Invent 2022の、セッション番号ANT336の『Building data mesh architectures on AWS』を聴講したのでレポートです。

セッションについて

登壇者

  • Travis Muhlestein, Chief Data & Analytics Officer, GoDaddy
  • Nivas Shankar, Principal Product Manager, AWS
  • Ian Meyers, Director of Product Management, Amazon Web Services

Session level

300 - Advanced

Session type

Breakout Session

動画

セッション概要

データファーストの企業は、より一層データメッシュアーキテクチャへの関心を高めています。このセクションでは、AWSでどのようにデータメッシュアーキテクチャを設計・構築・運用するのか学びます。このアーキテクチャにより分析の過程を最適化し、より速くビジネスへの洞察を導いてください。GoDaddy社の最高データ責任者Travis Muhlestein氏から、どのようにしてAWSを使ってデータメッシュを構築したのかも伺うことができます。

発表概要

このセッションは、大きく3つのパートに分かれていました。

  • データメッシュアーキテクチャについて説明するパート
  • AWSでどのように実現するのかについて説明するパート
  • GoDaddy社での取り組みについて紹介するパート

各々概要をご紹介します。

議題

データメッシュアーキテクチャについて

最新のデータ戦略では、幅広いデータソースに対して、強力なカタログとガバナンスモデルを使い、保有データの理解・発見性を高めるとともに、セキュリティガードレールにより安心して拡張できるようにします。その上で、分析・機械学習を実行するアプリケーションとデータを保存する仕組みを構築し、ビジネス上の問題解決に利用します。分析された情報は、エンドユーザー・ビジネスアナリスト・より良い意思決定に必要なアプリケーション・デバイスなどに公開されます。これらで行われた意思決定はデータソースにフィードバックされ、顧客体験の向上に使われることとなります。

モダンなデータ戦略

AWSでは、S3を中心に各種サービスを活用してシステムを構築していきます。

AWSでのモダンなデータ戦略

現状はデータを1箇所に集めるような仕組みが一般的で効果的な戦略ですが、それが本当に適切かはビジネスによります。データの活用方法については、それぞれのビジネスユニットが異なる要件を持つことが多くなってきています。その結果、例えばデータレイクが複数できてしまっているようなケースにおいては、データの発見や利用申請や権限制御などに課題が発生し、そのための強力なデータガバナンスが必要になります。

お客様の声

中央集権的なデータレイクの課題

データメッシュでアーキテクチャを考えることで、中央集権的なアーキテクチャとは異なり、独立したプラットフォーム(データドメイン)への投資を認め、単独で活動できるようになります。その上で、データガバナンスやデータカタログを活用し、どのように相互運用するか考えていきます。個々のドメインは、セルフサービス型でデータ共有を行います。例えば別のビジネスユニットがやってきて利用申請をしてデータを活用する場合、ドメインの単位でアクセス制御・使用状況や許可の測定と監査を行うことができます。

なぜデータメッシュなのか

AWSでどのように実現するのか

まずはデータメッシュの核心となる4つの原則についてです。これはThoughtworks社のホームページ同社のメンバーが出版している書籍に記載されている内容と同じです。

4つのコアな原則

この原則を踏まえて、AWS上でのデータメッシュの5点の設計目標を紹介されました。この目標を達成すれば、ドメインごとにデータ製品を構築して中央データベースのデータエンジニアのボトルネックを気にすることはなくなるのでアジリティが上がったり、各々のデータカタログを作成してドメイン同士で相互にデータを共有したりすることができます。

データメッシュのデザインのゴール

モダンなデータアーキテクチャがもつ5つの部分

データメッシュアーキテクチャのシステムを構築する場合、カタログやポリシー管理の一元化・プロデューサーとコンシューマー間のワークフロー管理のプロビジョニングのような課題の解決のため、強力なデータガバナンスの仕組みが必要になります。

この課題については、AWS上で構築する場合は、re:Invent2022で新しく発表されたAmazon DataZoneを使うことで解決ができます。

DataZoneによるガバナンスの中央化

話を戻して4つの原則について一つずつ詳しく確認していきます。

まずData domain ownershipです。例えば企業が自社が持っているデータセットについていくつかのドメインをつくりたいと考えた場合、組織の中にいくつかのプロダクションアカウント、分析アカウント、オペレーションアカウントのようなアカウントを作り、AWS Organizationsを使って組織化することができます。ドメインは自分のデータを、カタログにどう登録するか・どう保護するか・どう品質管理するかを考えつつ、保存していきます。そして、AWSでサポートしているデータレイク・データマーケットプレイス・データウェアハウスの3つのモデルのどれで共有するのか考えます。

データメッシュの原則1

2つ目はData as a productです。ドメインの所有者が自分たちのドメイン内のデータをリッチ化・変換・クレンジングし、コンシューマーがそのまま使えるようにしておくという原則です。

データメッシュの原則2

3つ目はSelf-serve sharingです。データコンシューマーが自分で、どのようなデータセットがあるか・どのようなドメインがあるか・アクセス要求はどう実施するのか・どのようにデータにアクセスするのか、などが分かるようになっており、実際に実行できるようになっていることです。

データメッシュの原則3

最後にFederated data governanceです。データセットにタグを付けて管理することで、そのドメインのデータセットが何か・どのように管理されているかが分かり、監査が一元化され、簡単になります。データのアクセスに使っているクレデンシャル情報も、中央管理アカウントで管理が可能になります。

データメッシュの原則4

実装例としては以下の2つを紹介頂きました。どちらもプロデューサーアカウント・ガバナンスアカウント・コンシューマーアカウントの3つの単位から構成されるモデルです。プロデューサーアカウントでデータを共有できるように加工した後、ガバナンスアカウントにデータロケーションとデータカタログを登録します。このようにして、あるアカウントから別のアカウントにデータ・アクセスを拡張できる仕組みを実現したことになります。この仕組みはAWS Lake Formationや、将来的にはAmazon DataZoneにて実現されます。コンシューマー側はサブスクリプションを申請し、承認されたらAthenaやRedshift Spectrumなどを使ってデータ製品にデータを問い合わせることができるようになります。

データメッシュアーキテクチャパターン1

データメッシュアーキテクチャパターン2

GoDaddy社での取り組み

GoDaddy社では小規模事業者のドメイン名を起点として、メール・ウェブサイト・ソーシャルプレゼンス・マーケティングと支援を行なっています。

vision&mission

データメッシュはAWSのサービスとAlationのような3rdパーティー製品を組み合わせて実現しているそうです。

data mesh

データメッシュ全体としては、10の事業部門と300以上のチームにまたがるデータ製品が開発され、さまざまなビジネス成果を上げいます。

アーキテクチャ

結果として、以下のようなビジネス成果を得られたそうです。

ビジネス成果

最後に

今回はAWS re:Invent 2022のセッションの一つである『Building data mesh architectures on AWS』のレポートでした。

データメッシュの原則に触れつつ、どのようにAWSのサービスを使ってドメインやセルフサービスなデータ製品をつくるのかが分かるセッションでした。また、GoDaddy社での実際の事例を知りたい方にも良い内容です。

AWS上でデータメッシュアーキテクチャの構築を検討している方にはぜひ視聴していただければと思います。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.