[レポート] モダンデータスタックにおけるデータオブサーバビリティ（データの可観測性）

大阪オフィスの玉井です。

9月8日に行われたObservability for the Modern Data Stackというウェビナーのレポートをお届けします。主催はHightouch社です。

セッション概要

登壇者

• Alexis Jones
  • Product Marketing at Hightouch
• Glen Willis
  • Founding Solutions Architect at Monte Carlo
• Kevin Tran
  • Sr. Sales Engineer at Hightouch

超概要

以下のことについて話すプレゼンテーションでした。

• なぜデータの信頼性が必要なのか？
• 「データオブザーバビリティ（データの可観測性）」とは何か？
• Hightouchのデータオブザーバビリティに関する機能の紹介
• HightouchとMonte Carloの連携の紹介

セッションレポート

アイスブレイク

※意外と色々な話があったのでダイジェストでレポートします。質問しているのは司会者のAlexis氏

• Kevinさん、 パンプキン・スパイス・ラテの季節はいつ？
  • 9月の初め頃
  • 労働者の日が終わったらすぐ
• Glenさん、最初に行ったコンサートは？
  • ボブ・ディラン
    • 母と一緒に行った
    • 14歳のころ
    • 正直、全盛期の声と違ってて少しがっかりした
• Kevinさん、カラオケでよく歌う曲は？
  • Blink182の「I missed you」
    • ちょっとボーカルが叫ぶところがあって、そこでみんなテンションが上がる
  • Alexis氏は高校の頃ファンだった模様
• Glenさん、朝型？夜型？
  • 間違いなく夜型
• Kevinさん、今の仕事をしてなかったら何をやってたと思う？
  • アートキュレーションとアートの制作
  • 音楽や3Dセンサーと連動するような作品を作る（？）

自己紹介

Alexis氏

私の名前はAlexis Jonesです。Hightouch社のプロダクトマーケティングを担当しています。Hightouchに入社する前は、New Relicでプロダクトマーケティングを担当していたので、ソフトウェアエンジニアリングの分野で可観測性の領域に触れていましたが、今回Glen氏をお迎えして、データエンジニアリングの分野でこの話をすることができて本当にうれしいです。

Kevin氏

私はKevinです。Hightouch社のソリューションエンジニアです。前職はSalesforceでソリューションエンジニアをしていました。

Glen氏

皆さん、こんにちは。私はGlen Willisです。Monte Carlo社でソリューションアーキテクトをやっています。以前は、Mixpanel社のソリューションアーキテクトでした。

なぜデータの信頼性が必要なのか？

まず、なぜデータの信頼性を気にするのか、その理由を簡単に説明します。

そもそも、データを収集する意義は、データの信頼性にあります。成長率と顧客維持の結果を役員会に報告することから、ブランド認知、製品エンゲージメント、最終的な採用を促進するためのマーケティング費用の配分方法の決定、さらには四半期ごとの市場投入チームの戦略設定まで、成功するチームはデータを使って競争相手を追い詰めているのです。そして、そのような意思決定の原動力となる、正確で最新のデータを持つことが、かつてないほど重要となっています。

データの信頼性は、先程の例から分かる通り、今日の世界では譲れないものです。多くの重要な意思決定がデータに依存しています。不正確なデータや信頼性の低いデータが壊れると、取締役会に報告する収益指標がおかしくなり、マーケティングコストの配分を間違え、間違った人をターゲットにして間違ったタイプの広告を出したり、間違ったリードを追いかけるために貴重な営業時間を使ったりすることになります。

データの信頼性にこだわる前に、まずデータへのアクセス性を重視し、ビジネスチームがデータにリアルタイムでアクセスできるようにする必要があります。

そこで登場するのが、データアクティベーションです。データアクティベーションは、クラウドベースのデータウェアハウスであるソースオブトゥルースから、ビジネスチームが毎日使用するツールに、一貫した実用的なデータをもたらします。サードパーティーのシステムと統合するために、カスタムで脆弱なコードを書く必要はありません。すでにデータウェアハウスにあるデータをアクティブにして、そのデータが必要なアプリケーションと同期させるだけです。その結果、SalesforceやFacebook広告、Marketo、Zendeskなどのサービスにおいて、数分でリアルタイムの顧客データを利用できるようになりました。

