こう
- 「API が
遅いと 言われたら、 どこから 調べますか」 - 「昨日から
一部の 画面が 重いと 問い 合わせが 来ました。 どう 原因を 探しますか」 - 「とりあえずキャッシュを
入れる、 で良いですか」 (裏から聞く形)
面接官が
- 勘で
直し始めず、 まず数字で 「どこが、 いつから、 誰に とって」遅いかを絞れるか - 平均ではなく、
遅い ほうの 人の 時間を 見ているか - 1 つの
要求の 時間の 内訳を 見て、 遅い所を 突き止める 手順を 持っているか - 直した
あと、 本当に 速くなったかを 同じ 物差しで 確かめるか
短い答え
- まず
数字で 絞ります。 いつから、 どの API が、 平均ではなく 遅い ほうの 人 (上から 5% や 1% の 人) に とって、 どれだけ 遅いかを見ます。 - 次に 1 つの
要求の 時間の 内訳を 見ます。 DB の 問い 合わせ、 外の サービスの 呼び出し、 接続や 処理の 順番の 待ちの どこで 時間を 使っているかを、 トレースや ログで 分けます。 - 遅い
所が 分かってから 直し、 直した あとは 同じ 数字で 速くなったかを 確かめます。
この
少し
まず範囲を絞る
「遅い」は
- いつから
配備、 データの 増加、 使う 人の 増加など、 同じ 時刻に 変わった 物が 手が かりになります - どの API か
全部が 遅いなら 共通の 部分 (DB、 ネットワーク、 台数) を、 一部だけなら、 その 処理を疑います - 誰にとってか平均ではなく、
遅い ほうの 人の 時間 (95 パーセンタイルや 99 パーセンタイル) を 見ます。 特定の 利用者や、 データの 多い 人だけ遅いこともあります
時間の
1 つの
よく
- DB の
問い合わせ インデックスが 効いていない、 1 件ずつ問い 合わせを 繰り返している (N+1 問題) など。 遅い 問い 合わせの 記録と、 実行計画 (EXPLAIN) で 確かめます - 外のサービス決済や
認証などの 呼び出しが 遅い。 待つ 時間の 上限 (タイムアウト) が 無いと、 相手の 遅さが そのまま 自分の 遅さになります - 待ち行列 DB の
接続の 取り合い (コネクションプールが 足りない)、 処理の 順番待ち。 処理 その ものは 速いのに、 始まるまでが 遅い形です
SQL クエリ
EXPLAIN SELECT * FROM orders WHERE user_id = 42 ORDER BY created_at DESC LIMIT 20;実行計画で、
直す順番と確かめ
原因が
直したら、
話すときは、
よく
- 平均の
速さだけで 「問題ない」と言う 平均が 速くても、 遅い ほうの 人は とても 待っている ことがあります - 原因を
知らずに キャッシュや 台数を足す 遅さの 元が 残るので、 また 同じことが 起きます。 費用だけ 増える こともあります - 手元の
少ない データで 試して 「速い」と言う本番の データの 量や 偏りでしか 出ない 遅さがあります
深掘りの問い
- 「トレースの
仕組みが 無い 環境なら」 入口と 出口、 DB と 外の 呼び出しの 前後で 時間を ログに 出し、 同じ 要求の 番号で つな げて 読む、と答えます - 「DB は
速いのに API が 遅いときは」接続を 取るまでの 待ち、 外の サービス、 大きな 応答を 組み立てる 処理、を 順に 疑う、と答えます - 「遅さを
先に 見つけるには」遅い ほうの 人の 時間に 目標を 置き、 外れたら 知らせる 形に する、と答えます