今すぐNew Relicを開始 さらなる革新をお望みですか?10月から夢の実現を始めましょう。
今すぐ申し込む

本記事は、英語で公開されているブログ記事の抄訳となります。

機能の正確性にデータの適時性が重要となるデータ処理パイプラインで、システム内の予期せぬ遅延にどのように対処すればよいでしょうか?

パイプラインのレイテンシが重要な理由

New Relic は、メトリクス、ログ、イベント、トレースを保存できるオブザーバビリティプラットフォームを提供します。また、ユーザーはデータの適時性を非常に重視しており、システムがどのように動作しているかをリアルタイムで確認し、問題があればできるだけ早く通知を受け取りたいと考えています。こうしたユースケースにおいて、データ処理パイプライン内の処理の遅延は大きな問題となる可能性があるため、適切に遅延を検出し、対処を講じる必要があります。たとえば、アラートパイプラインでデータが遅延し、遅延を検出するための対処を何も講じていなければ、そのデータはアラートクエリの集計から欠落するおそれがあります。これにより、信号喪失 (Signal Lost) を含む、アラートの誤検知につながってしまう可能性があります。

New Relic では、データの取り込みや保存、アラート通知といった一連の機能をスムーズに実行するために、ストリーミング抽出、変換、ロード(ETL)パイプラインを大規模に実行しています。お客様はエージェントまたは API を通じてデータを送信し、当社はそのデータを非同期的に処理して保存します。アラートパイプラインまたはその他のリアルタイムストリーム製品によってデータが保持され、評価される前に、さまざまな API または製品でドメイン固有の検証または処理が行われる場合があります。

ストリーミングパイプラインを実行する場合は、信頼性のベストプラクティスと戦略 (負荷分散、ボトルネックの回避、冗長性など) に従って、クリティカルパスでの遅延を回避する必要があります。ただし、最適な信頼性戦略を採用しても、ハードウェアに障害が発生するなど、パスのどこかで回避が困難なレイテンシが生じる可能性は否定できません。実際、これらの戦略の中には、負荷分散を改善するためにデータを並べ替えるなど、レイテンシの特定や対処をより複雑なものにしてしまう可能性もあります。このブログでは、レイテンシの発生を不可避なものと捉え、その処理に適用できる戦略に焦点を当てています。

パイプラインによるレイテンシの処理方法

レイテンシの影響が少ないシステム設計について考えます。

まず、データを整理しましょう。データが厳密に順序付けされていることが分かっていれば、その完全性についても推定することができます。あるデータが到着した際、そのデータに付けられたタイムスタンプよりも以前のデータはすべて到着済みであり、その時間内の処理はすべて完了している、と考えられるでしょう。アラート条件 (Alert condition) の Streaming method の一つである Event flow は、このような概念により成立するもので、データの順序によって集計対象データの境界を定め、処理を進めます。このようなデータの場合には、パイプラインのレイテンシは時系列内のすべてのデータに同じ量の影響を与えるため、処理は暗黙的にレイテンシに合わせて調整されます。

先頭の分が順番どおりに到着しない境界を定義する

しかし、厳密な順序を維持することが常に望ましい、または可能であるとは限りません。実際にはスケーラビリティの観点から、負荷分散と並列処理が必要になるほか、さまざまなソースや API からのデータストリームを結合する際にもまた複雑な問題が発生します。

そのようなケースでは、データをバッファリングして並べ替えることができます。これは、累積メトリック API の一部でも使用される概念であり、デルタ値を導出します。バッファリングの待機時間の検討も重要になりますが、比較的単純なケースでは、サンプリング間隔に基づくヒューリスティックが適用されます。

Detected_timeseries_gap

次に、おそらくもっとも興味を持たれているかもしれない、システム内で発生する可能性のある予期しないレイテンシを追跡し、補正するための戦略について解説します。

レイテンシへの動的な適応

使用するバッファリングの範囲と量を動的に調整するための、いくつかの戦略について考えてみましょう。

トラフィックフローの追跡

データ取り込みのラグを追跡する方法として、一連の処理の初めの段階で、パイプラインを通るすべてのデータに、その取り込み時間を示すメタデータを付加します。この情報はデータと一緒にパイプラインを介して後続の処理に渡されるため、プロセッサーがデータの受信時間との差を計算して、処理の終端に到達するまでにかかる時間を推定できます。

トラフィックフロー

タイムウェーブ

