こんにちは！ 承認チームでGoエンジニアとしてインターンをしているunagamです。
今回は 「チューニングする対象をどう選ぶか」 について書きます。 インターン生や新卒のエンジニアなど、パフォーマンスチューニングをやりたいけど何から始めればいいのかわからない人の助けになれば幸いです。 世の中の技術ブログには「どう速くするか(やり方)」を記した記事はたくさんある一方で、「どうやって改善対象を選ぶのか」を記した記事はほとんど見かけません。 ですが選び方を知らないまま改善に取り組むと、ほとんど使われていないコードを一生懸命速くしてしまうという悲しいことが起こりかねません。 そこでこの記事では改善対象の選び方に焦点を当てて解説します。 その後、実際にDatadogを用いて改善するべき箇所の選び方を実演します。
なぜパフォーマンスチューニングをするのか
選び方を語る前に、なぜチューニングするのかを確認します。ここで挙げる2つの動機が、後で説明する「選び方の2軸」にそのまま対応するためです。
- ①ユーザー体験(以下: UX)の向上 — レスポンスが遅いとそれだけでストレスになり、ユーザーは離れていく。Googleの調査では「表示速度が1秒→3秒に遅くなると、離脱確率が32%増加する」1というデータもあるほどで、速いほど離れにくいサービスになる。
- ②インフラコストの節約 — クラウド料金は「どれだけ計算リソースを消費したか」で決まる。処理を軽くすればその分コストが減り、利益(=売上 − コスト)に直接効く。
つまりチューニングは「ユーザー視点」と「企業視点」の両方で意味を持ちます。そして後述するように、この ①UX → レイテンシ、②インフラコスト → 総処理時間(負荷) という2つの軸が、対象APIを選ぶときの判断軸になります。
【本題】改善するAPIの選び方
ここからが本記事の核心です。私たちは今回改善する対象として、APIに焦点を当てて解説します。重いAPIを探すといっても「重い」には2つの意味があります。1リクエストあたりが遅いのか、それともサービス全体で大量に時間を消費しているのか。この2つを別々の指標で捉え、組み合わせて優先度を判断します。
軸1: レイテンシ(=UX)
1つ目の軸はレイテンシ、つまり「リクエストを送ってからレスポンスが返ってくるまでの時間」です。 レイテンシが大きければ、その分ユーザーの待ち時間が長くなってしまうのでUXの悪化につながります。
補足 : 一般的にパフォーマンスを確認する際には平均レイテンシではなく、「全体の95%のリクエストがこの時間内に完了する」という基準を示す「95パーセンタイル(p95)」という指標がよく使われます。例えば、p95の値が200msの場合、全リクエストの95%が200ms以内に収まっており、残りの5%が200ms以上かかっていることを意味します。直感的には平均レイテンシだけ見れば十分に思えるかもしれません。しかし平均レイテンシだけを見ていると「平均レイテンシが100msであるのに、p95が1,000msに達している」といった極端な遅延を見落とす恐れがあります。したがってパフォーマンスチューニングにおいては取りこぼしのないよう、p95といったリクエストの中でも極端に遅いものを指標として使います。
軸2: 総処理時間(=インフラコスト)
2つ目の軸は総処理時間、つまり「そのAPIが一定期間にサーバーで費やした処理時間の合計」です。ざっくり言うと次の関係になっています。
総処理時間 ≈ リクエスト数 × 平均レイテンシ
総処理時間が大きいAPIは、「1回が重い」か「大量に呼ばれている」かのどちらか(あるいは両方)で、サーバーのリソースを最も食っている = インフラコストを最も生んでいるAPIです。これは②インフラコストに対応します。本記事では、この総処理時間を表す指標としてDatadogのTotal Timeを使います。
ここで重要なのは、レイテンシが高いことと総処理時間が大きいことは別物だということです。たまにしか呼ばれないAPIは、1回が遅くても(レイテンシが高くても)総処理時間は小さくなります。だからこそ、この2軸を組み合わせて見る必要があります。
2軸マトリクスで優先度を判断する
レイテンシ(縦のUX)と総処理時間(横のインフラコスト)を2軸に取ると、APIは次の4領域に分類できます。
①最優先(赤・右上 / レイテンシ 高 × 総処理時間 高):1回が遅く、かつ大量に時間を消費している。UX、コスト共に悪いため、改善すれば両方に効く。まずここを狙う。
②インフラコスト削減(オレンジ・左上 / レイテンシ 低 × 総処理時間 高):1回は速いが大量に呼ばれている。誰も「遅い」と文句は言わないが、実はサーバーのリソースを一番食っている。コスト視点で改善する価値あり。
③後回し(黄・右下 / レイテンシ 高 × 総処理時間 低):1回は遅いが、たまにしか呼ばれない。改善インパクトは小さいので基本は後回し。ただし下記の例外に注意。
④無視(灰・左下 / レイテンシ 低 × 総処理時間 低):速くて呼ばれてもいない。改善しても得るものがほぼない。後回しでOK。
最優先は迷わず①、レイテンシ、総処理時間共に大きいAPIです。これは「ユーザーが遅いと感じていて、かつインフラ負荷も高い」ので、UX改善とコスト削減の両方に効きます。最後が④で、これは触っても得るものがほぼないので後回しでよいです。
注意したいのが②と③で、この2つの優先順位はチームの状況によって逆転しうるということです。②(コスト)を優先するか③(UX)を優先するかは、機械的に決まるものではありません。
- インフラコストが経営課題になっている、サービス全体の負荷を下げたい → ②を優先(大量に呼ばれるAPIを削れば効果が大きい)
- ユーザーの離脱や体感速度が課題、対象が重要な画面の経路 → ③を優先(1人あたりの体験を直接改善できる)
つまり「②が常に上」でも「③が常に上」でもなく、今チームがUXとコストのどちらをより重視しているかで②と③は入れ替わります。①と④だけが固定で、間の優先順位は自分たちの目的に照らして判断してください。
③の例外:頻度の低さ ≠ 重要度の低さ
③(高レイテンシ・低総処理時間)は「たまにしか使われないAPIだから後回し」が基本ですが、ここには罠があります。総処理時間が小さいのは単に呼び出し回数が少ないだけで、そのAPIが重要でないとは限りません。
たとえばログイン・決済の確定・サインアップのような経路は、1日の呼び出し回数こそ少なくても、遅ければそのまま離脱・機会損失に直結します。なので③に分類されたAPIは、機械的に切り捨てる前に 「これは業務上クリティカルな経路ではないか?」 を一度確認することをおすすめします。
Datadogで改善するAPIを選んでみる
ここからは具体例としてDatadogを用いて、実際に改善するAPIを選定する様子を見せていきます。
Datadog > APM > serviceで、自分が関わっているAPIサーバーの情報を見ることができます(画像は承認チームのAPIサーバー)。ここにはレイテンシの指標となるp95 latencyとTotal Timeの両方の列があるので、まさに先ほどの2軸をそのまま確認できます。それぞれの列をクリックするとソートできるので、
- まず Total Timeで降順ソートして「サービス全体に効く候補」を把握し、
- その中でレイテンシも高いもの(=①領域)を最優先候補として選ぶ、
という流れで対象を絞り込めます。たとえば画像の一番下のAPIはp95が2.74秒でTotal TimeもAPI全体の上位5番目であり、①領域に該当したため今回はこれを改善対象に選びました。
まとめ
最後に、特に覚えてほしいことをまとめます。
- 改善対象は「レイテンシ(=UX)」と「総処理時間(=コスト)」の2軸で選ぶ(DatadogではレイテンシとTotalTimeで見られる)
- ①レイテンシ、総処理時間共に大きいAPIが最優先(UX・コスト両取り)
- レイテンシだけ大きく総処理時間が小さいAPIは基本後回し。ただし業務クリティカルな経路は例外
- ②(コスト)と③(UX)の優先順位は、チームが何を重視するかで入れ替わる
「レイテンシだけ見て、たまにしか使われないAPIを一生懸命速くしてしまう」——そんな悲しい事態を避けるために、ぜひ総処理時間も合わせて見て、価値の高い改善対象を選んでみてください。
アンドパッドではプロダクト開発だけでなく、技術的な関心・知識をもとに実際の開発・価値提供に繋げられるインターンも募集しています。 ぜひカジュアル面談や採用応募をご検討ください。
