eDreams ODIGEO データメッシュの内側 - プラットフォーム エンジニアリングの視点

※この投稿は米国時間 2023 年 12 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: バルセロナに本社を置く eDreams ODIGEO（略称 eDO）は、44 か国で 2,000 万人以上の顧客にサービスを提供する世界最大級のオンライン旅行会社です。同社がレガシーのデータ ウェアハウス環境をモダナイズし、BigQuery を基盤としたデータメッシュへと生まれ変わらせた経緯を紹介します。

eDO の方針の根幹には常にデータ分析があります。同社は、ビジネスの急成長に対応するとともに、顧客中心のアプローチへとシフトするために、数年かけてデータ アーキテクチャを一元的なデータ ウェアハウスから BigQuery を基盤としたモダンなデータメッシュ アーキテクチャへと大きく進化させてきました。この投稿では、技術的なお客様事例紹介とは異なる視点で、eDO がデータメッシュを確立する過程で学んだ教訓を紹介します。

eDO のデータ プラットフォーム アーキテクチャの進化

eDO ではもともと、一元的なデータチームがデータ ウェアハウス管理を担当していました。当時、データは常に利用可能で、信頼できる状態が保たれていましたが、会社が成長するにつれ、新規のデータ追加や複雑化する状況への対応が困難になっていました。一部の分析チームは独自のパイプラインおよびサイロを構築し、データの可用性およびチームの自律性を高めていましたが、その一方で、データの信頼性、品質、所有権の面で新たな課題が生じていました。

会社が成長を続け、複雑化が進むにしたがって、データサイロは限界に達しました。さらに、AI とデータ サイエンスの面からも、統合データモデルの必要性が顕著になりました。当時は 2019 年で、次の選択として自然だったのは、データレイクを中心とした一元的モデルを導入することでした。しかし、このようなモデルは、ビジネス ドメインおよび自律型チームに基づいて構成された eDO の分散型 e-commerce プラットフォームに適していません。また、言うまでもなく、急成長に伴うデータ変更の必要性にも迫られていました。

そこで、eDO は代替案としてデータメッシュを採用し、ビジネスに依存しないデータチームと、プラットフォームおよびチームの構成に沿った分散型データ アーキテクチャを導入しました。この枠組みのもとでは、データチームはもはやデータを「所有」せず、プロデューサーとコンシューマ向けのセルフサービス型コンポーネントの構築に注力します。

eDO のデータメッシュとデータ プロダクト アーキテクチャ

最終的に出来上がったのは、ビジネスに依存しない、セルフサービス モードで動作するデータ プラットフォームです。このアプローチなら、従来の一元的なデータチームの方式と異なり、開発チームはデータ インフラストラクチャに関する懸念から解放されます。また、データ プラットフォーム チームは、ビジネスに関する知識を要求されません。さらに、システムの機能がさらに複雑化しても、データチームに過剰な負担がかかることがありません。

データメッシュを採用するにあたって最大の難点となったのは、社内の慣習、組織、所有権に絡む事柄です。さらに、エンジニアリングの面での課題も山積していました。具体的には、大量のデータを処理する能力はもちろん、異なるビジネス ドメインからのデータセットを効率的に関連付けて結合する、データセットの複数のバージョンを管理する、正しいドキュメントを常に利用可能な状態にしておく、といった要件が求められます。さらに、維持費を抑えることや、システムを利用するチームやドメインの数を問わずスケーリングする、といったことも重要となってきます。

データメッシュの構築にあたっては、アーキテクチャの中心に BigQuery を据え、多数の Google Cloud プロダクトを採用しました。これらの採用の決め手となったのは、サーバーレスという特性、標準プロトコルのサポート、そして、既存の e-コマース プラットフォームとの統合が容易であるという点です。

このアーキテクチャの実現にあたって欠かせなかったのが、データ コントラクトの導入です。具体的には、以下のような条件を満たすコントラクトを使用しました。

• 単一のマイクロサービスおよびそのチームが排他的に所有する
• Avro および YAML ファイルを使って宣言的に実装する
• Avro スキーマでドキュメントを作成する
• 所有元のマイクロサービスのソースコード リポジトリで管理する

この宣言型のコントラクトによって、データの取り込みおよび品質チェックを自動化することが可能となり、ビジネス ドメインに関する知識が不要になりました。また、マイクロサービスがコントラクトを排他的に所有するようにしたこと、ならびに、人が読める形式のドキュメントを git リポジトリに格納したことで、プロデューサーがコントラクトの所有権を持つことが促進されました。

最後に、データ アーキテクチャについて見てみると、このプラットフォームには 4 種類のデータ プロダクト（ドメイン イベント、スナップショット、デリバティブ、品質レコード）があり、それぞれ、異なるアクセス パターンとニーズを満たしています。

学んだ教訓と、今後のプラットフォーム計画

プロジェクトに着手してからの 4 年間で、eDO は多くのことを学びました。また、近い将来、さまざまな改善や新機能の導入を予定しています。

学んだ教訓:

• コンシューマ代表としてアーリー アドプターを務めてくれる適任者を厳選する。
• オンボーディングをオプションにする。
• データ プロデューサーとのフィードバック ループを育む。
• データ品質は可変であることを前提に、中央チームが定めるのではなく、プロデューサーとコンシューマの間で合意するようにする。
• 実際の利用状況に基づき、データ プロダクトの反復的作成を計画する。
• データのバックログを、チームのプロダクト バックログに含める。
• データ コントラクトのモデリングは最も難易度とリスクが高い分野なので、連携ガバナンスに含める。
• ドメインチームおよびプラットフォーム チームにとって、データメッシュの採用は難易度の高いエンジニアリング プロジェクトであるという認識をもつ。
• データ コントラクトにドキュメントを含め、そのコントラクトのドメインについて知識がある読者向けの内容にする。

今後も、データメッシュの改善を続けていく予定です。現在、以下のような計画があります。

• データ品質 SLA の改善 - データのコンシューマとプロデューサー間の SLA を改善するために、データの正確性と整合性を測定する方法を検討中です。
• 自主的な移行 - 分析チームにデータサイロからデータメッシュへ移行してもらうために、「データ成熟度評価」という新しいフレームワークを試行中です。
• サードパーティに対応するデータ コントラクト - サードパーティのプロバイダからのデータに対応するため、複数のパイプラインやデータ コントラクトを作成中です。
• タイムリーなデータ取得 - ストリーミング プラットフォームから BigQuery にデータを取得する際のレイテンシを減らせるよう取り組んでいます。
• ドキュメントの多層化 - ドキュメントに新たな項目を追加し、データ コントラクトだけでなく、ビジネス ドメインの概念やプロセスに関する内容を含める予定です。

まとめ

データメッシュは、データ管理の新しく有望なアプローチであり、従来の一元的なデータ アーキテクチャが抱える課題を克服する道筋を示してくれます。eDO が実際の経験を通して学んだ教訓を参考に、データメッシュの導入プロジェクトをぜひ成功に導いてください。

Google Cloud でデータメッシュを導入する方法について詳しくは、こちらのテクニカル ホワイト ペーパーをお読みください。

ー eDreams ODIGEO、チーフ アーキテクト Carlos Saona 氏

ー Google EMEA、EMEA データ分析スペシャリスト Luis Velasco