データの遅延に基づいてバッファリング範囲を動的に決定するための別のアプローチとして、合成データを用いて、一度にパイプラインに注入されるデータサイズを固定化することです。私たちは定期的に一定量のデータ ポイントを API に書き込み、各セットを「タイムウェーブ」と呼んでいます。ウェーブ内の各データポイントには、同じ送信時刻がデータとして含まれます。これは単にウェーブがいつ送信されたかを知るだけではなく、各データポイントの世代を示す ID としても機能します。データサイズが固定化されていれば、その既知のサイズに基づいて、パイプラインの後半において、各ウェーブにおけるデータポイントの数も予測できるようになります。これにより、データポイントの到着状況から、遅延の発生状況やデータ損失を検出できます。世代のすべてのデータポイントが到着すると、それらの世代のデータは処理が追いついているものとしてマークされます。

タイムウェーブ

外部オブザーバー

パイプラインの各部分を個別に監視し、個々のレイテンシを照合して合計することもできます。具体的には、Kafkaコンシューマーラグのように、サービスとキューの遅延時間になるでしょう。この計測データを同じ場所、同じフォーマットで送信するか、あるいは、どのような監視を行い、どのようにデータを配置するかを判断するサービスが別途必要になります。

外部オブザーバー

スコープ設定

これらの戦略のスコープを限定することで、パイプライン内部の処理の影響で生じたレイテンシを特定することができます。これは、オブザーバビリティの目的と、こうした情報を最も的確な方法でプログラム的に使用することの両方において重要です。New Relic では、サービスの機能ごとのパイプラインとセルラーアーキテクチャーのセルごとにパスを分離しているため、的確に対象を識別することができます。

また、ここでは、分散トレースを使用して、よりきめ細かいレイテンシ情報を取得し、データが移動するパスの全体と、具体的にどの部分が速度低下の原因となっているかについて、より詳細な粒度で可視性を提供することもできます。

課題

各戦略には特有の課題もあります。

  • トラフィックフローベース:パイプライン内の障害は、障害が解消され、遅延データがパイプラインの最後に到着するまで監視されません。これは、非常にきめ細かいパストレースを使用することで軽減できることがありますが、インシデントでパスが頻繁に変更されうるようなケースでは、実際には難しい作業となります。さらに、パスのごく一部 (たとえば、単一の Kafka パーティション) で生じたレイテンシでは影響を受けるデータポイントが少なく、データが下流にルーティングされるまでにあまり分散されず、データが流れる可能性があるすべての場所でのレイテンシ検出が困難になる可能性があります。
  • タイムウェーブベース:計測されていないパスについてはまったく情報がありません。つまり、考えられるすべての入力開始ポイントで合成データを生成し、考えられるすべてのアプリケーション**と**キューパーティションパスにウェーブが流れるようにする必要があります。この問題は、パイプライン側でこのデータをすべてのキューに均等配置するよう特別なルーティングを行い、送信する合成データの量を増やすことで軽減できます。
  • 外部オブザーバー:パイプラインのすべての部分を確実にカバーし、どの部分がどの下流製品パイプラインに影響を与えるか、またそれらの部分をどのように追加するかを理解するためのソリューションを構築する必要があります。一般に、これはギャップのないエンドツーエンドの処理時間を取得するための優れた方法ではありませんが、サービスの健全性とレイテンシが密接に関係する状況下で、チームが的確なアラートを受け取る方法の一つです。

ユースケースにもよりますが、まったく計測を行わずに一連の処理を行う場合と同等か、それよりも悪い遅延が発生する可能性があります。New Relic では、上記の戦略を組み合わせてパイプラインのレイテンシを監視し、それに適応します。

まとめ

顧客への影響を正確に判断するためには、まずはパイプラインのレイテンシを正確に把握することが重要です。その上で、パイプラインのパフォーマンスが低下している部分を特定し、そのレイテンシに自動的かつ動的に適応します。こうした施策は、パイプラインの各機能の正確性を維持するだけでなく、パフォーマンス目標に対するオブザーバビリティを提供するためにも必要となります。

レイテンシの影響を軽減するシステム設計は重要ですが、予期せぬレイテンシの問題に対する戦略を立てることも重要です。New Relic では、レイテンシを回避できない場合に、レイテンシを処理する戦略を開発しました。

複数の手法を組み合わせて採用し、これらの戦略の範囲を定めることで、必要に応じてデータのバッファリングと処理を動的に調整できます。各戦略には独自の課題がありますが、考え抜かれて調整されたアプローチにより、パイプラインのパフォーマンスと回復力が大幅に向上しています。