re:Invent 2024: AWSのデータ共有ソリューションとOccidentalの活用事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Achieve seamless and secure data sharing (ANT325)
この動画では、データ共有とセキュリティに関する課題と、それを解決するAWSのソリューションについて詳しく解説しています。AWS Glue Data Catalog、Amazon Redshift、AWS Data Exchange、AWS Clean Roomsなど、様々なデータ共有ソリューションの特徴と活用方法が紹介されます。特に注目すべきは、Occidentalの事例で、Data Meshアーキテクチャを活用して13のProducerドメインを構築し、DELTACIPHERというGenerative AIツールを開発して掘削データの分析を劇的に効率化した実例が示されています。また、新しく発表されたAmazon SageMaker Unified Studioにより、データカタログやクエリエディタなどが1つのツールに統合され、より効率的なデータ分析が可能になることも紹介されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
データ共有とセキュリティの課題に対するAWSソリューションの紹介
みなさん、こんにちは。Amazon Redshiftのシニアプロダクトマネージャーを務めるYanzhu Jiです。本日は、モダンなデータアーキテクチャについて、そして組織内でのデータ分析の拡張とデータコラボレーションの強化のためにデータ共有をどのように活用できるか、さらにデータ共有におけるセキュリティの確保について、みなさんとご一緒に探っていきたいと思います。 本日は、AWSのPrincipal Big Data ArchitectであるSaurabh Bhutyani氏、そしてOccidentalのData & Analytics Strategic AdvisorであるJamey Johnston氏をお迎えしてお話を進めていきます。
アジェンダはこちらです：まず、お客様がデータ共有とセキュリティに関して直面している一般的な課題について見ていきます。次に、これらの課題を克服し、データコラボレーションを促進するためのAWSのソリューションについて探っていきます。その後、JameyがOccidentalの実例を紹介し、AWSソリューションを活用してデータ共有の課題をどのように解決したかをご説明します。さらに、Saurabhが、AWSが提供するサードパーティのデータ共有およびコラボレーションソリューションについてお話しします。
データ駆動型組織への転換における課題とAWSの対応策
データは重要です。ほぼすべてのお客様がそれを認識しています。お客様はデータを重要な推進力として捉え、その投資を増やし続けています。複数のソースによる調査では、82%の組織がChief Data Officerを任命し、94%の組織がデータ駆動型イニシアチブへの投資を増やしていることがわかりました。データ駆動型イニシアチブを成功させたお客様は、最大20%の収益成長を実現しています。
しかし、 これらの投資がすべて成功しているわけではありません。調査によると、 データ駆動型組織への転換を完了できた組織は4分の1にすぎません。 お客様がデータを進化させ、要件がより複雑になっていく過程で、課題は3つの側面から生じています。1つ目はデータサイロです。データが複数のリポジトリに分散しており、それらを連携させるために追加の取り込みコストが必要となります。これは通常、複雑化する使用ケースへの相互運用性が不足しています。2つ目の課題はデータコピーに起因します。データが分散しているため、あるところから別の場所にデータをコピーする必要があります。カラム名の更新などモデルの変更が発生するたびに、すべての場所で更新する必要があり、そうしないとデータ間の同期が失われ、分析の精度が低下してしまいます。3つ目の課題は分断されたガバナンスです。異なるデータリポジトリには、異なる環境で重複したデータアクセス制御が存在します。AWSデータ環境からのデータ共有のネイティブサポートがない場合、これらの異なるアクセス制御の同期を確保し、一貫したデータアクセスを維持することは非常に困難です。
AWSはこれらの課題に対応するソリューションを提供しています。まず、ユーザーが適切なデータセットを効率的に発見して特定できるようにし、データサイロを解消して迅速な意思決定を促進します。次に、遅延なくリアルタイムでデータにアクセスできるよう、遅延を最小限に抑えます。3つ目に、組織内外での安全で規制に準拠したデータ共有を可能にする、堅牢なデータガバナンスポリシーツールを提供します。そして最後に、同様に重要な点として、データ保護の重要性を認識し、お客様の個人情報とお客様のお客様の情報を保護する必要性に対応します。
現在、これらの保護されたポリシーをサポートしています。先ほど説明したように、すべてのデータが同じ環境にあるわけではないため、Data Lake、Data Warehouse、Lakehouse、Data Meshなどからどのようなユースケースが可能で、どのようなソリューションが提供できるのかを順を追って説明していきます。
AWS Glue Data CatalogとAmazon Redshiftによるデータ共有の実現
ある企業で働いており、組織内でData Lakeを構築していて、データアクセスと権限を一元管理するための技術メタデータカタログの使用を検討しているとします。最も重要なのは、組織内の異なる部門が同じデータセットで協力して作業できるよう、簡単にデータを共有できることです。AWS Glue Data CatalogはData Lake用のメタデータストアです。多様なデータセット全体でのデータの管理、発見、ガバナンスに関連する課題に対応することで、Data Lakeでのデータ共有を実現します。Data Lake全体のメタデータに関する単一の情報源として機能し、ユーザーが効率的にデータセットを見つけて理解できるようにし、データサイロを解消します。
最も重要な点として、AWS Glue Data CatalogはAmazon Athena、Redshift Spectrum、Amazon EMRなどのさまざまなサービスやツール、そしてサードパーティツールと統合されています。異なるエンジンを使用してデータにアクセスする場合でも、同じ体験、同じデータ、同じガバナンスを得られ、チームが協力して作業できます。AWS Glue Data Catalogを使用すれば、Data Lakeでのデータ共有を非常に簡単に実現できます。データ所有者として、AWS Glue Data Catalogにリソースリンクを作成し、これらのリンクは別のAWSアカウントと共有したいデータを指し示します。所有者はAWS Lake Formationを通じて権限とポリシーを定義し、受信者がアクセスできる範囲を制限できます。
受信者側では、共有されたデータが他の所有データと同様にAWS Glue Data Catalogに表示されます。唯一の違いは、実際のデータは所有者アカウントに残ったままという点です。受信者は所有者が定義した権限に従って、Amazon Athena、Spectrumなどのサービスを使用してデータをクエリできるようになります。Lake Formationは、適切な人に権限が付与されていることを保証します。これがAWS Glue Data Catalogでのデータ共有の仕組みです - データを移動することなく、アカウント間で安全かつ効率的にデータを共有する方法です。
では、Data Lakeではなく、Amazon Redshiftのようなデータウェアハウスを使用している場合はどうでしょうか？チームやビジネスユニット間で協力してダッシュボードを構築したり、レポートを生成したり、分析を実行したりしたいが、データが異なるデータウェアハウスクラスターにある場合を想像してみてください。ここでAmazon Redshiftが、データウェアハウス間、アカウント間、リージョン間でのデータ共有を支援します。これまでに、Amazon Redshiftのデータ共有機能は、すでに何千もの顧客が共有データに対して日々何百万ものクエリを実行しています。Amazon Redshiftのデータ共有により、顧客は1つのデータウェアハウス内、データウェアハウス間、そしてリージョン間で、ライブで透過的なトランザクション整合性のあるデータを共有することができます。
私たちは、お客様が異なるデータ共有アーキテクチャを構築している様子を目にしており、ここでは典型的な2つのアーキテクチャ、Data MeshとHub and Spokeをご紹介します。Data Meshアーキテクチャでは、異なるビジネスグループがデータを共有し、協力することができます。Hub and Spoke構造では、データを共通の環境に取り込み、サテライト型のコンシューマーが同じデータにアクセスできるようになります。データの共有と連携は、さまざまな構造で実装することができ、これらの設定では、Producerにもなれば、Consumerにもなることができます。Data Meshアーキテクチャについては、後ほど私の同僚のSaurabhが詳しく説明します。
Amazon Redshiftでのデータ共有の仕組みを理解するには、2つの重要な概念があります。 1つ目はProvisioned Clusterとクラスターワークグループ、2つ目はAmazon Redshift Managed Storage（RMS）です。クラスターまたはクラスターワークグループは、データの読み取り、書き込み、分析、変換を協調して行うコンピュートノードで構成されています。RMSはデータを保存する場所で、データの追加、削除、変更を行うと、Amazon S3にコミットされます。クエリを実行すると、データウェアハウスはまずメモリ内にデータがあるかどうかを確認します。メモリ内にある場合は、そのデータを使用してクエリを実行し、ない場合はS3からデータを取り込んでからクエリを実行します。
データ共有は、この機能を拡張したもので、お客様は他のクラスター、サーバー、ネームスペース、そして他のアカウントとデータを共有したい場合に、それらを指定することができます。これらのオブジェクトをData Shareに追加すると、他のデータウェアハウスがデータをクエリできる権限を与えることになります。 しかし、読み取り専用のアクセスでは、特にETLワークロードをスケールさせてデータウェアハウスへの書き込みアクセスが必要な場合など、すべてのユースケースに対応できないかもしれません。 最近、Multi-Data Warehouse Writesの一般提供を発表しました。これにより、データコンシューマーが元のデータベースに書き込むことができるようになりました。この機能により、大規模なETLワークロードを、読み書き両方の機能を持つ異なるデータウェアハウスに分割することで、より高いパフォーマンスで処理できるようになります。Producerは、誰がデータベースに書き込めるかの権限をコントロールできます。この強力な機能により、Data Meshアーキテクチャの実現が可能になり、ワークロードが簡素化され、データ分析がより容易になります。
Amazon SageMaker Lakehouseがもたらす統合データ分析環境
さて、Data LakeとData Warehouseの両方を使用している場合、データ共有を管理するために異なるサービスを行き来したくないかもしれません。そこで、私たちは新しい概念であるLakehouseを導入しました。 LakehouseはData Lakeの柔軟性とオープン性を、Data Warehouseのパフォーマンスとトランザクショナルなデータ管理機能と組み合わせたものです。これにより、組織はビジネスインテリジェンス、ETL処理、ダッシュボード作成、さらにはAI/MLや生成AIアプリケーションなどの最先端技術まで、さまざまな分析ユースケースに適したサービスやツールを幅広く選択できるようになります。
Matt Garmanは先ほど、Amazon SageMaker Lakehouseを発表しました。これは、Amazon S3とAmazon Redshift Data Warehouseにまたがるデータを統合し、単一のデータコピーで強力な分析やAI/MLアプリケーションを構築できるようにするものです。Amazon SageMaker Lakehouseでは、EMR、AWS Glue、Amazon RedshiftなどのAWSサービスや、Apache Sparkなどのオープンソースフレームワークを含む、すべてのApache Iceberg互換のツールやエンジンを使用して、データをその場でアクセス・クエリできる柔軟性が得られます。Lakehouse内のデータは、AWS Lake Formationで安全に保護することができます。
AWS Lake Formationでは、きめ細かな権限設定が可能で、一元的にデータを管理できます。 Lakhouseにアクセスするには、AWS Glue Data Catalogに移動し、テーブルの論理コンテナとなるデータベースを作成します。その後、これらのテーブルの保存場所を選択できます。Icebergのようなオープンフォーマットを使用したい場合はAmazon S3に保存するか、Amazon RMSのようなBIアプリケーションに保存するかを選択できます。データの保存場所に関係なく、それらをIcebergテーブルとしてアクセスし、BIダッシュボードを強化するためのマテリアライズドビューを作成することができます。
まとめると、Lakhouseはデータとデータウェアハウスの体験を統合し、データがさまざまな場所にサイロ化されている状況と比べて、データのコラボレーションとガバナンスをはるかに容易にします。それでは、データ共有とData Meshについて、Saurabhに説明してもらいましょう。ありがとう、Yanzhu。皆さん、こんにちは。私はPrincipal Big Data Specialist Solutions ArchitectのSaurabh Bhutyaniです。私の好きなデータ共有トピックの1つであるData Meshについて説明していきましょう。 Data Meshを使用した共有について説明する前に、 まずData Meshとは何かを理解しましょう。Data Meshは、ドメイン指向のチームに責任を分散化することを可能にする、新しいアーキテクチャおよび組織的なアプローチです。
Data Meshアーキテクチャとその実装におけるAmazon DataZoneの役割
ドメイン指向のチームとは、組織のData Stewardのように、データを身近に扱い理解している人々のことです。これらの人々は、データの品質、整合性、そしてどこでどのように使用されるべきかを理解しています。Data Meshはパターンとして、ドメインオーナーやData Stewardがデータへのアクセスを制御し、管理することを可能にします。これらのドメインオーナーがアクセスを承認し、どのデータを誰と共有するかを決定し、データセットに制限を設けることもできるため、中央集権的なプラットフォームデータ管理チームは必要ありません。
もう1つの側面として、Data Meshパターンの一部として、ドメインオーナーがデータをプロダクトとして共有することが挙げられます。プロダクトは、1つまたは複数のデータアセットの組み合わせです。1つのテーブルを1つのプロダクトとすることも、ドメイン階層の一部として複数のテーブルを組み合わせることもできます。Data Meshでは、WebベースのIDEなどのツールセットを使用して、組織の人々が一緒にデータにアクセスし、データを発見し、使い始めることができるセルフサービスのデータプラットフォームを実装できます。データを利用するには購読が必要で、ドメインオーナーがいつでもデータへのアクセスを承認することができます。
AWS エコシステムの中で、データ共有のためのData Meshパターンを構築できるサービスであるAmazon DataZoneについて見ていきましょう。Amazon DataZone は、データプロデューサーとコンシューマーが共通のプラットフォームで協力できるようにします。これは一連のツールを通じてデータに関わる人々をつなぎ、次のスライドでより詳しく見ていきます。自動的なディスカバリーを可能にし、生成AIの機能も備えています。ビジネス用語の用語集を生成し、技術的なデータに追加したいデータオーナーは、Amazon DataZoneの機能を使用してビジネス用語集やビジネスコンテキストを生成し、技術カタログに追加することができます。これにより、組織の誰もが、データを使い始める前にそのデータが何を表しているのかを簡単に理解できるようになります。
Amazon DataZoneの詳細を見ていきましょう。 左側には、異なるアカウントやリージョンから様々なデータを持ち込むことができるデータプロデューサーがいます。右側には、データにアクセスし、協調的な環境を求めるデータコンシューマーがいます。彼らはデータへのアクセスだけでなく、様々なツールやサービスを使用してインサイトを得ることができます。プロデューサーとコンシューマーの間には、この協調的なサービスを実現する共通レイヤーとしてAmazon DataZoneが存在します。
Amazon DataZoneの最上位にはドメインがあります。これらのドメインは組織階層として考えることができます - 通常、各組織にはマーケティングや財務など、異なる事業部門があります。Amazon DataZoneのドメインの一部として、組織階層をドメインの集合として構築し、その階層全体を作成することができます。 Amazon DataZoneは、AWSコンソールの外部にデータポータルを提供します。ユーザーに提供すれば、AWSコンソールにログインすることなく、ブラウザを通じてこのデータポータルにアクセスできます。このデータポータルのもう一つの利点は、OktaのようなCorporate Identity Providerと統合できることです。AWSの認証情報も使用できますが、企業の認証情報を使用してポータルにアクセスすることができます。
他のAWSサービスと同様に、DataZoneにもAPIが用意されています。クライアントアプリケーションや独自のダッシュボード、UIを構築する場合は、DataZone APIを活用することができます。Amazon DataZoneはビジネスデータカタログを提供しており、これは Amazon DataZoneの中核となるものです。データプロデューサーは、データメッシュパターンで説明したビジネス用語集やコンテキストを追加しながら、ビジネスデータカタログにアセットを公開します。コンシューマーはデータポータルを通じてこのビジネスデータカタログにアクセスし、データアセットを検索・発見して、それらを購読することができます。データプロデューサーによってサブスクリプションが承認されると、データにアクセスし、好みのツールで使用を開始できます。
データへのアクセスと好みのツールでの使用のために、DataZoneはProjectsとEnvironmentsという概念を提供します。 Projectsは、コンシューマーが集まってデータにアクセスできるワークスペースです。Environmentsは必要な計算リソースを提供します - 例えば、AthenaやRedshift Spectrumを使用する場合、プロジェクトの一部としてEnvironmentsが処理するプロビジョニングが必要になります。下部には、ガバナンスとアクセス制御があり、DataZoneではデータオーナーや管理者がガバナンスを管理できます。ドメインオーナーとして、データセットやデータプロダクトにプロパティを設定し、どのコンシューマーがどのデータの列や行にアクセスできるか、どの認可ポリシーを適用すべきかを指定できます。
Amazon DataZoneがデータメッシュパターンをどのように加速するか見ていきましょう。 DataZoneは分散型のオーナーシップを提供します。 中央には、先ほど説明したドメインの概念があります。組織のためのルートドメインを作成し、組織階層をマッピングするためのサブドメインをルートドメインの一部として作成できます。これを行うと、プロデューサーはProjectsとカタログ、さまざまな分析サービスを使用して、データポータルを通じてこれらのドメインにアクセスし、データを公開できます。同様に、コンシューマーはこれらのAmazon DataZoneドメイン内で検索や発見を行うことができます。興味深い点は、プロデューサーは単なるプロデューサーである必要はなく、コンシューマーにもなれることです（その逆も同様です）。これこそが、複数のプロデューサーが存在し、プロデューサー自身が他者のデータを消費することもできるデータメッシュの素晴らしさなのです。
それでは、AWSのもう一つのエキサイティングな進展についてお話ししましょう。 次世代Amazon SageMakerについてご存知の方はどれくらいいらっしゃいますか？私たちは複数のキーノートで発表を行いました。 多くの方がご存知のようですね。Matt GarmanのキーノートでもSwami氏が昨日お話ししたようにも触れられました。
次世代Amazon SageMakerがもたらす統合データ分析体験
次世代Amazon SageMakerは、お客様に人気のあるすべてのサービスとツールを、現在パブリックプレビュー中のSageMaker Unified Studioと呼ばれる統合された環境に集約します。先ほどAmazon DataZoneについてお話ししましたが、この新しいプラットフォームは、Lakehouseのデータアクセスを、データとガバナンスをミドルティアとして活用する統合的な方法で提供します。Unified Studioは、様々なAWSサービスのツールを統合しています。2009年にローンチしたAmazon EMRや、2012年にローンチしたAmazon Redshiftなど、データ分析とMLスタックにおいて、私たちには多くの成熟したサービスがあります。
お客様からは、それぞれのStudio環境の特徴を学ぶ必要があるというフィードバックをいただいていました。EMRには独自のEMR Studioがあり、SageMakerにも独自のSageMaker Studioがありました。そこで、これらのStudio体験をすべて統合したのです。これにより、組織内の異なる役割の方々 - ビジネスアナリスト、データスチュワード、プロジェクトマネージャー、MLサイエンティスト、MLエンジニア、Gen AI開発者など - が、この単一の統合されたStudioで組織のユースケースに協力して取り組むことができるようになりました。これは様々なユースケースを扱う上で、非常に画期的なことです。私たちはこれまでこのようなことを実現したことがなく、この統合Studio体験には本当にワクワクしています。
Unified Studioでは、より迅速なコラボレーションと構築が可能です。Amazon EMRでデータの準備と統合を行い、SageMaker AIを使用してAIとMLモデルのトレーニングとデプロイを行い、現在パブリックプレビュー中のBedrock IDEでカスタムGen AIアプリを構築し、Amazon RedshiftでSQLクエリを実行することができます。さらに、ノートブックのスケジューリング機能も備えています。SparkデベロッパーやMLエンジニアが作成したPython、PySpark、Scalaのノートブックコードを、環境を離れることなくStudio内でスケジュールすることができます。
この統合Studioの素晴らしい点は、AWSコンソール外での体験を提供することです。管理者がOCTAなどの外部IDPプロバイダーを設定できる統合機能を備えており、Unified Studioへのログイン時に企業の認証情報を使用することができます。DataZoneと同様に、組織のメンバーはAWSコンソールへのアクセスを必要とせず、この新しい統合Studio IDE環境の中ですべての作業を行うことができます。 この統合Studioを支えているのが、Amazon SageMaker Data and AI Governanceです。統合Studioは最上位に位置し、データとAIガバナンスが中心層となっています。
データとAIガバナンスの一環として、データ、モデル、生成AI、コンピューティングを単一のカタログとして統合したSageMaker Catalogもローンチしました。このカタログは、先ほど触れたAmazon DataZoneを基盤として構築されています。私たちは過去2年から2年半にわたり、多くのお客様とAmazon DataZoneを活用してきました。そして今回、その上にSageMaker Catalogを統合・構築しました。現在DataZoneをご利用の方は、BlueprintやDomainなど多くの同じコンセプトを継承しているため、スムーズにSageMaker Catalogに移行できます。
SageMaker Catalogに実装したもう一つの重要な機能は、Amazon Q統合です。デモをご覧になっていない方は、ぜひお試しください。ビジネスデータカタログにデータを公開すると、自然言語で質問することができます。例えば、「顧客データを含むデータセットを教えてください」と尋ねると、顧客データを含むすべてのデータアセットのリストが表示されます。それらをクリックすると、データのスキーマを確認したり、データの始点から終点までの流れ、存在する列、加えられた修正、実行された変換などを含むデータリネージを確認したりできます。
これらすべてがAmazon SageMaker Catalogの一部としてアクセス可能です。さらに、データ品質などの追加機能も提供しています。AWS Glueのデータ品質機能をご存知の方もいらっしゃると思いますが、その要素をSageMaker Catalogに取り入れました。この統合されたStudioでは、カタログを利用でき、データにアクセスして購読する前にその品質を確認することができます。
プロデューサーとして、私はSageMaker Catalogにデータを公開でき、コンシューマーとして、この統合Studioに入って、自分に関連するデータセットを検索して見つけることができます。データを利用する前に、その品質とリネージを確認することができます。Amazon DataZoneと同様に、カタログにデータを共有するプロデューサーとして、どの列とロールを共有したいかを指定するデータフィルターを設定できるガードレールを用意しています。これにより、コンシューマーはデータセット全体ではなく、特定の要素にのみアクセスできます。例えば、10列あるテーブルのうち5列にPIが含まれている場合、PI列を除いたバージョンを共有して、コンシューマーに5列のみへのアクセスを提供し、組織内の他のコンシューマーには10列すべてを利用可能にすることができます。
また、統合Studioの一部として、監査可能なロギングとモニタリングも実装しています。ユーザーがStudio内で行うすべての操作は、CloudWatch Logsの一部として追跡・記録されます。管理者やプラットフォーム管理チームは、監査の観点からユーザーがどのようなアクションを取ったかを理解することができます。Studioでは「Project」という概念を導入しており、これは、データ、コンピューティングリソース、作業中のコードやスクリプトへのアクセスを提供する高レベルの抽象化です。最も重要なのは、データスチュワード、プロジェクトマネージャー、品質管理担当者、MLエンジニア、ビジネスアナリストなど、ユースケースに取り組むすべての人々を結び付けることです。統合Studioの中で、このProjectという傘の下で全員が協力し、ビジネスユースケースに取り組むために、データ、コンピューティング、コードにリアルタイムでシームレスにアクセスすることができます。
OccidentalのData Meshアーキテクチャ実装事例と得られた教訓
それでは、Occidental PetroleumのデータメッシュとDataZoneの活用事例、そしてAWSサービスの活用方法についてお話しいただくJamieをお迎えしたいと思います。Jamie、いかがお過ごしですか？ありがとうございます。ヘッドショットに大きなカウボーイハット、巨大なAWSのベルトバックル、ブーツが写っているのにお気づきかと思いますが、はい、私はTexas出身です。私はOccidentalのデータ・アナリティクスのStrategic Advisorを務めており、本社はTexas州Houstonにあります。私たちは中東、アフリカ、北米、ラテンアメリカで事業を展開しており、Occidentalは100年以上の歴史を持つ企業です。
私たちには3つの主要な事業があります。1つ目は生産性向上です。高性能な石油・ガス資産の安全性と効率性を継続的に向上させ、グローバルな持続可能性を推進するイノベーションを通じて、人々の生活を支える重要なエネルギーを生産しています。私たちの目標は、現在そしてネットゼロの未来において、信頼性の高いエネルギーを提供することです。2つ目の主要事業は必須化学品です。Occidentalは必須化学品の世界的リーダーとして、水処理、医薬品、建設、その他の重要産業で使用される不可欠な製品で人々の生活を向上させています。安全性と品質へのコミットメントを持って、生活を豊かにする製品の基本的な構成要素を持続可能な方法で製造することが私たちの目標です。最後に、3つ目は私たちの最も新しい主要事業であるカーボンイノベーションです。ここではAWSとのパートナーシップにより、新しいものを革新し構築する機会を得ました。West TexasのPermian盆地における画期的なDirect Air Capture施設を含め、持続可能な二酸化炭素削減のためのカーボンキャプチャー・利用・貯蔵技術とカーボン除去技術を推進しています。
私たちの目標は、自社の排出量を削減し、他社の削減も支援することです。これがOccidentalで行っている3つの主要事業です。
では、Occidentalのデータプラットフォームに関する私たちの現状と今後についてお話ししましょう。これは皆さんの多くも同じような状況かもしれません。オンプレミスのデータウェアハウスを使用しています。左側を見ると、リレーショナルな構造化データを含むすべてのソースが、リレーショナルデータベースのオンプレミスデータウェアハウスに流れ込んでいます。主にBIレポーティング、レポート、ビジュアル、分析アプリケーションに使用されています。約30テラバイトのデータがあり、2000以上のアプリケーション、ユーザー、プロセスが毎日このデータベースにアクセスしています。非常に活発で大規模なシステムであり、それに伴うさまざまな課題があります。
皆さんもおそらくオンプレミスのデータウェアハウスをご存じで、使用されているかもしれません。実行しているサーバーの規模でしか拡張できないという制限があります。メンテナンスの負担も大きく、データベースのアップグレード、OSのアップグレード、ハードウェアの保守が必要で、その際にはダウンタイムが発生します。Occidentalでは、リレーショナルデータベースが対応していない非構造化データやストリーミングデータを大量に生成しています。データの取り込み規模は膨大で、石油・ガス事業だけでも20億以上のデータポイントがあります。このデータを社内のタイムシリーズデータベースに取り込むと、リレーショナルデータベースのスケーラビリティを圧迫してしまいます。さらに、生成AIやAI/MLプロジェクトが進む中で柔軟性が限られています。データウェアハウスはクエリやレポーティングには適していますが、データサイエンティストが20億行のテーブルをフルスキャンすると、アプリケーションやレポートを使用している人々のパフォーマンスに影響を与えてしまいます。
これらの課題に対応するため、私たちはAmazonと提携し、 クラウドプロバイダーとしてAWSを採用して、Oxy Data and Analytics Platformを構築しました。右上のロゴ、そして私のシャツにもあるのがそれです。これはData Meshアーキテクチャです。下から見ていくと、AWSクラウド上のData Meshにデータが流入してきます。データソースは一般的なアプリケーション用の相関データベースや、多数のデバイスからです。石油・ガス施設、化学プラント、そして直接空気回収施設の運営により、多くのデバイスやセンサーから大量のデータが生成されます。Apache AirflowやAWS Kinesis、その他のサービスを使用して、そのデータをProducerドメインに流し込んでいます。13のProducerドメインがあり、コアサービスとしてデータレイク用のAmazon S3、データウェアハウス用のAmazon Redshift、時系列データ取得用のAWS IoT SiteWise、特定用途向けのAmazon DynamoDBを使用しています。
中間層では、Amazon DataZoneがガバナンスを管理しています。Producerのすべてのデータをカタログ化し、データの技術カタログを提供し、アクセス制御とともにConsumer層へのパブリッシングを処理します。Lake FormationやData Sharingを自前で処理する必要を避けるため、意図的に数ヶ月待ってDataZoneを使用することにしました。Amazon Redshift DataZoneがバックグラウンドで自動的にそれを処理してくれるので非常に便利で、そしてConsumer層にデータを共有します。Consumer層では、ユーザーは使い慣れたBIツールを使って、Amazon RedshiftやAmazon S3経由のAmazon Athenaにアクセスできます。また、実験用のAmazon S3やAmazon SageMaker、Amazon Bedrockも用意されており、データサイエンティストがデータを扱い実験できる環境も整っています。
Producer層のデータドメインの構成についてご説明します。正確な名称ではありませんが、FinanceやOperations、HRM、HSEなどを見ていただくと、財務部門のような企業レベルのドメインがあることがわかります。これらのエンタープライズレベルのドメインには、財務データ、HRMデータ、HSEデータ、そしてMidstreamマーケティングデータが含まれています。
これらは独自のドメインを持ち、Essential Chemistry、Production、Carbonという3つのコア事業のための運用ドメインもあります。事業内には、石油・ガス部門のDrilling and Completionなどの運用ドメインがあります。このようなProducerドメインが13あり、Federatedガバナンス層を通じて、ビジネスデータカタログ、DataZoneを通じたデータポータル、データプロジェクトが提供されます。DataZoneは、Occidentalのデータメッシュを非常に簡単かつシームレスにユーザーに提供するための重要なコンポーネントでした。
私たちのプラットフォームの利点には、クラウドのスケーラビリティがあります。Amazon Redshiftにより、入力データに対して無制限のスケールを実現し、レポーティングと分析のためのデータウェアハウスを大幅にスケールアップする能力を提供しています。また、データの民主化とデータカタログを実現し、ユーザーはデータカタログとDataZoneを通じてセルフサービスでデータにアクセスできます。さらに、DataZoneに接続してすべてのデータを集約する別のビジネスカタログも用意しています。ユーザーは利用可能なデータを確認し、アクセスし、ポータルを通じてそのアクセスを得ることができます。
オンプレミスのデータウェアハウスで直面していた課題の1つは、その制限事項でした。このデータベースは、分析やML、Generative AIではなく、トランザクショナルなウェアハウジングクエリ向けに設計されていたのです。約1ヶ月半前にそのデータはAWS上のEC2に移行しましたが、Amazon SageMakerやGenerative AI向けのAmazon Bedrockのすぐ近くに位置するクラウド上のS3と比べると、AIやML用途での使いやすさという点ではまだ及びません。私たちはAmazon SageMaker Unified Studioに大変期待を寄せています。プレビューを見て実際に使用してみましたが、クエリエディタやSageMaker、データカタログがすべて1つのツールに統合されたこの体験を、ユーザーの皆様にも提供できることを心待ちにしています。
分散型アーキテクチャとデータドメインを採用することで、データを最もよく理解しているデータオーナーやエキスパートが、それぞれのドメインでアクセス管理やFederatedデータガバナンスを実装できるようになりました。私たちのデータガバナンスアプローチは、連邦政府の構造に似ています。つまり、全ドメインで従うべき基準を設定しながらも、個々のデータドメインではデータオーナーが必要に応じてデータを管理できる仕組みになっています。このData Meshアプローチは効果的で、AWSの優れた統合サービスは、Occidentalがこれを実現する上で重要な役割を果たしてきました。
私たちはOccidental Data Analytics platformを構築しましたが、その成果を示す特筆すべきツールの1つをご紹介したいと思います。DELTACIPHERと呼ばれるツールで、これは私たちのDeltaイニシアチブの一部です。これはOccidental内で掘削や完遂に関する先進技術やイノベーションに取り組むチームによって開発されました。Teams上にチャットボットのような体験を構築し、エンジニアがGenerative AIを活用して運用に関するインサイトにすぐにアクセスできるようになっています。会話形式のクエリを、アナリティクスプラットフォーム上のテーブルに対するSQLクエリに変換することができます。
このツールにより、複雑なクエリの作成や手動でのデータ集計を必要とせずに、複数の井戸の分析を加速することができます。つまり、掘削エンジニアは一日中データベースにクエリを投げたり、レポートを作成したり、グラフを分析したり、Teamsのチャットを検索したりする必要がなくなりました。 DELTACIPHERに行って、「Well XYZの概要と問題点をリストアップしてください」や「なぜ掘削を中断したのか説明してください」といった質問をするだけで、即座に回答が得られます。
例えば、午前10時40分の掘削中断について尋ねると、システムはほぼ瞬時に包括的な回答を提供しました。ODAにロードされている現場の掘削エンジニアやスタッフのTeamsチャットを参照し、Amazon Athenaを使用してデータレイク内のODAにある掘削データを確認しました。掘削作業者から受け取る様々な数値のイメージについては、Claudeを使用してそれらのイメージやグラフをデータテーブルに変換し、ODAにロードしています。これらは通常グラフとしてしか受け取れないものですが、今ではデータテーブルとしてすべてのインサイトを得ることができます。数百万行の掘削データ、数百のチャット、そしてすべてのチャートを1分以内に統合して分析できます。これは掘削エンジニアが1、2日かかるような作業です。非常に価値のある成果が得られています。
アーキテクチャはどのようになっているのでしょうか？私のような技術好きの方々が気になるところだと思いますが、まず左上のプロデューサー層から見ていきましょう。掘削と仕上げに関するプロデューサー層には、Teamsのチャットデータ、実際の掘削データ、そして先ほどお話したチャートなどのデータが入ってきます。これらのデータはすべてAmazon S3に保存され、DataZoneによって左下のコンシューマー層で利用可能になります。右下では、ユーザーがTeamsからDELTACIPHERを起動し、API Gatewayを通じてLambda関数を呼び出し、Amazon Bedrockエージェントを使用してデータを取得し、結果を返すという流れになっています。
Occidentalの次のステップについてお話しします。私たちはODAとドメインについて約1年から1年半ほど取り組んできました。DataZoneの新機能の一つにドメインユニットがありますが、現在その定義に取り組んでいます。ドメインユニットは、メインドメインのサブドメインとして考えることができます。また、DataZoneにはデータプロダクトという機能があります。これはData Meshの文脈でのデータプロダクトとは異なり、個々のデータプロダクトをグループ化して一つのデータプロダクトとして扱うことができます。例えば、地質取引データの場合、実際の取引データとコストセンターなどの次元データを一つにまとめて、地質取引という一つのデータプロダクトにすることができます。また、DataZoneで行と列レベルでのアクセス制御を実装中です。Data Exchangeを通じてStandard and Poorからのデータ取得も検討しています。これについては後ほどRobが詳しく説明します。そして先ほど触れたように、Amazon SageMaker Unified Studioも私たちの重要な検討項目の一つです。
約1年半の取り組みから得られた教訓をお話しします。「完璧は善の敵である」という言葉をご存知かもしれません。AIやMLアプリケーションを構築する際、完璧なものは存在しません。皆さんもチャットボットなどを使用したことがあると思いますが、常に完璧というわけではありません。AIやMLのユースケース、そしてAIエージェントを構築する際は、完璧でなくても使い始めることが大切です。
プラットフォームを構築する過程で、必要なドメインユニットの数について議論がありました。先ほど13個とお話ししましたが、1ヶ月前までは11個で、最近2つ追加しました。プラットフォームの良いところは、最初から完璧である必要がなく、必要に応じて柔軟に変更やドメインの追加ができることです。命名規則などについても、様々な意見がありましたが、最終的には一つの方法に決める必要がありました。
Data Meshの変更には慎重な検討が必要です。Data Meshは単なる技術ではなく、根本的に異なる考え方が必要です。従来のデータウェアハウスでは、中央のグループがビジネス要件に基づいてデータウェアハウスを構築し、データを取り込んでいました。しかしData Meshでは、データドメインの柔軟性により、エンドユーザーでもデータを取り込むことができるツールを持っています。そのため、ワークフローやガバナンスの仕組み、各データドメインの機能チームの運営方法について考える必要があります。Data Meshを計画する際は、技術面だけでなく、ガバナンスやデータ品質を確保するために、ビジネス部門やIT部門とどのように協力していくかについても考慮する必要があります。
ビジネス成果を見失わないようにしましょう。この会場にいらっしゃる方々の多くは技術系のIT担当者だと思いますが、最終的には、設計やガバナンスに関するすべての取り組みは、ビジネス成果を中心に考えるべきだということを忘れないでください。
もう1つの重要な側面は、プラットフォームの実装における透明性が価値を持つということです。 私たちは複数のチームと、支援してくれたいくつかのコンサルティンググループと共に取り組みました。DevOpsでは Infrastructure as Codeを広範に活用しています。すべての作業は Infrastructure as Codeを通じて行われ、すべてのコードはGitリポジトリにチェックインされ、各チームは適切なアクセス権限に基づいてアクセスできます。データをロードするためのパイプラインを構築したい場合、その仕組みを確認できます。すべてが標準化され、必要に応じて利用できるように設定されているからです。
タスクの並列化は進捗の妨げになることがあります。 データのセットアップを始める際は、データ取り込みのためのワークストリームを過度に並列化しないようにしましょう。私たちが行ったことの1つは、地理的取引データという「ゴールデンデータフロー」と呼ぶものを開始したことです。他のものを始める前に必要な教訓をすべて得るために、まずこれ1つだけに取り組みました。8つのストリームを同時に実行して、やり方を変えるべきだったと気付くのではなく、1つに焦点を当てました。これがゴールデンスタンダードとなり、本番環境に導入し、その品質を確認しました。そこから得た教訓を、残りのすべてのワークストリームに適用しました。
では、Sarahにバトンを渡したいと思います。AWSは重要な推進力となり、私たちのデータ分析を次のレベルに引き上げることを可能にしました。DAや石油・ガス生産、化学事業で行っていることにより、大きく前進することができています。Jamie、OccidentalがDataZone、Data Mesh、Chatbotソリューションを活用して構築した素晴らしいユースケースを説明してくれてありがとうございます。
サードパーティデータ共有におけるAWSソリューションと今後の展望
ここまで、ファーストパーティデータの共有に必要なすべてを見てきました。つまり、データが常にAWS内にあり、AWS組織内のプロデューサーとコンシューマーの間でアカウント間共有を行う場合についてです。しかし、もちろんサードパーティとのデータコラボレーションを行いたいユースケースもあるでしょう。そこで、利用可能なオプションを見ていきましょう。 AWS Data Exchangeは、サードパーティデータのライセンス取得をより迅速かつ容易にする5つの方法を提供しています。データプロバイダーからのデータをライセンス取得し、プロジェクトや組織の一部として使用したい場合は、AWS Data Exchangeを利用できます。AWS Data Exchange for Data Filesを使用すると、新規または更新されたデータが自動的にAmazon S3バケットにエクスポートされ、複雑な開発パイプラインを管理することなく、データのエクスポートにかかる時間と労力を節約できます。
これらのデータファイルには、テキストデータだけでなく、データプロバイダーからライセンス提供される画像、音声、動画など、さまざまな形式のデータを含めることができます。ライセンスを取得すれば、それらを自分のS3バケットに取り込み、AWSのネイティブテクノロジーやサービスを使用して分析することができます。次に、AWS Data Exchange for Amazon S3があります。これは、データプロバイダーが既存のS3バケットにデータを持っている場合、データを移動やコピーする必要がなく、そのままライセンス提供できる仕組みです。サブスクリプションを購入すれば、プロバイダーのS3バケットから直接データにシームレスにアクセスできます。
また、表形式や構造化されたSQLフォーマットのデータを扱うオプションもあります。AWS Data Exchange for AWS Lake Formationでは、表形式データを持つデータプロバイダーがLake Formationのパーミッションと細かなアクセス制御を有効にし、S3上のライブテーブルに即座にアクセスできるようデータをライセンス提供できます。同様に、AWS Data Exchange for Amazon Redshiftでは、データプロバイダーが既存のRedshiftクラスターやウェアハウスからデータをライセンス提供でき、ユーザーは自分のRedshiftウェアハウスからそれらのRedshiftデータソースに直接クエリを実行できます。
最後に、サードパーティのAPIを見つけて発見し、ライセンス提供を受けたい場合のオプションもあります。AWS Data Exchange for APIと呼ばれるオプションがあり、APIのライセンスを取得すれば、アプリケーションからAPIコールを開始し、必要なものを構築するために使用することができます。
これらは素晴らしいのですが、自分のデータから洞察を得たいと思っているうえに、基礎となるデータを公開せずに、マーケットプレイスに存在するすべてのデータを使用したい場合はどうでしょうか？個々のデータ行は公開したくないけれど、それでも洞察を得たい。例えば、広告主として自社のウェブサイトに来訪する顧客の広告データを持っているが、YouTube、Google Analytics、Amazon adsなど、他の複数の広告主からのデータでこれを補強したい場合を考えてみましょう。顧客データを公開せずに、どうやって洞察を得ることができるでしょうか？
そこで登場するのがAWS Clean Roomsです。これは、基礎となるデータを共有することなく、複数の当事者間でコラボレーションを可能にします。これは差分プライバシーと呼ばれるコンセプトでもあり、基礎となるデータは公開せずに、同時にすべてのデータを統合して洞察を得ることができます。もう一つの重要な点は、AWSでのデータ移動が不要だということです。Clean Roomsを使用したい人は、既存のS3バケットをオンボードしてClean Roomsに取り込むことができ、そこから複数の当事者がそのルームに参加してデータにアクセスし、洞察を得ることができます。
では、Consumerがデータの行レベルにアクセスするのを防ぐにはどうすればよいのでしょうか？そのために、Clean Roomsはクエリのコントロールと制御を提供します。Clean Roomsにオンボーディングする際、自分のデータに対して集計やパーセンタイルなどの特定のクエリのみを実行可能とし、select starやlimitを使って基礎となるデータを見ることができないように設定できます。Clean Roomsでコラボレーションを行う全ての人は、インサイトを得るための集計クエリのみを実行でき、行レベルのデータにはアクセスできません。Clean Roomsは暗号化コンピューティングを使用しており、データがストレージに保存されている時や転送時に確実に暗号化されるようアルゴリズムを活用しています。
最後に、Clean Roomsはプログラムによるアクセスを提供します。Clean Roomsにはコンソール体験とダッシュボードがあり、そこで複数の関係者のデータに対してSQLクエリを直接実行することができます。カスタムアプリケーションを社内で構築したい場合は、APIベースのプログラムによるアクセスを利用することができます。今日は多くのことを学び、数多くのユースケースを見てきました。皆さんのユースケースに応じて、AWSには適切なソリューションがあります。また、美しい統合Studioを備えた次世代のSageMakerについても見てきました。ぜひ実際に試してみてください。これによって、Producer-Consumerモデルを実現し、Generative AIと共にビジネスカタログを使用してデータにアクセスするための全ての要素を統合することができます。
本セッションにご参加いただき、ありがとうございました。モバイルアプリでのアンケートへの回答をお忘れなく。もちろん5点満点をいただけることを期待しています。もし満足いただけず5点未満をつけようとお考えの方は、セッション後に個別にお話しさせていただければと思います。どんなご質問にもお答えいたします。皆様、ありがとうございました。素晴らしい一日と、残りのre:Inventをお楽しみください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion