※本記事は、AWS re:Invent 2024のセッション「Investing in data quality: Nasdaq's journey to data reliability (BIZ207)」の内容を基に作成されています。このプレゼンテーションはAWSパートナーであるMonte Carloによって提供されました。詳細な情報はAWS re:Inventのウェブサイト（https://go.aws/reinvent ）でご覧いただけます。本記事では、セッションの内容を要約しております。

登壇者紹介： Michael Weiss氏は、Nasdaqの Intelligence PlatformにおけるAVP（Assistant Vice President）of Product Managementを務めています。同氏は、NasdaqのデータプラットフォームとAWSの統合、そしてMonte Carloとの協業を通じて、データ品質向上とオブザーバビリティの実現に取り組んでいます。特に、大規模なデータ品質プログラムの実装における豊富な実務経験を持ち、本セッションではその知見を共有しています。

なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのセッション映像をご覧いただくことをお勧めいたします。

1. Nasdaqの概要

1.1. グローバルな取引所事業

私はMike Weissで、NasdaqのIntelligence PlatformのAVP of Product Managementを務めています。今日は、私たちがMonte Carloとデータオブザーバビリティを活用してデータ品質を向上させた取り組みについてお話しします。

多くの方はNasdaqを米国の取引所運営者として知っているかもしれませんが、実際には私たちの事業はそれよりもはるかに広範です。Nasdaqは世界中で30以上のマーケットプレイスを運営しており、特に北米とノルディック地域に強い基盤を持っています。

取引所運営において、マッチングエンジンから出力される情報は極めて重要です。この情報は市場の透明性と公平性を確保する上で不可欠な要素となっています。取引所としての機能を果たすためには、これらの情報を正確かつ迅速に処理し、必要な関係者に提供する必要があります。

Nasdaqの取引所事業は、単なる株式取引の場を提供するだけでなく、市場参加者に対して高度な技術インフラストラクチャとサービスを提供することで、効率的で信頼性の高い市場運営を実現しています。この基盤があってこそ、次に説明する金融テクノロジープロバイダーとしての役割も可能になっているのです。

1.2. 金融テクノロジープロバイダーとしての役割

Nasdaqは取引所運営に加えて、世界最大級の金融テクノロジープロバイダーとしての役割も担っています。私たちは、世界中で130以上のマーケットプレイスに対して金融テクノロジーを提供しています。これは単なるシステム提供にとどまらず、市場運営に必要な包括的な技術基盤の提供を意味しています。

さらに、私たちは2,200以上の金融機関に対してサービスを提供しています。これらの機関は、私たちのテクノロジーを活用して、自身の金融サービスを運営しています。金融テクノロジープロバイダーとして、私たちは各機関の固有のニーズに応じたソリューションを提供する責任があります。

このような広範な技術提供の経験は、私たち自身の取引所運営からの知見と相まって、より効果的なソリューションの開発につながっています。私たちはテクノロジープロバイダーとして、市場参加者が必要とする高度な技術インフラストラクチャを提供し続けています。この役割は、次に説明するデータ活用の様々な領域と密接に関連しており、私たちのビジネスの重要な柱となっています。

2. データ活用の主要領域

2.1. 規制報告

マッチングエンジンから得られる情報の活用方法には、いくつかの重要な領域があります。その中でも最も基本的なものが規制報告です。

取引所として、私たちには様々な規制当局への報告義務があります。これは単なる形式的な要件ではなく、市場の透明性と公正性を確保するための重要な責務です。規制当局に対して、必要な情報を正確かつタイムリーに提供することは、規制された事業体としての基本的な要件となっています。

私たちは規制報告のためのデータ処理を自動化し、効率的に運用しています。これは単にデータを収集して報告するだけでなく、コンプライアンス要件に照らし合わせて、データの正確性と完全性を確保する必要があります。そのため、データの品質管理は規制報告において特に重要な要素となっています。

私たちは初期に規制報告製品をサービスとして提供しようとしましたが、その時点では時期尚早でした。この経験から、まず自社のユースケースに焦点を当て、そこで得られた知見を基に、より洗練されたソリューションを開発することにしました。このアプローチにより、規制報告の精度と効率性を大幅に向上させることができました。

2.2. 市場監視

市場監視は、マッチングエンジンから得られる情報の二つ目の重要な活用領域です。私たちが運営する市場が法律に則って適切に機能していることを確認し、市場の健全性を維持することは極めて重要な責務です。

市場監視の主な目的は、市場が正しく機能していることを確認し、法令に違反する行為や悪意のある参加者を早期に特定することです。これは単なるコンプライアンスの問題ではなく、市場の信頼性を維持するための根幹的な活動です。私たちは、不正行為や市場を混乱させる可能性のある行動を早期に発見し、迅速に対応できるシステムを構築しています。

私たちは市場監視において、取引データを常時監視し、異常な取引パターンや潜在的な問題を検出しています。この監視プロセスでは、大量のデータをリアルタイムで分析し、問題が発生した場合に即座に対応できる体制を整えています。早期発見と迅速な対応は、市場の健全性を維持する上で不可欠な要素となっています。

このような市場監視活動を効果的に行うためには、データの品質が極めて重要です。不正確なデータや遅延したデータは、市場監視の実効性を著しく低下させる可能性があります。そのため、私たちは市場監視システムのデータ品質管理に特に注力しています。

2.3. クライアントレポーティング

データ活用の三つ目の重要な領域は、クライアントレポーティングとインサイトの提供です。私たちは、取引データを活用してクライアントの行動を詳細に分析し、それを基にした戦略的な意思決定を支援しています。

私たちは市場参加者の取引行動を分析し、異なる市場セグメントを明確に特定しています。この分析により、各セグメントの特性や傾向を把握し、それぞれのニーズに合わせたアプローチを展開することが可能になります。

市場シェアの拡大や収益の最適化を図るため、私たちは市場状況に応じて新しい注文フローを誘引する戦略を立てています。クライアントの取引パターンを分析することで、新規の市場参加者を引き付け、既存の参加者の取引を活性化させる機会を特定しています。

このようなクライアントレポーティングとインサイトの提供は、私たちのビジネス戦略の重要な要素となっています。データの質が高く、タイムリーであることが、この分析の精度と有用性を決定づける重要な要因となっています。

2.4. ビジネスインサイト

データ活用の最後の重要な領域は、主要なビジネスインサイトの創出です。私たちは、取引データに限らず、顧客に関する包括的な視点を構築することを重視しています。これは単なる取引活動の分析を超えて、顧客との関係性全体を把握することを意味します。

私たちは顧客を360度の視点で理解することを目指しています。これは取引活動だけでなく、顧客が私たちの会社とどのように関わっているかを総合的に把握することです。特に重要なのは、私たちが多くの金融機関に対してテクノロジーを提供していることを考慮する必要があることです。例えば、ある顧客が取引参加者であると同時に、私たちの技術を利用している場合、その影響を総合的に評価する必要があります。

このような包括的な顧客理解により、私たちは取引活動以外の顧客との関わりを理解し、より適切なサービスを提供することができます。特に、私たちのテクノロジーサービスを利用している金融機関に対しては、取引活動とテクノロジー利用の両面から、総合的な価値提案を行うことが可能になります。

このようなビジネスインサイトの創出は、私たちのビジネス戦略の重要な柱となっています。データの品質と信頼性は、これらのインサイトの価値を決定づける重要な要素となっています。

3. Intelligence Platformの進化

3.1. AWS活用の歴史（2013年〜）

私たちのIntelligence Platformは、10年以上にわたる進化の過程を経て今日の形になっています。2012年に、私たちは規制報告製品をクラウドサービスとして提供することから始めました。しかし、この最初の取り組みは市場がまだ準備できていない時期であり、期待通りの成果を上げることができませんでした。

この経験を活かし、2013年からは自社のユースケースに焦点を当てた取り組みに方向転換しました。この時期はAmazon Redshiftが最初にローンチされた時期と重なり、私たちはRedshiftの初期採用者として、クラウドネイティブなデータソリューションの構築を開始しました。

私たちのアプローチは、常にボトムアップ型でした。最初は基盤となるデータレイクやデータウェアハウスの構築から始め、データの収集方法や効率的な保存方法に注力しました。その後、段階的にスタックを上へと拡張し、現在のインサイト管理スイートにまで発展させてきました。

この発展過程で、私たちは常にクラウドネイティブソリューションとしてAWSを活用してきました。これは単なる技術的な選択ではなく、スケーラビリティと信頼性を確保するための戦略的な判断でした。現在では、ビジネスユーザーがデータにアクセスし、活用できるプラットフォームとして成熟し、他の市場運営者や金融機関にも提供できる段階に達しています。

3.2. 主要な成果と指標

Intelligence Platformの導入により、私たちは顕著な業務改善を達成しています。最も注目すべき成果は、新しいレポートやインサイトの市場投入までの時間を75%削減できたことです。これは、データの収集から分析、レポート生成までの一連のプロセスを効率化したことによる直接的な成果です。

現在、私たちのレポーティング製品やインサイト製品は、社内で約2,200人のユーザーによって活用されています。この規模のユーザーベースは、プラットフォームの有用性と使いやすさを実証しています。

さらに重要な指標として、私たちは日次で6,000から10,000件のレポートを生成しています。一見すると、これは決して大きな数字には見えないかもしれません。しかし、これらのレポートは全て厳格なSLAを順守する必要があり、それぞれが重要なビジネス価値を持っています。各レポートは、正確性と適時性が要求される重要なビジネス情報を提供しており、私たちはこれらを確実に処理し続けています。

これらの成果は、データの品質管理とプラットフォームの信頼性向上への継続的な投資の結果です。数値は着実に改善を続けており、今後も向上が期待できます。

3.3. プラットフォームの拡張計画

私たちは現在、Intelligence Platformを非Nasdaq市場向けに展開する重要な段階に来ています。私たちの市場テクノロジー提供の一環として、他の市場運営者や金融機関が自らプラットフォームを構築する必要がないよう、このソリューションを提供することを計画しています。

この展開は段階的に進めています。すでに非Nasdaq市場向けにIntelligence Platformのローンチを開始しており、2024年末から2025年にかけて、本格的な本番環境での展開を開始する予定です。この展開により、他の市場運営者は私たちが10年以上かけて構築し、改良を重ねてきたプラットフォームの恩恵を直ちに受けることができます。

提供サービスには、データの収集から分析、インサイトの生成まで、私たちが自社で実証済みの機能が全て含まれます。これにより、各市場運営者は独自のデータプラットフォームを一から構築する必要がなく、すでに実績のある信頼性の高いソリューションを活用することができます。このアプローチは、私たちの市場テクノロジー事業の重要な戦略的展開となっています。

4. データオブザーバビリティの実装

4.1. データオブザーバビリティの定義

データオブザーバビリティとは、Gartnerの定義によれば、分散環境における完全なエンドツーエンドのデータモニタリングを意味します。これには、データの品質、系統、そしてデータダウンタイムによる財務的影響の把握が含まれます。

モダンなデータの課題に対応するためには、技術パートナーの選定が極めて重要です。パフォーマンス、スケーラビリティ、信頼性を提供できるパートナーが必要です。私たちはAmazon Redshiftを実装した後、データ品質に焦点を当てるためにデータオブザーバビリティの導入を決定しました。

データオブザーバビリティの実践では、データ品質から始めるのが一般的であり、それは正しいアプローチです。基本的なテスト、データの形状の理解、一貫性の確認、適時のロードの確認など、これらは全ての組織が取り組むべき基本的な要素です。

しかし、データオブザーバビリティの真価は、時間の経過とともに発揮されます。本番環境のデータは静的ではなく、今日行っていることが6ヶ月後には適切でなくなる可能性があります。データオブザーバビリティの真の強みは、データが時間とともに変化する中で、継続的にモニタリングを行い、その変化に応じて適応できる仕組みを提供することにあります。これこそが、私たちがMonte Carloを選択した理由の一つです。

4.2. モニタリングワークフロー

データオブザーバビリティのワークフローは、検出、トリアージ、解決、そして測定という4つの重要なステップで構成されています。

検出フェーズでは、複数の重要な要素を監視します。まず、データの新鮮さを確認します。データが予定通りにロードされているかを監視することが重要です。次に、データ量を確認します。例えば、通常1日100万レコードが期待される場合に100レコードしかない場合、明らかに問題が発生している可能性があります。また、スキーマの変更も監視します。スキーマの変更は、パイプラインに影響を与える可能性があるため、早期に検知する必要があります。さらに、フィールドの健全性、値の妥当性など、データ品質に関する様々な側面を監視します。