しかし、単にデータがあればいいというわけではありません。そのデータを信頼できるかどうかが重要なのです。つまり、意思決定の原動力となるデータの正確さと適時性を信頼できることが重要であり、そのためには可観測性が必要なのです。

可観測性についての「入門書」として、これほど適した人物は他にいないでしょう。Monte Carloほど、その応用とデータエンジニアリングに適したものはないでしょう。

それではMonte CarloのGlen氏、お願いします。

データオブサーバビリティ（データの可観測性）について

ここで重要なのは、可観測性とは何か、私たちはそれをどのように考えているのか、ということを説明することだと思います。

以前は、これの意味するところは、より多くの手動テストを設定することでした。そして、それを定期的に実行していました。

手動テストに焦点を当てた場合の問題点は、データ内でどのような問題が発生しうるか、その幅と全体像を把握することができないことです。つまり、既知の未知要素に焦点を当てることになるのです。そして、そのような問題に対して積極的にテストを行うのです。しかし、ここではより広範なニーズがあります。それは、未知の問題についても確実にアラートを出すこと、そして、発生したデータ品質の問題についてアラートを出すだけでなく、それが（データパイプラインの）下流にどんな影響を及ぼす可能性があるのかを理解できるようにすることです。そして、発見と解決までの時間を短縮することができます。

次のスライドに移りますが、ここでデータオブザーバビリティが出てくると思います。データの可観測性とは、実際に発生したデータ品質の問題だけを見ることではありません。これらの問題が何であるかを理解するだけでなく、これらの問題の根本的な原因が何であるか、また、（データパイプラインの）下流にどのような影響を及ぼす可能性があるかを理解することができることです。

Hightouchのように複雑なデータ構造を持つものを使用する場合は、その複雑さを理解する必要があります。そのため、どこで何が起こっているのかを完全に観察し、理解することが必要です。

そこで、データオブサーバビリティを3つの部分に分けて考えることにしました。

1つ目は検出です。どんな種類のインシデントが発生しても、実際に警告を発することができることを理解し、確信するのです。そのためには、カスタマイズされたチェックを設定するだけでなく、未知のインシデントを検出するための幅広い機能を持つことが非常に重要です。

2つ目は解決です。データインシデントが発生した場合、それをどのように解決するのか、インシデントを迅速に特定し、さらにその問題を解決する方法を理解するための最初のステップを踏み出せるかどうかが、重要なポイントになるでしょう。

そして、最後は、1つ目と2つ目のステップを踏む必要がないようにするための予防策です。これは、機械学習を駆使し、より積極的な方法で未知のものを理解することによって実現されます。そうすることで、今後、そのようなことが起こらないようにすべてを構築することができます。

Monte Carloでは、前のスライドにあるように、データオブザーバビリティの柱を通じて、データの鮮度や量、テーブルのスキーマを監視し、異常な変化があれば自動的にアラートを出すことができます。さらに、もう少し深く掘り下げて、フィールドレベルでの分布を理解し、下流への影響を調べ始めると、データの品質に関するインシデントとデータパイプラインとを直接結びつけて、データのラインナップを可視化し、影響が何であるかをエンドツーエンドで完全に理解できるようにします。

Monte Carloでは、検知・解決・予防を、すべてのデータ、データレイク、データウェアハウス、オーケストレーションツール、BIツールに直接接続し、先ほど述べたように、エンドツーエンドで監視して、問題の発生時期や下流の影響を理解できるようにします。そして、それをさまざまなチャネルに送ります。よりプロアクティブに反応することができるので、データ品質に関するあらゆるインシデントに対して、一歩も遅れることなく、むしろ一歩先んじて対応することができるのです。

Hightouchの場合、すべてのデータをデータレイクやデータウェアハウスに直接取り込むので、Monte CarloとHightouchを接続すれば、Hightouchが扱うすべてのデータの上に、完全なデータ観測性を確保することができます。

では、Hightouchの可観測性についても少しお話ししましょう。

Hightouchのデータオブザーバビリティに関する機能の紹介

