データパイプラインのオブザーバビリティー：データエンジニア向けモデル

データパイプラインのオブザーバビリティーとは、データパイプラインの状態をいつでも監視し、理解する能力のことです。具体的には、オブザーバビリティーは、パイプラインの内部状態と、その状態がシステムのアウトプットとどのように相互作用するかについての洞察を提供します。

世界のデータ・パイプラインは データ・オブザーバビリティーを向上させる必要があるとIBMは考えていますしかし残念なことに、今日のデータ・エンジニアリングで発生する事象のうち、観察可能なものはほとんどありません。ほとんどのデータ・パイプラインは移動するために構築されていますが、監視は行われません。測定しますが、追跡しません。変換はしますが、伝えることはありません。結果は、悪名高いブラックボックスの事例です。

何が入るか分かっているはずです。何が出てくるか分かっているはずです。しかし、その間に何が起こるのでしょうか？そして、なぜこの不一致が生じるのでしょうか?残念なことに、この謎を解決するために構築されたパイプラインはほとんどありません。その多くは、最良のシナリオ用に設計されていました。
しかし、現実ではマーフィーの法則がより厳密に管理されており、ブラックボックスのアウトプット側には、奇妙な値や不可解な欠落列が多数表示されることがよくあります。データ・エンジニアは頭を悩ませています。修正するにはまず観察しなければならないことに気づいています。

このガイドでは、次の点について説明します。

1. データの可観測性とは何ですか?
2. データ・パイプラインのオブザーバビリティーとは？
3. パイプラインにとってデータ・オブザーバビリティーが重要なのはなぜですか？
4. データ・パイプラインにオブザーバビリティーをどのように実装しますか？
5. データ・オブザーバビリティー・プラットフォームはどのように役立ちますか？

「オブザーバビリティー」はちょっとしたバズワードになっているので、以下のように定義するのが最善でしょう。つまり、データ・オブザーバビリティーとは、アプリケーションや、データ・パイプラインのようなシステムの中のデータのヘルスを監視し、改善するための包括的な用語です。

「データ監視」では、データ・パイプラインやデータの現在の状態を知ることができます。データが完全、正確、かつ新鮮であるかどうかを示します。パイプラインが成功したか失敗したかがわかります。データ・モニタリングは、物事がうまくいっているか、壊れているかを示すことはできますが、それ以外のコンテキストは多く得られません。

そのため、モニタリングはオブザーバビリティーの１つの機能にすぎません。「データ・オブザーバビリティー」は、以下を含む包括的な用語です。

• モニタリング（監視）： パイプラインやシステムの運用状況を把握できるダッシュボード
• アラート： 予想されるイベントと異常の両方
• 追跡： 特定のイベントを設定し、追跡する機能
• 比較： 異常のアラートを含む長期的な監視
• 分析：パイプラインとデータヘルスに適応する自動問題検知
• 次善アクション: エラーの修正を実行するために推奨されるアクション

1つのアクティビティー（監視）だけでなく、アクティビティーのバスケットを包含することで、オブザーバビリティーはエンジニアにとってはるかに有用になります。データ・オブザーバビリティーは、問題を説明するだけではありません。それを解決するのに役立つコンテキストと提案を提供します。

IBM Databandの共同創設者兼CTOであるEvgeny Shulman氏は、次のように説明します。「データ・オブザーバビリティーは、システム・メトリクスに詳細なコンテキストを追加し、システム・オペレーションのより深い評価を提供し、エンジニアが介入して修正プログラムを適用する必要があるかどうかを示すことであり、監視だけではありません」IBMを提供しています。「言い換えれば、モニタリングでは、あるマイクロサービスが一定量のリソースを消費していることがわかりますが、オブザーバビリティーでは、その現在の状態がクリティカルな障害に関連しており、介入が必要であるということがわかります」

データ・パイプラインでは、このような事前対応型のアプローチが特に重要です。

データパイプラインのオブザーバビリティーとは、データパイプラインの任意の時点、特に内部状態を、システムのアウトプットに基づいて監視し、理解する能力のことです。基本的な監視にとどまらず、パイプライン内でデータがどのように移動し、変換されているかをより深く理解することができ、多くの場合、メトリクス、ロギング、データ・パイプラインのトレースに関連付けられます。

