1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

「サイトが遅い」の原因探し、全部見る人ほど迷子になる理由

1
Posted at

はじめに

「なんだかサイトが遅いんだけど…」

こう言われて、どこから調べればいいのかわからず、困ったことはありませんか?🐢

ログを開いて、サーバーのグラフを見て、気づいたら何時間もたっていた。そんな経験がある人も多いと思います。

ついこう考えてしまいがちです。

調べる量が足りないから見つからない。もっとたくさん見れば、原因はいつか見つかる

でも、本当にそうでしょうか?

この記事では、同じ「遅い」という問い合わせに、AさんとBさんの2人が取り組みます。2人とも同じ道具(New Relic)を使えます。それなのに、原因にたどりつくまでの時間は大きくちがいました。

差の正体は、才能でも道具でもなく、「調べ方の考え方」のちがいです。

01_hajimeni.png


お題:会員サイトが「なんだか遅い」

どんな場面?

舞台は、小さなスポーツクラブの会員サイトです。

02_odai.png

この記事は「この材料だけで調べる」前提で考えます。会員サイトにはNew RelicのAPM(アプリの見張り役)がすでに入っていて、リリースの記録もNew Relicに送る設定になっている、という設定です。

New Relicって、なに?

New Relicは、ひとことで言うとシステムの健康診断の機械です。

人が病院で血圧や体温をはかるように、New Relicはサイトの「速さ」「エラーの数」「サーバーの調子」などを、ずっと記録してくれます。記録はグラフで見られるので、「いつから」「どこが」おかしいのかを調べるのに使えます。

無料プランでも、毎月100GBまでデータを入れられて、全部の機能を使えるユーザーが1人分ついてきます。

03_newrelic.png

登場人物

04_tojojinbutsu.png

ここで、ちょっと考えてみてください。あなたなら、まず何から調べますか?🤔


Aさんのやり方:あやしいところを、全部調べる

場面1:サーバーに入って、全部チェック

Aさんは連絡を受けて、すぐに動きました。

遅いということは、どこかに問題があるはず。見落としがないように、上から順番に全部調べよう。

Aさんはサーバーに入り、CPU、メモリ、ディスクを1つずつ確認しました。

  • CPU:40%(少し高い…?)
  • メモリ:70%(これも少し高い…?)
  • ディスク:60%(まだ大丈夫そう)

次にログです。1日分のログはおよそ12万行。「error」という言葉でさがすと、300件も出てきました。ところが、よく読むと、ほとんどが前からずっと出ている、問題のない警告でした。

05_a_zenbu.png

場面2:どのグラフも「少しあやしい」

次にAさんは、New Relicの画面を開きました。サーバーのグラフ、アプリのグラフ、ブラウザのグラフ…。全部で23枚のグラフを1枚ずつ見ていきます。

06_a_graph.png

でも、グラフというのは、いつも少しはギザギザしているものです。

このグラフも少し上がっている。こっちも少しあやしい。…どれが原因なんだろう。

どのグラフも「少しあやしい」ように見えて、決めきれません。どうでしょうか? この気持ち、わかる人も多いのではないでしょうか。

場面3:とりあえず再起動

調べ始めてから2時間がたちました。受付スタッフからは「まだですか?」と何度も連絡が来ます。

Aさんは「とりあえず、サーバーを再起動してみます」と決めました。

Aさんの報告.txt
お待たせしてすみません。
サーバーを再起動しました。少し速くなったようです。
引き続き様子を見ます。

再起動したのは、ちょうど利用者が少ないお昼の時間でした。そのため、たまたま速く見えただけでした。そして次の朝、また「遅いです」と連絡が来てしまいます。

原因がわからないまま「とりあえず再起動」すると、同じことがまた起きます。 さらに「直った」と思ってしまうので、本当の原因から遠ざかってしまいます。

07_a_saikido.png

Aさんの結果

08_a_kekka.png

Aさんは、決してサボっていたわけではありません。むしろ、だれよりもたくさん調べました。それなのに、なぜうまくいかなかったのでしょうか?

Bさんのやり方:範囲をせまくしてから調べる

場面1:まず、3つ聞く

同じ連絡を受けたBさんは、すぐにサーバーには入りませんでした。最初にしたのは、受付スタッフに質問することです。

受付スタッフとの会話.txt
Bさん:「遅い」のは、いつからですか?
スタッフ:昨日の夕方くらいからだと思います。
Bさん:どの画面が遅いですか?
スタッフ:会員を探す画面です。予約の画面はふつうです。
Bさん:だれが使うと遅いですか?
スタッフ:わたしも、ほかの受付の人も、みんな遅いです。

たった3つの質問で、こんなことがわかりました。

09_b_kiku.png

場面2:調べる範囲をせまくする

Bさんは、こう考えました。

「サイト全体」ではなく、「昨日の夕方からの、会員を探す画面」だけを調べればいいんだ。

調べる場所を、サイト全体から1つの画面にせまくしたのです。これなら、23枚のグラフを全部見る必要はありません。

10_b_semaku.png

場面3:グラフの「変わり目」を探す

BさんはNew RelicのAPMを開き、会員を探す画面(/members/search)の応答時間のグラフだけを見ました。