ここでは、お客様がデータパイプライン、シンク、モデルのトレンドをより深く理解するために、私たちがアプリに組み込んだネイティブ機能について、お話したいと思います。

私たちのルーツは、データエンジニアリングです。エンジニアとして、私たちは使用するツールの時間を節約するのが大好きで、Snowflake、dbt、Five tranなど、自社で何かを構築する必要がないように、常にツールを採用しています。

しかし同時に、こうしたツールを活用すると、ツールがブラックボックス化する危険性があることも知っておいてください。その結果、ツールの内部で何が起きているのかがわからなくなってしまうのです。私たちはその痛みを感じているので、Hightouchの目標は、ユーザーのためにできる限りのことをすること、そして物事がうまくいかないときに、フードの下を覗いてすべてを見ることができるようにすることでした。

私たちのデータオブサーバビリティに関するビジョンは、このスライドにあるように要約することができます。つまり、お客様がデータパイプラインに自信を持ち、Hightouchのデータがデータスタック全体の中でどのように位置づけられるかを明確にするための機能と統合を構築します。簡単に説明すると、コンピテンスとは、ボンネットの下で起こっていることを可視化し、所有し、コントロールすることです。

繰り返しになりますが、私たちは皆、ブラックボックスのように感じられるソフトウェアを使用した経験があります。私たちがHightouchを開発したのは、エンジニアにモデルやデータパイプライン、データアーキテクチャの構築といった本来の業務に集中してほしいからです。つまり、自分でコストをかけずに、時間を自由に使えるようにするのです。

またコンテキストの面では、特にモダンデータスタック環境がいかに堅牢であるかを考えると、これらのデータがサイロの中に存在することはないという現実があります。このようなデータは、データスタック内で壁で囲い込んでしまうべきではありません。そこで、リネージやメタデータといった概念や、Monte Carloのようなベンダーとの提携が必要になってくるのです。

この半年ほどは、お客様がデータの同期やモデルを理解し、デバッグし、品質を向上させるために必要なものを提供するために、プラットフォームのネイティブな機能を実現することに懸命に取り組んできました。

この機能は、一般的に4つのデータオブサーバビリティなカテゴリに分類されます。

1つ目はLife debuggerで、これはアプリにネイティブに備わっており、ユーザーは特定の同期実行のリクエストとレスポンスを簡単に確認することができます。また、行をフィルタリングして検索し、問題をより迅速に特定することができます。また、非常に重要なこととして、私たちはお客様のデータを保存しませんし、決して保存しません。Life debuggerについても同様で、そのアーキテクチャの仕組みは、データがデータウェアハウスからユーザー自身のS3バケットに直接送信され、それが安全なハイブリッドアーキテクチャを通じてアプリに供給される仕組みになっています。

2つ目は、潜在的なデータの問題を未然に防いだり、問題が発生したときにそれを認識できるようにします。色々な設定できるアラートも用意しており、SMS、Slackなど、お客様が使いたいツールやプラットフォームでの通知に対応しています。アラートチャンネルを選択し、行の失敗の数でアラートイベントを構成するものを定義することができます。そうすれば、そのような通知を受け取ることができます。

3つ目について話します。Glen氏が言ったように、反応的な行動から、より積極的な行動へとシフトすることが、データオブサーバビリティの約束事です。Datadogのようなプラットフォームは、このビジョンを現実のものにするために発見されました。そこで、私たちはDatadogとのネイティブな統合により、Datadogアプリケーションに直接、プロアクティブな異常検知と同期データのダイナミックなダッシュボード機能を提供します。これにより、潜在的な問題の一歩先を行くことができ、データパイプラインを最適化することができます。

そして最後に、Sync logと呼ばれるものです。Life debuggerは単発のエラーの追跡と解決に役立ちますが、時にはシンクをより総合的に分析したい場合もあります。Sync logは、同期のログレベルの詳細をデータウェアハウスにプッシュし、SQLでデータを照会できるようにするものです。そこで、そのデータをSQLでクエリすることができるようになります。さらに、Monte Carloのような最高水準のベンダーと連携することで、より効果的な運用が可能になります。すべてのデータがデータウェアハウスに戻されるので、Monte Carloのようなベンダーと一緒に、より深いモニタリングやスタック全体にわたる幅広い観測性など、実に興味深いことを始めることができるようになるのです。では、さっそく、この仕組みの端から端までをお見せしましょう。