データ・パイプラインには、多くの場合、データが収集、変換、保管される一連の段階が含まれます。これには、さまざまなソースからのデータ抽出、データ・クレンジング、データ変換（集計など）、データベースやデータ・ウェアハウスへのデータのロードなどのプロセスが含まれる場合があります。これらの各段階には、データ品質、信頼性、システム全体の性能に影響を与える可能性のある異なる動作や潜在的な問題が存在する可能性があります。

オブザーバビリティーは、データ・パイプラインの各段階がどのように機能するか、またその内部処理が特定のタイプのアウトプット、特に必要なレベルの性能、品質、精度を実現しないアウトプットとどのように相関するかについての洞察を提供します。これらの洞察により、データエンジニアリング・チームは何が問題だったのかを理解し、それを修正することができます。

データパイプラインのオブザーバビリティーが重要なのは、パイプラインが複雑なものから複雑なものになり、多数の同時システムから多数の相互依存システムへと依存するからです。

ソフトウェア・アプリケーションはデータ・パイプラインからメリットを受けるだけでなく、データ・パイプラインに依存している可能性がこれまで以上に高まっています。エンドユーザーも同様です。AWSのような大きなプロバイダーが停止し、世界中のアプリケーションのダッシュボードが瞬く間に消えてしまうとき、複雑さが危険な依存関係を生み出すという兆候を至る所で見られるようになります。

現在、分析業界は年平均成長率12%を達成しています。Gartnerによれば、2027年にはウクライナの経済規模に匹敵する1,050億ドルという驚異的な規模になるといいます。このペースで行くと、企業のデータ量は現在、 毎月62% 増加しています。このすべてのデータを保管し、分析している企業はどうでしょうか？彼らは、自社のビジネスをそれに賭けており、それを実行するデータ・パイプラインが機能し続けると信じています。

データ品質の問題やパイプラインの障害の主な原因は、パイプライン内のトランスフォーメーションにあります。今日のデータ・アーキテクチャーのほとんどは不透明で、内部で何が起こっているかを把握することができません。トランスフォーメーションは起こっているものの、期待どおりではない場合、データ・エンジニアはその理由について多くのコンテキストを持っていません。

あまりにも多くのDataOpsチームが、コンテキストのない問題の診断に時間をかけすぎています。そして、最初の直感に従い、アプリケーション・パフォーマンス管理（APM）ツールを使用してDataOpsパイプラインを監視しても、うまくいくことはほとんどありません。

「データ・パイプラインの振る舞いは、ソフトウェア・アプリケーションやインフラストラクチャーとは大きく異なるものです」とEvgeny氏は言います。「データ・エンジニアリング・チームは、高レベルのジョブ（またはDAG）ステータスやデータベースの性能のサマリーについての洞察を得ることができますが、パイプラインの管理に必要な適切なレベルの情報については可視性が欠けています。このギャップにより、多くのチームは問題の追跡に多くの時間を費やしたり、常に偏執的状態で作業したりしています。」

より大規模で専門性の高いデータチームを持つことは役に立ちますが、そのチームメンバーが連携しなければ問題になります。より多くの人々がデータにアクセスし、独自のパイプラインや独自のトランスフォーメーションを実行すると、エラーが発生し、データの安定性に影響を及ぼします。

今日、データの安定性と、そのデータがビジネス内外の消費者による使用に適しているかどうかを心配するエンジニアが増えています。そのため、データ・オブザーバビリティーに関心のあるチームが増えているのです。

データ・オブザーバビリティーは、データがどのように流れ、最初から最後まで処理されるかについての洞察を提供することで、データパイプラインと連携します。データ・パイプライン内でどのようにデータ・オブザーバビリティーが機能するかについて、さらに詳しく説明します。

