performance-engineering

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

目的

パフォーマンスエンジニアリングでは、負荷テスト、プロファイリング、最適化を行い、信頼性とスケーラビリティを備えたシステムを実現します。このスキルでは、適切なパフォーマンステスト手法（負荷、ストレス、ソーク、スパイク）の選択、ボトルネック（CPU、メモリ、I/O）を特定するプロファイリング手法、バックエンド API、データベース、フロントエンドアプリケーション向けの最適化戦略を提供します。

このスキルを使用すると、ローンチ前にシステムの処理能力を検証し、CI/CD パイプラインでパフォーマンスのリグレッションを検出し、プロファイリングによってボトルネックを特定して解消し、スタック全体でアプリケーションの応答性を最適化できます。

このスキルを使用するタイミング

よくあるきっかけ：

• 「API が想定されるトラフィックを処理できるか検証する」
• 「最大処理能力と限界点を見つける」
• 「アプリケーションが遅い原因を特定する」
• 「メモリリークやリソース枯渇を検出する」
• 「SEO のために Core Web Vitals を最適化する」
• 「CI/CD でパフォーマンステストを設定する」
• 「クラウドインフラのコストを削減する」

ユースケース：

• ローンチ前のキャパシティプランニングと負荷検証
• リファクタリング後のパフォーマンスリグレッションテスト
• 応答時間の遅延や高レイテンシの調査
• 長時間稼働するサービスでのメモリリークの検出
• データベースクエリのパフォーマンス最適化
• オートスケーリング設定の検証
• パフォーマンス SLO と予算の策定

パフォーマンステストの種類

負荷テスト

想定されるトラフィック量でのシステムの動作を検証します。

使用するタイミング： ローンチ前のキャパシティプランニング、リファクタリング後のリグレッションテスト、オートスケーリングの検証。

ストレステスト

システムの処理能力の限界と障害モードを特定します。

使用するタイミング： キャパシティプランニング、障害時の動作の把握、インフラの規模に関する判断。

ソークテスト

メモリリーク、リソース枯渇、時間経過に伴う性能劣化を特定します。

使用するタイミング： メモリリークの検出、接続プールのクリーンアップの検証、長時間実行されるバッチジョブのテスト。

スパイクテスト

トラフィックが急増したときのシステムの応答を検証します。

使用するタイミング： オートスケーリングの検証、イベント駆動型システム（製品ローンチなど）のテスト、レート制限の動作確認。

すばやく判断するためのフレームワーク

どのテストタイプを使用すべきですか？

What am I trying to learn?
├─ Can my system handle expected traffic? → LOAD TEST
├─ What's the maximum capacity? → STRESS TEST
├─ Will it stay stable over time? → SOAK TEST
└─ Can it handle traffic spikes? → SPIKE TEST

テストパターン、負荷シナリオ、結果の解釈について詳しくは、references/testing-types.md を参照してください。

負荷テストをすばやく始める

k6（JavaScript）

インストール：

brew install k6  # macOS
sudo apt-get install k6  # Linux

基本的な負荷テスト：

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 20 },
    { duration: '1m', target: 20 },
    { duration: '30s', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.get('https://api.example.com/products');
  check(res, {
    'status is 200': (r) => r.status === 200,
  });
  sleep(1);
}

実行： k6 run script.js

ストレス、ソーク、スパイクテストの例については、examples/k6/ を参照してください。

Locust（Python）

インストール：

pip install locust

基本的な負荷テスト：

from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
    wait_time = between(1, 3)
    host = "https://api.example.com"

    @task(3)
    def view_products(self):
        self.client.get("/products")

    @task(1)
    def view_product_detail(self):
        self.client.get("/products/123")

実行： locust -f locustfile.py --headless -u 100 -r 10 --run-time 10m

REST API のテストやデータ駆動型テストについては、examples/locust/ を参照してください。

プロファイリングをすばやく始める

プロファイリングを行うタイミング