HightouchとMonte Carloのデモ

Hightouch

私が現在、SnowflakeなどのツールとSalesforceやHubSpotなどのビジネスツールとの間の同期をどのように管理しているかを、皆さんにお見せしたいと思います。

現在、私はSalesforceとHubSpotの両方に顧客データを同期させるHightouchを持っています。Hightouchのおかげで、コードを書かなくてもこれらのツール間で簡単にデータを同期できるようになりました。これらの統合は、営業とマーケティングチームが仕事を遂行する上でミッションクリティカルなものです。マーケティングはこのデータを使ってキャンペーンを実施し、営業のHubSpotはこのデータを使ってSalesforce内のユーザーにアウトバウンド営業をするのですから、期待通りに機能していないことを常に意識しておくことが重要です。

うちのAlexisが言ったように、HightouchにはSlack等によるアラート、アプリ内デバッガーなどの機能が組み込まれており、期待通りに動作していない場合のトラブルシューティングを行うための可視性を提供します。しかし、もっと深い洞察を得たり、同期中に発生したエラーの全体像を把握したい場合もあります。そこで素晴らしいのは、新機能のSync logによって、エラーや同期中に発生したあらゆることを詳細に把握できるようになったことです。

最近のSync logのリリースにより、Hightouchは詳細な同期情報をデータウェアハウスに書き戻すことができるようになり、UIで期待するデータオブサーバビリティをすべてデータウェアハウスの生データとして取得できるようになりました。Hightouchの各同期では、同期されたすべてのデータのスナップショット、Hightouchが実行した操作の変更ログ、各同期の実行とそのステータスの全体的なビューを同期するオプションが用意されています。この機能により、物事がどのように行われているかだけでなく、データ内で顕在化した行やエラーも観察できるようになりました。

さらに素晴らしいことに、Hightouchは、このデータを活用するためのdbtパッケージをあらかじめ用意してくれています。このデータをモデル化し、BIツールに取り込むことができます。

しかし、今日取り上げるのは、この生データをMonte Carloのようなデータオブサーバビリティツールに接続するだけで、データのモデル化やコードの記述、データの実態に関する専門家になることなく、データパイプラインに関する洞察を明らかにできる方法です。なぜなら、結局のところ、それは生データであることに変わりはないからです。

では、Glenに話を譲りましょう。彼は以前、私がSnowflakeに同期させたこのデータをすべて、Monte Carloにフックしてくれました。

Monte Carlo

Monte CarloでHightouchを使うということで、先ほどKevinが言ったように、すべての同期をMonte Carloで見ています。Sync logはすべてSnowflakeに送信され、Monte CarloはSnowflakeの上に乗っていることになっています。

このデモ環境では、時間の経過に伴う更新パターンを見ることができますし、Snowflakeに送信されるSync logのテーブルのサイズの変化も見ることができます。また、Hightouchが Snowflake内で更新している他のすべてのテーブルも、私たちがその上に乗って観察できるようにし、このSync logテーブルのコンテキストで、エンドツーエンドの全経路を表示できるようにします。

また、Kevinは、これらのテーブルの上で何らかのインシデントを特定できることを確認するために、意図的にいくつかのものを壊しました。この具体的な事例では、ここに飛び込んでみると、テーブルレベルだけでなく、すべての更新パターンとサイズの変化も確認することができます。しかし、このケースでは、実際の失敗のステータスが、このSync Run Tableの実際のフィールドレベルで増加したことも確認できました。

ここで、このことを確認するだけでなく、別の観点からも確認することができます。なぜなら、このSync Run Tableの中には、異なるフィールドがあり、この場合、失敗した回数を書き込んでいるのです。これは、Sync Run Tableだけでなく、Snowflakeで更新されている他のテーブルでも、この種のインシデントを実際に監視できることを強調するために作成したもので、実際にこのように増加していることが分かります。その上で、インシデントのアラートをすぐに提供し、過去の値に基づいて閾値を設定するだけでなく、実際の根本原因の分析に着手し、最終的な経緯を理解できるようにします。