すると、昨日の17時ちょうどから、グラフがはっきりと上がっていました。0.3秒だったものが、4.8秒になっています。

しかも、グラフの17時のところには、縦の線(リリースの印)が立っていました。New Relicの変更追跡の機能で、「17時にリリースがあった」ことが記録されていたのです。

11_b_kawarime.png

リリースの中身を見ると、「会員検索に『退会した日』の条件を追加」と書いてありました。さらに処理の中身(トランザクショントレース)を見ると、**データベースからさがす処理(SQL)**だけで4.5秒かかっていました。

変更追跡は、リリースなどの「変更」をNew Relicに記録しておく機能です。記録しておくと、グラフの上に縦線の印が出るので、「この変更のあとから、おかしくなった」とすぐに気づけます。

場面4:New Relic AIにも聞いてみる

Bさんは、自分の考えが合っているか、New Relic AIにも聞いてみました。New Relic AIは、ふつうの言葉で質問すると、New Relicのデータを調べて答えてくれるアシスタントです。

New Relic AIへの質問.txt
会員検索(/members/search)が、昨日の17時ごろから遅くなっています。
いちばん時間がかかっている処理と、その時間に何が変わったかを教えてください。

AIは、遅くなったのが17時のリリースのあとであることと、SQLに時間がかかっていることを、グラフつきで教えてくれました。Bさんが自分の目で見たことと同じです。

12_b_ai.png

AIの答えは、かならず自分の目でも確かめましょう。Bさんは先に自分でグラフを見て、「17時のリリースがあやしい」とあたりをつけていました。だから、AIの答えが正しいかどうかを判断できたのです。

Bさんは、わかったことを開発の担当者に伝えました。

Bさんの報告.txt
- 会員サイトが遅いです。調べてください。
+ 会員を探す画面だけが、昨日17時のリリース(v2.4)のあとから遅いです。
+ 応答時間は 0.3秒 → 4.8秒。そのうち 4.5秒 がSQLです。
+ 「退会した日」の条件の追加が関係していそうです。

開発の担当者は、すぐにデータベースの設定(インデックス)を足してくれました。会員を探す画面は、0.3秒にもどりました。

Bさんの結果

13_b_kekka.png


2人をくらべる

2人の結果を、表にしてみました。

くらべること Aさん Bさん
原因がわかるまでの時間 2時間30分(わからず) 約20分
見たグラフの数 23枚 3枚
読んだログ 約12万行 0行
スタッフへの最初の返事 2時間後 5分後
次の日も遅かった? 遅かった なおった

使った道具は同じです。それなのに、どうしてこんなにちがったのでしょうか?

Aさんは、調べる量をふやしました。Bさんは、調べる範囲をせまくしました。ちがいは、それだけです。

14_kurabe.png

Aさんの「全部調べる」が、いつもまちがいというわけではありません。サイトがまったく開かない、全部の画面でエラーが出ている、というときは、全体を見ることが正解のこともあります。この記事は「一部が遅い」という場面での話です。


「遅い」と言われたときの心得5か条

第1条:調べる前に、まず聞く

「いつから」「どこが」「だれが」を聞くだけで、調べる範囲はぐっとせまくなります。

第2条:全部は見ない

見るグラフは、問題の画面に関係するものだけにしぼります。たくさん見るほど、「少しあやしい」ものがふえて迷ってしまいます。

第3条:グラフの「変わり目」を探す

「数字が高いかどうか」ではなく、**「いつ変わったか」**を見ます。いつもより急に変わったところに、ヒントがあります。

第4条:その時間に「変えたこと」を疑う

リリース、設定の変更、データの追加など。変わり目と同じ時間に何があったかを調べます。変更追跡で記録しておくと、すぐに見つかります。

第5条:わかったことは、数字で伝える

「遅いです」ではなく、「0.3秒が4.8秒になった」と伝えます。相手もすぐに動けます。

15_kokoroe.png

🎁 おまけ:応答時間のグラフを出すNRQL

New Relicでは、NRQLという言葉でデータを取り出せます。会員を探す画面の応答時間を、2日分グラフにする例です。

NRQL
SELECT average(duration)
FROM Transaction
WHERE name LIKE '%members/search%'
SINCE 2 days ago
TIMESERIES

New Relic AIに「会員検索の応答時間を2日分グラフにして」とお願いしても、作ってもらえます。


おわりに

AさんとBさん、どちらが「いつも正しい」というわけではありません。Aさんの丁寧さと責任感は、とても大切なものです。大きな障害では、Aさんのように全体を見わたす力が役に立つ場面もあります。

ただ、「なんだか遅い」と言われたときは、調べる量をふやす前に、調べる範囲をせまくする。この考え方を1つ持っておくだけで、調べ物はずっと楽になります。

New Relicは、その「せまくする」をとても助けてくれる道具です。無料プランから始められるので、まずは自分のサイトのグラフを見てみてはいかがでしょうか?😊

この記事に出てくる人物、会話、数字、会員サイトは、すべてフィクションです。New Relicの画面や機能の名前は、記事を書いた時点のものです。最新の情報は公式のドキュメントで確認してください。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?