• データ取り込み: オブザーバビリティーは、データがパイプラインに取り込まれる時点から始まります。取り込まれたデータの量、処理速度、エラーや遅延の有無を監視できます。
• データ処理： データがさまざまな処理段階を経て移動するため、オブザーバビリティー・ツールは各段階のオペレーションの動作を監視できます。これには、障害の監視、レイテンシーの測定、リソース利用の追跡、データが正しく変換されていることの確認が含まれます。
• データ・ストレージと配信：続いてオブザーバビリティーは、ストレージと配信の段階に進みます。データベースやデータ・ウェアハウスにデータが書き込まれる速さを監視し、データが正しい宛先に配信されていることを確認し、問題があれば警告を発することができます。
• エラー追跡とトラブルシューティング： オブザーバビリティー・ツールは、エラーが発生した場所やその根本原因を特定するのに役立ち、修復アクションさえも提案します。これは、ダウンタイムを最小限に抑え、データ・パイプラインの信頼性を確保するためにクリティカルです。
• 性能の最適化： データ・パイプラインの性能を監視することで、オブザーバビリティー・ツールはボトルネックと最適化の機会を特定するのに役立ちます。これにより、リソースの効率的な使用と処理時間の短縮につながります。
• 異常検知： オブザーバビリティーは、潜在的な問題や改善すべき領域を示す可能性のある異常を特定するのに役立ちます。たとえば、データの処理に通常よりも大幅に時間がかかっている場合、パイプラインの特定の段階に問題があることを示している可能性があります。
• アラートとレポート： オブザーバビリティー・ツールには多くの場合、潜在的な問題をリアルタイムで通知できるアラート機能が含まれており、迅速な対応が可能です。また、包括的なレポート機能も提供しており、データパイプラインの全体的なヘルスや性能を理解するのに役立ちます。

データ・オブザーバビリティー・プラットフォームは、モニタリング・ツールだけでは得られない洞察を提供します。単に何が問題だったのかを伝えるだけでなく、それがどのような問題を引き起こしているのかを教え、それを修正するための手がかりや次善のアクションも提供します。現在のパイプラインの再構築や、いわば「飛行中にエンジンを変更する」ような必要もなく、継続的にこれを行います。

• データ・パイプラインは複雑なシステムです。継続的な調査を実施するデータ・オブザーバビリティー・アーキテクチャーが必要です。
• どこで失敗したか、そしてその理由を知る必要があります。オブザーバビリティー・プラットフォームは、まさにその目的のためにエンドツーエンドの監視を提供します。
• 下流の依存関係を追跡する方法が必要です。修正した結果が根本的な問題に対処することを期待するのではなく、知る必要があります。

データ・パイプラインは複雑なシステムであり、継続的な調査を実施するデータ・オブザーバビリティー・アーキテクチャーが必要です。問題が発生した場所とその理由を把握できるように、エンドツーエンドの監視のためのオブザーバビリティー・プラットフォームが必要です。下流の依存関係を追跡する方法が必要です。修正によって根本的な問題が解決されたことを期待するのではなく、それを知ることが必要なのです。

データ・オブザーバビリティー・プラットフォームには以下を含める必要があります。

• シンプルなセットアップ：パイプラインの変更は必要でしょうか？
• エンドツーエンドのトラッキング： 下流の依存関係を監視できますか？
• オブザーバビリティー・アーキテクチャー：単なる監視以上のことをしているでしょうか？
• しきい値の設定：独自に異常検知を行うことができますか？
• 管理：保存データを監視できますか？
• データ・オブザーバビリティー・オープンソース： 調整可能なオープンソース・コンポーネントを提供していますか？
• 分散システムのオブザーバビリティー： 分散システムも監視できますか？

また、プラットフォームは多くの処方的なガイダンスも提供する必要があります。データ・オブザーバビリティーとデータ・エンジニアリングの分野は急速に変化しており、問題と同じ速さで進化するプラットフォームを見つけるための最良の方法の1つです。もはや監視だけでは不十分です。監視、追跡、警告、対応が必要です。

IBM Databandのデータ・パイプライン監視機能は、ジョブや実行の失敗などのデータ・インシデントを迅速に検知し、パイプラインの拡張に対応できるようにします。さらなる詳細については、 今すぐデモを予約してください。