たとえば、Snowflakeで更新したさまざまなテーブルをもとに、BIツールを構築している場合、インシデントが発生したことだけでなく、下流で実際にどのような影響があるのかを非常に迅速に理解することができます。これはどの程度重要なのか？そして、発生したさまざまなデータ・インシデントに対して、どのような優先順位を設定する必要があるのか？といったことがわかります。

10月末にIMPACTを開催します。このイベントには、FoxやGitLabなど、最も革新的な企業が参加しています。IMPACTでは、これらの企業がプレゼンテーションを行うことになっており、非常に楽しみにしています。

質疑応答

データエンジニアがデータオブサーバビリティを始めるのに最も簡単な方法は何でしょうか

Monte Carloを使うことだと思います。また、Monte Carloの価値はすぐに使えることなので、プロセスは非常に速いです。そして、自動的にデータの全系統を収集し始めることができるのです。

Hightouchのようなものを使っている場合、一般的に非常に複雑なデータスタックになります。そのため、データの系統を自動的に解析し、鮮度、ボリューム、スキーマの変更などの情報を自動的に提供することができます。これこそが、最も良いスタート方法だと思います。

一般的なデータリネージの使用例にはどのようなものがあるでしょうか

デモで少し強調したように、Monte Carloでは、すべての系統を自動的に解析します。ここでの使用目的は、データ品質に関するインシデントが下流に与える影響を理解することです。

歴史的に見れば、何らかのテストを実行していれば、データ品質インシデントが発生したこと、そしてそれがどのテーブルのどこで発生したかを理解することができます。しかし、データ品質インシデントのために、次にパイプラインを実行するときに、何が影響を受け、どのような下流のBIレポートや他のテーブルが影響を受ける可能性があるのかを理解することは、それほど簡単ではありません。

そこで、リネージを活用して、インシデントが発生したことだけでなく、下流で実際にどのような影響があるのか、（データ品質問題が解決するまでは）レポートが古くなる可能性や影響がある可能性があり、その数字を信用してはいけないということを誰に知らせる必要があるのかを理解できるようにします。

データオブサーバビリティを担当するのは誰になるのでしょうか

例えば、SREはシステムの稼働率や信頼性のために存在する専門的なロールのようなものだと思います。

データ分析のチームでは、通常、データエンジニアと呼ばれる人たちが一緒に仕事をします。彼らは、データオブサーバビリティとは何か、またデータ品質のチェックについて、先駆的な役割を担っています。

データオブサーバビリティを持ち込む時期はいつくらいが妥当でしょうか

ここで私が言いたいのは、早すぎるということはないということです。なぜなら、通常、巨大なインシデントが起こる頃には、それはもう少し手遅れになっているからです。このような問題は、組織やデータへの依存度によって、さまざまなタイミングで顕在化すると思います。しかし、やはり早すぎるということはないと思います。特に、「既知の未知」と「未知の未知」について話し始めると、「未知の未知」は、発見されたときに最も大きな打撃を受けるからです。それは、数週間から数カ月後になることもあります。場合によっては、このような状況を改善するのが遅すぎることもあります。

ですから、痛点が見え始めたら、もう手遅れとまではいかなくても、間違いなくその時だと思います。だから、いつでも（データオブサーバビリティを）やる価値があるんです。

データオブザーバビリティの世界では、ソフトウェアエンジニアリングの世界で見られるような、責任の所在を明らかにしない事後調査が行われているのでしょうか

Monte Carloでは、「未知の未知」を観察することができるので、より積極的に予想外のことに取り組むことができますし、場合によっては、より多くのテストを行うことで、未知を既知のものにすることもできます。そのため、未知のものを監視するだけでなく、未知のものを検出した場合は、よりカスタマイズされたチェックを行い、同じ問題に遭遇しないようにすることができるのです。

おわりに

「BIツールのダッシュボードの数値がおかしい」みたいな問題は、実際の現場で非常によくあります。その修正や原因究明には意外と時間がかかるもので、もしその時間が他のことに使えたら…と思うことは数知れません。

そんな環境にデータオブサーバビリティの概念を持ち込むのは非常に有効だと思うのですが、反面、それなりの規模のデータ分析基盤が無いと何にも始まらないようにも思えました。