症状	プロファイリングの種類	ツール
CPU 使用率が高い（>70%）	CPU プロファイリング	py-spy, pprof, DevTools
メモリが増加し続ける	メモリプロファイリング	memory_profiler, pprof heap
応答が遅く CPU 使用率が低い	I/O プロファイリング	クエリログ, pprof block

Python のプロファイリング

py-spy（本番環境でも安全に使用可能）：

pip install py-spy

# Profile running process
py-spy record -o profile.svg --pid <PID> --duration 30

# Top-like view
py-spy top --pid <PID>

メモリプロファイリング：

from memory_profiler import profile

@profile
def my_function():
    a = [1] * (10 ** 6)
    return a

# Run: python -m memory_profiler script.py

Go のプロファイリング

pprof（組み込み）：

import (
    "net/http"
    _ "net/http/pprof"
)

func main() {
    go func() {
        http.ListenAndServe("localhost:6060", nil)
    }()
    startApp()
}

プロファイルを取得：

# CPU profile (30 seconds)
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30

# Interactive analysis
(pprof) top
(pprof) web

TypeScript/JavaScript のプロファイリング

Chrome DevTools（ブラウザー/Node.js）：

Node.js：

node --inspect app.js
# Open chrome://inspect
# Performance tab → Record

clinic.js（Node.js）：

npm install -g clinic
clinic doctor -- node app.js

プロファイリングのワークフローと分析について詳しくは、references/profiling-guide.md と examples/profiling/ を参照してください。

最適化戦略

キャッシュ

キャッシュを使用するタイミング：

• 頻繁にクエリされるデータ（>100 req/min）
• データの鮮度に対する許容範囲（1 分を超える古さが許容される）

Redis の例：

import redis
r = redis.Redis()

def get_cached_data(key, fn, ttl=300):
    cached = r.get(key)
    if cached:
        return json.loads(cached)
    data = fn()
    r.setex(key, ttl, json.dumps(data))
    return data

データベースクエリの最適化

N+1 の防止：

# Bad: N+1 queries
users = User.query.all()
for user in users:
    print(user.orders)  # Separate query per user

# Good: Eager loading
users = User.query.options(joinedload(User.orders)).all()

インデックスの作成：

CREATE INDEX idx_users_email ON users(email);

API パフォーマンス

カーソルベースのページネーション：

app.get('/api/products', async (req, res) => {
  const { cursor, limit = 20 } = req.query;

  const products = await db.query(
    'SELECT * FROM products WHERE id > ? ORDER BY id LIMIT ?',
    [cursor || 0, limit]
  );

  res.json({
    data: products,
    next_cursor: products[products.length - 1]?.id,
  });
});

フロントエンドのパフォーマンス（Core Web Vitals）

主要な指標：

• LCP（Largest Contentful Paint）： < 2.5s
• INP（Interaction to Next Paint）： < 200ms
• CLS（Cumulative Layout Shift）： < 0.1

最適化手法：

• コード分割（遅延読み込み）
• 画像の最適化（WebP、レスポンシブ対応、遅延読み込み）
• 重要なリソースをプリロードする
• レンダリングをブロックするリソースを最小限に抑える

詳細な最適化戦略については、references/optimization-strategies.md と references/frontend-performance.md を参照してください。

パフォーマンス SLO

サービスタイプ別の推奨 SLO

サービスタイプ	p95 レイテンシ	p99 レイテンシ	可用性
ユーザー向け API	< 200ms	< 500ms	99.9%
内部 API	< 100ms	< 300ms	99.5%
データベースクエリ	< 50ms	< 100ms	99.99%
バックグラウンドジョブ	< 5s	< 10s	99%
リアルタイム API	< 50ms	< 100ms	99.95%

SLO の選定プロセス

1. ベースラインのパフォーマンスを測定する
2. ユーザーの期待を特定する
3. 達成可能な目標を設定する（ベースラインより 10～20% 改善）
4. システムの成熟に合わせて反復する

詳細な SLO フレームワークとパフォーマンス予算については、references/slo-framework.md を参照してください。

