レスポンスタイムの分析

ボーッとしていたら1年が過ぎてしまいました。この記事は、はてなエンジニア Advent Calendar 2022の4日目です。

はてなでSREをやっているhappy_siroです。

僕の所属しているチームでは定期的に継続的なパフォーマンスの劣化を確認しています。具体的には、先月や、先々月と比べて今のレスポンスタイムがどう変化しているか、というようなことを確認しています。このとき、エンドポイント毎の変化を確認しようとすると、エンドポイント数が膨大でなかなか難しい…という課題がありました。

この課題を解決するためのアプローチの一つが レスポンスタイムの平均 - happy_siro's blog です。今回はまた違った方法で戦ってみたので、それについて書きます。

今回のアプローチ

前回は、統計的仮説検定を利用して見るべきエンドポイントを絞ろうとしていました。今回は、見るべきグラフを工夫すれば人間が全部確認できるのではないか、という仮設でアプローチします。

グラフの工夫

グラフを書くライブラリの選定

今回は Vega-Altair: Declarative Visualization in Python — Altair 4.2.0 documentation を利用しました。 言語をまたいで共通で利用できることを目指した Vega という visualization grammar の Python による実装です。Pythonによるデファクトは、Matplotlib — Visualization with Python なんですが、言語をまたいで可視化の知識が流用できるかもしれない…というところに惹かれて Vega-Altair を使用しました。

試行錯誤

工夫の前に、アクセス数があまりに少ないエンドポイントについては確認する必要がないので、アクセス数である程度足切りしました。

ここから、グラフを試行錯誤してきます。 月ごとのレスポンスタイムをエンドポイント毎にグラフにしています。データはすべてダミーです。またこれらの作業はJupyter Notebook| Home で行っています。

まずは、単純な折れ線グラフです。 グラフは、Vega-Altair: Declarative Visualization in Python — Altair 4.2.0 documentation で書いています。選定の理由は、後に書きます。

何がなんだかわかりませんね。

ちなみにですが、最初はこういったグラフを睨みながらパフォーマンスの劣化を確認していました。 誰が見てもわかりやすい、というグラフではないのでグラフを眺めるセンスが要求され、担当者ごとにパフォーマンス分析の品質に差が生まれてしまいました。またこのグラフを眺めて考えるのはめんどくさい…という問題もありました。

もう少し工夫します。

小さいですね…。これは横にすべてのエンドポイントを並べました。 上に比べればエンドポイントごとの変化はわかりやすくなっています。これでもまぁ良いんですが、もうちょっと工夫します。

レスポンスタイムをy軸にとりx軸に時間をとると、一つのグラフの中で線が多くするか、グラフの数を増やすか、のどちらかになってしまいます。 そこで、y軸にエンドポイント名を、x軸に時刻を、レスポンスタイムを色で表すことにします。

具体的なレスポンスタイムは完全にわからなくなりましたが、傾向はなんとなくわかります。 このデータはランダムなので意味は読み取れませんが、実際のデータでも傾向は読み取れ、継続的に遅くなっているエンドポイントを発見できました。

既存のツールを利用しなかったのはなぜ

ツールが整備されていなかった、かつ、今すぐパフォーマンスの分析をしたかったから、です。 仕事をしていると手持ちの道具でなんとか問題を解く必要があるケースはままあります。そういったときでも汎用的な可視化ライブラリ、分析ツールでデータがあればパフォーマンスを解析していくことができました。 これは今回の作業の学びの一つです。

まとめ

グラフを工夫し確認する必要のあるデータを絞ることで、たくさんあるデータでも人間が全部みれそう、ということがわかりました。 データさえあれば分析や可視化は汎用的なもので対応可能だ、ということもわかりました。