Blog

性能問題は「どこが遅いか」より「なぜ遅くなる設計か」

• フロント：初回表示、操作応答、描画（CWV）
• API/バックエンド：DB/キャッシュ/外部I/O、N+1
• インフラ：スケール、コールドスタート、ネットワーク
• 運用：監視、SLO、性能退化の検知

性能改善の“王道パターン”

• 計測して、遅い経路（Top遅延）を特定する
• 原因を分類（CPU/IO/ロック/ネットワーク/描画）
• 効く順で直す（キャッシュ、クエリ、分割、圧縮）
• 再発防止（ゲート化、予算化）

つまり、“速くする”より“遅くならない仕組み”を作る仕事です。

よくある誤解（性能が治らない原因）

• 「圧縮すれば速くなる」→ △（根本がAPI/DBだと効かない）
• 「サーバー増やせば解決」→ △（設計負債は増える）
• 「負荷試験で十分」→ ❌（本番のRUMがないと外す）
• 「速さはエンジニアだけの責任」→ ❌（仕様と優先度の問題）

性能は、技術×仕様×運用の掛け算です。

① 指標設計・見える化（勝ち筋を作る）

• SLO/SLIの設定（レイテンシ、エラー率、稼働率）
• RUM/APM/ログ整備（遅延の“証拠”を取る）
• 性能予算（Performance Budget）の設定

② ボトルネック解析（原因を当てる）

• 分散トレーシングで遅い区間を特定
• DBクエリ解析（実行計画、インデックス）
• フロント解析（バンドル、レンダリング、画像）

③ 改善実装（最短で効く手を打つ）

• キャッシュ設計（CDN/アプリ/DB）
• API最適化（ページング、バッチ、N+1対策）
• フロント最適化（分割、遅延ロード、画像最適化）

④ 維持の仕組み（退化を止める）

• CIで性能チェック（Lighthouse/負荷試験の自動化）
• アラート設計（SLO違反、P95悪化）
• ポストモーテムと再発防止（ルール化）

例：P95レイテンシ悪化の対応

• 9:30：ダッシュボード確認（P95/CWV/SLO）
• 11:00：トレーシングで遅いAPI/SQLを特定
• 13:30：クエリ改善・キャッシュ設計・検証
• 16:00：負荷試験で再現→改善効果を確認
• 18:00：CIゲート追加（同じ退化を止める）

特徴：原因特定→最短改善→再発防止がセットです。

• 性能指標（SLO/CWV/レイテンシ）が決まっている
• RUM/APM/ログがあり、原因を追える
• 負荷試験や性能チェックがCIで回っている
• 性能退化が起きたら止められる（ゲート/アラート）
• 改善後に再発防止（ルール化）が残る

2つ以下なら、まず指標→計測→ゲートの順で整えるのが近道です。

必須になりやすい領域

• 指標理解（P95/P99、SLO、CWV）
• 観測（ログ/メトリクス/トレース）
• ボトルネック解析（CPU/IO/ロック/ネットワーク）
• DB/キャッシュ設計（インデックス、TTL、整合性）
• フロント最適化（バンドル、画像、レンダリング）
• CIゲート設計（性能退化の自動検知）

評価されやすいカテゴリ

• クラウド（監視・スケールの理解）
• ネットワーク/DB基礎（遅延の原因に直結）
• 運用/SRE系（SLO/障害対応）

ただし最強は、「P95を改善し、退化を止めた実績」です。

おすすめの順番（現実的ルート）

• 感覚ではなく、数値と証拠で話したい
• 原因究明が好き（推理・検証が苦にならない）
• 横断で改善するのが得意（フロント〜インフラ）
• “再発防止”までやり切れる

• パフォーマンス → SRE / プラットフォームエンジニア
• パフォーマンス → フロント/バックエンドアーキテクト
• パフォーマンス → テックリード / VPoE補佐
• パフォーマンス → DX/標準化推進