Yao Yueは、QCon San Franciscoでの講演において、システムの測定データを表示する方法を見直すよう呼びかけている。ほとんどの監視ダッシュボードでデフォルトの形式となっている線グラフは、クリーンで連続したデータには適しているかもしれない。しかし、時系列が増えたり、ノイズが大きくなったり、問われている内容がそもそも時間と関係していなかったりする場合には、役に立ちにくくなる。
Yueは、大規模システムの運用に15年間携わった経験を基盤としている。そのうち7年間は、レベル1サービスのオンコール勤務に従事していた。また、Twitterではキャッシュチームを率いた後、パフォーマンスチームを立ち上げた。2022年11月以降は、インテリジェントなパフォーマンスエンジニアリングによってソフトウェアの効率と信頼性を向上させる企業、IOP Systemsの共同設立にも携わっている。
問題は線そのものではない
Yueは、線グラフが測定点だけを表示するのではなく、連続する2点の間に線を引くものだと説明する。つまり、実際のデータには存在しない視覚的な要素を追加していることになる。彼女はこれを、測定値の間を補間する「extrapolation(外挿)」と表現している。データが規則的であれば有用な場合もあるが、特にその間に何が起きたか分からないメトリクスでは、直接的な情報を持たない2つの測定値の間に経路が存在するような印象を与える可能性がある。
この問題は、多数のレプリカや時系列を含むシステムでさらに大きくなる。多くの線や色によって監視ダッシュボードは豊かに見えるかもしれないが、「処理レートは変化したか」「新しいデプロイによって顕著な劣化が生じたか」といった問いへの答えが分かりやすくなるわけではない。多くの場合、グラフを解釈できるのは、詳細を長時間見つめる経験豊富なエンジニアだけである。Yueは、このようなパターンは信頼性を重視するエンジニアリングには適していないと考えている。
測定の性質に応じた形式の選択
講演者は、データの形状、測定の種類、そしてチームがそこから何を知りたいのかという3つの観点から始めることを提案している。データが密集している場合は、時間ウィンドウ内の平均値を使ったり、最小値、最大値、平均値を計算したりすることで、ノイズを減らし、傾向を強調できる。ただし、この変換は単にグラフを見栄えよくするためではなく、問われている内容に役立つものでなければならない。
Yueは、データの要約によって重要な違いが隠れる可能性があると警告している。彼女は「Datasaurus」の考え方を例に挙げる。生の値を描画すると形状が根本的に異なるデータセットでも、同じ平均値と標準偏差を共有することがある。そのため、線を使わず点だけを表示するほうが、場合によってはより正確である。実際の測定値を明示し、不確かな視覚的経路を追加しないからだ。
講演によれば、測定データの大半は、カウンター、ゲージ、ヒストグラムという3つの主要な種類に分けられる。時間とともに増加するカウンターには線が適している場合がある。しかし、監視アプリケーションで表示されることが多いのは生のカウンターではなく、連続する2つの値の差である。たとえば、リクエストレートやエラー率がこれに当たる。Yueは、この差を区間や棒として表現すると、累積的な変化とばらつきをより正確に示せると考えている。
一方、ゲージは2回の読み取りの間の期間について何も保証しない。2つの測定値の間で値が上昇したり低下したりしても、データには現れない可能性がある。そのため講演者は、できるだけ外挿を少なくし、点をそのまま表示することを好む。レイテンシについては、単一の値では不十分だと強調している。レイテンシは1つの数値ではなく分布を表すからだ。P99やP99.9のようなテールの情報を、1本の線に縮約するのではなく保持するには、ヒストグラムのほうが優れた手段だとしている。
実際には何が変わるのか
講演の最も重要な主張は、すべての線グラフを置き換えることではなく、可視化を運用上の問いと結び付けることにある。問いがSLAに対する負荷の影響である場合、データを負荷の範囲ごとにグループ化できる。たとえば、毎秒500件または5000件のリクエストといった範囲に分け、それをレイテンシ分布と関連付ける。そうすれば、負荷とレイテンシの直接的な関係がグラフに現れ、負荷がピークに達した時点を探すために異なる日を調べ続ける必要がなくなる。
同様に、2つのソフトウェアバージョンを比較する場合は、測定値をバージョンごとにグループ化し、時間を分析の主軸にせず、分布やパーセンタイルを比較できる。ハードウェアの種類を選ぶ際には、パフォーマンスデータをインスタンスタイプや価格などの別の情報と組み合わせ、実際のサイジング判断に重要な項目を比較する表にまとめるという考え方も示している。
certi.newsの見解
この見方は、視覚デザイン上の問題だけでなく、監視ツールのアーキテクチャ上の制約も明らかにしている。測定値の保存システムは通常、一方にメトリクス名とラベル、もう一方に値とタイムスタンプを置く構造になっている。そのため、時間に沿った値に関するクエリは比較的容易だが、あるメトリクスの値を別のメトリクスの値と結び付けることは難しい。たとえば、レイテンシを負荷と関連付けたり、ソフトウェアバージョンごとにパフォーマンスを比較したりする処理である。
実務的には、監視ダッシュボードの改善は、必ずしも色や新しいグラフを選ぶことから始まるわけではない。まず、ダッシュボードが支援すべき意思決定を明確にする必要がある。チームは、データを再グループ化したり、時系列データベースの外部にある情報源を統合したりする必要があるかもしれない。同時に、この講演はすべての人に通用する単一の処方箋を提示しているわけではない。測定の種類と形状、そして問われている内容が最適な表現を決めることを強調しており、現在のすべての監視ツールがこうした変換を自動的に提供しているとは、出典からは確認できない。そのため、試行可能性、生データへのアクセス、各要約方法の限界の理解は、信頼性チームとパフォーマンスエンジニアリングチームにとって、引き続き未解決の実務的な課題である。
ニュースの出典
InfoQ - Architecture Articles
原文を開く ↗