問題を検出した後の次のステップはトリアージです。ここでは、まず影響範囲を理解することが重要です。データの系統（lineage）を確認し、どのレポートやインサイト、そしてどの顧客に影響があるのかを把握します。また、問題のあるデータ資産の所有者を特定し、適切なコミュニケーションを行うことで、迅速な解決につなげます。

解決と測定のプロセスでは、データや関連するコード、システムの修正を行い、正常な状態に戻すことを目指します。私にとって面白い点は、データアップタイムの考え方です。10年以上データに携わってきましたが、システムのアップタイムについては常に議論されてきました。しかし、データそのもののアップタイム、つまりデータが正しく機能しているかについては、これまであまり注目されてきませんでした。私たちは、データが正しくロードされているかだけでなく、そのデータが正しいかどうかを測定する必要があります。これこそが、Monte Carloのようなデータオブザーバビリティツールが提供する重要な価値の一つです。

このワークフローを効果的に実行することで、データの問題を早期に発見し、影響を最小限に抑えながら、迅速な解決を実現することができます。

4.3. Monte Carloの導入アプローチ

Monte Carloは、私たちのデータ処理全体を統一的に監視する中核的なプラットフォームとして機能しています。データの取り込みから準備、出力に至るまでの全工程を一貫してモニタリングできる環境を実現しています。

具体的には、まずデータの取り込み段階でのモニタリングを行います。データが一貫して正しくロードされているか、予期されるボリュームと一致しているかを確認します。次に、データの形状を監視し、変更があった場合に即座に検知できるようにしています。

データ変換の段階では、パイプラインのモニタリングを実施しています。さらに、重要な指標に対してはフィールドヘルスモニタリングを実施しています。これにより、範囲外の値、重複、null値などの異常を検知することができます。これらの機能により、以前よりも迅速に問題を検出し、解決し、予防することが可能になりました。

Monte Carloプラットフォームの導入により、私たちは事後対応的なアプローチから予防的なアプローチへと移行することができました。ビジネスユーザーが問題を報告する前に、私たちがデータの異常を検知し、対応することが可能になりました。これは、月次決算の収益データが誤っているとユーザーから指摘されるような事態を未然に防ぐことにもつながっています。このような予防的なアプローチにより、データの信頼性は大きく向上し、ビジネスへの影響を最小限に抑えることができています。

5. 実践的な成果と事例

5.1. イントラデイロードの問題検出と解決

Monte Carloの導入により、私たちは具体的な成果を上げています。その一つが、イントラデイデータロードの問題に関する事例です。Monte Carloのモニタリング機能により、データロードが正しく実行されていないことを、日中のうちに検出することができました。

これは非常に重要な成果でした。なぜなら、この早期発見により、翌日の請求処理を待つことなく、同日中に問題を解決することができたからです。従来のプロセスでは、このような問題は翌日の請求処理実行時まで発見されず、その後で再処理が必要となっていました。

この早期発見と即時対応により、約8時間の開発時間と運用時間を節約することができました。これは単なる時間の節約以上の意味を持ちます。データの問題を早期に発見し、インタラクティブに解決できることで、ビジネスへの影響を最小限に抑えることができました。

このような成功事例は、データオブザーバビリティツールの価値を実証するものです。問題の早期発見と迅速な解決は、データ品質の維持とビジネス継続性の確保に直接的に貢献しています。

5.2. 重複データの早期発見

Monte Carloの導入による成果の二つ目の事例として、データセット内の重複情報の早期発見が挙げられます。この重複データは、請求額の誤算や請求処理の不正確さにつながる可能性がある重要な問題でした。

Monte Carloのモニタリング機能により、請求処理の実行前に重複データの存在を検知することができました。これにより、請求処理を一時停止し、データの修正を行うことで、誤った請求の発生を防ぐことができました。この予防的な対応により、開発チームと運用チームの時間を大幅に節約することができました。

従来のプロセスでは、このような問題は請求処理の実行後に発見され、データの再処理や請求の修正が必要となっていました。しかし、Monte Carloによる早期発見により、そのような事後対応的な作業を完全に回避することができました。

このような予防的なアプローチは、単に運用効率を改善するだけでなく、顧客満足度の維持にも貢献しています。誤った請求を防ぐことで、修正作業や顧客とのコミュニケーションにかかる時間と労力を削減することができました。

