データパイプラインのオブザーバビリティに関する実践ガイド

このブログシリーズをフォローしている方は、トピックの大部分がソフトウェアやその背後にあるインフラストラクチャの健全性の監視という共通のテーマを共有していることに気付くでしょう。この記事では、より非伝統的なユースケースであるデータパイプラインのオブザーバビリティに焦点を当て、New Relicなどのプラットフォームを使ってデータパイプラインのオブザーバビリティの実践を向上させる方法について説明します。

背景について

現代のあらゆるデジタルビジネスにおいて、データが王様であることは周知の事実です。多くの場合、それが意思決定プロセスの中核となります。New Relicでは、データのサブセットが生成する請求書の基礎となるため、さらに重要です。これは、2020年にNew Relicがライセンスベースの購入モデルから使用量ベースのモデルに切り替えたためです。使用量ベースの価格設定は新しい概念ではありませんが、当社が行った変更は、自社のデータパイプラインのオブザーバビリティの実践に大きな影響を与え続けています。これは、各顧客の課金対象使用量を追跡する使用量パイプラインに特に当てはまります。課金対象の使用量データを監視する場合、正確さが重要であり、各顧客に正確に請求することが最も重要です。毎月何千もの請求書が発行されるため、それぞれの使用量を手動で確認することは不可能です。以下は、データパイプラインのオブザーバビリティを適切に実現する方法を考えるためのフレームワークです。これはこの分野における当社自身の経験から生まれたものですが、提起されたポイントは他の状況にも適用できるはずです。

1. 目標の把握

この分野に取り組む上での良い出発点は、データパイプラインのオブザーバビリティで何を達成したいのかと自問することです。ほとんどのパイプラインに適用できる一般的な目標がいくつかあります。SLA達成の監視、エラーのアラート、特定のトラフィックパターンや外れ値の監視などです。ただし、目標はビジネスに固有のものである場合もあります。当社の場合、主な目標は2つあります。

• 請求可能な使用量を正確に把握し、それに基づいて請求書を発行する
• 使用パイプラインでデータ品質チェックが自動化されていることを確認する

2. データの把握

これは当然のことのように思えるかもしれませんが、データを真に理解することは見落とされがちなステップです。時間をかけてこれを行うと、目標を達成するためにどこに投資する必要があるかが明らかになります。詳しく調べる際に検討すべき質問を、以下に示します。

• データの形状はどのようなものか？そのスキーマは何か？目標の達成に必要なすべての属性を備えているか？あるいは、さらに多くのデータソースを追加して強化する必要があるか？
• データの量はどれくらいか？使用しているシステムでは1秒あたりいくつのデータポイントを処理しているか？ボリュームの急増はあるか？

これらの質問がわからない場合や適切な答えを持っていない場合は、カスタムイベントやカスタムメトリックを使用してデータ処理パイプラインを計装するという簡単な方法があります。これを行うことで、これらの質問に対するベースラインの回答を取得するのに役立つNew Relicクエリ言語（NRQL）クエリを簡単に作成できるようになります。

当社の場合、パイプラインで追跡する多くの項目の1つは、製品チームが生成した使用イベントの数です。これらのイベントは、個々のサービスまたはAPIによって収集された「生の」使用量を表し、パイプラインへの主な入力として機能します。一貫性を維持するため、すべての製品チームがこれらの生のイベント生成に使用する内部ライブラリを構築しました。このライブラリは、使用イベントのペイロードを標準化するだけでなく、生成されたイベントに関するカスタムメトリックを報告する機能も提供します。これらのカスタムメトリックを使用すると、次のようなNRQLクエリを記述できます。

この特定のクエリは、次のようなグラフを作成し、トレンドにおけるマクロレベルの偏差についてのインサイトを提供します（このデータに対してアラート条件も設定します）。

このタイプのデータのもう1つの用途は、キャパシティプランニングです。仮に、X百万イベント/時間にY個のKafkaブローカーが必要であることがわかっている場合、イベントレートが一定量増加した場合に必要となる追加のブローカー数を合理的に予測できます。

3. 小規模から始める

新しいデータパイプラインを作成する初期段階であれば、最初からオブザーバビリティを組み込むのが最善策です。ただし、パイプラインが確立されている場合は、小規模から始めるのがよいアプローチです。

一般的なデータ処理パイプラインでは、入力と出力の間に複数のステージが存在する場合があります。

一度に全体を計装しようとするのではなく、まずは小規模の価値の高い領域に焦点を当てます。優先順位付けの際に考慮すべき事項は次のとおりです。

• 潜在的に不安定な既知の領域。たとえば、特定の段階（コード、インフラストラクチャなどが原因で）が不安定になる可能性があることがわかっている場合、まずそれらを計装することを検討します。
• ビジネスへの影響が最も大きい領域。たとえば、特定の段階でビジネスに不可欠なメトリクスを計算している場合は、それが優先順位を付けるのに適した候補となる可能性があります。

どこに重点を置くべきかを特定したら、前述のカスタムイベント/メトリクスAPIや、New Relicのインスタントオブザーバビリティクイックスタートのいずれかを使用して、オブザーバビリティを実現できます。

4. 迅速な成果物を探す

高度なデータパイプラインのオブザーバビリティ技術（人工知能 [AI] や機械学習 [ML] など）は存在しますが、迅速な成果をもたらすよりシンプルな技術を実装することの価値を過小評価しないでください。当社が社内で使用している方法の1つは、サンプルデータを定期的に使用パイプライン全体に送信し、変換された出力の正確性をチェックすることです。以下に、この手法が実際にどのようになるかを示した図を示します。

上記のサンプルパイプライン図を拡張すると、一定の間隔で入力（X）を生成するプロセスを作成し、New Relicを使用して実際の出力と期待値（Y）を比較できます。入力Xに出力Yがない場合にさまざまなチャネルに通知するアラート条件を作成することで、この監視をさらに自動化できます。

これはパイプライン内のどこに問題があるかを示すものではありませんが、パイプラインが正常に機能している（または機能していない）かどうかを確認するための適切なベースライン信号として機能します。New Relicでは、請求対象となる測定ごとに、このようなシンプルで総合的なデータチェックを実施しています。入力が予想される出力と一致しない場合、プラットフォームは直ちに適切なチームに調査を依頼します。

まとめ

データパイプラインのオブザーバビリティは、多くの複雑さを伴う大規模なドメインです。各パイプラインには独自の技術要件とビジネス要件が伴いますが、それらすべてに少なくとも1つの共通テーマがあり、それらを遵守する必要があります。この記事が、独自のオブザーバビリティの実践を実装するためのフレームワークと、実用的なヒントを提供できれば幸いです。また、New Relicのようなプラットフォームを使用すると、いかに迅速かつ簡単に開始できるかについてもご理解いただければと思います。