この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
データアナリティクス事業本部の鈴木です。
AWS re:Invent 2022にて、セッション番号PRT222の『Why operationalizing data mesh is critical for operating in the cloud (sponsored by Capital One)』を聴講したのでレポートです。
セッションについて
登壇者
Patrick Barch, Sr Director, Product Management, Capital One Software
Session level
200 - Intermediate
Session type
Breakout Session
動画
セッション概要
データメッシュは、スケールするクラウドデータエコシステムために企業が採用できるフレームワークと原則のセットを提供し、データ管理にクラウドを利用する企業が直面する課題の解決に貢献します。このセッションでは、Capital One社がデータガバナンスの責任を各ビジネスラインのデータプロダクトオーナーに分散させることで、データエコシステムのスケールにどのように取り組んだかを学びます。また、Capital One社で採用した二つの柱を例に、企業がどのように効率的な運用を行えるかをご紹介します。本講演は、Capital One社（AWSパートナー）の提供によるものです。
発表概要
発表は大きく3つのパートで行われました。
- Capital One社でのデータ活用に関する経緯の紹介
- データメッシュの原則をどのように適用したか
- Capital One社でのデータメッシュの運用について
まずCapital One社では、発足当初からデータとテクノロジーのサービスへの活用に注目しており、特に約10年前から社内のテクノロジー利用方法の改革に取り組み始めたそうです。
クラウドを全面的に導入すると、さまざまな場所でさまざまなメンバーがデータを保存したり利用するようになるため、それぞれの要件にあった管理方法が必要になりました。
このような状況を解決するために、様々なツールを組み合わせることになり、最終的には以下のような上手くいかないシステムを構築するかもしれません。
このようなシステムでは、データパブリッシャーはデータの品質チェックなどの作業を行う必要があるほか、データの仕様変更があった場合に、適切に下流のメンバーを探し出し、それを伝える必要があります。データの消費者は、使用しているデータが正常なのか知る必要があります。データガバナンスチームはポリシーの適用先が多く、管理が難しくなります。このような理由から、このアーキテクチャでシステムをスケールさせす際には、システムはとても複雑になるそうです。
そのような場合にデータメッシュが有効です。データメッシュは原則の集まりであり、データエコシステムを管理を保ちつつスケールさせるためのアーキテクチャーの観点でのフレームワークです。
原則の中で、登壇者が一番の核心だと思っている原則は、「Data as a product」とのことでした。この原則に沿ってマインドセットの変革ができれば、ほかの原則は自然とついてくるそうです。これを実現するためには、データ製品をドメイン単位でどのように組織化するかを決め、データ製品のオーナーがセルフサービスでさまざまな活動を行えるようにする必要があります。
データメッシュ自体は2019年に誕生し、2020年から普及し始めましたが、Capital One社では類似の考え方でデータエコシステムの構築を進めていたそうです。それは以下の2つの柱からなるそうです。
- Centralized tooling and policy
- Federated data management
まず1つ目の柱についてです。
事業部門を独立した組織とデータの責任単位に分割し、階層化したそうです。大きなビジネスラインは3つか4つの階層、小さなビジネスラインは1つの階層というように、階層の数は規模によるそうです。各ビジネスラインには、それをサポートするための同じ役割分担を与えられています。
- Performing data steward:担当するビジネスユニット内の1つまたは複数のデータセットのリスクに対して責任を負います。
- Managing data steward:ビジネスユニット内のすべてのデータセットのリスクに責任を持ちます。
それようにメンバーを雇用したというよりは、既存メンバーが本業を持ちつつ行ったようです。
全社的なメタデータ管理の共通基準策定、リスクに応じたガバナンスの調整、データの重要性に応じた異なるデータ品質基準の定義なども行いました。
データ消費者のデータへのアクセスリクエストについては、消費者から見てデータの品質が分からないようなケースがあり、不要なリクエストの繰り返しが後を絶たなかったそうです。事業部門とそのデータの機密性のマッピングを作成し、例えばユーザーはまず機密性のないデータへのアクセスをリクエストできるようにし、権限を上げる必要があるときだけアクセスを再リクエストするようにすることで解決したそうです。
また、2つ目の柱として、4つの体験について紹介頂きました。
データプロデュース体験では、データの作成者が自分でデータを公開するためのプロセスを回せる仕組みを作りました。大きい企業では、データの公開は1〜2ヶ月くらいかかる大規模な開発になりがちです。データの作成者はまずメタデータの登録から始め、カタログへの登録、データ品質チェック、ジョブのスケジュール化、変換パイプラインの設定などを行い、データエンジニアリングチームの支援なしに、自動的にパイプラインが構築されるようにしているそうです。パイプラインがONになると、事前に設定しておいたガバナンスステップが自動的に実行されるそうです。エコシステムにデータを取り込む方法はたった1つだけにしたそうです。ただ、この方法はあまり厳格ではなく、柔軟であるように気をつけたそうです。
データコンシューマー体験では、以下のようなことを実現したそうです。
- あるデータセットに対して、単にデータを提供するだけではなく、推奨事項や既知の知見も分かるようにしておく。
- そのデータで実行される一般的なクエリ例も分かるようにする。
- そのデータを使用している人気のレポートも分かるようにする。
- 以下のようなデータの品質が分かるような情報も提供する。
- データ品質ルール
- データリネージ
- プロファイル
- データの鮮度や更新頻度
- そのデータを他に誰が使っているか
- 自分でアクセス権があるのか確認できるようにする。アクセス権がない場合は、同じワークフローでリクエストを送信し、適切な承認者に転送して、承認または拒否させることができる。
また、ガバナンスの仕組みはできる限り自動化しているそうで、例えばデータワークフローで不適切な個人情報の取り扱いがあればリスク管理チームに自動で連絡が飛び改善活動に入れたり、データ品質に関するインシデントの情報は定期レポートに自動出力されてレビューできるようになっているそうです。これをガバナンス体験としています。
最後にインフラストラクチャ管理に関する体験です。ベストプラクティスが守られ、適切なコスト管理が実施されていることを信頼し、ビジネスチームが自社のインフラを管理できるセルフサービスツールを構築したそうです。
例えば、アナリストグループで新しく計算リソースが必要になった場合、Snowflakeのリソースのプロビジョニングをリクエストします。アクセス管理を設定して、承認ワークフローを経た後、最終的にデータエンジニアリングの助けを借りないまま、リソースが自動的にプロビジョニングされます。それに加えて、チームが自己管理できるように、コスト予測・コストトレンド・コスト上昇を確認するためのダッシュボードや、コストの異常を通知するアラートも作成したそうです。
上記の活動により、データ分析環境の準備のため、中央のデータ分析基盤構築チームがボトルネックにならず、ビジネスチームが自分のペースで動けるようになったそうです。
結局のところ、データメッシュは概念・原則であり、運用モデルで、これを本当に組織で運用しようと思った場合、今回紹介いただいた4つの体験を構築するだけでなく、従来のデータエンジニアリング活動を、ビジネスチームが理解できるように公開し、ビジネスチームが使いやすいツールやセルフサービスを用意することで、それぞれのビジネスチームが実行できるようにする必要があるとのことでした。
最後に
今回は『Why operationalizing data mesh is critical for operating in the cloud (sponsored by Capital One)』のレポートでした。
Capital One社でどのようにスケール可能なデータエコシステムを構築・運用しているのかについて紹介頂きました。データメッシュというキーワードに注目して聴講したセッションでしたが、単にデータメッシュはどういうものでというところより遥か先の、データメッシュの原則をどのように理解して、会社として実現しているのかという点まで紹介されていて、とても勉強になりました。
もちろんこのような仕組みがマッチするかはケースバイケースではあるものの、1例としてぜひ覚えておきたい事例でしたので、興味がある方はセッション動画の方をご視聴ください。
0
