specsfy-specialist-performance-engineering

パフォーマンスエンジニアリング

使う場面

• 遅延、スループットの低下、リソースの過剰な使用、バンドルサイズの肥大化、または予想されるピークに対応できるかどうかの懸念が報告された場合に呼び出します。
• すでに提案されている最適化を見直し、測定済みのベースラインと仮説に基づいているのか、単なる直感なのかを確認する場合にも呼び出します。
• 本番環境のメトリクス／アラートの仕組み自体を設計する場合には呼び出しません。その場合は $specsfy-specialist-observability を使用してください。ここでは、すでに観測または疑われている特定のパフォーマンス問題の診断と解決に焦点を当てます。
• ボトルネックがクエリ／インデックスにある場合は $specsfy-specialist-postgres と、修正にパイプライン内の自動ガードレールが必要な場合は $specsfy-specialist-delivery-engineering と連携します。

フロー

1. コードに手を加える前に、ジャーニー、メトリクス、目標パーセンタイル、予想負荷、パフォーマンス予算を定義します。
2. 代表的な環境とデータ量で問題を再現します。ごく小さな開発用データセットを使って診断することは避けてください。
3. 現在のベースラインを測定し、どこで時間が費やされているかを把握するため、境界（クライアント、ネットワーク、アプリケーション、データベース、外部依存先）ごとに時間を分解します。
4. 具体的な仮説を立て、特定した境界に適したプロファイラー／トレースを使用します。一般的な最適化を当てずっぽうで試すのは避けてください。
5. 関連する要因を一度に1つだけ変更し、ベースラインと同じ条件で再度測定します。
6. 実際の負荷、タイムアウト、リトライの下でも修正によって正確性が保たれることをテストします。並行処理時に破綻する最適化は、最適化とは言えません。
7. パフォーマンス回帰テストやパイプライン内の予算などのガードレールを作成し、回帰を見逃したまま再発するのを防ぎます。

パターン

• 平均値だけではなく、パーセンタイル（p50、p95、p99）と分布全体を使用します。平均値では、実際のユーザー体験に最も大きく影響するロングテールが見えません。
• 最適化箇所を決める前に、クライアント、ネットワーク、アプリケーション、データベース、外部依存先の各レイテンシを明確に分けます。
• キャッシュが空の状態と温まった状態の両方を、単独のリクエストだけではなく実際の並行処理条件下でも測定します。
• キャッシュなしの経路のコストを確認し、無効化戦略を定義する前にキャッシュ層を追加しないでください。その確認なしに追加されたキャッシュは、古いデータに関するバグの最も一般的な原因です。
• 負荷、タイムアウト、リトライの下で正確性を保ちます。平均レイテンシを下げても、競合状態やリトライの喪失を引き起こす最適化は許容できません。
• オブザーバー効果（プロファイラーや計測自体が測定結果に影響すること）を管理し、JIT、ディスクキャッシュ、接続プールを測定する前にウォームアップを確実に行います。
• 現在観測されるトラフィックの平均ではなく、実際に予想されるピークシナリオに基づいて容量とヘッドルームを定義します。

反パターン

• 測定済みのベースラインなしに「遅そう」という理由だけで最適化すること。変更前後の数値がなければ、改善したのか、効果がなかったのか、別のパーセンタイルで悪化したのかを判断できません。
• ボトルネックの実際の境界を特定せずに、症状を解決するためにインデックス、キャッシュ、並列処理を追加すること。テスト環境で測定された症状は解決しても、本番環境では効果がない、または認識されるレイテンシを下げないままボトルネックを別の場所に移すだけになることがあります。
• 同じ負荷下で同じパーセンタイル分布を比較せず、2つのバージョンの平均値を比較すること。平均値の改善によって、p99のロングテールが悪化したことが隠れる場合があります。
• N+1クエリ、並列化できる直列の呼び出し、避けられるネットワークのラウンドトリップを調べる前に、ハードウェアやレプリカを増やすこと。ウェブシステムの遅延で最も一般的な原因は、CPU不足ではなくラウンドトリップの過剰です。

検証

• 将来の比較に向けて、ベースラインをアーカイブした再現可能なベンチマーク（非公式なメモだけでは不十分です）。
• 汎用プロファイラーを「念のため」使うのではなく、分解ステップで得られた根拠に応じて、CPU、メモリ、I/O、またはクエリをプロファイリングします。
• 明確な成功基準（目標負荷における目標パーセンタイル）と、テスト中に実際の本番環境へ影響を与えない安全な上限を定めた負荷テストを実施します。
• メトリクスの過去の安定性に応じた感度で、パイプライン内で自動的に回帰を検知します。ノイズの多いメトリクスには、誤検知が頻発しないよう、より大きな許容幅が必要です。
• 同じ条件での変更前後のベースラインなしに、「高速化した」と宣言しないでください。「速くなったように見える」は根拠になりません。

関連するスキル

• $specsfy-specialist-astro と $specsfy-specialist-nextjs は、計測によってボトルネックが特定された後に、フレームワークの予算設定と修正を行います。
• $specsfy-specialist-debugging は、負荷時に発生する機能上の不具合を切り分け、最適化の余地と混同しないようにします。
• $specsfy-specialist-software-architecture は、局所的な実装ではなく境界が処理能力を制限している場合に、構造的な変更を扱います。
• $specsfy-specialist-web-api-design は、スループットとレイテンシーの最適化中も、再試行、ページネーション、契約を維持します。
• $specsfy-specialist-observability は、本番環境での劣化をインシデントになる前に検知するシグナルの仕組みを構築します。
• 特定されたボトルネックがクエリ、インデックス、またはキャッシュ戦略にある場合は、$specsfy-specialist-postgres と $specsfy-specialist-redis を使用します。
• $specsfy-specialist-delivery-engineering は、パフォーマンスのガードレールをパイプラインの自動ゲートに変換します。

Web Vitals、ベンチマーク手法、負荷テスト、プロファイリング、パフォーマンス予算については、公式情報源を掲載した references/standards.md をご覧ください。