ペアーズにおけるData Catalog導入の取り組み

Transcript

1. 2025年4⽉3⽇ 春のSREまつり 〜 ⼤規模サービス "あるある" との戦い事例 〜 ペアーズにおける DataCatalog 導⼊の取り組み
2. About Me Hikaru Sasamoto（@hisamouna34） • 株式会社エウレカ ◦ 2022年に⼊社 ▪ SRE & Data Platform Team ◦ ⿇雀、スポーツ(バスケ‧アメフト‧サッカー)が好き
3. 今⽇のお話しする範囲について • ペアーズで最近導⼊した DataCatalog 環境について • DataCatalog を活⽤した取り組みについて • 話さないこと ◦ DataCatalog ツールの詳細
4. Agenda 1. DataCatalog とは 2. なぜ DataCatalog を導⼊するに⾄ったか 3. ペアーズにおける DataCatalog 構成 4. DataCatalog 活⽤の取り組みを紹介 5. まとめ
5. DataCatalog とは • DataCatalog はデータ利⽤者が必要なデータを探し出せるサービス • DataCatalog のエンドユーザ (参考⽂献 [1]) ◦ Data analytics end users ▪ インサイトが得られるデータソースを発⾒するために DataCatalog を 使う⼈たち ◦ Governance end users ▪ 保護すべき confidential データや sensitive データを発⾒するために DataCatalog を使う⼈たち ◦ Everyday end users ▪ 上記に該当しないがデータに関して知りたくて DataCatalog を使う⼈ たち
6. DataCatalog を導⼊する前に直⾯していた問題 • データガバナンス観点 ◦ ペアーズが保有するデータ資産の全体像を把握することは、開発の効率化やデータガバナ ンス強化の観点から⾮常に重要 ◦ データに関する知識や理解が⻑年在籍している社員の暗黙知として蓄積されているケース が散⾒された ◦ ペアーズでは DLP (Data Lifecycle Policy / データライフサイクルポリシー) を定めてお り、データの分類 (例：UGC、本⼈確認書類、個⼈識別情報) に応じて適切な取り扱いを ⾏なっている ▪ そのため、データ分類の管理がとても重要 ▪ 以前はスプレッドシートで管理されていたが、属⼈性が⾼く、更新漏れや重複管理 のリスクがあった
7. DataCatalog を導⼊する前に直⾯していた問題 • 開発‧分析観点 ◦ 新機能の開発に使えそうなテーブルを⾒つけたが、各カラムの定義が不明 で使⽤を躊躇する ◦ 特定のビジネスデータを分析したいが、どのテーブルに格納されているの か探すのに時間がかかる ◦ あるデータの変更が他のシステムにどのような影響を与えるか把握でき ず、変更に慎重にならざるを得ない ▪ データの関係性(データリネージ)を明確にしたい
8. DataCatalog を導⼊を決断 • こうした背景から、データに関する情報を⼀元管理し、誰もが必要な時に必要な情報を知れる 「データを管理する機構」として Data Catalog の導⼊することにした • まずは、データの管理場所の⽤意と最低限のデータ分類ができるようにすることを⽬指す ◦ データリネージやメタデータの充実は次のステップとすることにした
9. DataCatalog ツールとして、Atlan を採⽤ • Atlan のメリット ◦ SaaS ツールのため、⾃社でのインフラ整備‧管理不要 ◦ 各種⾔語のSDKの提供 ◦ 豊富なデータソースコネクションの提供 ▪ MySQL, BigQuery, Tableau… ◦ データソースへのキーレス認証が可能 ▪ e.g. IAM Role ベースでの DynamoDB, S3 アクセスが可能 ◦ RDBMS への直接アクセスすることなしに、テーブル定義などの取得が可能 ▪ 外部サービス (Atlan)からのアクセスのためのネックワークの整備が 不要
10. ペアーズのデータソース(⼀部)を DataCatalog で管理できるように • アプリケーション⽤途 ◦ MySQL ◦ DynamoDB • 分析⽤途 ◦ BigQuery ◦ dbt (SQL ベースのデータモデリングツール) • 未対応だが、いつか DataCatalog で管理したい ◦ S3 ◦ Tableau ◦ その他、スプレッドシートで管理しているデータ
11. ペアーズ DataCatalog システム構成図 詳細は次スライドで
12. Atlan で確認できるカタログデータ データソース カタログデータ類 MySQL • スキーマ名 • テーブル ◦ 名前、Description • カラム ◦ 名前、Description、データタイプ • テーブルサイズ、レコード数 DynamoDB • テーブル ◦ 名前 • アトリビュート ◦ 名前、データタイプ • テーブルサイズ、アイテム数 • LSI, GSI BigQuery / dbt • データセット名 • テーブル ◦ 名前、Description • カラム ◦ 名前、Description、データタイプ • (BigQuery) テーブルサイズ、行数
13. • MySQL ◦ EKS 上で実⾏した Job が Amazon Aurora MySQL にアクセスし、 カタログデータを取得 ◦ カタログデータを S3 にアップロード ◦ Atlan は S3 にアクセスする Atlan へのカタログデータ Ingestionフロー
14. Atlan へのカタログデータ Ingestionフロー • DynamoDB ◦ Atlan が DynamoDB にアクセス ▪ DescribeTable で取得できる情報がカタログデータ ◦ 上記だけだと、全アトリビュートをカタログ化することができない ▪ DynamoDB は Key-Value 型のスキーマレスなデータベースのため、アイテムが持 つアトリビュートは事前のスキーマ定義からは分からない ▪ そのため、アプリケーションコード( Go )を静的解析して、dbt モデルとして出⼒ ▪ dbt のカタログデータとして管理
15. DynamoDB - アプリケーションコード(Go)を静的解析し、モデル化 • 構造体の dynamodbav タグからアトリビュートを取得 • 構造体名からテーブル名を定義している const を取得 • 取得したテーブル名‧アトリビュートを dbt モデル化 type DDBSample struct { ID int64 `dynamodbav:"id"` Status int64 `dynamodbav:"status"` CreatedAt string `dynamodbav:"created_at"` } const SampleTableName = "ddb_sample" version: "2" models: - name: catalog_dynamodb_ddb_sample config: alias: ddb_sample materialized: table columns: - name: id type: string tags: - ddb_data_type::number - name: status type: string tags: - ddb_data_type::number dbt モデル化
16. Atlan へのカタログデータ Ingestionフロー • BigQuery ◦ Atlan が BigQuery にアクセスしカタログデータを取得 • dbt ◦ Github Actions でカタログデータを⽣成 ▪ 前述の DynamoDB カタログデータも含む ◦ S3 にアップロード ◦ Atlan は S3 にアクセス
17. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 活⽤事例
18. (再掲) DataCatalog を導⼊する前に直⾯していた問題 • データガバナンス観点 ◦ ペアーズが保有するデータ資産の全体像を把握することは、開発の効率化やデータガバナ ンス強化の観点から⾮常に重要 ◦ データに関する知識や理解が⻑年在籍している社員の暗黙知として蓄積されているケース が散⾒された ◦ ペアーズでは DLP (Data Lifecycle Policy / データライフサイクルポリシー) を定めてお り、データの分類 (例：UGC、本⼈確認書類、個⼈識別情報) に応じて適切な取り扱いを ⾏なっている ▪ そのため、データ分類の管理がとても重要 ▪ 以前はスプレッドシートで管理されていたが、属⼈性が⾼く、更新漏れや重複管理 のリスクがあった
19. データ分類の管理に DataCatalog を活⽤ • DLP データを DataCatalog での管理に変更 • 対象データに DLP ⽤メタデータを付与 • 承認ベースでのメタデータ付与が可能なので、意図しない DLP データの⼊⼒を避けることが できる • 今後は、Atlan API を使って、分類に応じた適切な実装をしているかの確認に活⽤できそう
20. (再掲) DataCatalog を導⼊する前に直⾯していた問題 • 開発‧分析観点 ◦ 新機能の開発に使えそうなテーブルを⾒つけたが、各カラムの定義が不明 で使⽤を躊躇する ◦ 特定のビジネスデータを分析したいが、どのテーブルに格納されているの か探すのに時間がかかる ◦ あるデータの変更が他のシステムにどのような影響を与えるか把握でき ず、変更に慎重にならざるを得ない ▪ データの関係性(データリネージ)を明確にしたい
21. から抜粋 (参考資料[2])。 DataCatalog 構築により、LLM アプリケーションが活⽤できるデータソースが充実 LLM for Developer として、 社内ユーザ向けのツールを提供 LLM for Developer への取り組み
22. ⾃然⾔語でのデータ関連質問への回答をしてくれる Slack Bot 提供 • Atlan に保存されたカタログデータのダンプを S3 にアップロードし、Amazon Bedrock Knowledge Bases に同期 • ⾃然⾔語での問い合わせが可能になり、⾮エンジニアでも使いやすく • Amazon Bedrock Knowledge Bases MCP を実装し、開発にカタログデータを利⽤できるように 参考資料 [3]
23. ⾃然⾔語でのデータ関連質問への回答をしてくれる Slack Bot 提供
24. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 今後の展望
25. 今後の展望 • MySQL の Performance Schema のデータや インデックス情報も DataCatalog で管理 できるようにしたい ◦ MCP で Amazon Bedrock Knowledge Bases の情報を取ってくるようにできれ ば、開発時にデータソースに関する情報(テーブルサイズ、インデックスの有無) に応じて、適切なコード⽣成をサポート ◦ MySQL へのクエリレビューで活⽤できそう • データの依存関係を明らかにする ◦ BigQuery と BI ツールの関係性がわかれば、不要なテーブル洗い出しに使える • メタデータをデータオーナが簡単に付与できる仕組みづくり
26. DataCatalog を活⽤して、データガバナンスの好循環を⽣み出す
27. 参考⽂献‧資料 • [1] Ole Olesen-Bagneux . The Enterprise Data Catalog . O'Reilly Media, Inc, February 2023 • [2] Takumi Ogawa . SREが投資するAIOps ~ペアーズにおけるLLM for Developerへの 取り組み~ https://speakerdeck.com/takumiogawa/sregatou-zi-suruaiops-peazuniokerullm-fo r-developerhenoqu-rizu-mi • [3] Takashi Narikawa . ペアーズにおけるAmazonBedrockを⽤いた障害対応⽀援⽣成 AIツールの導⼊事例 https://pages.awscloud.com/rs/112-TZM-766/images/20241115-AWS-AIML-2-Eurek a.pdf
28. We’re hiring! ペアーズではエンジニアを積極採⽤中！ カジュアル⾯談もお待ちしております！ (X: @hisamoua34)