5.3. 請求データの整合性確保

私たちは最近、請求エンドポイントへのMonte Carloの適用を開始したばかりですが、すでに重要な成果を上げています。特に印象的だったのは、請求データにおける欠損を発見した事例です。この事例は、このスライドを作成した後に発生したものですが、非常に示唆に富む出来事でした。

私たちのシステムでは、バージョニングにビューを使用しており、これらのビューを様々なRedshiftエンドポイントに適用しています。この事例では、特定のビューの更新が請求エンドポイントに適用されていないことが、Monte Carloのスキーマ変更検知機能によって発見されました。

具体的には、Monte Carloが私たちのエンドポイントでスキーマの変更を検知したことがきっかけでした。この警告を受けて、私たちはまずビューの更新が正しく適用されているかを確認しました。この確認プロセスにより、請求エンドポイントへのビュー更新が漏れていることが判明しました。

最も重要な点は、この問題の発見から解決までの時間です。従来であれば、このような問題の特定と解決には数時間を要していたかもしれません。しかし、Monte Carloのスキーマ変更検知により、問題を数分で特定し、解決することができました。このような迅速な問題解決は、請求データの正確性を確保する上で極めて重要です。

6. 技術的アーキテクチャ

6.1. 中央集中型インジェストアカウント

私たちは、データの取り込みと管理に関して、比較的伝統的なデータレイクのセットアップを採用しています。具体的には、中央集中型のインジェストアカウントを設置し、そこですべてのNasdaq市場の情報を一元的に取り込み、保存しています。

このアーキテクチャの中心となるのが、S3バケットの活用です。私たちは中央のS3バケットに全てのデータを一度格納します。これにより、データの一貫性と整合性を確保することができます。また、この中央集中型の構造により、データの取り込みプロセスを標準化し、効率的に管理することが可能になっています。

アクセス管理に関しては、他のユーザーが自身のクエリツールを持ち込んで、このS3バケットに接続できるような構成を採用しています。これにより、各ユーザーは必要な情報にアクセスすることができます。このアプローチは柔軟性が高く、様々なユースケースに対応することができます。

この中央集中型のアーキテクチャは、Monte Carloによるモニタリングの基盤としても機能しており、データの品質管理とオブザーバビリティの実現に重要な役割を果たしています。

6.2. 共有モニターの配置

私たちは、Monte Carloの導入において、複数段階のアプローチを採用しています。その最初の段階として、共有モニターの配置を実施しました。これは、共通のRedshiftエンドポイントに向けて設定されたモニターです。

共有モニターの主な機能は、基本的なスキーマ検知とボリュームメトリクスの監視です。共通Redshiftエンドポイントを監視することで、データの取り込みが正常に行われているか、データ量が期待値と一致しているかを確認しています。

この基本的なモニタリング構造は、データパイプライン全体の健全性を確保する上で重要な役割を果たしています。私たちはこれを基盤として、より詳細なアプリケーション固有のモニタリングを構築しています。共有モニターによって検出された異常は、迅速に関係者に通知され、適切な対応を取ることができます。

このアプローチにより、基本的なデータ品質の問題を早期に発見し、対処することが可能になっています。これは、より高度なアプリケーション固有のモニタリングを効果的に機能させるための重要な基盤となっています。

6.3. アプリケーション固有のモニタリング

共有モニターに加えて、私たちは特定のアプリケーションに特化したモニタリングも実施しています。具体的には、分析用のRedshiftエンドポイントでは、DBTジョブの実行状況を監視しています。DBTモデルが期待通りのメトリクスと情報を出力しているかを確認することで、データ変換プロセスの健全性を確保しています。

特に重要なのが請求エンドポイントのモニタリングです。請求データの処理には規制上の監督が伴うため、高度な精度と信頼性が要求されます。このため、請求エンドポイントには特別な監視体制を敷いています。先ほど説明した請求データの整合性確保の事例は、このモニタリング体制があったからこそ実現できました。

このように、アプリケーション固有のモニタリングは、それぞれのユースケースに特有の要件や規制要件に対応するために不可欠です。私たちは各アプリケーションの特性を理解し、それに適したモニタリング戦略を実装しています。これにより、データの品質と信頼性を確保しながら、ビジネス要件と規制要件の両方を満たすことができています。