CI/CD 統合

パイプラインでのパフォーマンステスト

GitHub Actions の例：

name: Performance Tests

on:
  pull_request:
    branches: [main]

jobs:
  load-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install k6
        run: |
          curl https://github.com/grafana/k6/releases/download/v0.48.0/k6-v0.48.0-linux-amd64.tar.gz -L | tar xvz
          sudo mv k6-v0.48.0-linux-amd64/k6 /usr/local/bin/

      - name: Run load test
        run: k6 run tests/load/api-test.js

パフォーマンス予算：

// k6 test with thresholds (fail build if violated)
export const options = {
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

プロファイリングのワークフロー

標準的なプロセス：

1. 症状を確認する（CPU 使用率の高さ、メモリの増加、応答の遅さ）
2. ボトルネックを仮定する（CPU？ メモリ？ I/O？）
3. 仮説に基づいてプロファイリングの種類を選ぶ
4. 現実的な負荷のもとでプロファイラーを実行する
5. プロファイルを分析する（フレームグラフ、呼び出しツリー）
6. ホットスポットを特定する（リソースの 80% を使用する上位 20% の関数）
7. ボトルネックを最適化する
8. 再度プロファイリングを行い、改善を検証する

ベストプラクティス：

• 現実的な負荷のもとでプロファイリングする（アイドル状態のシステムではなく）
• 本番環境ではサンプリングプロファイラー（py-spy、pprof）を使用する（オーバーヘッドが小さい）
• ホットパスに注力する（最も大きなボトルネックから最適化する）
• 最適化の前後を比較して検証する

ツールの推奨

負荷テスト

第一候補：k6（JavaScript ベース、Grafana 対応）

• モダンなアーキテクチャ、クラウドネイティブ
• JavaScript DSL（ES6 以降）
• Grafana/Prometheus との統合
• マルチプロトコル対応（HTTP/1.1、HTTP/2、WebSocket、gRPC）

使用する場面： モダンな API、マイクロサービス、CI/CD 統合。

代替：Locust（Python ベース）

• Python ネイティブ（Python でテストを記述）
• リアルタイム監視用の Web UI
• 複雑なユーザーシナリオにも柔軟に対応

使用する場面： Python を多用するチーム、複雑なユーザーフロー。

プロファイリング

Python：

• py-spy（サンプリング、本番環境で安全）
• cProfile（決定論的、詳細）
• memory_profiler（メモリリークの検出）

Go：

• pprof（組み込み、CPU／ヒープ／ゴルーチン／ブロックのプロファイリング）

TypeScript/JavaScript：

• Chrome DevTools（ブラウザー／Node.js）
• clinic.js（Node.js のパフォーマンススイート）

ツールの詳細な比較については、references/testing-types.md と references/profiling-guide.md を参照してください。

参考ドキュメント

詳細ガイド：

• references/testing-types.md - 負荷、ストレス、長時間、スパイクの各テストパターン
• references/profiling-guide.md - 各言語での CPU、メモリ、I/O のプロファイリング
• references/optimization-strategies.md - キャッシュ、データベース、API の最適化
• references/frontend-performance.md - Core Web Vitals、バンドルの最適化
• references/slo-framework.md - SLO、パフォーマンス予算の設定
• references/benchmarking.md - ベンチマークのベストプラクティス

例：

• examples/k6/ - 負荷、ストレス、長時間、スパイクの各テスト
• examples/locust/ - Python ベースの負荷テスト
• examples/profiling/ - プロファイリングの例（Python、Go、TypeScript）
• examples/optimization/ - キャッシュ、クエリ、API の最適化

関連スキル

包括的なテスト戦略については、testing-strategies スキルを参照してください。

CI/CD 統合パターンについては、building-ci-pipelines スキルを参照してください。

負荷テストに基づくインフラストラクチャのサイジングについては、infrastructure-as-code スキルを参照してください。

Kubernetes のパフォーマンステストについては、kubernetes-operations スキルを参照してください。